14.1 Closing a Project (CP) Process: Handover, Acceptance & Lessons

Closing a Project (CP) Process: Handover, Acceptance & Lessons in PRINCE2 7

Practitioner Core Mandate: In professional project management, an undefined or informal ending is as dangerous as an unplanned start. Without a definitive, formalized closure process, projects inevitably fall victim to "project drift"—an expensive condition where project teams continue incurring expenditure, absorbing operational maintenance, tweaking minor deliverables, and blurring accountability long after original objectives have been delivered. The Closing a Project (CP) process provides a disciplined boundary, ensuring that products are formally transferred to operational ownership, residual risks are handed over, corporate resources are released, and hard-won lessons are systematically captured.

---

1. Purpose, Objectives & Context of Closing a Project (CP)

The Fundamental Purpose of Closing a Project

The purpose of the Closing a Project (CP) 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 Project Initiation Documentation (PID) have been achieved (or that the project has nothing more to contribute), and that the project is brought to an orderly end.

Core Governance Objectives

To achieve this purpose, the CP process ensures that:

• Operational Verification: The project team verifies that all products scheduled for delivery have been completed, tested, and accepted according to their agreed Product Descriptions.
• Definitive Handover: Operational ownership of the products is formally transferred to the customer and operational maintenance teams, ensuring ongoing support arrangements are active.
• Performance Evaluation: Project performance is comprehensively audited against the baselines established in the PID across all seven performance targets (Cost, Time, Quality, Scope, Benefits, Risk, and Sustainability).
• Release of Resources: Equipment, facilities, specialist personnel, and unspent capital budgets are formally released back to the business or redeployed.
• Organizational Learning: Lessons learned throughout the project lifecycle are extracted from the Lessons Log and compiled into a structured Lessons Report for organizational dissemination.
• Follow-on Actions: Any uncompleted work, unresolved issues, and residual risks are systematically captured as Follow-on Action Recommendations and transferred to operational managers.

                  THE CLOSING A PROJECT LIFECYCLE BRIDGE

   FINAL DELIVERY STAGE                                CLOSURE & OPERATIONS

   ┌──────────────────────────────────────────────┐
   │ CONTROLLING A STAGE (CS)                     │
   │ • Final specialist deliverables built        │
   │ • Acceptance criteria validated              │
   └──────────────────────┬───────────────────────┘
                          │ PM triggers closure
                          ▼
   ┌──────────────────────────────────────────────┐
   │ CLOSING A PROJECT (CP)                       │
   │ • Confirm acceptance & sign-off              │
   │ • Evaluate project (End Project Report)      │
   │ • Compile Lessons Report                     │
   │ • Document Follow-on Action Recommendations  │
   └──────────────────────┬───────────────────────┘
                          │ PM recommends closure
                          ▼
   ┌──────────────────────────────────────────────┐    ┌─────────────────────────┐
   │ DIRECTING A PROJECT (DP):                    │───►│ POST-PROJECT OPERATIONS │
   │ AUTHORIZE PROJECT CLOSURE                    │    │ • Benefits reviews      │
   │ (Project Board formally closes project)      │    │ • Ongoing maintenance   │
   └──────────────────────────────────────────────┘    └─────────────────────────┘

Lifecycle Placement: A Process, Never a Stage

A vital distinction tested rigorously on the PRINCE2 Practitioner exam is the lifecycle position of Closing a Project:

• CP is an event-driven process executed by the Project Manager near the end of the final management stage.
• CP is NOT a separate management stage. There is never a standalone "Closure Stage" on the project schedule. The work of closing down the project is planned and executed under the approved Stage Plan for the final delivery stage.
• When the final specialist products are being finished and verified within the final stage, the Project Manager initiates the activities of CP instead of executing Managing a Stage Boundary (SB).

Division of Authority: The PM Prepares, the Project Board Decides

A critical governance boundary governs project termination:

