PMP Project Closure Checklist: Steps, Lessons & Handover

The closures I have run well are the ones I remember fondly. The closures I have run badly are the ones that haunt me. I once let a project end without a proper handover meeting because the team was tired and the next assignment was already pulling at our calendars. Six months later, the operations team that inherited the system had no idea who to call when an integration broke. The fault was mine. The closure phase had been rushed, the lessons were never written down, and the people who could answer the questions had already left for other work.

Closure is the most neglected of the five process groups. It is also the one that determines whether the organisation actually gets the value the project was supposed to deliver. PMI defines this in Process 4.7, Close Project or Phase, the final process in the Integration Management knowledge area. Closure covers deliverable acceptance, contract closure, lessons learned, archiving, final reporting, team release, and the often-forgotten stakeholder thank-you. In this article I will walk through a complete closure checklist, give a step-by-step facilitation guide for lessons learned workshops, examine the common ways closure goes wrong, and provide a template for the closure report I have used on roughly twenty projects.

Project closure is the formal completion of all activities across all process groups, leading to the orderly conclusion of the project or phase. It is not the same as "we finished the work." Work finishes when the last deliverable is accepted. Closure is the administrative, organisational, and emotional wind-down that should follow.

Closure exists for several reasons. It marks the formal transition from project mode to operations mode. It captures the experience of the team while it is fresh. It ensures contracts are properly concluded and obligations released. It releases the team to other work cleanly. And it leaves behind the artefacts that future projects can learn from.

"The work was finished in October. Closure took us until December. The team thought we were stalling. In retrospect, those eight weeks saved the operations team a year of pain."

I treat closure as a project within the project. It has its own scope, schedule, and budget. On larger projects I assign a dedicated closure coordinator. On smaller projects the PM does it personally. Either way, the closure period is planned, not improvised.

In the PMBOK Guide Sixth Edition, Process 4.7 Close Project or Phase is the final integration process. It belongs to the Closing Process Group and consumes the following inputs: the project charter, the project management plan, project documents (including the assumption log, change log, lessons learned register, risk register, and quality reports), accepted deliverables, business documents, agreements, procurement documentation, and organisational process assets.

The techniques include expert judgement, data analysis (document analysis, regression analysis, trend analysis, variance analysis), and meetings. The outputs are the project documents updates, the final product or service transition, the final report, and updates to the organisational process assets (specifically the lessons learned repository and the historical information archives).

For the exam, the key things to know:

• Closure happens after all deliverables are accepted
• Accepted Deliverables is a required input (no acceptance, no closure)
• Lessons Learned is finalised and added to the OPA
• A Final Report is produced
• The project manager remains accountable through closure

A common exam trap is to suggest closure can be skipped if the project is cancelled. PMI is clear that even cancelled projects are formally closed; the reason for closure is documented.

The checklist I use on every project, with rough effort estimates, is below.

This list looks long, but most items run in parallel. On a typical project I plan for a closure window of three to six weeks, ending with formal sponsor sign-off.

Acceptance is the prerequisite for closure. Without explicit, documented acceptance, the project cannot close. PMI describes this in Process 5.5 Validate Scope, but it culminates in the closure phase.

I use a simple acceptance record for each deliverable: name, description, acceptance criteria, evidence of meeting criteria, accepter (name and role), date, and signature. The collection of acceptance records becomes the basis for closure.

"If the customer cannot describe what they received and confirm it meets their criteria, you have not finished the project. You have stopped working on it."

Three patterns to be aware of:

1. Provisional acceptance. Common when there are minor punch-list items. Documented as accepted with a list of agreed remediation items.
2. Conditional acceptance. Acceptance with conditions that must be met within a defined window. Useful when warranty or stabilisation is involved.
3. Refusal to accept. Rare but real. Triggers a recovery plan rather than closure.

Premature acceptance is one of the most damaging closure mistakes. If the customer signs only because the team is leaving, the operational handover will be painful.

