The last post, Project and PMO Lessons Learned Overview, provided an overview of the project lessons learned review process. This post and future posts will go into more detail on the different aspects of the process. I also would like to state that I will highlight where there are differences with PMO lessons learned. However, the principles are similar.
Remember the objective
It is worth taking a moment to remember the objective of conducting the review. After all it is an investment of time and money, and, like other activities, it must add value (those who have read my other blog posts will know that one of my core principles is that PMO and project activities should only be performed if they add value and / or are absolutely required – if not don’t waste time and money performing them).
The objective is to learn from what has happened (good and bad) so that changes can be made to improve the process in the future. The rationale being, if something has worked well, we want to ensure that all projects use a similar approach as it should provide the same benefit. Likewise, if something goes badly, it makes sense to take steps to avoid the same issue impacting other projects.
Of course it is not quite as simple, as each project will be different and what has worked well for a project may not be applicable to others. I want to expand on this point in a future post.
When to conduct lessons learned
If you ask a project manager when to conduct a lessons learned review, I would be confident that the majority would say at the end of the project. A relatively small minority will say at the end of a significant toll gate.
While both answers are correct, the second response provides far more value to an organisation than the response “at the end of the project”. The reason being, the earlier that lessons can be identified and embedded into an organisation, the more value they will provide. So the ideal response to the question would be to conduct reviews on an ongoing basis so as to allow for continuous improvement.
Obviously, it would be impossible to conduct reviews on a continuous basis. Likewise, you would have to question the value (remember the principle only perform an activity if it adds value). Therefore, the following provides 4 ideas of where you can use lessons learned.
This may sound counter intuitive, why would you want to have lessons learned at the start of a project? Well, this is not so much lessons learned from the current project, it is the learning’s and collective knowledge from other projects.
When starting a new project, the project manager should check to see if a similar type of project has been undertaken before (does not matter if it was not finished). Then request details of lessons learned, arrange to meet project manager, sponsor, etc so as to find out “first hand” more information.
If a similar project has not been completed before, put a request out to the project managers, PMO teams, etc. There is a possibility that somebody may have completed a similar project at another organisation. Definitely worth buying them a coffee to get their thoughts on where there may be problems.
Gaining this knowledge will allow you to incorporate these learning’s into your planning. This should improve the odds of a successful outcome.
If no one has completed a similar project, another approach is to ask for other project managers to conduct peer reviews of your plans, terms of reference, etc. Good project managers will be able to review and ask probing questions that will tease out potential issues. Updates can then be made resulting in a more robust approach.
In many project life cycles, there are phases of work i.e. Initiate, Design, Build, Test, Implement. Some organisations define tollgates that need to be satisfactorily achieved in order to move to the next phase. It can be common to use this in association with gated funding so that the budget to support the next phase can only be drawn down when the tollgate is achieved.
The project team will usually need to prepare evidence that the tollgate has been met to present to the project steering committee. So, if they have to prepare a presentation, it is logical for the presentation to include lessons learned. These can then be used to inform and make changes for future phases.
The PMO can take the presentation, analyse, review against defined tools and processes and then, where appropriate, make changes to benefit the wider organisation.
3. Change Request
Most projects will have at least one change in scope, budget or schedule over the lifetime of the project. This will result in the project team having to create a change request to present to the steering committee or change board to reset the project.
The analysis and presentation provides a similar opportunity to the tollgate review. The project team will need to provide the driver for the change and why it impacted the project.
Again the PMO should review the reason and workout if any changes need to be made across other projects.
4. Project Closure
Finally, the point where we started, lessons learned should always be completed at the completion of the project. This will follow a defined template that is specifically designed to capture all aspects of lessons learned for the project.
This review will be more in-depth and will capture inputs from project team, sponsors, stakeholders, etc. While the feedback will be more comprehensive, it comes to late to help the project so the time invested is for the benefit of others. The only time it may be a benefit for the project is if it involves multiple workstreams.
To close I would like to summarise the key messages.
- Lessons learned does not have to wait until the end of the project
- Look for natural opportunities to learn and make changes i.e. change control, tollgate, etc
- Adopt an approach on continuous improvement, making changes even if there has not been a formal review
- PMO should be the custodian of the learning’s – actively reviewing and embedding organisation changes to improve project delivery
The next post will cover the end of project lessons learned review in more detail including the structure of the template.