• The Project Manager executes the CP process: preparing closure, facilitating product handover, compiling reports, and recommending project closure.
• The Project Manager never closes the project on their own authority.
• Only the Project Board—acting under the Directing a Project (DP) process in the activity Authorize project closure—has the delegated executive authority to declare the project officially ended, disband the Project Management Team, and release remaining funds.

---

2. The Five Activities of Closing a Project (CP)

PRINCE2 7 table 19.1 names five activities (19.4.1 to 19.4.5). Two of the 6th Edition names have changed: confirm project acceptance is now confirm project acceptance, and there is no separate learn lessons activity — the lessons report is an output of evaluate the project, and CP ends with request project closure. Note also that the planned and premature routes share the last three activities:

┌─────────────────────────────────────────────────────────────────────────────┐
│                 THE 5 ACTIVITIES OF CLOSING A PROJECT (CP)                  │
├─────────────────────────────────────────────────────────────────────────────┤
│ 19.4.1 PREPARE PLANNED CLOSURE                                              │
│    • Verify that all products are completed, verified, and approved.        │
│    • Use the communication management approach to tell interested parties.  │
│    • Close the project log; secure and archive all project information.     │
│    • Update the Project Plan with actual delivery metrics and final costs.  │
├─────────────────────────────────────────────────────────────────────────────┤
│ 19.4.2 PREPARE PREMATURE CLOSURE (alternative entry, on a premature close   │
│        request from the project board)                                      │
│    • Salvage useful deliverables, secure work in progress, cancel orders.   │
│    • Document reasons for termination and financial impacts.                │
├─────────────────────────────────────────────────────────────────────────────┤
│ 19.4.3 CONFIRM PROJECT ACCEPTANCE                                           │
│    • Confirm operational and maintenance arrangements are in place.         │
│    • Transfer physical, digital, and legal custody of products to users.    │
│    • Obtain formal, recorded acceptance against the acceptance criteria.    │
│    • Record unresolved items as follow-on action recommendations.           │
├─────────────────────────────────────────────────────────────────────────────┤
│ 19.4.4 EVALUATE THE PROJECT                                                 │
│    • Audit actual performance against the PID baselines across all seven    │
│      targets (cost, time, quality, scope, benefits, risk, sustainability).  │
│    • Outputs: END PROJECT REPORT and LESSONS REPORT created; benefits       │
│      management approach updated if required.                               │
├─────────────────────────────────────────────────────────────────────────────┤
│ 19.4.5 REQUEST PROJECT CLOSURE                                              │
│    • Output: project closure request, which triggers Directing a Project    │
│      (activity 14.4.5 'authorize project closure').                         │
│    • The project board — not the project manager — closes the project.      │
└─────────────────────────────────────────────────────────────────────────────┘

[!EXAM WATCHPOINT: CP ACTIVITY NAMES] Options built on confirm project acceptance or learn lessons are using 6th Edition names. In PRINCE2 7 the third activity is confirm project acceptance, the lessons report comes out of evaluate the project, and the process ends by requesting closure — the closure decision itself belongs to the project board in DP.

Activity 1 (19.4.1): Prepare Planned Closure

In a standard, successful project lifecycle, the Project Manager initiates closure when all products in the final Stage Plan are nearing completion:

• Verification against Baselines: The Project Manager checks the baselined Project Product Description from the PID and individual Product Descriptions to verify that every agreed deliverable has been built, quality-checked, and approved.
• Product Register Check: The PM reviews the project log: product register to verify that every product has reached an approved status at the expected version.
• Updating the Project Plan: The PM records actual completion dates, resource consumption, and expenditures, calculating final baseline variances.

Activity 2 (19.4.2): Prepare Premature Closure

If the Project Board determines that the project is no longer viable, desirable, or achievable (or if the business layer cancels the initiative), the Board instructs the PM to close the project prematurely. The PM executes this activity instead of planned closure (detailed in Section 14.2).

Activity 3 (19.4.3): Confirm Project Acceptance

Specialist deliverables cannot be abandoned at the project boundary. The PM oversees the operational transition to business-as-usual (BAU):

