20
Closing a project
This chapter covers:
•preparing for formal closure
•preparing for premature closure
•handing over the project product
•evaluating the project and recording lessons
•recommending project closure
•guidelines for tailoring products and roles
20 Closing a project
The purpose of the closing a project process is to provide a fixed point at which acceptance of the project product is confirmed, and to recognize that objectives set out in the original PID have been achieved (or approved changes to the objectives have been achieved), or that the project has nothing more to contribute.
The objective of the closing a project process is to:
•verify user acceptance of the project product
•ensure that the host site is able to support the products when the project is disbanded
•review the performance of the project against its baselines
•assess any benefits that have already been realized and update the benefits management approach to include any post-project benefit reviews
•ensure that provision has been made to address all open issues and risks, with follow-on action recommendations.
Figure 20.1 provides an overview of closing a project.
One of the defining features of a PRINCE2 project is that it is finite; it has a start and an end. If the project loses this distinctiveness, it loses some of its advantages over purely operational management approaches.
A clear end to a project:
•is always more successful than a slow drift into use as it is a recognition by all concerned that:
•the original objectives have been met (subject to any approved changes)
•the current project has run its course
•either the operational regime must now take over the products from this project, or the products become inputs into some subsequent project or into some larger programme
•the project management team can be disbanded
•project costs should no longer be incurred
•provides an opportunity to ensure that all unachieved goals and objectives are identified so that they can be addressed in the future
•transfers ownership of the products to the customer and terminates the responsibility of the project management team.
Closure activities should be planned as part of the stage plan for the final management stage. When closing a project, work is required to prepare input to the project board in order to obtain its authorization to close the project. Subsequently, the executive should also notify corporate, programme management or the customer that the project has closed (see section 15.4.5).
It is also possible that the project board may wish to trigger a premature closure of the project under some circumstances (e.g. if the business case is no longer valid). If the project is being brought to a premature close, this process will still need to be executed, but may have to be tailored to the actual project situation.
A number of actions specific to the project product may be required after the project, and these should be documented and planned for as follow-on action recommendations. These may have different audiences and therefore may need to be issued individually. The needs of the recipient will determine the format and content; some may want a formal report, some a log entry on a system, and others a meeting.
The activities within the closing a project process are project-manager-oriented and are to:
•prepare planned closure
•prepare premature closure
•hand over products
•evaluate the project
•recommend project closure.
20.4.1 Prepare planned closure
Before closure of the project can be recommended, the project manager must ensure that the expected results have all been achieved and delivered.
Figure 20.2 shows the inputs to, and outputs from, this activity.
PRINCE2 recommends the following actions:
•Update the project plan with actuals from the final management stage.
•Request a product status account from project support. From the product status account, ensure that the project product:
•has been approved by the authorities identified in the project product description
•meets all the quality criteria, or is covered by approved concessions.
•Confirm that the project has delivered what is defined in the project product description, and that the acceptance criteria have been met.
•Seek approval to give notice to corporate, programme management or the customer that resources can be (or are about to be) released.
Table 20.1 shows the responsibilities for this activity.
Table 20.1 Prepare planned closure: responsibilities
Key: P (producer) – responsible for product’s production; R (reviewer) – ideally independent of production; A (approver) – confirms approval.
20.4.2 Prepare premature closure
In some situations, the project board may have instructed the project manager to close the project prematurely. In such circumstances, the project manager must ensure that work in progress is not simply abandoned, but that the project salvages anything of value created to date and checks that any gaps left by the cancellation of the project are raised to corporate, programme management or the customer.
Figure 20.3 shows the inputs to, and outputs from, this activity.
PRINCE2 recommends the following actions:
•Update the issue register (and, if necessary, the issue report) to record the premature closure request.
•Update the project plan with actuals from the final management stage.
•Request a product status account from project support. From this, determine which of the project product’s components:
•have been approved by the authorities identified in their product descriptions
•are currently in development (and which of those need to be completed)
•are covered by approved concessions
•have yet to be started
•need to be made safe
•may be useful to other projects.
•Agree the means for recovering products that have been completed or are in progress (if appropriate). This will need project board consultation and may include additional work to create, make safe or complete products that might be useful to other projects (e.g. making an unfinished building safe and weatherproof). In some cases, the additional work may require an exception plan.
•Seek approval to give notice to corporate, programme management or the customer that resources can be (or are about to be) released early.
Table 20.2 shows the responsibilities for this activity.
Table 20.2 Prepare premature closure: responsibilities
Key: P (producer) – responsible for product’s production; R (reviewer) – ideally independent of production; A (approver) – confirms approval.
The complete list of responsibilities for each product is shown. Where a product is produced, reviewed or approved in another process, the responsibility is shown in parentheses, as in (P), (R) or (A).
The project product must be passed to an operational and maintenance environment prior to the project being closed. This may happen as a single release at the end of the project, or the project approach may include phased delivery where products are handed over in a number of releases. In the case of a premature closure, there may be some products that have been approved but not yet handed over and, depending on the project board guidance, the ownership of some or all of those products may need to be transferred to the customer.
When handing over products, the benefits management approach may need to be updated to include the post-project benefits review(s) of the performance of the project product in operational use. Such benefits reviews may identify whether there have been any side-effects (beneficial or adverse) that could provide useful lessons for other projects.
There may be multiple handovers throughout the project lifecycle. It is not a project activity to undertake benefits reviews post-project, only to plan for such benefits reviews to occur. If the project is part of a programme, then the post-project benefits reviews need to be covered by the programme’s benefits management activities.
Figure 20.4 shows the inputs to, and outputs from, this activity.
PRINCE2 recommends the following actions:
•In consultation with the project management team, prepare follow-on action recommendations for the project product to include any uncompleted work, issues and risks. There could be separate follow-on action recommendations for the project product (or its components) or for each distinct user group (e.g. human resources, finance, operations).
•Check that the benefits management approach includes post-project activities to confirm benefits that cannot be measured until after the project product has been in operational use for some time (e.g. reliability requirements).
•Examine the PID to confirm how products are to be handed over to those who will maintain them in their operational life:
•confirm that the correct operational and maintenance environment is in place
•consider the early life-support requirements of each product being handed over because the early life of a product is often the period of peak demand on the support organization
•when a product requires a lot of potentially expensive support and maintenance, ensure that a suitable service agreement or contract has been drawn up between the operations and maintenance organizations and the end-users. Such an agreement should be included as a product to be developed by the project
•confirm acceptance from the operations and maintenance organizations
•request and obtain acceptance records
•transfer the responsibility for the products from the project to the operations and maintenance organizations and update the products’ configuration item records, if used.
Table 20.3 shows the responsibilities for this activity.
Table 20.3 Hand over products: responsibilities
Key: P (producer) – responsible for product’s production; R (reviewer) – ideally independent of production; A (approver) – confirms approval.
The complete list of responsibilities for each product is shown. Where a product is produced, reviewed or approved in another process, the responsibility is shown in parentheses, as in (P), (R) or (A).
Successful organizations learn from their experiences with projects. When evaluating the project, the objective is to assess how successful or unsuccessful the project has been. It may also be possible to improve the estimation for future projects by analysing the estimates and actual progress metrics for this project.
Figure 20.5 shows the inputs to, and outputs from, this activity.
PRINCE2 recommends the following actions:
•Review the project’s original intent as agreed in the initiation stage and defined by the PID, baselined at that time.
•Review the approved changes as defined by the current version of the components of the PID.
•In consultation with the project management team, prepare an end project report to include:
•the project manager’s summary of how the project performed
•an assessment of the results of the project against the expected benefits in the business case
•a review of how the project performed against its planned targets and tolerances
•a review of team performance
•a review of the project product (which should include a summary of any follow-on action recommendations)
•if necessary, the documented reasons why a project was brought to a premature close.
•In consultation with the project management team, review the lessons log to identify lessons that could be applied to future projects and incorporate them into the end project report. The report should include:
•a review of what went well, what went badly and any recommendations for corporate, programme management or customer consideration; in particular, the project management method, any delivery approach(es) used, project approaches and controls, and any abnormal events that caused deviation
•a review of useful measurements such as: how much effort was required to create the products, how effective the quality management approach was in designing, developing and delivering fit-for-purpose products (e.g. how many errors were found after products had passed quality inspections), and statistics on issues and risks
•any useful knowledge gained regarding the tailoring of PRINCE2 for the project.
Table 20.4 shows the responsibilities for this activity.
Table 20.4 Evaluate the project: responsibilities
Key: P (producer) – responsible for product’s production; R (reviewer) – ideally independent of production; A (approver) – confirms approval.
The complete list of responsibilities for each product is shown. Where a product is produced, reviewed or approved in another process, the responsibility is shown in parentheses, as in (P), (R) or (A).
20.4.5 Recommend project closure
After the project manager has confirmed that the project can be closed, a closure recommendation should be raised to the project board. Figure 20.6 shows the inputs to, and outputs from, this activity.
PRINCE2 recommends the following actions:
•Use the communication management approach to identify any organization or interested party who needs to know that the project is closing. Consider also communication activities for public relations and marketing opportunities at this point.
•Close the project’s issue register, risk register, quality register, daily log and lessons log.
•Make sure that all project information is secured and archived (in accordance with the change control approach) in order to permit any future audit of the project management team’s decisions, actions and performance.
•Prepare and send a draft project closure notification for review by the project board, stating that the project has closed.
Table 20.5 shows the responsibilities for this activity.
Table 20.5 Recommend project closure: responsibilities
Key: P (producer) – responsible for product’s production; R (reviewer) – ideally independent of production; A (approver) – confirms approval.
The complete list of responsibilities for each product is shown. Where a product is produced, reviewed or approved in another process, the responsibility is shown in parentheses, as in (P), (R) or (A).
The activities in this process may be combined, split or run concurrently to suit the context, but care should be taken to ensure the integrity of the interface to the directing a project and controlling a stage processes.
If the final stage(s) of the project includes initial operation of the outputs, the hand over products activity may not be undertaken in the project’s final management stage as part of closing the project, but may happen within a number of previous management stages. Closing the project would then only require confirmation that all handovers have been completed.
20.5.2 Tailoring products in closing a project
Table 20.6 provides tailoring guidelines for management products in closing a project.
Table 20.6 Guidelines for tailoring products in closing a project
Management product |
Tailoring guidelines |
End project report |
Any element of the composition may be provided in a separate document or information source, which should be cross-referenced. The composition may be adapted to suit the readership; for example, confidential elements, such as the review of the business case or team performance, may be included in separate documents. |
Lessons log |
Lessons from the log or lessons report (if one has been created) are usually included in the end project report but may be presented in a separate document. |
20.5.3 Tailoring roles in closing a project
The project manager is responsible for the creation of all new management products in this process, but may delegate work to others provided overall responsibility is retained.
The checking that post-project benefits reviews are planned to take place may be undertaken by the senior user in the hand over products activity.
20.5.4.1 Closing a simple project
All activities may happen in a very short timescale; for example, handover, evaluation and closure approval (from directing a project) could all happen at a single meeting. Closure activities do not need to be formally documented, with a daily log entry, minutes of a meeting or email sufficing, provided it is clear to all stakeholders and the project management team that the project is closed and what the follow-on actions are.
20.5.4.2 Closing a project when using an agile approach
When using agile, project closure is still likely to be a formal event. However, most of the information is already known and most of the work is already done due to the iterative and incremental nature of the agile way of working. Examples of this would be that benefits may already be being realized, most of the project product’s functionality is in operational use, and documentation is almost complete and just needs to be finalized. In addition, many lessons will already have been identified during retrospectives at the end of each sprint.
20.5.4.3 Closing a project from a supplier perspective
It should be decided when the project is completed from a supplier perspective. For example, this may be when the work is completed, after any maintenance or warranty period has elapsed, or when the contract is fulfilled.
20.5.4.4 Closing a project within a programme
All the guidance provided above is applicable to a project within a programme, except that any decisions and the plan for the benefits reviews will be made in the context of the programme, whether closure is premature or is on completion of the project.