Closure is the set of actions that end a project properly, and it is the phase most likely to be half done. By the time it arrives the interesting work is finished, the people who would do it have been assigned elsewhere, and nobody is watching a project that has already delivered.
What closure consists of
Final acceptance comes first. Deliverables are checked against the acceptance criteria that were agreed, and somebody with the authority to accept them says so in writing. Acceptance obtained informally is the commonest route to defending work six months later against criteria that have drifted since.
Contract closure is a separate act. Every procurement is settled, final payments made, claims resolved, retained obligations and warranties recorded, and the seller's performance written down for whoever procures next. An open contract carries liability and occasionally a recurring charge nobody is watching.
Releasing resources returns people, equipment, licences and facilities. Doing it late costs real money, because a project that has finished carries on consuming budget and holding people other work is waiting for.
Archiving puts the plans, the baselines, the change decisions, the registers and the final performance data somewhere retrievable. The audience is a future project, an auditor, and whoever has to answer a question about this work in three years.
The closure checklist
The list below is the whole of it, grouped by the kind of obligation each item settles. Naming an owner beside every line is what stops closure stalling, since the usual failure is a set of tasks that belong to everybody and are booked by nobody.
| Group | What has to happen | Who owns it |
|---|---|---|
| Contractual | Check every deliverable against the acceptance criteria and obtain acceptance in writing | The customer or sponsor accepts, and the project manager obtains it |
| Contractual | Settle final payments, retentions and outstanding invoices | Procurement, with the project manager confirming delivery |
| Contractual | Resolve outstanding claims and disputes | Procurement, escalated to legal where a settlement is needed |
| Contractual | Record warranties, retained obligations and support periods | The project manager, into the archive and the handover pack |
| Contractual | Write down how each seller actually performed | The project manager, for whoever procures next |
| Administrative | Close the budget and stop the cost codes | Finance, on the project manager's instruction |
| Administrative | Release people, and give each line manager the performance input they need | The project manager, with the resource managers |
| Administrative | Return equipment, licences, facilities and building access | The project manager |
| Administrative | Close or transfer every open risk, issue, assumption and dependency | The project manager, to a named receiver in each case |
| Administrative | Archive plans, baselines, change decisions, registers and final performance data | The project manager, into the organisation's repository |
| Administrative | Move the lessons learned register into the organisational repository | The project manager |
| Administrative | Write the final report | The project manager, approved by the sponsor |
| Handover to operations | Hand over documentation, runbooks, configuration and the known defect list | The project manager to the service owner |
| Handover to operations | Agree the support arrangement and who gets called when it breaks | The service owner, funded by whoever now carries the running cost |
| Handover to operations | Complete training and confirm the operational team can run it unaided | The service owner |
| Handover to operations | Transfer accounts, credentials and administrative access | The project manager to the service owner |
| Handover to operations | Record the benefit claimed, the baseline measure, who owns the benefit now and when it will be checked | The project manager, handing to the benefit owner |
| Handover to operations | Name and date the day the project stops owning it | The sponsor, in writing |
A cancelled project is closed the same way
Termination is one of the ways a project ends and the activities are identical. Acceptance is still sought for whatever was completed, contracts are still closed, people are still released and records are still archived. The pressure runs the other way, because a cancelled project feels like an embarrassment and closing it properly keeps it visible for another month.
There is usually more to harvest than anyone expects. Work finished to a usable standard can often be transferred, procured assets can be redeployed, and the reasoning behind the decision to stop is the most useful thing the organisation will learn that year. A cancellation closed properly is a decision. A cancellation abandoned is a set of live contracts, orphaned work and an explanation nobody can reconstruct.
Handover, and the moment the project stops owning it
A deliverable that works is a different thing from a deliverable somebody can run. Handover transfers the thing together with what keeps it alive, meaning documentation, support arrangements, training, access, the known defects and an agreement about who gets called when it breaks.
The transfer should be explicit and dated. The ambiguous version is a project team that has notionally finished and is still answering calls, alongside an operations team that never quite accepted anything, and it can persist for a year because nobody ever named the day.
Accepted is not the same as realised
Acceptance says a deliverable meets what was specified. It says nothing about whether the benefit that justified the funding has appeared, and the two are separated by time. A system accepted in March produces the savings that paid for it across the following two years, if it produces them at all.
That gap is why realisation is normally somebody else's accountability once the project has closed. The project's job at closure is to make the measurement possible, by recording what the business case claimed, what the baseline measure was, who owns the benefit now and when it will be checked. Skip that and the organisation can say what it built and cannot say whether building it was worth doing.
The final report
The final report outlives everybody involved. It sets out what was delivered against what was agreed, final cost against the baseline, the schedule outcome, the significant changes and why they were approved, the risks that materialised and the lessons worth carrying forward.
Written as a summary of achievements it is worthless inside a month. Written as a description of what happened, including the parts that went badly, it becomes the one document a future project manager estimating similar work actually wants. That is the argument for writing it while the detail is still available rather than after the team has dispersed.