Valuing “Institutional” Knowledge

It seems to me that institutional knowledge (IK) is like common sense. Much as there is rarely anything ‘common’ about common sense so is there rarely anything remotely ‘institutional’ about institutional knowledge. Most often, IK is the province of your more rabid ivory-tower, b-school types who use IK as an excuse to justify chairing more meetings or your application development guys, who think that storing all the emails on a project, most of the presentations, and some versions of the code is IK. It’s neither.

At its best IK acts like a corporate research library devoted to the policies, practices, products and history of an organization. It is accessible, germane, trusted and utilized. It is the corporate memory and a reflection of how the institution thinks and solves problems.

As a new generation of collaboration tools begins to roll-out (Google Wave , Sharepoint 2010 and others) there’s the usual buzz going around about how these tools will allow companies to better leverage IK on projects and usher in a new age of business productivity. (cue: images of sunrise, fanfare, children playing, etc.) While it’s true that these apps may represent the latest and greatest in collaboration tools the limiting factor on their benefit to your company is likely…wait for it…your company.

You see, I think IK has value only if your company is organized around some basic precepts:

  • a company CAN learn from internal history
  • failure has value
  • success needs formal review too
  • project administration is important

If your organization doesn’t share and prioritize…institutionalize…these precepts then whatever is preserved by collaboration software will likely be wasted.

These four precepts interact with IK in some very basic and important ways. Our tendency to emphasize the differences in today’s marketplace from previous ones gives no credence to the fact that consumers (i.e. the people with the money) behave very similarly today as they did 30 years ago. Good ideas need to be remembered and periodically reviewed so that when business conditions change, they can be implemented. If your company doesn’t respect the ideation of those who went before IK tools won’t likely do as much for you as they could.

Now, in my experience, when a brilliant idea fails it’s proud-parent is rarely called upon to give a formal write-up as to why everything went South – in fact the brave soul is usually shunned, marginalized, and if the flop was big enough, rapidly terminated. This is a great way to waste IK. All of the research, documentation, assumptions, presentations, etc. should be handed over to a corporate curator, packaged, cataloged and interred in a corporate archive. The key decision-makers should be interviewed and their learnings recorded. The company spent money, usually millions, on this project and it doesn’t even want to give the project a formal burial. It’s a lost opportunity.

However, what is worse in my opinion, is when a company has a breakout success, fails to understand fully why it happened, and blithely assumes that its success was due to its brilliance rather than the marketplace. If you do not capture the IK on why something worked it can be as risky as avoiding something because it failed once.

Last, project administration; the note-taking; the meetings; the emails; the documentation; more meetings; the uploading; the versioning – project administration amounts to discipline. This is vital to utilizing IK in the future and is probably the least respected component of a successful company. Don’t confuse time worked, emails sent, presentations produced, meetings scheduled, etc. with project administration, what I refer to here is the lost art of taking all the dross of a project; filtering it to understand what happened; annotating when and why decisions were made; preserving and editing the notes…and throwing the rest away. Editing is important to the successful application of IK to new situations. If someone has to sort through a mess to learn something then not only is their time wasted but so it the effort and expense that went into collecting and storing it.

With the advent of a generational shift in collaboration tools, we are undoubtedly on the verge of a new era of workplace productivity (again). This time, when you are considering new collaboration tools give some thought to the way that you collaborate.

• Does the organization have an institutionalized approach to collaboration or are you just posting individual efforts to a glorified bulletin board?
• Are you preserving the hard-fought lessons that you are learning in a rough economy or are you just filling up space on a server and calling it productivity?

Design Discussion: Look-Feel, IA, Content Layout

Look / Feel

  • Colors
  • Type faces
Temporary Eyesore | Constuction Fence
Creative Commons License photo credit: EVERYDAYLIFEMODERN
Temporary Eyesore | Constuction Fence
Creative Commons License photo credit: EVERYDAYLIFEMODERN

Info Arch

  • Layout
  • Design
  • Navigation

world's fastest
Creative Commons License photo credit: dchou0123


  • specific modules
  • placement / priority / emphasis

Creative Commons License photo credit: TheArtGuy

It’s difficult to process all of these at once; you can run the danger of allowing shortcomings in one area overshadow Good Things in other areas.

While the end-product – the Designed Page – needs also to be reviewed as a whole, it can make good sense to break out these items individually and rate the works by them.

This should help with internal review processes and discussions as well as feedback for vendor partners doing IA and Design with you.

Managing Expectations in Project Timelines (with FAQ)

As we’ve delivered products through the years, managing timelines – and stakeholders’ perceptions thereof – has been an interesting source of teachable moments.

The snarky note below was for a core team-only. The tone in it is not recommended for general stakeholders. The FAQ covers two main recurring points; additional contributions would be great – please send them.

Our April 11th due date for Final Design approval and sign off is now missed by at least 20 days. None of the later milestones, therefore, were hit. Everyone should understand that the other dates – Production, Coding, Integration, Testing, Launch – move out accordingly.  Even so, I don’t want to presume this understanding is there throughout the rest of our extended team, so I’d like to send a new timeline out to everyone. I’d also like your help in backing me up and reïterating this message. 

I have some FAQs prepared that I can send (e.g. “Q: But you said Launch was May 15! How can it not be May 15!?”; “Q: But this latest design is so much like the existing design! Doesn’t that mean it’s really easy to put in place”)

Thanks, and please let me know if you’ve got feedback for me before I circulate our new timelines for this relaunch.

The Team

Btw –

A: Because of the relatively fixed nature of the space / time continuum, moving one point affects the other points in a directly-proportional ratio
A. No – it’s still a design job that requires Design, production and coding that needs to happen with the same resources we have in place today.

Corollary: “Q: So, can’t we get some more help to speed it up? More designers, Producers and coders to still hit our date two whole weeks from now?”
A: Sorry, but no. Especially in such tight timeframes, adding additional resources does not automatically mean our time-to-market improves. Getting external resources up to speed could help in a longer-term project, but not one that’s expected in just a few weeks. A re-launch project like this is like giving birth to a new life. Giving birth takes about nine months for humans. Adding additional resources to the pregnancy will not speed up the birth.