Contract closure ensures every procurement agreement is properly concluded. It includes:

• Confirming all deliverables under the contract are received
• Confirming all payments are made or scheduled
• Releasing any retentions or bonds
• Filing any warranties or service-level agreements
• Documenting any disputes and their resolution
• Obtaining formal release from each vendor

On one project I closed, we discovered three months after closure that we had not formally released the warranty on a piece of equipment, which meant we had been paying for cover we no longer needed. A clean contract closure prevents this.

PMI is specific that contract closure is administrative closure on the procurement side. It happens before or alongside project closure. The legal department or commercial team often leads it, but the PM is accountable for its completion.

The lessons learned workshop is the single highest-value closure activity, and the one most often done badly. The classic failure mode is to schedule it in the last week, with the entire team in a tired Friday afternoon meeting, and to leave with a flipchart full of complaints that nobody types up.

My facilitation guide:

1. Schedule two workshops, not one. A mid-project workshop (often at major milestone) and a closure workshop. The mid-project one captures fresh details that would otherwise be forgotten.
2. Hold workshops in the morning. Energy is higher and people are more reflective.
3. Set ground rules. Blameless framing. Focus on systems and processes, not individuals.
4. Use a structured prompt. I use: "What worked well? What did not work? What surprised us? What would we change? What should the organisation know?"
5. Capture in real time. I have a notetaker writing into a shared document while the conversation happens.
6. Separate the lesson from the action. A lesson is an insight. An action is what we will do about it. Both should be captured but distinguished.
7. Categorise each lesson. People, process, technical, organisational, external.
8. Identify the audience. Some lessons are for the team (immediate). Some are for the PMO (process). Some are for the executive (strategy).
9. Close the loop within two weeks. Publish the lessons, share them with named owners, and confirm what will be done.
10. Feed the lessons into OPAs. This is the difference between lessons learned and lessons captured.

A good lessons learned session leaves the team feeling they have contributed something useful. A bad one leaves them frustrated that nothing will change.

The project archive is the corpus of documents and data that the organisation retains. Without an archive, the project's existence dissolves into individual memories that drift apart over time.

What I archive on every project:

• The signed charter
• The final project management plan and baselines
• All change requests and their approvals
• The lessons learned register
• The final risk register and issue log
• The acceptance records for all deliverables
• The final report
• All contracts and their closure documents
• Significant correspondence (escalations, decisions)
• The project schedule final version
• Final cost reports
• Quality reports and any audit findings
• The communications plan and key communications

I do not archive every Slack message, every meeting transcript, or every working draft. The archive is curated, not exhaustive. The discipline is to prune ruthlessly so future readers can find what matters.

Archive location varies by organisation: SharePoint, Confluence, a dedicated PMO repository, or an enterprise document management system. Whatever the platform, the archive should outlive the project team and be discoverable by name, date, sponsor, and topic.

The final report is the single most important closure document because it is what future managers will read. I keep mine to ten pages plus appendices.

Structure I use:

1. Executive summary (one page)
2. Project recap: original purpose, objectives, success criteria (one page)
3. What was delivered: actual deliverables, with reference to acceptance records (one to two pages)
4. Performance against baselines: cost, schedule, scope, quality variance (one page)
5. Variance analysis: why we differed from plan (one to two pages)
6. Lessons learned summary: top ten, with owners (one to two pages)
7. Benefits realisation plan: what should be measured, by whom, when (one page)
8. Outstanding items: anything not closed and how it will be handled (one page)
9. Acknowledgements: team, partners, sponsors (half page)
10. Appendices: detailed cost, schedule, lessons register

The final report is signed by the PM and acknowledged by the sponsor. It is the formal record of project completion.

Releasing the team is more than removing them from the resource plan. It is the formal handover of accountability and recognition of effort.

What I do for every team member at closure:

