Free Template · Word · Updated March 2026
Free Project Closure Report Template
Word Download
Every project deserves a proper ending. This structured Word template documents your final outcomes against objectives, schedule and budget performance, approved scope changes, key achievements, lessons learned and formal handover — giving sponsors, clients and future project teams a complete picture of how the project ended.
Objectives vs achieved
Side-by-side table comparing each planned objective against its actual outcome with a Met / Not Met status.
Schedule & budget analysis
Planned vs actual dates and costs with variance explanation fields — the two things sponsors always ask about first.
3-way sign-off section
PM, Sponsor and Client signature blocks — the formal confirmation that the project is officially closed.
Project Closure Report
Free Word template — instant download
Format
Word (.docx)
Sections
9 structured sections
Sign-off
3-way approval section
Performance
Schedule + budget analysis
Framework
PMI & PRINCE2 aligned
Price
Free — no signup needed
No email required. Instant Word download.
01 — Template Sections
What's in the Template — All 9 Sections
The closure report template follows the structure used across both PMI and PRINCE2 frameworks. It is designed to be completed by the PM and reviewed by the sponsor — not written jointly. The PM writes it; the sponsor approves it.
1
Project Summary
A brief description of the project, its original objectives and the overall outcome — Successful, Partially Successful or Unsuccessful. Sets the context for everything that follows.
2
Objectives — Achieved vs Planned
A row-per-objective table with planned target, actual result and a Met/Not Met status. Every objective from the original project charter should appear here — nothing left out, even the uncomfortable ones.
3
Schedule Performance
Planned vs actual start and end dates, schedule variance in days, and an explanation field. Also covers major milestone delivery — which milestones were hit on time and which slipped.
4
Budget Performance
Approved budget vs actual cost, variance in dollars and percentage, contingency usage and explanation. The template prompts for the reason — not just the number — so the sponsor understands the story behind the figures.
5
Scope Changes
A summary of approved change requests that altered the scope baseline — CR number, description, approval date and impact. This section is the audit trail that explains why the final scope differs from what was originally agreed.
6
Key Achievements
A bullet list of what went well and what the project is most proud of. Often overlooked in favour of the problems — but important for team morale and for surfacing good practices worth repeating.
7
Issues and Lessons Learned
A high-level summary of key lessons. The full detail belongs in the Lessons Learned Register — this section provides the top 3–5 lessons most relevant to future projects. Includes both positive lessons and areas for improvement.
8
Handover Summary
What was handed over, to whom, where documentation is stored and what support arrangements are in place. Links to the Handover Document for full detail.
9
Project Sign-Off
Three-way signature table: Project Manager, Project Sponsor, and Client/Customer representative. The sponsor's signature formally closes the project and releases the team and any remaining budget.
02 — Writing the Performance Sections
How to Write the Schedule and Budget Sections
Sections 3 and 4 are the ones sponsors read most carefully. They want to understand not just what happened but why — and what you would do differently. Here is how to approach each outcome honestly.
✅ Delivered on time & budget
On Track
State the variance clearly. "Delivered 2 days ahead of schedule and 3% under budget." Explain what contributed — good planning, contingency management, team performance. Don't be falsely modest.
⚠️ Minor variance
At Risk
Quantify the variance and name the root cause. "Delivered 8 days late due to CR-004 scope change approved in Week 6. Original delivery date met for all baseline scope." Approved changes explain variance — own it, but contextualise it.
❌ Significant overrun
Missed
Be direct — don't use passive language. "The project was delivered 6 weeks late and 18% over budget. Root cause: underestimated integration complexity at inception. Lesson: integration testing must be scoped with the technical lead before project approval."
The most important sentence in any closure report: "What we would do differently is…" Sponsors and future PMs reading this document years later care more about this than the exact variance numbers. One honest, specific lesson learned is worth more than a perfectly formatted performance table.
Reporting on Objectives That Weren't Met
If an objective was not achieved, it must appear in Section 2 with a "Not Met" status. Do not omit it, minimise it or reframe it as "partially met" unless the project truly delivered a proportion of that objective. Sponsors and auditors compare the closure report against the original project charter — inconsistencies undermine your credibility.
For each unmet objective, include: what was actually delivered, what the gap is, why it occurred (root cause, not excuse), and what will happen to the outstanding work — is it being picked up as a separate project, absorbed into BAU, or dropped?
03 — Closure Checklist
Project Closure Checklist — Before You Submit
The closure report is usually the last document a PM produces. Before submitting it for sponsor sign-off, work through this checklist to make sure the project is genuinely ready to close — not just the report.
✓
All deliverables formally accepted. The customer or business owner has signed the sign-off form confirming acceptance of every deliverable — not just informally agreed.
✓
Handover complete. The handover document is signed, the receiving team has confirmed they can support the solution, and all documentation is in the agreed repository location.
✓
All contracts and purchase orders closed. Supplier contracts are complete, final invoices paid or disputed, and procurement is confirmed closed with Finance.
✓
Team released. All project team members are formally released back to their line managers or reassigned. Their project time codes are closed so no further charges are raised against the project budget.
✓
Lessons learned documented. The Lessons Learned Register is completed and submitted to the PMO or knowledge base — not just included as a summary in this report.
✓
Financial close confirmed. Final cost report agreed with Finance, any unspent contingency formally returned or carried forward, and the project cost centre confirmed closed.
✓
Benefits realisation plan in place. If the project has expected benefits that will be measured post-go-live, confirm who owns benefits tracking and when the Post-Implementation Review will be scheduled (typically 3–6 months post-launch).
✓
Open risks and issues resolved or transferred. Any risks or issues that remain open must be formally transferred to the receiving team or business owner — not simply left open with no owner.
04 — Context
Closure Report vs Post-Implementation Review
These two documents are often confused but they serve very different purposes at very different times. Both are important — and the closure report should explicitly note when the PIR will take place.
This Template
Project Closure Report
When: At project end / go-live
Question: Did we deliver what we said we would?
Focus: Delivery vs plan — schedule, budget, scope, objectives
Audience: Sponsor, client, PMO
Outcome: Formal sign-off. Project officially closed.
Separate Document
Post-Implementation Review
When: 3–6 months after go-live
Question: Did it deliver the expected business outcomes?
Focus: Benefits realisation — actual vs projected ROI, KPIs
Audience: Business owner, sponsor, finance
Outcome: Benefits confirmed. Recommendations for future.
Both documents should be created for every significant project. The closure report is not complete without noting when the PIR is planned and who will own it. Download our Post-Implementation Review template to use alongside this closure report.
PMP exam note: In the PMBOK 7th edition, project closure is part of the Closing process group. Key outputs include the final project report (equivalent to this closure report), the transition of deliverables to operations, and the update of organisational process assets — including lessons learned. The exam distinguishes between closing a phase (stage gate) and closing the project (final). In PRINCE2, the Closing a Project process produces the End Project Report, the Benefits Management Approach and the Lessons Report. See our 200 PMP practice questions for closure-related scenario questions.
05 — FAQ
Project Closure Report — 4 Common Questions
A project closure report is a formal document produced at the end of a project that summarises the final outcomes. It records how the project performed against its original objectives, schedule and budget, documents approved scope changes, captures key lessons learned, confirms what was handed over and to whom, and obtains formal sign-off from the sponsor and stakeholders. It serves as the official record that the project is complete and provides a knowledge base for future projects.
A complete closure report should include: a project summary with overall assessment; objectives achieved vs planned; schedule performance with variance explanation; budget performance with variance explanation; a summary of approved scope changes; key achievements; lessons learned (with the full detail in a separate Lessons Learned Register); a handover summary confirming what was delivered, to whom and where documents are stored; and a formal three-way sign-off section.
The closure report is typically signed by three parties: the Project Manager (who prepares it), the Project Sponsor (who formally authorises closure and releases the team and budget), and the client or customer representative (who confirms acceptance of deliverables). The sponsor's signature is the most critical — it formally closes the project. In organisations with a PMO, a Programme Manager or PMO Director may also be required to countersign.
A project closure report is produced at the end of the delivery phase and documents what the project delivered against its plan. A post-implementation review is produced 3–6 months after go-live, once the solution has been in use long enough to measure whether the expected business benefits have been realised. The closure report asks "did we deliver what we said we would?" — the PIR asks "did it deliver the business outcomes we expected?" Both are important; the closure report should note when the PIR is planned and who will own it.
Explore More Free PM Resources