Over the last 3 posts I have explored the different aspects of project reviews and how they can be used to improve the delivery of change. In this post I want to cover the dimensions of a review and the types of question to ask.
Lessons Learned Template
The actual lessons learned template should have a logical structure that covers all of the important aspects of a project. It suits a word processor or spread sheet format.
Below is designed to give ideas on how a template could be structured around logical groupings and example questions. Remember, you need to use questions that allow for open and honest discussions that do not look to assign blame. Therefore, it is important that questions and responses are factual and non-emotive.
Overview / Background
Project Objectives – this reminds those involved in the review of the original purpose and makes it more likely that feedback will be relevant and meaningful.
Scope of review – it is important to be clear of the scope of what is being reviewed so as to capture focused feedback. For example, the review may want to target the performance of the technology solution. Therefore, this would be defined in the scope and then could be used as a point of reference during the review feedback sessions (stopping people feeding back on other areas that are not applicable to the review).
The first part of the review should be used to capture feedback on the high level performance of the project.
- Project Outcome – did the project achieve the defined objectives
- Scope – did the project deliver the documented / agreed scope
- Schedule – did the project deliver inline with the schedule
- Budget – did the project deliver within the allocated budget
- Benefits – were the benefits in the signed-off business case realised?
All should allow the user to provide feedback and comments as well as examples to back-up any statements.
This should explore in detail the main project lifecycle processes. Where there have been delays / challenges, these should be captured together with underlying reasons.
Was the project initiated quickly and efficiently?
Were there barriers to initiation
Were approvals given quickly?
Requirements / Design
Objectives clear, understood achievable
Requirements gathered to sufficient detail
Requirements accurately documented
Tasks captured and understood
Any issues gathering requirements?
Testing plans were clear and accurate
Testing covered all functionality
Were there many defects
Were defects quickly addressed?
Was their sufficient implementation planning
Was there a back out plan
If back out was used, was it a success
Was the implementation a success
Were resources suitable trained
Were there post go-live issues?
Progress was tracked against plan
Robust reporting established
Change control implemented and followed
Was there many changes? If so were there common themes
Robust governance established
SteerCo’s well attended
Was there appropriate quality control
Risks, issues and dependencies managed effectively?
Were all project objectives met
Was the project team released in a structured manner
Was all project documentation completed and archived
Did sponsor sign-off project was complete?
While the focus is on the project team. This section should also capture any appropriate findings in respect of sponsor, stakeholders, etc that have had a positive or negative impact on the performance.
Did the team have sufficient resources
Did the team have the correct skills
Was the team recruited in line with schedule? If not what was the impact
Were resources prioritised from other projects
Were BAU resources available as required
Did the sponsor support requests and provide resources?
Depending on who is conducting the review. You can make the questions more focused:
Was the project manager, sponsor effective, etc
Did the project have sufficient budget
Was the budget approved quickly
Was the budget incorrect? If so what was the reason?
Did the project deliver the required outcomes
Could the outcomes be measured
What was the cause for not meeting the required outcomes?
All of the key findings from the review should be captured and consolidated within the document. Findings can be captured with the questions. However, it is helpful to consolidate the findings in a separate section with a reference to the finding in the document.
The findings can then be consolidated into themes and analysed to establish what changes should be made to existing processes (or new ones established).
They should be captured using a standard format, preferably tabular format so that they can be easily copied from each lessons learned document and transferred to a central register. This allows for output from multiple projects to be compared and then changes designed for the organisation, not just for a single project.
It is important to have a structured approach to lessons learned to give the best chance of identifying what went well and not so well in a standard way for all projects. This will allow the information to be captured and then compared against all other projects to identify themes that need to be addressed. The result should be an improvement in an organisations project delivery.
If you have access to the Quality Assurance Framework, you may find the 120 pre-populated questions a useful input for structuring your template.