Tuesday, May 01, 2007

Lessons Learned




I sometimes wish that Lt. Columbo was real. Then I could hire him to be part of my KM team. He was great at asking questions (plus he'd make me look like a snappy dresser). The kind of questions that could unpick a murder's alibi like a badly darned sock. "Ma'am, there's just this one thing that's been bothering me. Maybe you could help me out..." And that would be it. The series itself was anti-whodunnit. You knew in advance what was going on. The pleasure came in the remorselessness with which the dogged detective worked out what had really gone on. Which is a great place to start talking about Lessons Learned programs.

So organisations do stuff again & again (see previous post about the importance of recurring events). Sometimes they do it well. And sometimes they do it badly. And they want to get better at it. Shawn's third diagram (Plan -> Act -> Reflect -> Learn -> Plan) captures this desire well. Mostly people plan then act then plan again. The idea of stopping to reflect is viewed as inefficient. Of course, the cost of not reflecting & learning can be high. So there has been a recent discussion on ACT-KM about lessons learned. If you want to find out what was said by Dave Snowden, Patrick Lambe, Toby Cooper, Han van Loon, Alan Dyer, Cory Banks, Gemma Smyth & Allan Crawford then you're going to have to sign up & join. For now, I will make 2 observations:

1. The learning cycle needs to run at different scales. We as individuals need to reflect on our actions & learn from them. Teams need to do this (preferably during a project as well as after). And whole organisations need to do this. The questions can be simple:

i. What went well
ii. What could be improved
iii. What we will do next time

Or

i. What was supposed to happen?
ii. What actually happened?
iii. Why were there differences?
vi. What can we do different right now?

It is vital to note that a lesson is only learned when we do something differently the next time.

2. I remember once being a in meeting where we were discussing collecting key lessons learned around project management best practice.

"So we just need to collect the gems."
"Can you specify what a gem would be?"
"You know, the gems."
"Can you give me an example of a gem?"
"Er..."

This went on for about half an hour. Needless to say, nothing came of this exercise. People know a gem when they see it. And beauty is in the eye of the beholder.

Now we often have to dig for gems. And the importance of questioning in these activities becomes obvious:
"Why was the project a success?"
"We had a great team" -> What successful project doesn't have a great team? How was this team different to normal?
"We followed the project plan" -> Beware of this one. It's possible but rarely true.
"We communicated with the client" -> Ah, we have employees with the gift of speech (our hiring policy must be improving). Now how did you communicate with the client?

The 5 Whys are very useful here. And the good Lt. wouldn't go amiss either.