• Operational Readiness Confirmation: Verifying that support contracts, service desks, operating manuals, and training are ready.
• Transfer of Ownership: Transferring legal, physical, and digital custody of the deliverables to operational managers.
• Formal Customer Acceptance: Securing formal sign-off from the Senior User and customer representatives.
• Follow-on Action Recommendations: Documenting any unfulfilled requirements, minor defects accepted under concession, or ongoing maintenance advice.

Activity 4 (19.4.4): Evaluate the Project

The Project Manager performs a forensic evaluation of delivery performance, comparing final outcomes against the baselines in the PID across all seven performance targets. This single activity produces two reports: the End Project Report captures how the project performed, and — operationalizing the principle learn from experience — the Lessons Report synthesizes transferable insights drawn from the lessons log and from interviews with team members and stakeholders. The benefits management approach is also updated here if required, because post-project benefit reviews must be owned by someone after the team disbands.

Activity 5 (19.4.5): Request Project Closure

The Project Manager submits a project closure request to the project board, attaching the End Project Report and Lessons Report. This triggers authorize project closure (14.4.5) in Directing a Project. The project manager prepares the case for closure; only the project board can issue the project closure notice that actually ends the project.

---

3. Confirming Project Acceptance: Operational Readiness, Ownership & Sign-Off

The handover of specialist deliverables represents the physical and legal realization of the project's investments. Handover is not a casual drop-off; it is a structured transfer of operational accountability.

┌─────────────────────────────────────────────────────────────────────────────┐
│                     THE PRODUCT HANDOVER CHECKLIST                          │
├─────────────────────────────────────────────────────────────────────────────┤
│ 1. OPERATIONAL & MAINTENANCE READINESS:                                     │
│    • Operational Support Agreements (Service Level Agreements / OLAs active)│
│    • Helpdesk, ticketing, and tier-1/2/3 technical support mobilized        │
│    • Operational staff and end-users fully trained with documentation       │
│    • Spare parts, supply-chain logistics, and vendor warranty terms active  │
│    • Digital security access, source code repositories, and data archived   │
├─────────────────────────────────────────────────────────────────────────────┤
│ 2. FORMAL CUSTOMER ACCEPTANCE:                                              │
│    • Validation of acceptance criteria in Project Product Description       │
│    • Unconditional acceptance OR Acceptance with concessions (agreed minor  │
│      defects to be resolved in operational maintenance)                     │
│    • Formal signed acceptance certificate from Senior User / Customer       │
├─────────────────────────────────────────────────────────────────────────────┤
│ 3. ASSET & CUSTODY TRANSFER:                                                │
│    • Product register status and acceptance dates updated                   │
│    • Transfer of legal titles, building occupancy permits, or IP licenses   │
│    • Financial assets, operational operating budgets, and warranties handed │
│      over to designated operational asset owners                            │
└─────────────────────────────────────────────────────────────────────────────┘

The Operational Readiness Checklist

Before a customer can take custody of deliverables, operational support systems must be active. Handing over an automated warehouse without trained maintenance engineers or warranty contracts guarantees operational failure. The PM must verify:

• Operational service level agreements (SLAs) and operating level agreements (OLAs) are executed.
• Operations and maintenance staff have received required technical training and documentation.
• Facilities, equipment warranties, software licenses, and cloud tenant ownership are transferred.
• Health, safety, environmental, and statutory compliance certifications are filed with relevant regulators.

Full Acceptance vs. Acceptance with Concessions

On the Practitioner exam, handover scenarios frequently involve deliverables that do not achieve 100% perfection:

• Unconditional Acceptance: The product satisfies every acceptance criterion defined in the Project Product Description and individual Product Descriptions without exception. The customer signs the acceptance certificate unconditionally.
• Acceptance with Concessions (Conditional Acceptance): The customer agrees to accept delivery of the product despite minor non-critical defects, cosmetic flaws, or uncompleted secondary features.
  • The customer and Project Board agree that the defects do not justify delaying closure or keeping the project team mobilized.
  • The Project Manager must document these accepted deficiencies as Follow-on Action Recommendations.
  • Operational business teams absorb the responsibility for rectifying these concessions under standard operational maintenance budgets.

