Have we learned anything?

 

In a recent role, I had the opportunity to review the lessons submitted by teams running large, complex projects and programs and found that over 90% of what was being captured and shared was of low or no value.

Back in April 2009, I published my very first blog article titled "Lessons Learned; Avoid the Oxymoron".  Since that time, I've gained a broader appreciation of the multiple challenges organizations face when trying to get sustainable, reusable knowledge out of projects and felt it was time to put a capstone on my writing about this specific topic.

So what have I learned about lessons over the past decade?

Patterns

• Frequent identification - either on a fixed cadence such as in a sprint ending retrospective or just-in-time based on a team's recognition that there is something of value to be captured and shared.
• Scrubbing and distillation - lessons are like a diamond hiding within a drab rock. Someone needs to take the time to harvest reusable knowledge from a raw lesson. This is not simple because stripping out too much specificity will result in a generic, low value outcome, but leaving in too much contextual detail will make it hard for a reviewer to decide whether it is applicable to their project or not.
• Category-driven response - depending on whether a lesson is a reminder, an organizational blocker or true knowledge, its deposition will be quite different. Reminders might be a call for more training or guidance whereas blockers should be escalated to an appropriate owner.
• Context-based guidance - rather than poring over hundreds of lessons spanning a project's lifecycle, it is helpful if a reviewer can be presented with a subset of lessons applicable to where they are in a project.
• Likes and dislikes - give reviewers the ability to like or dislike lessons. Let the free market decide which are truly useful and should be retained and those which can be safely purged.
• Regular incorporation into standards - instead of leaving it up to an individual to decide whether a particular lesson should be followed or not, those which are applicable in most cases should be baked into your templates, standards and policies.

Anti-patterns

• Lesson suppression - sometimes the most valuable lessons are those which weren't shared. A good PM must provide a safe environment and approach to help stakeholders be open about sharing the good, the bad and the ugly.
• Finger pointing - PMs need to ensure that lessons learned sessions don't turn into the blame game.
• Going through the motions - a risk of capturing lessons frequently is that the activity becomes mechanical and produces little value. Team members should have the confidence to cancel a session if there is nothing of value to be shared.
• Superficial parroting - as with requirements, the value of lessons comes from their analysis, not just regurgitation.

"The only real mistake is the one from which we learn nothing" - Henry Ford