Skip to content

Project Closure Report

At a glance

  • Purpose: Confirm that the deliverable was accepted, everything was handed over, nothing is left running, and the project's outcome can be compared with what was promised.
  • Use it when: At the end of delivery, before the project is formally closed. Also useful for a cancelled or stopped project — closure is needed in either case.
  • Owner: The project manager; the sponsor or business owner accepts it.
  • Related: Module 12 · Lab 25

How to use this template

  1. Compare the outcome against the original business case, not against the latest revised plan. It is the only honest comparison, and it is the one that makes future business cases credible.
  2. State what was delivered and what was not, with the acceptance record. Silent omissions at closure become permanent surprises for operations.
  3. Close the financial and contractual side: final costs, unused contingency, invoices, licences, support agreements, and the disposal of anything temporary.
  4. Hand over ownership. Every component, document, and ongoing obligation must have a named receiving owner, or it will be discovered later by whoever hits it first.
  5. Record the residual risks and known limitations explicitly, and get them accepted. An accepted limitation is a managed one; an unrecorded one is a future defect report.

Field descriptions

Section What goes in it Watch out for
Outcome against business case Original promise, actual result, and variance Comparing against the revised baseline only
Acceptance record Who accepted, when, against which criteria Acceptance assumed because nobody objected
Delivered vs not delivered Both lists, with reasons Deferred items quietly dropped
Financial closure Final cost, contingency used, remaining commitments Unspent contingency left unstated
Contractual closure Supplier performance, warranties, licences Support obligations no one owns
Handover Component, receiving owner, date, and evidence Handover to a team that did not agree
Residual risks Risk, exposure, and who owns it once the project closes Risks closed because the project closed
Resources released People, environments, subscriptions, access Access left open after the team leaves

Blank template

# Project Closure Report — [Project name]

| | |
| --- | --- |
| **Closure date** | [YYYY-MM-DD] |
| **Project manager** | [Name] |
| **Sponsor / accepting authority** | [Name, role] |
| **Outcome** | [Completed / Completed with limitations / Partly delivered / Stopped] |

## 1. Outcome against the business case

| Original promise (from the business case) | Actual result | Variance | Explanation |
| --- | --- | --- | --- |
| [Benefit or measure] | [Result] | [±] | [Cause, evidence-based] |

## 2. Acceptance

| Deliverable | Acceptance criteria | Accepted by | Date | Evidence |
| --- | --- | --- | --- | --- |

## 3. Delivered and not delivered

| Delivered | Not delivered | Reason | Where it is tracked now |
| --- | --- | --- | --- |

## 4. Schedule and cost summary

| Item | Baseline | Actual | Variance | Cause |
| --- | --- | --- | --- | --- |
| Finish date | | | | |
| Total cost | | | | |
| Contingency used | — | | — | |

## 5. Contractual and financial closure

| Item | Status | Owner of the ongoing obligation |
| --- | --- | --- |
| Final invoices and payments | | |
| Licences and subscriptions | | |
| Support and warranty arrangements | | |
| Unused contingency | | |

## 6. Handover

| Component or document | Receiving owner (named) | Date | Evidence of handover |
| --- | --- | --- | --- |

## 7. Residual risks and known limitations

| ID | Risk or limitation | Exposure | Accepted by | Owner after closure |
| --- | --- | --- | --- | --- |

## 8. Resources released

| Resource | Released on | Confirmed |
| --- | --- | --- |
| [People, environments, access, subscriptions] | | |

## 9. Lessons

[Link to the [lessons learned register](lessons-learned-register.md). Do not duplicate entries here.]

## 10. Sign-off

| Role | Name | Date | Statement |
| --- | --- | --- | --- |
| Sponsor | | | Outcome accepted |
| Business owner | | | Benefits ownership transferred |
| Operations or support | | | Support arrangements accepted |

Worked example

From Lab 25, on the analytics dashboard project — invented figures for teaching, closed with limitations:

Original promise (business case) Actual result Variance Explanation
Replace three manual weekly reports Two of three replaced; the third depends on data the source system cannot supply Partly met Discovered in week 11; the source limitation was not known at business-case time
Reduce report preparation effort Reduced for the two automated reports; unchanged for the third Partly met Same cause as above
Deliver within the 16-week window Delivered in week 16, having re-baselined once at week 14 Met against the revised baseline; 3 weeks late against the original Baseline was front-loaded and the performance defect was found late
ID Residual risk or limitation Exposure Accepted by Owner after closure
RR-01 The third report remains manual Staff effort unchanged Business owner Operations manager
RR-02 Performance is verified only to 1,200 records; the source may exceed this Slow screens at higher volumes Business owner Operations manager, with monitoring

The closing sentence of this report matters as much as the tables: "The project closed three weeks later than originally promised, and met its revised baseline. The variance was caused by a front-loaded baseline and late discovery of a performance defect; both are recorded in the lessons learned register." Closure is where the project's credibility with its sponsor is either maintained or lost, and stating the variance plainly — with its cause — is what earns the benefit of the doubt on the next business case.

Common mistakes

  • Comparing only against the revised baseline. Re-baselining is legitimate, but the original promise is the honest reference point.
  • Acceptance assumed rather than recorded. If nobody signed, the project has not been accepted, however pleased everyone seems.
  • Cancelled projects not closed. They need just as much handover, and the reasons are the most valuable lessons available.
  • Handover without a named receiver. "Given to operations" is not a handover unless a person accepted it.
  • Residual risks closed by closure. They outlive the project and need new owners.
  • Resources left running. Forgotten environments, subscriptions, and access are a recurring cost and a security exposure.
  • Duplicating the lessons register. Link it; a closure report that repeats it will disagree with it.
  • Benefits claimed at closure. Many benefits arrive months later; state how and when they will be measured, and who owns that measurement.