Hans Jonasson, PMP, CBAP, founder of JTC Unlimited, has over 25 years of experience in the areas of project management, business analysis and professional development Lessons learned must be one of the biggest time wasters in the discipline of project management. Most organizations do them to some extent. Most of the time nobody looks at them after the project is done. But still we keep trying to persuade people to do them. What do we expect? That they will learn from history? A wise man said (Churchill? Not sure), “The only thing we ever learned from history is that we never learn from history”.
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
written by Tim Eiler, March 17, 2010
If you're the PM or Scrum Master, write down the lessons learned and build a loose system of accountability through reminder.
-
- +0
-
-
written by Gareth Byatt, March 22, 2010
It is also important to take the time to talk to your peers at the start of a project in order to learn lessons that are valid to you for your project. Face to face is best, but in today's global world this often needs to be done by phone.
-
- +0
-
-
You’re also correct in the various uses you suggest for lessons learned and the importance of applying lessons during the project, not just on the next project. There’s nothing in the current models to prevent this.
The problem is that nobody in most project organizations takes personal responsibility for making improvements, especially in the overall processes. For example, people routinely are sent to training and then not given the opportunity to use what they’ve learned. Reducing lessons learned to the top three won’t change the fact that nobody in the organization acts upon them.
There are organizations where people do learn and act upon their lessons. These are called organizations that eat your lunch. By the way, look at any successful football coach; and you’ll see someone who’s learning moment to moment, at halftime, and for the next game. That’s also why they get paid millions of dollars and most project workers don’t.