So does that mean that we should not do them? Not necessarily. But we should maybe re-think what we use them for. And I know that some companies are doing that already.
My first thought is that we need to change the mindset that lessons learned are done at the end of the project. If we instead do lessons learned at major milestones and at the end of project phases, then we can actually take advantage of those lessons on the very project we are working on. When we find out that our status meetings are too long and boring and irrelevant for some stakeholders we have a chance to improve them. And when we see that our change control process is being ignored we can educate and enforce for the rest of the project.
Secondly, we should use the lessons learned to improve our processes, training programs, checklists and templates. So when we realize that we did not adequately capture the customer’s requirements for performance, security, and ease of use, we can then add questions in those areas to our standard questionnaires. And when we realize that our use cases are too detailed and overlapping and we have too many of them, we can provide training and templates in order to improve future efforts.
Thirdly, we should accept that lessons learned may be primarily for ourselves, not to repeat mistakes in the future and the documentation needs to focus on that.
So skip the excessively large lessons learned documents. Do not create the complicated databases where nobody can find or extract any useful information. Those efforts discourage lessons learned since they take work and it is hard to see the value. Sometimes it is great to remember KISS (Keep It Simple, Stupid). After all, a lesson learned in the hand (or head) is worth 10 in the archive.
What do you think? If any of you have good working examples, please share them with the rest of us.
Don’t forget to leave your comments below