The last couple of posts have been covering the topic of project reviews and how the output can help improve the outcomes of other projects across an organisation (or even later phases of the same project). When to conduct a lessons learned review focused on the different points where you can conduct a review. By far the most used, is the review that is completed when a project is complete. This post will focus on the mechanics and structure of this important process.
Preparation
It is important that the appropriate preparation takes place ahead of the review. As with anything, if you do not prepare, the quality of output will suffer.
Approach
There should be a standard approach to conducting the lessons learned reviews. This should ideally be owned by the PMO. Hopefully, there will already be a defined process to use, if not you will have to spend time creating:
- Process
- Tools and Templates
This does not have to be overly complicated. As you will recall, the objective is to work out what went well (so the organisation can embed and do more of the same on other projects) and what did not go well (so the organisation can identify the root cause and not repeat).
The process provides a standard approach to:
- Review selection
- Setting up reviews
- Executing reviews
- Analysing findings
- Defining actions to embed change
Process
This should detail the end to end flow of the process:
- Overview: provides context of process – useful for senior management
- Detail: builds on the overview to explain detailed steps of the process
- Templates: to be used to execute the review process
Review Selection
This will define the criteria for selecting when a review should be conducted on a project. This will normally be at the end of the project. However, as mentioned in the last document, this may be at other key phases.
The selection criteria is important as it sets a clear policy across an organisation as to when reviews must be conducted. This ensures common understanding and allows delivery teams to include in their plans as a formal milestone. It also educates the organisation and embeds the process i.e. senior management will start asking for the output of the reviews.
Setting up Reviews
With a clearly defined policy, the delivery team should plan the required reviews into the project schedule. This should be done pragmatically as the purpose is to provide benefit to the project and wider organisation. Reviews should not be scheduled just because it is stated in the policy.
For example, a review may naturally take place at the end of phase for a multi phase project. If delivery team is also scheduled to be holding a planning workshop, at a 5 day offsite, for the next phase, move the review earlier or later.
Likewise, if the review is scheduled for 2 weeks after a new system has been implemented, it may be wise to delay to later. This will allow the team to deal with any production issues, and provide more time for issues and benefits from the project to develop.
Executing the Review
It is important that all of the review sessions are scheduled ahead of time and any supporting information / templates issued. This is especially important for senior members of staff as their diaries ten to be very difficult to secure time at short notice.
If the approach is to hold a lessons learned workshop, there may be a requirement for inputs to be prepared and gathered ahead of the session. Make sure that all participants have sufficient time to complete and return the lesson learned template. This will allow time for the data to be consolidated and any themes identified.
If the information has been gathered and consolidated ahead of the workshop, the information should be packaged so that it can be used to drive the session.
- Review / discus themes
- Reach agreement on themes and underlying root cause
- Review and agree what has been learned
- Agree practical steps to embed learnings
It is possible for a number of the workshop steps to be completed ahead of the workshop. However, I find it very helpful to discuss and agree as a group so as to ensure alignment. It also often leads to additional ideas.
Analysing Findings
The agreed findings and next steps from the workshop should be reviewed and documented. Particular focus should be on the steps to embed the process.
The PMO should review the findings against output from other projects to see if there are any wider trends across project delivery for the organisation. It is possible that other projects have raised similar points and these are being embedded. The check allows for any proposed changes to be refined.
The findings should be captured into a register to ensure that they are tracked through to implementation. Ideally this will sit in the PMO. It is a good idea to define and use standard themes so that lessons learned and recommendations can be grouped. This will increase the value of data mining.
Define Actions and Embed Change
The findings should be sent back to the workshop attendees and any other stakeholders, for review. When agreement is reached, work can commence to embed the changes. The register can be used to track progress and to report back to stakeholders.
Summary
In order to conduct a productive lessons learned review:
- Ensure that there is a simple process with defined tools and templates
- Schedule reviews at an appropriate time in project life cycle – be pragmatic
- Seek input ahead of review workshop
- Hold workshop and review themes, agree root cause and changes
- Analyse against other findings across the organisation and refine
- Capture in register and implement
Following this structure should result in an improvement in the outcomes of future projects.
