PRINCE2 - Closing a Project (CP) part 4
of the Cabinet Office under delegated authority from the Controller of HMSO.
Evaluating a Project (CP3)
Fundamental principles
Successful organisations learn from their experiences with projects.
This is more likely if the lessons learned are somehow preserved beyond the end of the project.
Context
This is the internal project evaluation.
The aim here is to assess how successful or unsuccessful the been, not how successful the end product is.
There may be a separate external evaluation – for example, from a quality assurance group.
The comments gathered over the course of the project in the Lessons Learned Log are arranged into a Lessons Learned Report.
The log is created at the outset of the project and incremented as the project progresses with observations on what aspects can usefully be noted to help future projects. It should include observations on management, specialist and quality procedures, products and techniques.
Again, the results are to be input to the Project Board sub-process 'Confirming Project Closure (DP5)'.
Process description
The objectives of this sub-process are:
- Update the Project Plan with actuals from the ‘final’ stage
- Assess the results of the project against what it was intended to achieve
- Examine the records of the completed project to assess the quality of its management, especially quality and risk management [see ‘The Complete Risk Management package’]
- Identify lessons to be learned from the project and applied on future projects.
The updated Project Plan allows the Project Manager to document in the End Project Report how well the project has performed against its Project Initiation Document, including the original planned cost, schedule and tolerances.
Not all benefits will have been achieved by the time of project closure.
Any achievement or non-achievement that can be defined should be part of the report.
A note of any benefits that need to be measured after operational use of the final product is passed to Identifying Follow-on Actions (CP2) for inclusion in the Post-Project Review Plan.
The report should also take into consideration the effect on the original Project Plan and Business Case of any changes that were approved.
The End Project Report should give final statistics on changes received during the project and the total impact of approved changes.
Any outstanding changes should match up with follow-on actions defined in Identifying Follow-on Actions (CP2).
Statistics may also be appropriate for all quality work carried out.
The End Project Report is concerned with how will the project fulfilled its objectives or, in the case of a premature close, did not fulfil its objectives. The Lessons Learned Report, by way of contrast, is concerned with how well the project was managed and with the project’s use of project management processes and techniques – that is, PRINCE2® and any local standards used – and what can be learned form this implementation.
This report will be approved by the Project Board and issued to interested parties as part of 'Confirming Project Closure (DP5)'.
At the start of the project, a Lessons Learned Log should be created.
A note should be added to this every time the project management team spot something about the management or specialist processes, products, techniques or procedures that either made a significant contribution to the project’s achievements or caused a problem.
This includes the performance of all the project management team, the change control and quality results.
In this sub-process, all the notes should be collated and turned into a report, including any views with hindsight on the project’s management.
The report should aim to answer the question: ‘what should be done differently next time?’
A configuration audit should have been done at the end of the project, as part of sub-process Decommissioning a Project (CP1), to look for discrepancies.
The cause of any discrepancies might justify an entry in the Lessons Learned Report.
The report is also the repository of any useful measurement and quality statistics collected during the project that will help in the planning and estimation of subsequent projects.
It is important to identify at the beginning of the project who should receive the Lessons Learned Report and make sure that the Project Board knows where it should go. There is little point in preparing the report, only to find that will not be used.
If a project is brought to a premature close, the reasons should be documented in the Lessons Learned Report, focusing on any failure in the methodology, specialist tools and techniques or staff that caused or contributed to the premature close.
Conversely, if the premature close was caused by successful application of the PRINCE2 method, for example, identification that the project was no longer viable or had exceeded its project tolerances, this should also be documented.
Responsibilities
The Project Manager bears overall responsibility for this sub-process, but additional information could come from anyone involved in the project.
| Management information | Usage | Explanation |
|---|---|---|
| Project Initiation Document | Input | Original statement of project objectives, scope and constraints. |
| Issue Log | Input | The reasons for Off-Specification may provide lessons for future projects. |
| Risk Log | Input | What risks were considered and what happened to them may provide lessons for future projects. |
| Project Quality Plan | Input | This will indicate whether the quality policy and procedures were adequate, and correctly stated. |
| Quality Log | Input | Statistics of the number of quality checks made and the errors found are useful to a quality assurance function. |
| Configuration Item Record | Input | Are there any discrepancies between the records and reality? These may inform the conduct of future products. |
| Lessons Learned Log | Input | This should be an ongoing document from the start of the project, completed with relevant notes of the good and bad lessons learned about management and specialist procedures, forms, other documents, tools and techniques. |
| Project Plan | Update | Updated with the figures from the ‘final’ stage. Will be reviewed when producing the End Project Report. It may also be useful when preparing the Lessons Learned Report. |
| Daily Log | Input | This may contain useful information which can be analysed as part of the End Stage Report or the Lessons Learned Report. |
| Business Case | Input | Any benefits realised already should be described in the report. |
| Lessons Learned Report | Output | This takes the Lessons Learned Log and writes it up into a report to be passed via the Project Board to the group charged with maintaining such quality standards. |
| End Project Report | Output | Evaluation of the achievement of objectives as defined in the Project Initiation Document and of the management performance of the project. |
These are given in tabular form in the file ‘CP3 evaluating a project.doc’ in the product package.
Key criteria
- Which management processes or procedures have worked well?
- Which management processes have had problems?
- Was it easy to achieve the required quality?
- Which quality procedures have worked well?
- Were there any weaknesses in quality procedures for specific types of products?
- How well did risk strategies work?
- Were there any unforeseen risks?
- How well were the risks managed?
- Was the contingency used?
- Was training in the management, quality and delivery processes and procedures adequate?
- Were there recognisable benefits from the level of training given or recognisable problems caused by lack of training?
- How will did any support tools work?
- Could anything have been done to improve skill levels before the relevant work was done?
- If there has been deviation from the Project Initiation Document, is the Project Board still prepared to accept the project closure?
Are those deviations reflected in the End Stage Project Report and Lessons Learned Report? Where appropriate, are any deviations reflected in the Follow-on Action Recommendations?
Concentrate on items that can be of use to future projects.
Observations on successful elements can be as useful as identification of failures and omissions.
Deviations documented in the End Project Report, the Lessons Learned Report and the Follow-on Action Recommendations should, as far as is sensible, avoid overlap – in other words, the same deviations should not be unnecessarily recorded in several places.
Consider whether there are any lessons about the quality procedures that should be directed to any quality assurance function.
These might be weaknesses in current standard practices new quality testing requirements from the products of the project that are not currently covered by standards or new ways of testing quality that the project has pioneered.
Where the project is part of a programme, the programme support office should review the Lessons Learned Report for applicability to the programme or to individual projects within the programme.
There are a number of possible recipients of the Lessons Learned Report.
The aim is to identify the group that will distribute the report to other projects, jot just current ones but any that may be starting up in the future.
Ideally, this should be a group that has the responsibility to maintain project management standards.
Some organisations have a project management office; others make the responsibility part of the duties of a quality assurance group.
Elsewhere it may be known as management services or the central Project Support Office.
Managing Successful Projects with PRINCE2 - 2005 edition
Managing successful Projects with PRINCE2 – 2009 edition
Directing Projects with PRINCE2.
plus:
The Complete Project Management package.
And much more besides - at a fantastic price.