The last 3 posts have explored the different aspects of project reviews and how they can be used to improve the delivery of change. This post will 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).
Overall Performance
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.
Project Processes
his should explore in detail the main project lifecycle processes. Where there have been delays / challenges, these should be captured together with underlying reasons.
Initiation
- 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?
Implementation
- 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?
Control
- 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?
Closure
- 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?
Project Team
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
Budget
- Did the project have sufficient budget
- Was the budget approved quickly
- Was the budget incorrect? If so what was the reason?
Outcomes
- Did the project deliver the required outcomes
- Could the outcomes be measured
- What was the cause for not meeting the required outcomes?
Findings
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.
Summary
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.
