PRINCE2 - Closing a Project (CP) part 3
of the Cabinet Office under delegated authority from the Controller of HMSO.
Identifying Follow-on Actions (CP2)
Fundamental principles
If there is any unfinished business at the end of the project, it should be formally documented and passed to those who have the authority and responsibility to take action.
Context
Most of the input will be those items on the Issue Log that were held back by the Project Board.
The output is submitted to the Project Board as Follow-on Action Recommendations.
Process description
The aims of this sub-process are to:
- Check that all Project Issues and risks are closed or transferred to Follow-on Action Recommendations. Establish actions required following the project
- Document any Follow-on Action Recommendations
- Recommend a date and produce a plan for any post-project review(s) considered necessary
A number of actions may be required after the project.
The input will come mainly from those Project Issues that were put into ‘pending’ status by the Project Board during the project.
The Risk Log may also contain risks that may affect the product in its useful life.
All unfinished work is documented in Follow-on Action Recommendations.
Many project schedules should be re-examined after a period of use to check on their quality, effectiveness in use and achievement of benefits.
Examination of the updated Business Case will identify whether there are any expected benefits whose achievement cannot be measured until the product has been in use for some time. If this is the case, a recommendation date and plan should be made for a post-project review, the benefits to be measured at that time and the measurements too be applied.
These benefits should have been defined in the Business Case.
It is not a project activity to produce the post-project review, only to plan it.
In summary, the post-project review is to assess achievement of the benefits claimed in the Business Case.
The following questions are a sample:
- To what level has the product achieved the benefits expected?
- Is there an identifiable trend of improving benefits?
- Are the user(s) happy with the product?
- Is the product proving to meet quality expectations?
- Is the product as well supported as was expected?
- Are the support staff happy with what they have been given to support the product?
- Have there been any unexpected problems in the introduction?
- Has the product caused new problems?
The Post-Project Review Plan will make use of the information contained in the Business Case.
The Product Description is given in file ‘Business case.doc’ in the product package.
This should have stated how the achievement of benefits was to be measured.
The plan should be defining:
- What benefit achievements are to be measured?
- When benefit achievement can be measured?
- How the achievement can be measured?
- The pre-delivery situation against which achievement is to be compared
- Who is needed to carry out the measurements (individuals or skill types)
Responsibilities
The Project Manager is responsible for this sub-process.
| Management information | Usage | Explanation |
|---|---|---|
| Issue Log | Input | Unactioned Project Issues will form the basis of any Follow-on Action Recommendations. |
| Business Case | Input | This will reveal benefits whose achievement cannot be measured immediately and will therefore need a post-project review. |
| Risk Log | Input | Check for any risk to the operational use of the need product(s). |
| Post-Project Review Plan | Output | Suggested plan for a post-project review for ratification by the Project Board. |
| Follow-on Action Recommendations | Output | Recommendations for further work, which the Project Board must direct to the appropriate audience for attention. |
These are given in tabular form in the file ‘CP2 identifying follow-on actions.doc’ in the product package.
Key criteria
- Is a post-project review needed to measure achievement of business benefits and re-examine the quality of products after a period of use?
- How much time needs to elapse before these benefits can be measured?
- Are the benefits for this project alone or combined with the outcomes from other projects?
- Which ‘pending’ Project Issues should be recommended for follow-on action by the operation and support teams?
- Which ‘pending’ Project Issues should be recommended to be turned into Project Mandates for potential enhancement projects or referred to programme management for further action?
Arrangements for any post-project review should be discussed informally with the Project Board before making any recommendation so as to avoid any disagreement in the subsequent sub-process, 'Confirming Project Closure (DP5)'.
The date for the review should be set as soon after the project closes as would allow adequate assessment.
The quality of a product may have appeared fine during testing, but is it sill good after a period in the working environment?
Also, where some benefits will take much longer to come to fruition, it is worth considering a recommendation to the Project Board that these are the subjects of another, later post-project reviews.
Dependent on the type of project product, there may be contractual issues to be resolved for the operational and maintenance support of the products.
A copy of the recommended follow-on actions should always be sent to the operational support group to keep it informed.
Where the project is part of a programme, the Project Board’s recommendation to close the project should be reviewed by programme management in the light of the list of follow-on action recommended.
If the project is part of a programme, the follow-on actions should be assigned by programme management, where appropriate.
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.