Certifications PMP CertificationWorld’s top PM cert CSM: Certified ScrumMasterTop agile cert CAPMEntry-level PM cert PRINCE2UK & Europe standard View All Certifications ?
PM Guides Agile GuideComplete breakdown Scrum GuideRoles, ceremonies, artifacts EVM GuideAll formulas explained View All Guides ?
Career & Salary PM Salary 2026By country & level How to Become a PMStep-by-step roadmap 50 Interview QuestionsWith strong answers
PM Software Monday.com ReviewTop pick 2026 ClickUp ReviewBest value Best Free PM ToolsNo trials, truly free View All Software ?
Free Tools & Templates EVM CalculatorFree, no signup Gantt Chart MakerBuild & export free PMP Eligibility Checker30-second result Free PM Templates30 templates in Excel, Word and PDF
Get the Free PMP Guide ?
Free Template · Word · Updated March 2026

Free Project Closure Report Template
Word Download

Every project needs a proper ending. This Word template records your final results against the objectives, schedule and budget, the approved changes, what went well, the key lessons and the formal handover. Your sponsor, your client and the next project team all get a clear picture of how the project ended.

✓Word (.docx)
✓Free: no signup
✓Updated March 2026
✓PMI & PRINCE2 aligned
✦
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
↓ Download Free Template

No email required. Instant Word download.

Quick answer

A project closure report is the final document that records whether a project met its objectives, schedule and budget, and formally hands it over. This free nine-section Word template covers outcomes, performance, approved changes, achievements, lessons learned and sign-off, aligned with PMI and PRINCE2.

The closure report gives the top 3 to 5 lessons only. If you need to record every lesson in detail, with causes and actions, use my lessons learned register template. This page is about the closure report itself: what to write in each section, with a filled-in example.

Project Closure Report template preview: 9 sections, Outcomes vs objectives, Schedule and budget performance, Lessons learned and sign-off
What is inside the free project closure report template.

Project Closure Report template at a glance

FormatWord (.docx)
Sections9, from outcomes to formal sign-off
Lifecycle phaseClosing
Owned byProject manager; approved by the sponsor
Best forFormally closing a project and recording results
01 · Template Sections

What's in the project closure report template?

The template follows the structure used in both PMI and PRINCE2. You, the PM, write it. The sponsor reviews and approves it. It is not a group writing exercise.

✦
From my experience: Skipping closure is one of the most common mistakes I see. On my UAE construction projects, the closure report was where we recorded what was handed over, which snag items were still open and who owned them, and what we would do differently. Without it, open items got lost between the site team leaving and the facilities team taking over. When I teach closing to my PMP students, I tell them: the project is not closed until open items have a new owner.
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 against actual cost, the variance in currency and percentage, how much contingency was used and why. The template asks 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 do you write the schedule and budget sections?

Sections 3 and 4 are the ones sponsors read most closely. They want to know what happened, why, and what you would do differently. Here is how to write 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..." People reading this report years later care more about that than the exact variance numbers. One honest, specific lesson is worth more than a perfect performance table.

Reporting on Objectives That Weren't Met

If an objective was not met, it goes in Section 2 as "Not Met". Do not leave it out, play it down or call it "partially met" unless part of it really was delivered. Sponsors and auditors compare the closure report with the original charter. Gaps you hide will damage your credibility.

For each unmet objective, write what was delivered, what the gap is, why it happened (the root cause, not an excuse) and what happens to the remaining work: a separate project, normal operations, or dropped.

Worked example

Example: objectives and handover rows for a fit-out project

Here is how Section 2 and the handover section might look at the end of an office fit-out in the UAE. This is an example only. Notice the "Not Met" row: it is written plainly, with the reason and what happens next.

ItemPlannedActualStatus / note
Handover dateAgreed handover date in the contractHanded over 2 weeks lateNot Met. Fire alarm re-inspection after a failed Civil Defence visit. Lesson: book a pre-inspection.
Snag listAll snags closed before handoverMinor snags still open at handoverPartially Met. Open snags listed with owner and target date, passed to the fit-out contractor.
As-built drawings and O&M manualsApproved by consultant at handoverApproved and stored in the client document systemMet.

Mistakes I see when people fill this in

  • Only the good news. If the charter had five objectives, all five go in Section 2, including the missed ones.
  • Numbers with no reason. "2 weeks late" means nothing to the next team. Say why.
  • Open items with no owner. Snags, warranties and open risks need a named person after your team leaves.
  • Lessons copied from the last project. "Communication could be better" helps nobody. Write one specific thing to do differently.
03 · Closure Checklist

Project Closure Checklist: Before You Submit

The closure report is usually the last document you write. Before you send it for sign-off, go through this checklist to make sure the project is really 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

What is the difference between a closure report and a post-implementation review?

People confuse these two, but they do different jobs at different times. Both matter, and your closure report should say when the PIR will happen.

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.

Do both for any significant project. The closure report is not complete until it says when the PIR is planned and who owns it. Download the Post-Implementation Review template to use with this closure report.

✦
PMP exam note: In PMBOK 6 terms, closing the project belongs to the Close Project or Phase process in the Closing process group. Key outputs are the final report (like this closure report), handing deliverables over to operations, and updating organisational process assets such as lessons learned. The exam separates closing a phase from closing the whole project. In PRINCE2, the Closing a Project process produces the End Project Report and a Lessons Report, and updates the benefits management approach for reviews after the project. See our 200 PMP practice questions for closure scenarios.
05 · FAQ

Project Closure Report: 4 Common Questions

A project closure report is the formal document you write at the end of a project to sum up the results. It shows how the project did against its objectives, schedule and budget, lists approved scope changes, captures the key lessons, confirms what was handed over and to whom, and gets formal sign-off. It is the official record that the project is finished, and a reference 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.
Usually three people sign: the Project Manager (who writes it), the Project Sponsor (who approves closure and releases the team and budget) and the client or customer representative (who confirms the deliverables are accepted). The sponsor's signature matters most, because it formally closes the project. Where there is a PMO, a programme manager or PMO lead may also 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.