[!CRITICAL EXAM RULE] Concessions Must Be Documented: Under PRINCE2 7, a Project Manager must never ignore or informally conceal a defect during handover. If a customer accepts a product with flaws, it must be formally classified as an "acceptance with concessions" and logged in the Follow-on Action Recommendations. Omitting concessions from handover documentation breaches the Focus on products and Manage by exception principles.

---

4. Evaluating the Project & Synthesizing Lessons Learned

Project closure requires an honest, objective audit of delivery performance. The Project Manager produces two foundational management products during closure: the End Project Report and the Lessons Report.

                    EVALUATION & LEARNING FLOW IN CLOSURE

   HISTORICAL BASELINES                  DELIVERY RECORDS                CLOSURE OUTPUTS

   ┌────────────────────┐                ┌─────────────────────┐
   │ Project Initiation │                │ Final Project Plan, │
   │ Documentation      │───────────────►│ Registers, Quality  │────────►[END PROJECT REPORT]
   │ (PID Baselines)    │                │ Records, Actuals    │         (Audit against
   └────────────────────┘                └─────────────────────┘          7 targets)

   ┌────────────────────┐                ┌─────────────────────┐
   │ Lessons Log        │───────────────►│ Team Interviews,    │────────►[LESSONS REPORT]
   │ (Recorded across   │                │ Supplier Reviews,   │         (Corporate
   │ all stages)        │                │ Experience Data     │          dissemination)
   └────────────────────┘                └─────────────────────┘

Evaluating the Project (The End Project Report)

The Project Manager compares actual project outcomes against the baseline targets established in the approved Project Initiation Documentation (PID). This audit covers:

1. Performance Across the Seven Targets: Final variance against baselines for Cost, Time, Quality, Scope, Benefits, Risk, and Sustainability.
2. Business Case Viability: Final projected investment return, operational savings, and verified dis-benefits compared to the original initiation business justification.
3. Product Performance: Summary of acceptance records, concessions granted, and off-specifications resolved.
4. Team and People Performance: Evaluation of leadership effectiveness, team collaboration, and stakeholder communication (operationalizing the People aspect).

Synthesizing Lessons (The Lessons Report)

PRINCE2 operationalizes the core principle Learn from experience across the entire project lifecycle:

• During Starting Up a Project (SU), the PM initializes the Lessons Log with historical lessons from previous projects.
• During Controlling a Stage (CS) and Managing a Stage Boundary (SB), the PM logs new operational experiences, anomalies, and successful techniques in the Lessons Log.
• During Closing a Project (CP), the PM extracts and analyzes the contents of the Lessons Log to author the Lessons Report.

Lessons Log vs. Lessons Report: The Essential Distinction

---

5. Managing Residual Risks & Follow-on Action Recommendations

When a project closes, its temporary governance structures dissolve. However, operational risks and unfinished tasks do not disappear into thin air. PRINCE2 mandates an orderly transition mechanism: Follow-on Action Recommendations.

┌─────────────────────────────────────────────────────────────────────────────┐
│         THE TRANSITION OF UNFINISHED ITEMS & RESIDUAL RISKS                 │
├─────────────────────────────────────────────────────────────────────────────┤
│ PROJECT DOMAIN (CLOSING DOWN)           OPERATIONAL DOMAIN (BUSINESS-AS-USUAL)│
│                                                                             │
│ ┌──────────────────────────┐            ┌─────────────────────────────────┐ │
│ │ Uncompleted Scope /      │           │ OPERATIONAL WORK ORDERS:        │  │
│ │ Outstanding RFCs         │──────────►│ Scheduled for future operational│  │
│ └──────────────────────────┘            │ software releases or maintenance│ │
│                                         └─────────────────────────────────┘ │
│ ┌──────────────────────────┐            ┌─────────────────────────────────┐ │
│ │ Accepted Deficiencies    │           │ WARRANTY & MAINTENANCE QUEUE:   │  │
│ │ (Concessions)            │──────────►│ Rectified by contractor under   │  │
│ └──────────────────────────┘            │ post-handover warranty clauses  │ │
│                                         └─────────────────────────────────┘ │
│ ┌──────────────────────────┐            ┌─────────────────────────────────┐ │
│ │ Active Threat /          │           │ OPERATIONAL RISK REGISTER:      │  │
│ │ Opportunity Risks        │──────────►│ Transferred to departmental     │  │
│ └──────────────────────────┘            │ risk owners for ongoing tracking│ │
│                                         └─────────────────────────────────┘ │
│ ┌──────────────────────────┐            ┌─────────────────────────────────┐ │
│ │ Closed Project Logs      │           │ CORPORATE KNOWLEDGE ARCHIVE:    │  │
│ │ (Risk, Issue, Quality)   │──────────►│ Archived for audit, statutory   │  │
│ └──────────────────────────┘            │ compliance, and PMO analytics   │ │
└─────────────────────────────────────────────────────────────────────────────┘

