KM Autopsies

Even the best knowledge manager in the world has at least one project that flamed out spectacularly. But how many knowledge managers have conducted an autopsy to find the cause of death?

By autopsy, I don't mean simply keeping a list of user complaints. What I have in mind is actually cutting the project open, digging around its inner organs and comparing them to the inner organs of a healthy, functioning KM project. (Sorry for the mixed metaphors.)

So what might a KM autopsy involve? A thorough examination along the following lines:

1. Did the project end up as you expected? If not, check your premises. Did you start with the wrong assumptions? Or were correct assumptions translated into the wrong objectives?

2. If you had the right objectives, did you bungle the execution? Where did you go wrong?

3. If you built it in conformity with sensible specifications, was there a problem with the roll-out?

4. Did your project require significant user training?

5. Did you provide all the necessary support for change management?

6. Is the rate of user adoption appropriate given the investment in the project?

Once you've completed this examination, you should have a clearer picture of the cause (or causes) of death. In medicine, the pathologist can stop right there unless the death in question is a criminal matter. In knowledge management, the death of a project is a criminal matter. So you have to push the analysis further -- not to identify the culprit, but rather to understand what needs to happen differently next time to avoid another dead project. In KM, some of the most valuable knowledge we have to manage is the knowledge we gain about our own processes. That's why we need to conduct KM autopsies.