What is included in a project closure report?
A closure report records what was delivered against what was approved, the final cost and schedule position against baseline, outstanding items with named owners and dates, benefits handed to the person who will measure them, lessons learned, the handover to support, and the formal acceptance that releases the team and closes the budget.
What the report is for
A closure report is a record of the end state. It is written so that someone who was not involved can establish, later, what was delivered, what it cost, what was left open and who now owns it. It is not a narrative of the project and it is not a case for the defence. The audiences are the sponsor, whoever governs the portfolio, finance, and the teams who inherit whatever the project leaves behind.
The test of a good one is whether it answers questions that get asked six months on: did we get what was approved, what did it actually cost, who owns the thing that was not finished, and is anyone measuring the benefits.
Delivery against scope
What was approved, what was delivered, and the difference. Approved changes are listed with their reference and their impact, so the gap between the original baseline and the final position is explained rather than left to be inferred. Anything descoped is named, along with the decision that descoped it and whether it is expected to return as a separate piece of work.
Cost and schedule
| Line | What it shows |
|---|---|
| Original baseline | Approved budget and dates at the point of approval |
| Approved changes | Each change request with its cost and schedule impact |
| Revised baseline | The position the project was actually measured against |
| Final actuals | Total spend by category, and the delivery date achieved |
| Variance | Difference against both original and revised baseline, with the reason |
| Committed and accrued | Invoices outstanding, purchase orders to close, retentions held |
Showing both baselines matters. Reporting only against the revised one flatters the outcome; reporting only against the original ignores decisions the sponsor took. The IT Project Budget & Vendor Tracker carries the actuals and commitments the closure figures come from.
Outstanding items
Every project closes with something unfinished: open defects, deferred requirements, documentation, a piece of technical debt, a contractual loose end. The report lists each one with a description, a named owner who has agreed to take it, a target date and the route it will be delivered through — normal support, a subsequent release, or a separate piece of work.
An item transferred to a team who has not agreed to take it is not transferred. The value of this section is that it names people rather than functions.
Benefits
Benefits are almost never realised by the time a project closes, which is why they need handing over rather than reporting on. For each benefit in the business case: what was claimed, the baseline it will be measured against, how it will be measured, who owns the measurement now, and when the first measurement is due. Benefits with no owner and no date are the ones that quietly disappear between closure and the next planning round.
Lessons learned
The section most often written and least often read. It becomes useful when each lesson is specific enough to act on and is addressed to someone. "Communication could have been better" changes nothing. "Third-party interface testing was scheduled after the environments were released, so it ran in the final two weeks" is a lesson another project can use.
Lessons are worth splitting into what to repeat and what to change, and each one benefits from an owner — the person or function that would have to do something differently. The project closure guide covers how to collect them while people still remember, rather than at the end when the team has dispersed.
Handover and service acceptance
Confirmation that the system has been transferred to whoever runs it: documentation handed over, known errors recorded, access provisioned, monitoring routed, support model live and hypercare exited. Where hypercare ran, its exit record attaches here. Where a support team has accepted the service, their acceptance is referenced rather than assumed.
Administrative closure
The unglamorous list that stops a closed project generating work for a year: contracts closed or transitioned, purchase orders closed, final invoices settled, licences transferred to the right cost centre, environments decommissioned or handed over, project accounts and access removed, documentation filed where it can be found, and the team formally released.
Acceptance
The report ends with a signature. The sponsor accepts that the project is complete on the basis of what the report describes, which is what closes the budget and releases the team. Without it, projects stay open on the portfolio and continue to absorb reporting effort long after the work has stopped. The Project Closure Report keeps the report, lessons log, benefits handover and handover checklist in one workbook so nothing is signed with a section missing.
Questions
When should the closure report be written?
After hypercare ends and the service has been accepted, so the report describes a settled position. Drafting sections during delivery is easier than reconstructing them afterwards.
Who approves it?
The sponsor, usually with the portfolio or PMO recording the closure. Where a supplier is involved, their acceptance of contractual completion is referenced separately.
How long should it be?
Long enough that each section can be answered from the document alone. The detail belongs in the attached logs rather than in the narrative.
Are benefits reported in the closure report?
The claims and the measurement arrangements are. The realised benefits are measured later, by the owner named in the report, against the dates it records.