This website covers topics on knowledge management, personal effectiveness, theory of constraints, amongst other topics. Opinions expressed here are strictly those of the owner, Jack Vinson, and those of the commenters.

Not interested in learning a lesson

Three Monkeys- See no Evil, Hear no Evil, Speak no Evil, Takahashi Haruka, 1932If you don't learn from your mistakes, you are doomed to repeat them.  If you don't learn from your successes, you can hardly improve upon them.

I came across Todd William's Back from the Red blog via his post, Kill the Postmortem.  He hasn't seen much value in "lessons learned" activities:

The primary reason the postmortem's fail is lack of executive commitment. Without the organization's management being behind the spirit of the retrospective and implementing the suggested changes, they are a waste of time. The event becomes drudgery. Attendees thoughtlessly answer questions while texting their friends or thinking about other tasks they have to perform.

Todd's more detailed reasons for why these things don't work are excellent examples of people (management) with their fingers in their ears, yelling, "La, La, La.  I can't hear you."*  If you are in a culture where people don't want to really know what happened, then there is no point doing them.

"Lessons learned" efforts are one of many types of things that are categorized as knowledge management.  In lessons learned, the idea (or hope) is that the organization should learn from its past mistakes and successes, repeating the good things and eliminating the mistakes next time.  But it takes much more than simply holding a postmortem at the end of an effort to make these things work.  The reference I still use today is Collison and Parcell's Learning to Fly, which talks about using knowledge about past efforts to guide the future: learn before; learn during; learn after.  This has to be something that the whole organization wants, not just some good idea and box-checking exercise.

What else can work?  In a project environment: Rather than looking at all the things that have gone wrong in a project, why not only worry about those things that have actually caused damage to the project?  In any project environment, there will be variability and things that go awry.  But not all of those things will cause serious damage to the project.  You need a mechanism for recording the issue at the time of the occurrence and then regularly reviewing the types of problems that cause the greatest impact across many projects.  Address those problems, and you should improve the entire functioning of your project environment.  Rinse and repeat.

* "La, la, la. I can't hear you" or "La, la, la.  I'm not listening." is from a TV show,  I think.  But it's so embedded in our culture that any references to  it are more recent references to the phrase on T-shirts, music videos and the like.

[Photo: "See no Evil, Hear no Evil, Speak no Evil, Takahashi Haruka, 1932" by electrons fishgils]

Blinding me with information

Trust is always important