I’d bet that everyone reading this article will have taken part in some kind of “lessons learned” meeting or brainstorm at some time in their career. These sessions are often part of a retrospective or post-project review, and are aimed at ensuring that organisations and project teams consider what went well – and also what went badly. The idea is simple: these lessons and pointers can be taken into account in future projects, iterations or phases. This should ensure that future activities run as smoothly as possible.
However, it doesn’t always seem to work this way. I was speaking with a contact of mine just the other day, who observed that in some organisations, the “Lessons Learned” process should really be called “Lessons Documented”. He implied (only half-jokingly) that in some companies, learning points get written down but then fester in a document that isn’t ever read again. The document might be loaded into a repository somewhere, but even if somebody wanted to read it, after six months everyone has probably forgotten where it is stored and what it contains. The whole process becomes about ticking boxes on a plan rather than driving genuine insight and change.
This observation really resonated with me, and I felt he’d hit the nail on the head. If we’re honest we’ve probably all seen this pattern occur. When running projects, there is the opportunity to capture valuable insight and data – everything from data about the amount of effort spent right through to insight about the issues that occurred and the problems that could have been avoided. The challenge is that by the time the project is finished, everyone is tired and ready to move onto the next big thing. Sadly, this might mean that rich insight is lost.