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
Pingback: New PM Articles for the Week of February 12 – February 18 - The Practicing IT Project Manager