Scope of Follow-on Action Recommendations

Follow-on Action Recommendations ensure that operational managers have complete visibility into the status of the product. They record:

• Residual Risks: Threats or opportunities identified on the project Risk Register that will persist during the operational lifespan of the product (e.g., supply chain dependencies for replacement components, cyber vulnerability patch schedules). These are formally transferred to operational risk registers.
• Unresolved Issues & Off-Specifications: Defects accepted under concession, uncompleted secondary features, or outstanding Requests for Change (RFCs) that were rejected during delivery due to budget/time constraints but are recommended for future operational releases.
• Operational Advice: Specific maintenance recommendations, servicing schedules, licensing renewal milestones, or post-implementation review instructions.

Closing Registers and Archiving Records

Once all products are handed over and reports compiled, the PM prepares the project records for archival:

• The Risk Register, Issue Register, Quality Register, and Daily Log are formally closed.
• Open items are checked to confirm they have been transferred to Follow-on Action Recommendations.
• All project records, configuration management records, baseline documents, and audit trails are secured and archived in corporate records management systems in compliance with statutory, legal, and company data retention policies.

---

6. Comparative Analysis: Managing a Stage Boundary (SB) vs. Closing a Project (CP)

Practitioners frequently confuse the end of an intermediate stage with project closure. The following comparative matrix highlights the critical governance differences:

---

7. Practical Scenario Evaluations

Scenario A: The Never-Ending Migration (Operational Drift)

A government agency engages a software systems integrator to replace its legacy revenue collection database. The project completes all core database migrations, user acceptance testing is signed off, and tax processing is operational. However, because three minor cosmetic interface bugs remain open and two external database connectors require quarterly API patching, the Project Manager refuses to close the project. For nine months, the project team remains mobilized, billing £80,000 monthly in project overhead while performing routine day-to-day database patch maintenance.

Practitioner Evaluation:

• Governance Failure: Severe project drift and failure to execute the Closing a Project (CP) process. The PM has confused project delivery with ongoing business-as-usual operations.
• PRINCE2 Violation: The project should have closed immediately following successful migration and core acceptance. The minor interface bugs and future API patch requirements should have been documented as Follow-on Action Recommendations and handed over to internal IT operations.
• Consequences: The agency wasted hundreds of thousands of pounds in project governance overhead for tasks that belonged in standard operational maintenance budgets.

Scenario B: The Unilateral Closure Trap

On a smart city traffic camera installation project, the Project Manager completes the final camera installations, verifies that all acceptance criteria are met, and compiles the End Project Report. Believing that closure is purely administrative, the PM sends an email to the entire organization stating: 'The project is officially closed and terminated as of today.' The PM instructs the equipment rental vendor to collect their scaffolding and reassigns the specialist camera technicians to other department initiatives without notifying the Project Board.

Practitioner Evaluation:

