The idea of lessons learned has been around for a long time in engineering and project management circles, so much so that it in many companies, it’s just another box to be ticked in a project closeout checklist. Lessons learned spreadsheets and databases abound in servers and hard drives all over the world, the lessons entered in once and invariably never looked at again. Now that the latest ISO 9001:2015 has a requirement explicitly mentioning lessons learned, it will no doubt be seen by many as just another administrative burden.
I think it’s a shame that lessons learned have largely been relegated to the level of annoying afterthought (unless of course someone insists on it being done properly). Even if they are filled in seriously, how many companies systematically work through their lessons learned registers and actually try to feed these back into their processes and systems? I suspect only a few.
I’d argue that this is because the usual implementation of the lessons learned process (e.g. formal “post-mortem” sessions at project closeout stage) is contrived and lacks time criticality, agency and feedback mechanisms. In other words, it goes against what we know about how people actually learn lessons.
For most of us, a lesson is learned at the moment we are aware of a mistake or poor decision. This also coincides with the moment our motivation is highest to fix the mistake and prevent similar errors in future. With the agency to do so, we can capture these lessons and identify mitigating measures at the point of discovery. Finally, instituting a feedback loop would test whether the lessons have been truly learned or not.
But think about how the typical lessons learned workshop is implemented. At this point, the project is pretty much over, mistakes that were made during the project are fading memories and most people in the project team just want to move on. Participants will cynically go through the motions of the workshop, disempowered and not once believing that their suggestions will ever be implemented in any meaningful way. Occasionally, there will be a brilliant idea, but it will most likely be lost in a rehash of the same “lessons” that have been learned from projects dating back to antiquity, e.g. we must communicate better with the client and clarify our assumptions up front.
If the lessons are stored in a centralised database, months may go by before anyone looks and sorts through it (if at all). The majority of lessons will be tossed in the “too hard” or “too vague” basket, and perhaps a few are actually implemented. If a lesson learned is actually implemented, is feedback provided to the people who suggested it? Is the implementation monitored and evaluated to see if it actually solves the problem and doesn’t introduce new ones?
A distinction should also be made between lessons that can be addressed through tweaking processes and workflows (e.g. communication channels between the client and project team), and purely technical lessons (e.g. specific design errors or unintended consequences from a technical decision). The implications of technical errors are obvious, but these lessons are the most difficult to systematically capture and implement from a lessons learned workshop because such workshops are biased towards adjustments in processes and systems. What normally happens is that the engineers involved will personally learn their lessons, but the new knowledge / experience gained will remain privately held and not disseminated to the broader organisation.
Ultimately, the lessons learned concept is a bit like socialism – a good idea in theory, but almost always a failure in practice.