PMBOK Closing Process Group: Closeout Checklist, Lessons Learned and Final Report
Projects do not end when the last task is done. They end when the work is accepted, the paperwork is finished, the contracts are closed, the team is released and the lessons are written down. Skipping that last stretch is how teams repeat the same mistakes. This guide covers the PMBOK closing process group: what it contains, a 13-point closeout checklist, how to run a useful lessons-learned session, a final report template and a worked example.
What the closing process group is
In the PMBOK Guide, Sixth Edition, the closing process group is the smallest: one process, Close Project or Phase, out of 49 in total. The Visual Paradigm guide to PMBOK 6 knowledge areas and 49 processes lists the counts as Initiating 2, Planning 24, Executing 10, Monitoring and Controlling 12 and Closing 1. The same guide notes that a separate Close Procurements process was removed in the Sixth Edition. Older study material may still show it.
Closing follows executing and uses what monitoring and controlling has accepted. It completes the cycle that began with the initiating process group. For how the groups relate to the life cycle, see the 5 phases of project management.
A note on editions. PMI’s page for the Eighth Edition (November 2025) says process guidance was reintroduced in a non-prescriptive way and does not describe the five groups by name. The closeout work below is good practice either way. Confirm which edition your course or exam uses.
The closeout checklist
Abdullah Oguz’s open textbook Project Management gives a list of closeout activities in its chapter Closing the Project. It says closing is a formal process in which the project manager reviews the plan to confirm all work is complete and objectives have been met, and that closure applies whether the project succeeds or fails. We have paraphrased its 13 activities and added a column for evidence.
| # | Closeout activity | Evidence that it is done |
|---|---|---|
| 1 | All tasks complete; deliverables checked and approved by the client | Signed acceptance |
| 2 | Project reports and documents collected and up to date | Final document set in the repository |
| 3 | All issues resolved, such as vendor disputes and stakeholder conflicts | Issue log with every item closed or handed over |
| 4 | All costs charged to the project | Finance confirms the final cost |
| 5 | Final deliverables released to the sponsor, clients and stakeholders | Handover record |
| 6 | Information shared to formalize acceptance of the project and deliverables | Distribution list and confirmation |
| 7 | Stakeholders notified that the project is complete | Completion notice sent |
| 8 | Supplier and vendor contracts terminated or closed | Closure letters; final invoices paid |
| 9 | Legal department consulted so no legal issues remain | Legal sign-off where relevant |
| 10 | Resources released: team members, facilities, equipment, materials | People reassigned; equipment returned |
| 11 | Post-implementation review, including lessons learned | Review meeting held; notes written |
| 12 | Paperwork finished; information archived in an organizational repository | Archive location recorded |
| 13 | Information easy to access later, such as cloud storage or physical files | Access tested by someone outside the team |
When projects close early or in phases
Closing is not only for projects that finish on plan. The Oguz textbook notes that projects can end in failure that leads to early termination. A phase can also be closed on a large project. Our summary of how closing differs:
| Situation | What changes |
|---|---|
| Normal completion | Full checklist, formal acceptance, final report and celebration. |
| Phase closure | Close the phase, confirm its deliverables and carry lessons into the next phase. |
| Early termination | Record why it stopped, what was completed, what is left, and how to dispose of work in progress. Settle contracts and release people with care. |
| Handover to operations | Add training, documentation and a support plan so the receiving team can run what you built. |
The lessons from a cancelled project can be just as valuable as those from a successful one, provided people feel safe to speak. See why projects fail.
The closing process, step by step
- Confirm completion. Compare the delivered work with the scope baseline and the acceptance criteria.
- Get formal acceptance. Obtain written sign-off from the client or sponsor.
- Close the money. Pay final invoices, confirm all costs are recorded and close the project’s accounts.
- Close contracts. Confirm suppliers have delivered, resolve open claims and record contract closure.
- Hand over. Transfer deliverables, documentation and any support responsibility.
- Hold the review. Run the lessons-learned session while memories are fresh.
- Release the team. Thank people, update their managers and reassign them.
- Archive and report. Store the records and issue the final report.
Running a lessons-learned session
Do it within a couple of weeks of delivery, include people from across the project, and keep blame out of it. A simple agenda, which is our suggestion:
- Goals and results (10 minutes). What did we set out to do, and what happened?
- What went well (15 minutes). What should we repeat?
- What did not (20 minutes). Focus on causes and systems, not people.
- What would we change (15 minutes). Specific actions with owners.
- Agree how to share it (5 minutes). Who records it and where does it live?
The test of a good lesson is whether someone on a different project could act on it.
| Weak lesson | Useful lesson |
|---|---|
| “Communication could be better.” | “Requirements changes reached developers by email and were missed. Use one shared change log and review it at each weekly meeting.” |
| “We ran out of time.” | “Testing was estimated at 2 days but took 6. Next time, ask testers to estimate and add a 30% buffer to testing tasks.” |
| “The supplier was bad.” | “The supplier had no delivery penalty in the contract. Include delivery dates and remedies in every supplier contract over a set value.” |
These examples are invented for illustration. Record real lessons in a shared repository, so the next team can find them.
Final project report template
Final project report: [project name]
Date: [date] · Prepared by: [name] · Sponsor: [name]
1. Summary: [Three sentences: what we set out to do, what we delivered, how it went.]
2. Objectives and results: [Each objective, its success measure, and the result.]
3. Scope: [Delivered / changed / dropped, with approved change requests.]
4. Schedule: Planned [dates] · Actual [dates] · Variance and reasons
5. Cost: Budget [amount] · Actual [amount] · Variance and reasons
6. Quality and acceptance: [Test results, defects open, date and name of sign-off.]
7. Risks and issues: [What happened, what is still open, who owns it now.]
8. Lessons learned: [Top five, each with a recommended action.]
9. Handover and support: [Who runs it now, documentation location.]
10. Benefits tracking: [Measures, owner, review dates.]
11. Recognition: [Who deserves thanks.]
Worked example
Take the website project from our planning and monitoring and controlling guides: a work budget of $13,200, a contingency of $1,320 (total $14,520) and a 24-day schedule. The final numbers below are our illustration.
| Measure | Plan | Actual | Variance |
|---|---|---|---|
| Work cost | $13,200 | $14,080 | +$880 (6.7% over) |
| Total with contingency | $14,520 | $14,080 | $440 below the total |
| Duration | 24 days | 27 days | +3 days (12.5% late) |
How to report it. The project went $880 over its work budget but stayed within the contingency, finishing $440 under the total. It ran three days late. Be honest about both: say what caused the overrun, and what you would do differently.
Three illustrative lessons.
- The overrun came from a content approval that took six days instead of two. Next time, book approvers’ review time in the plan.
- The payment integration was tested early, which saved time. Test the riskiest parts first.
- The change log stopped scope creep. Keep using it.
Then complete the checklist: get written acceptance, pay final invoices, hand the site to the support team, archive documents and release the team.
After closing: benefits
The Oguz textbook lists monitoring benefits realization after closing among the chapter’s learning objectives. The project delivers an output, such as a new system. The benefit is what the organization gains from it, such as faster orders or lower costs. Those benefits usually appear after the project team has gone.
Before you close, agree what will be measured, who owns it and when it will be reviewed, for example at three, six and twelve months. Use the measures from your original business case. See project management metrics for ideas.
Agile and hybrid projects
Agile teams close work more often. In common practice they end each iteration with a review of what was built and a retrospective on how the team worked. At the end of the whole effort, a final retrospective and a handover still apply. Contracts, budgets and archives need closing in the same way. See the use of agile project management.
Common mistakes
- Drifting to a stop. The project fades out with no formal end. Costs keep landing on it and nobody owns the leftovers.
- Releasing the team too early. People move on before the review, and memories fade.
- Blame in the review. People stop telling the truth.
- Lessons nobody reads. Store them where new projects will look, and ask planners to check them.
- No written acceptance. Disputes come later.
- Unclosed contracts. Open orders and unpaid invoices linger.
- Forgetting the benefits. The project is declared a success before anyone checks whether it worked.
If you are studying for the exam, our PMP exam prep course guide explains what to look for in a course, and project manager jobs shows what the role looks like day to day.
Frequently asked questions
What is the closing process group?
The PMBOK process group that formally completes the project or phase: confirming acceptance, closing contracts and records, releasing resources and capturing lessons.
How many processes are in the closing process group?
One in the PMBOK Guide, Sixth Edition: Close Project or Phase. An older Close Procurements process was removed in that edition.
What happens during project closure?
Deliverables are accepted, costs and contracts are closed, the team is released, a post-implementation review captures lessons, and records are archived.
What is a lessons-learned session?
A structured meeting held near the end of a project to record what went well, what did not and what to change next time.
Do cancelled projects need to be closed?
Yes. Closure applies whether a project succeeds or fails. Record why it stopped and what was learned.
What goes in a final project report?
A summary, objectives and results, scope, schedule and cost against plan, acceptance, risks, lessons learned, handover details and how benefits will be tracked.
Browse certificate, course and degree programs side by side.