Corporate memory - the hard way

The dream:

One of the central themes of KM is the design, building and maintenance of an effective 'corporate memory', a repository, a dare I say it, knowledge-base. Here the intellectual jewels of the organization will reside, easily accessible, expertly indexed, intuitively browseable. Here experts and novices will come for self-help knowledge, they will find the correct solution quickly, be able to apply the solutions with confidence, and learn from the 'collective experience of the organization'.

There is only one problem! this is a real dream. Many dollars have been invested, many organizations have egg on their collective faces, many repositories lie unused, shunned by novices and experts alike and yet there are more KM projects starting each day with the same vision / mission and yet another dream. Perhaps we think portals or automatic profiling or collaborative systems or social software will do it this time!

Where did we go wrong?

Knowledge vs. information:
We failed to clearly appreciate and understand that we were storing information, that context is key, content without community is not king, feedback, critique, continual validation and annotation is everything, information has a social side, knowledge flows via relationships not via access to static content.

Shared space:
We did not design for dialog, we built a vault to secure objects, when we badly needed a place to support relationships. We indexed, clustered and classified the content, when we really needed to point to people, we imposed order, when we should have co-designed, permitted emergence and shared the meaning, we had workflow and access rights, when we needed empathy, support, evangelism and interaction.

A hollow collection:
We discovered.
1) Collecting information is a breeze, even elicitation of rules and personal heuristics, [if we even thought that far], is the easy part, getting people to trust, apply & use 'strange' knowledge from others, is the major concern.

2) Knowledge emerges over time, it requires an environment of trust, a shared language, a familiarity, strong validation from colleagues you trust and lives in a community not in static text.

3) Knowledge to be used, requires understanding of context, rationale, implications, limitations and continual testing. Knowledge is fragile, it lives in the stories & spaces between individuals and communities, not in a database or entirely in a set of rules or collection of examples, or in policies or processes.

4) Knowledge changes, what you elicit the first time is likely to alter as individuals and groups validate, connect and use it, we were not prepared for unending cycles, we did not focus on reciprocity and
feedback.

5) You will not get real quality knowledge without trust, strong critique, deep dialog, open communications. If you do not elicit with an appreciation of maintaining the identity of the group / indivdual, you will only get shallow stuff.

6) Knowledge comes in many forms, we did not decide carefully what type of knowledge we wanted (knowledge of customers, of procedures, of policies, of strategy, of competitors, knowledge of best practices, knowledge from failures (the hardest to get, the most valuable?), knowledge of people - relationships, tips, tricks, short cuts, 'good' solutions, heuristics......)

7) The best elicitation is driven by dialog & quality questions, to get to the really good stuff, you need to have strong relationships and almost equally deep domain understanding, otherwise the gems get lost. We thought this was a library (organising and catalog) function.

8) Knowledge acquisition is NOT extracting concepts from documents, clustering objects, mining transactions. No system or tool can do it for you! we fell into the knowledge 'harvesting' trap along with others:

http://www.nelh.nhs.uk/knowledge_management/km2/harvesting_toolkit.asp
http://www.intelligentkm.com/feature/feat1.shtml
http://www.noweco.com/cerebe.htm
http://www.teximus.com/ProductFeatureCategory.jsp?instId=200&lang=en

Have we really learned anything yet????

Comments

[David Locke]

This is the idea that killed expert systems being recycled.

Employers pay for my expertise. If they want to pay me consulting rates or pay for an annuity that keeps me living for the next 50 years, I'll leave them the current methodology. But, it won't be very meaningful a few weeks down the road.

Take for instance today. I came across the notion of using blogs for internal engineering documentation. That changes a hell of a lot. And, right this minute, the idea went one step further. That's how it goes. No standing still ever. And, no catching up if you are my employer.

[Hero]

Innouncement!!!

[Tom Grey]

1) You cannot store the attributes of a relationship.
2) No amount of info about the past is an accurate guide to the future.
3) What managers want is a reliable what if model: if I do A, I get result X; if I do B, I get result Y. But the future is not reliable.

[Please test your right sidebar, I miss the left half of it.]