Project Closure: Definition and What Has to Be Done
Project closure is the formal end of a project: confirming deliverables are accepted, transferring operational responsibility to a support owner, handing benefits to their business owner, closing contracts and budget, capturing lessons, releasing the team, and obtaining sponsor sign-off. It is a defined piece of work, not the point at which people stop attending the stand-up.
What closure covers
| Area | What has to be settled |
|---|---|
| Acceptance | Every deliverable accepted, or accepted with recorded exceptions |
| Outstanding items | Open defects and unfinished scope transferred to a named owner with dates |
| Handover to support | Documentation, run instructions, access, monitoring and the support model agreed |
| Benefits | Each benefit passed to a business owner with its baseline, measure and review dates |
| Commercial | Purchase orders closed, final invoices settled, contracts ended or transitioned |
| Financial | Final actual against budget, with variance explained |
| Lessons | Review held, recommendations owned |
| People | Team released, with roles and end dates confirmed |
| Records | Decisions, RAID log, plans and reports archived where they can be found |
| Sign-off | Sponsor confirms the project is closed and no further spend is authorised |
How it is used
Closure is a sequence rather than a document. Acceptance comes first, because everything else depends on knowing what was delivered. Handover follows, and it is the step most often compressed: support inherits a system with no run documentation, and the project team fields calls for a further three months. Benefits transfer, commercial closure and the lessons review can run in parallel. Sponsor sign-off comes last and is the point at which the cost centre stops accepting charges.
On an IT project, closure is normally distinct from go-live by a stabilisation period. The system goes live, hypercare runs for a defined window with an agreed exit, and only then does the project close — the sequence covered in the hypercare guide and in the hypercare tabs of the cutover runbook and hypercare pack. Closing while hypercare is still running transfers unresolved problems to a support function that has not agreed to take them.
The mechanics — closure report, lessons log, benefits handover and handover checklist — sit together in the project closure report, and the project closure guide covers how each is worked through. Where the original benefit forecasts came from, and what they are being handed back against, is the business case.
Where it goes wrong
- Fading rather than closing. Attendance declines, the budget line stays open, and nobody can say whether the project finished.
- Support handover skipped. Documentation is promised and never produced, so the project team remains the support team informally.
- Benefits left with the project. The project closes and the benefit owner was never named, so the investment is never assessed.
- Open items dropped rather than transferred. Defects marked as closed at closure reappear as incidents.
- Closure before hypercare exit. The formal end arrives while the system is still unstable, and the support function inherits the instability.
- No sign-off. Without a sponsor signature and a closed cost centre, spend continues against a project nobody is managing.
Related terms
Hypercare — the post-go-live stabilisation period that normally precedes closure. Handover — the transfer of operational responsibility to a service owner. Lessons learned — captured during delivery and reviewed at closure. Benefits realisation — continues after closure, under a business owner. Closure report — the document recording the final position and the sign-off.
Questions
When should a project be closed?
After deliverables are accepted, hypercare has met its exit criteria, support has taken handover and outstanding items have owners. Go-live is not closure; the two are usually separated by weeks.
Who signs off project closure?
The sponsor, normally with the service or support owner confirming they have accepted handover. Sign-off is the point at which further spend against the project is no longer authorised.
What is in a project closure report?
Final position against scope, schedule and budget; deliverables accepted; outstanding items with owners; benefits handed over; lessons; and the sign-off itself.
What happens to open defects at closure?
They are transferred to the support backlog with an owner and a priority, not closed. Marking them closed at handover means they return later as incidents with no history attached.