• A direct conversation about what they contributed
• A formal note to their line manager describing their role and impact
• An entry in their performance record where the organisation supports this
• A specific named acknowledgement in the final report and closure communication
• An invitation to a closure event (formal or informal)

This is not optional. People remember how they were treated at the end of a project more than how they were treated at the start. Treating closure as a chance to recognise the team strengthens the network you will draw on for future projects.

"The team you treat well at closure is the team you can phone next year and they will pick up."

The closure communication is often skipped. It should not be. Stakeholders who supported the project should hear from the PM at the end, with three messages: what was delivered, what was learned, and what comes next.

A typical closure communication contains:

• A one-paragraph summary of what was delivered
• A short list of measurable outcomes against objectives
• Recognition of contributors
• A handover note to operations (who to contact going forward)
• A pointer to the final report and archive

I send this within two weeks of formal closure to all stakeholders who were on the communications plan distribution list. The format is usually a short email plus a one-page PDF attachment.

The thank-you to the sponsor is often a separate, more personal communication. I find a handwritten note works well; it lands differently from email.

The failures I have seen and (in some cases) committed:

1. Premature closure. The team disperses before deliverables are properly accepted. Recovery is painful.
2. Lessons lost. Workshops happen but the lessons are never written up or shared.
3. Archive chaos. Documents scattered across personal drives, never consolidated.
4. No final report. Closure announced informally without the formal record.
5. No benefits owner. The project ends but nobody is accountable for measuring whether the benefits actually arrive.
6. No operations handover. Deliverables transferred without a structured handover meeting, runbooks, or contact list.
7. Open change requests. Closure forced through with change requests still in flight.
8. Contracts not closed. Vendors continue to bill or hold retentions.
9. Team not released. Resources marked as project-allocated months after closure, blocking other work.
10. Sponsor not signing off. Closure happens in PM's head but is not formally agreed.

The discipline to avoid these is simply to follow the checklist. Closure failures are almost always failures of method, not of intention.

A condensed template, suitable for projects of medium scale.

PROJECT CLOSURE REPORT

Project name: [Name]
Project ID: [ID]
Sponsor: [Name]
Project manager: [Name]
Closure date: [Date]

1. Executive summary

One paragraph summary of the project, its outcome, and notable highlights.

2. Original objectives and outcomes

3. Performance against baselines

4. Deliverables accepted

List of deliverables with reference to acceptance records.

5. Outstanding items

Any work not completed and how it will be handled (post-project, by operations, deferred).

6. Top ten lessons learned

Numbered list with owner and target action.

7. Benefits realisation plan

What will be measured, by whom, by when.

8. Risks transferred to operations

Active risks at closure that move to the operational owner.

9. Contract closure status

Confirmation that all contracts are closed; any exceptions noted.

10. Team recognition

Named contributors.

11. Sponsor sign-off

Signature, name, date.

Process 4.7 covers both phase closure and project closure. The mechanics are similar but the emphasis differs.

Phase closure happens at the end of each major phase in a multi-phase project. It produces a phase end report, a go/no-go decision for the next phase, and updates to the project baselines. Lessons learned are captured but the team typically continues.

Project closure is the final closure described above. It produces the final report, releases the team, archives the project, and formally ends the project.

Both follow the same checklist, scaled to context. Phase closures are usually lighter on stakeholder communication and team release because the project continues.

Agile projects close at the end of a release or at the end of the product. The mechanics differ because Agile teams produce working software increment by increment.

In a Scrum-based programme I supported, the closure activities were spread across the final sprints rather than concentrated in a closure phase:

• The final sprint included formal acceptance of the release
• Lessons learned were captured in the final retrospectives plus a release-level workshop
• The archive was maintained as the project ran (digital-first)
• The final report drew on burnup charts, velocity data, and acceptance records
• The team was released to the next product or remained as a product team

For hybrid projects I treat the predictive elements with classical closure and the Agile elements with sprint-style closure, then write a combined final report. The two work together more easily than candidates expect.