Closing a Project Process in PRINCE2 2017

Executive summary

Purpose and why a fixed ending matters

Closing a Project provides a fixed point for confirmation that the project product has been accepted and that the project objectives in the original or formally changed PID have been achieved—or that there is nothing more the project can contribute. The temporary organisation should not continue indefinitely after its purpose ends.

A clear ending has practical consequences. Products move into operations or another project/programme, project-management responsibilities are released, project costs stop being incurred and unresolved matters are transferred to named owners. Without formal closure, teams can remain partly active, records can stay open and users can be uncertain about who supports the delivered product.

Closure work is planned in the final Stage Plan. The final stage should therefore contain not only remaining specialist products but also acceptance, handover, evaluation, lessons, benefits updates, archival work and the closure recommendation.

Closure objectives

The source identifies five major objectives: verify user acceptance; ensure the host environment can support the products after the project team disbands; review project performance against baselines; assess benefits realised and update post-project benefit review arrangements; and ensure open issues and risks are covered by follow-on action recommendations.

These objectives prevent closure from becoming a ceremonial meeting. Each should be supported by evidence. Acceptance should have an authorised record. Operational support should have an owner and readiness confirmation. Performance should be compared with the baselines rather than described only as “successful”. Open risks and issues should be transferred, not merely listed.

The process should also respect the distinction between outputs and benefits. A project can close before all benefits are realised because benefits often depend on operational use over time. The Benefits Management Approach is updated so the commissioning organisation can measure them after the temporary project has ended.

Activity — prepare planned closure

Planned closure is the normal graceful end. The Project Manager verifies that the expected project products have been completed, approved and delivered according to the authorised Project Plan and any approved changes. This does not mean every expected benefit has already occurred.

Check the product status, acceptance criteria, quality records and outstanding Work Packages. Resolve or explicitly transfer any remaining actions. Confirm that the operational or maintenance environment is prepared, including support responsibilities, documentation, training or other arrangements that were part of the project scope.

The Project Manager should also confirm that all project-management products are current enough to support evaluation and audit. A project cannot credibly compare performance against baselines if its plans and registers stopped being maintained before closure.

Activity — prepare premature closure

The process is also used when the project is terminated early, for example because continued business justification has disappeared. Premature closure does not mean simply telling the team to stop. The Project Board provides direction and the Project Manager identifies what should be completed, secured, salvaged, transferred or disposed of safely.

The source gives practical examples of incomplete products that may create safety or value considerations. Some partially completed products may be useful to another initiative; others may need to be made safe or dismantled. Leased equipment or committed resources may need cancellation, reuse or other commercial treatment.

Approved completed products that have not yet been handed over may still need to transfer to the customer. Open risks and issues require owners after the project ends. Lessons from an unsuccessful project may be particularly valuable and should still be captured.

Activity — hand over products

Products must be transferred to an operational and maintenance environment before the project is closed. Handover may occur as one final release or incrementally if the project approach uses phased delivery. The Project Manager confirms who owns each product after closure and that the receiving environment can support it.

Acceptance evidence should be linked to the Project Product Description and agreed acceptance criteria. Product approval within a delivery team is not automatically the same as overall customer acceptance. The source expects an acceptance record as part of the closure responsibilities.

For phased delivery, some products may already be operational. Closure still needs to confirm the total project acceptance state and any outstanding operational obligations. For premature closure, Board direction determines which approved products should transfer.

Activity — evaluate the project

Evaluation assesses how successful or unsuccessful the project was. Compare actual performance with authorised baselines for time, cost, scope, quality and other relevant objectives. Explain significant deviations and whether approved exceptions changed the final baseline.

The source notes that comparing estimates with actual performance can improve future estimating. Analyse where forecasts were accurate, where they were biased and what causes drove variation. This turns closure data into learning rather than merely recording variance.

Evaluate management performance as well as product delivery. Did stage controls work? Were issues escalated in time? Did quality criteria prevent late disputes? Were risk responses effective? Did stakeholders receive the information they needed? These lessons can strengthen later projects even when this project’s outputs were successful.

Benefits, lessons and follow-on actions

Assess benefits that have already been realised and update the Benefits Management Approach for reviews that must occur after closure. Confirm benefit owners, measures, baselines, timing and responsibility for performing the review once the project-management team is gone.

Capture lessons from the full lifecycle. The Lessons Log is consolidated into a Lessons Report where appropriate and made available for future use. The source stresses that premature projects also generate lessons; failure information can prevent repetition elsewhere.

Open issues and risks become follow-on action recommendations. The format depends on the recipient, but ownership should be explicit. Do not close a register simply to produce a clean dashboard if the underlying obligation still exists—transfer it first.

Activity — recommend project closure

Once the Project Manager confirms that closure conditions are met, a closure recommendation is raised to the Project Board. The Project Manager prepares the End Project Report, Lessons Report, updated Benefits Management Approach, follow-on recommendations and draft closure notification according to the tailored system.

The source also requires project information to be secured and archived so future audit of decisions, actions and performance remains possible. Issue, risk, quality, lessons and Daily Log records are closed after outstanding ownership has been addressed. Configuration information should reflect final product state.

The Board uses Directing a Project to authorise closure. Only then should the temporary project organisation be fully disbanded. Relevant stakeholders are informed according to the Communication Management Approach and responsibility for post-project work passes to the appropriate permanent organisation.

Practical verification checklist

• Plan closure activities in the final Stage Plan.
• Verify products are complete/approved or explicitly accounted for.
• Obtain authorised user/customer acceptance evidence.
• Confirm the receiving environment can support and own the products.
• Evaluate actual project performance against authorised baselines.
• Assess benefits realised and update post-project benefit review arrangements.
• Capture lessons, including lessons from premature closure.
• Transfer open risks, issues and actions to named post-project owners.
• Archive project information and final product/configuration status.
• Obtain formal Project Board closure authorisation before fully disbanding the team.

Common mistakes to avoid

• Assuming product delivery automatically closes the project.
• Claiming all benefits must be realised before closure.
• Disbanding the project team before operational ownership is clear.
• Closing risks and issues without transferring unresolved obligations.
• Skipping lessons because the project was terminated early.
• Allowing the project to remain informally open and continue incurring costs.

Related KEVOS handbook pages