Project Closure
Two projects deliver the same thing on the same day. Six months later one organisation is measurably better at this kind of work and the other is about to repeat every mistake. The difference happened in the last two days.
In short
- Closure converts a finished project into things the organisation keeps: an owner, lessons, and reusable material.
- The deliverable is identical whether you close well or not. Everything else isn’t.
- It gets skipped for structural reasons — nobody’s objective covers it — so it has to be scheduled like any other work.
- Two days on a six-month project. The cheapest high-return work available to a project manager.
Why the last two days are worth this much
A project spends months producing one thing: the deliverable. Closure is the only phase that produces anything else, and the things it produces have a longer life than the deliverable does.
Consider what a well-closed project hands the organisation. An operational owner, which frees the builders to start something new. A short written account of what went wrong, which is the input to every future estimate in this area. Searchable material the next team can reuse rather than recreate. And people who have actually finished, rather than people carrying a half-attachment to something that never formally ended.
None of that exists by default. All of it is created deliberately, at the end, by someone who has to choose to do it while everyone around them has already moved on.
What thin closure looks like, months later
Nobody notices weak closure at the time — that is precisely the problem. The symptoms arrive later, and they rarely get traced back:
- The builders are still support. Six months on, questions about the thing still route to the people who made it. Their new project is quietly running at 80% capacity and nobody has counted it.
- The same mistake, again. A new project makes an error a previous one already paid for. The lesson existed; it lived in someone’s head and they weren’t asked.
- Estimates that never improve. Without recorded actuals, every estimate is a fresh guess. Teams that close well get measurably better at estimating; teams that don’t, don’t.
- Nobody can say whether it worked. The project delivered, but did the problem go away? If success was never checked after the fact, the organisation cannot tell a good project from a busy one.
- The project is still open in the tool. A trivial symptom of a real thing: no moment was ever declared, so there was nothing to close.
- Assets get rebuilt. A checklist, a template, a script someone wrote — recreated from scratch by the next team because it was in a personal drive.
How much closure does a project need?
Two weeks of work
A demo, a message confirming acceptance, a named maintainer, and three bullet points of lessons in the project’s notes. Fifteen minutes, and it still buys most of the value.
Three to six months
Written acceptance, a handover session with documentation, a scheduled retrospective with the people who did the work, and an administrative checklist. One to two days.
A large programme
A formal close-out report, a benefits review scheduled months after delivery, contract and asset closure, and knowledge transfer treated as a workstream in its own right.
The over-doing failure exists here too, though it’s rarer: a close-out report so long that writing it becomes the last month of the project, read by nobody. The test is whether a specific future person is better off. If you cannot name who will read something, don’t write it.
How the three sections fit
Handover, retrospective and knowledge transfer are usually done in that order, and they answer three different questions:
- Handover asks who owns this now? It is about the deliverable and it has a hard finish — someone either accepted responsibility or didn’t.
- Retrospective asks what should we do differently? It is about the process and it is worthless unless it produces instructions rather than observations.
- Knowledge transfer asks what survives the team dispersing? It is about everything else — context, decisions, reusable material.
The dependency runs one way: a retrospective is much better if the handover has already happened, because acceptance is when the last surprises show up. Do the retrospective before delivery and you will miss the most instructive week of the project.
A note on cancelled projects
Everything in this chapter applies to a project that was stopped, and it applies more urgently, because there is no delivery moment to force the issue. A cancelled project generates the most useful lessons an organisation has access to — and almost nobody writes them down, because the instinct after a cancellation is to move on quietly.
Handling a cancellation visibly and respectfully also does something for the next project: it demonstrates that stopping is a real option, which is what makes the go/no-go gates in 2.0 mean anything.
How this looks in AB
In AB Projects the closure signal is archiving the project: members keep read access but lose write, so it becomes a frozen reference rather than a deletion. Because the Wiki, tasks and comments all live with the project, the next team can search the project name and find the actual context rather than just the deliverable.
The part that still takes deliberate effort is the same in every tool: writing the three or four lines that turn a completed task list into something a future team can use. The sections ahead cover what those lines should say.
What this chapter covers
Deliverables Handover
Getting a result accepted, and getting somebody to own running it — the difference between completion and handover.
Retrospective and Evaluation
Running a review that changes what happens next, and judging whether the project actually solved the problem.
Knowledge Transfer
Making what the team learned survive the team, and findable by people who don’t know it exists.
Terms used on this page
- Project closure
- The final phase: acceptance, handover, administrative closure, retrospective and releasing the team. Ends a project deliberately rather than by exhaustion. More →
- Handover
- Transferring a finished deliverable, its documentation and its responsibility to whoever will operate it. Incomplete handovers keep projects alive long after the work stops. More →
- Benefits realisation
- Checking, some time after delivery, whether the project actually produced the outcome it was funded for. Rarely done, and the only real test of whether a project succeeded. More →
- Retrospective
- A structured review of how the work went, aimed at changing what the next team does. Useful when it produces instructions rather than observations. More →
- Lessons learned
- The reusable conclusions from a project, recorded where a future team will find them. Lessons stored somewhere unsearchable are lessons unlearned. More →
- Close-out report
- The formal summary of what a project delivered against what it promised, plus its lessons. Worth the effort in proportion to who will actually read it. More →
Related reading
2.4 The Closing Phase
The lifecycle view of the same phase, including how to close a cancelled project.
1.3 Projects vs Operations
What the deliverable becomes after handover, and why that transition needs an owner.
8.0 Case Studies
Projects that succeeded and failed, and what their closure did or didn’t preserve.