• Governance Failure: Breach of the Defined Roles and Responsibilities and Manage by Exception principles. The Project Manager possesses zero authority to unilaterally close a project.
• PRINCE2 Violation: In CP, the PM merely prepares closure, compiles documentation, and formulates a recommendation to close. The formal authority to close the project rests exclusively with the Project Board executing the activity Authorize project closure in Directing a Project (DP).
• Consequences: The PM exposed the organization to severe commercial and operational risk. If the Senior User or Senior Supplier had disputed final contract payments, maintenance readiness, or asset condition, the Project Board had no opportunity to review the End Project Report or verify customer acceptance before resources were prematurely disbanded.

Scenario C: The Discarded Defects Pitfall

During final product handover for a commercial pharmaceutical packaging facility, the customer operations director agrees to sign the acceptance certificate on the condition that 12 minor calibration adjustments on the secondary conveyor belts are executed within 45 days. The PM is anxious to present a 'flawless' project to the Project Board, so the PM signs the customer acceptance agreement, deletes the 12 issues from the Issue Register, and omits any mention of them from the End Project Report. Six weeks later, uncalibrated conveyors jam, halting pharmaceutical shipping and causing £1.2M in perishable drug spoilage.

Practitioner Evaluation:

• Governance Failure: Unethical concealment of defects and gross violation of the Focus on Products principle and product handover procedures.
• PRINCE2 Violation: When products are accepted with outstanding deficiencies, the handover must be classified as an acceptance with concessions. The PM must capture every outstanding item, calibration requirement, and associated operational risk within the Follow-on Action Recommendations.
• Consequences: By failing to record follow-on recommendations, the operational facility managers had no record of the required 45-day calibration schedule, resulting in catastrophic operational failure and liability.

---

8. Responsibilities in CP: The RACI Chart and Practice Application

Table 19.2 — RACI for closing a project

Key: A Accountable (one role only) · R Responsible · C Consulted · I Informed. An empty cell means no assigned part.

Reading the chart

• The project manager is Responsible for all five CP activities and Accountable for none. Closure is prepared by the project manager and answered for by the project executive — which is the RACI expression of the rule that only the project board can actually close a project.
• Confirm project acceptance narrows the circle. The team manager, project assurance, and project support all drop to Informed; only the project executive, senior user, and senior supplier remain consulted. Acceptance is a business, user, and supplier decision, not a delivery-team one.
• The business layer appears exactly once, as Informed on request project closure. It does not authorize closure — the project board does, in DP activity 14.4.5.

How the practices are applied in CP (table 19.3)

Business case is evaluated against actuals and the benefits management approach is updated and handed over for post-project reviews; quality confirms via the quality register and product register that products reached an approved status and were accepted at a known version; plans is updated with final actuals; risk and issues transfer anything still open into follow-on action recommendations; progress produces the end project report against all seven performance targets and the lessons report; organizing releases the project management team and closes the project log.

---

9. Practitioner Exam Pitfalls & Governance Traps

• Trap 1: Believing Closing a Project is a Standalone Stage: On the exam, any option stating that the project enters a "Closure Stage" or that the PM drafts a "Closure Stage Plan" is strictly incorrect. Closing a Project is a process executed within the final management stage under the final Stage Plan.
• Trap 2: Believing the Project Manager Closes the Project: The PM prepares closure and recommends closure. Only the Project Board can formally authorize project closure under Directing a Project.
• Trap 3: Sweeping Minor Deficiencies Under the Rug: Exam questions often test whether a PM should delay closure until 100% of minor bugs are fixed. The correct PRINCE2 approach is to agree on an acceptance with concessions, log the outstanding items as Follow-on Action Recommendations, transfer them to operations, and proceed with closure.
• Trap 4: Assuming All Benefits Must Be Realized Before Closure: Projects deliver outputs (products), not necessarily final benefits. Most business benefits (e.g., 5-year revenue increases, market share growth) can only be realized during ongoing operations post-project. The project can and must close once outputs are accepted and the Benefits Management Approach is handed over.
• Trap 5: Thinking Registers Are Deleted Upon Closure: The Project Manager never deletes or destroys the Risk Register, Issue Register, Quality Register, or Daily Log. They are formally closed, signed off, and archived as corporate records to provide an unassailable audit trail.