I often wonder just how much project management organisations really learn from project successes and mistakes. I think we could all definitely learn better than we currently do.
I will start by saying that we should not wait until the end of the project to learn lessons (both good and bad) – these will be happening all the way throughout the project and should be logged as they happen. Completion of a Stage (including the final one at the end of the project) present a convenient time to review lessons and take action (including communicating the lessons to the wider project community), but waiting until the end of the project to even identify the lessons represents a missed opportunity for continuous improvement. Having said that, the end of the project is where projects usually consider lessons learned (if they do this at all), in the form of a post-implementation review.
In my portfolio management office (PfMO) experience I have seen post-implementation reviews come up with the same lessons again and again (e.g. build contingency into plans; take more time and care to gather requirements; don’t Go Live without full sign off / back-out plans / user training, etc.), but I have seen even more examples where post-implementation reviews weren’t carried out at all because: the project was too small / too simple; the project finished too long ago / hasn’t finished yet; I don’t have the time; the project team is now working on something else / has all left the company; nothing happens with Lessons Learned anyway; I don’t think it’s worth the effort (delete as applicable!).
I think the PMO can help with Lessons Learned, and that the problems lie not only with identifying the lessons, but also with what to do with the lessons that have been identified to embed the learning into the organisation’s experience and memory. Here are some ways that the PMO can help, to make sure the Lessons are not only learned but also acted on:
- The PMO can add the lessons to the corporate PM methodology.
Done well, robust PM processes and methodologies form part of an organisation’s corporate memory, and are built making intelligent use of the lessons the organisation has learned from previous projects. They are aimed at preventing the repetition of past mistakes without unnecessarily impeding delivery. But the more you add to the methodology, the more rigid and prescriptive it becomes, and the more likely it is to either be cheerfully ignored or blindly implemented in full (and you can bet it will be ignored on the big risky projects and implemented in full on the little simple ones!). The PMO should also avoid becoming the methodology police.
- The PMO could collect the lessons identified in a Big Database
…but to be useful this relies on someone (PMs? the PMO?) reviewing new projects against all the lessons in the database, and identifying relevant points to note.
- The PMO could add the lessons to a checklist
…but that relies on people (PMs)using the checklist and giving some serious consideration to what the items on the checklist represent (rather than just paying lip service and ticking the box). And there will always be the temptation for PMs to come up with a good reason why a checklist item doesn’t apply to the current project…
- The PMO can run Lessons Learned sessions
where the PM of a completed project presents their Lessons to the rest of the Project Management community (but this relies on an open and honest communications culture, and/or bribing the attendees with cakes), or…
- The PMO could pre-load the Risk Register template
with the risk of repeating mistakes made on previous projects – the mitigation for which would be to review the Lessons Learned Big Database for things to consider (and the PMO could add value by offering this as a service).
I think the last two approaches are the best, because one encourages the development of a learning community (this is the subject of a separate post) and the other places responsibility for reviewing past lessons (or not) with Project Managers, but supports them with a PMO service.
So that’s my approach to making project lessons “stickier”, learned through experience. What do you think? How do you ensure lessons from past projects are not just identified and logged, but learned and applied to new projects? Let me know in the comments.
If you would like to have the benefits of an approach like this but prefer not to have to worry about this sort of techy stuff, why not talk to us about taking care of it all for you on your next big project or programme?