The Closing Phase
Closing is the phase everybody agrees is important and almost nobody schedules. It costs a day or two, it produces nothing anyone is waiting for, and skipping it is invisible until the next project repeats a mistake this one already paid for.
In short
- “All tasks complete” is not the same as closed. Closing needs acceptance, an owner, a record and a release.
- A project that ships without naming an operational owner never really ends — the builders keep it forever.
- Retrospectives are only worth holding if someone will read them. Write them where the next team looks.
- Cancelled projects need closing too, and cancelling well is a skill worth having.
Why this phase gets skipped
Not laziness. The incentives point the other way, and it’s worth naming them:
- Everyone is already on the next thing. By the time closing is due, half the team has been reassigned. The remaining people have the least context and the least authority.
- Nobody’s objective mentions it. Delivery is measured. Closing rarely is. Work that isn’t measured loses to work that is, every time.
- The benefit lands on somebody else. The value of a good retrospective accrues to the next project. Classic externality: the cost is here, the payoff is over there.
- The end is fuzzy. Without acceptance criteria, there is no moment that obviously says “now”, so the project trails off instead of stopping.
All four are structural, which means the answer is structural too: put closing in the plan with dates and an owner, exactly like any other work. A closing phase that depends on goodwill after the deadline will not happen.
The five things closing has to produce
1. Acceptance, from a named person
Not “we demoed it and nobody objected”. Somebody with standing has to say the deliverable meets what was agreed. If acceptance criteria were written during planning, this takes ten minutes. If they weren’t, this is where you discover it — and where a friendly conversation turns into a negotiation.
2. An operational owner
Every deliverable becomes somebody’s ongoing work: a system to run, a process to follow, a document to keep current. Naming that owner — and having them accept — is what converts the project into operations. Skip it and the builders keep answering questions about it for years, which is a real cost that never appears on any project’s books.
The handover needs three things to be genuinely complete: the thing itself, enough documentation for someone else to run it, and an explicit acceptance of responsibility. 7.1 Deliverables Handover covers this properly.
3. A retrospective somebody will read
Two failure modes here, and they’re opposites. One is holding no retrospective. The other is holding a good one and writing it somewhere nobody will ever look.
What makes them get read:
- Store it with the project, not in a personal drive or a slide deck. The next person will search the project’s name.
- Write findings as instructions, not observations. “Communication could have been better” helps nobody. “Get the vendor’s security review started in week one — it took five weeks, not the two we assumed” is reusable.
- Keep it short. Three things to repeat, three to change. A twelve-page document is a document nobody opens.
- Make it safe. A retrospective that names people instead of causes teaches everyone present to say less next time.
7.2 Retrospective and Evaluation has the formats; 7.3 Knowledge Transfer covers making the lessons survive the team.
4. Administrative closure
The unglamorous list: close the budget, release licences and environments, archive the artefacts, terminate contracts, settle invoices. Boring, quick, and expensive if forgotten — the cloud environment nobody switched off is a genre of its own.
5. Releasing the team — explicitly
Tell people the project is over. It sounds trivial; it isn’t. Without a clear end, people carry a low-level obligation to the old project into the new one, answering questions and fixing small things that nobody counts. Say it out loud, and say what was achieved while you’re at it. This is the cheapest morale intervention available and it costs one message.
Closing a cancelled project
Cancellation is not failure of the phase; it’s often the phase working. But a cancelled project still needs closing, and it needs it more than a successful one because there’s no delivery moment to force the issue.
The same five items apply, adapted: state clearly what was decided and why (so it isn’t re-litigated in six months), find out whether any partial work is worth keeping and hand it to someone, write the retrospective — cancelled projects generate the most useful lessons in the organisation — close the spend, and be unambiguous with the team that the decision reflects the project’s circumstances, not their work. Teams that see a cancellation handled respectfully raise concerns faster on the next one.
How much closing is enough?
A two-week project
A demo, a message confirming acceptance, three bullet points of lessons in the project’s notes, and a sentence naming who maintains it. Fifteen minutes total.
A six-month project
A written acceptance, a real handover session with documentation, a scheduled retrospective with the people who did the work, and an administrative checklist. One to two days, planned in from the start.
Neither is expensive. What’s expensive is the version where none of it happens and the project simply stops being mentioned.
How this looks in AB
Closing in AB Projects is mostly about preserving signal:
- Handover → mark the project archived once delivered. Members lose write access by default but can still read everything — the archive is a freeze, not a deletion.
- Retrospective → a Retrospective page in the project Wiki, captured as Keep / Problem / Try. Pin it from the project home so it’s the first thing anyone sees later.
- Audit trail → the change-history tab on every task is a “what happened, when, and why” log nobody had to write.
- Knowledge transfer → because the Wiki, tasks and comments live with the project rather than scattered across drives, the next team can search the project name and find the actual context, not just the deliverable.
One addition worth making by hand: a final Wiki entry with the acceptance date, the person who accepted, and the named operational owner. Three lines. They are the three facts most likely to be needed and least likely to be recorded.
Terms used on this page
- Closing
- The final phase of the lifecycle: acceptance, handover, administrative closure, retrospective and release of the team. Ends the project deliberately rather than by exhaustion. More →
- Acceptance criteria
- The conditions a deliverable must meet before the receiving party agrees it is finished. Written during planning, they make acceptance a check; written at the end, they make it a negotiation. More →
- Handover
- Transferring a finished deliverable, its documentation and its responsibility to whoever will operate it. Incomplete handovers are the main reason projects stay alive after the work stops. 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 →
- Sign-off
- A named person’s explicit confirmation that a deliverable is accepted. The moment that makes “done” a fact rather than an opinion. More →
Related reading
7.0 Project Closure
The whole chapter on ending projects well, and turning endings into organisational capability.
7.1 Deliverables Handover
Handing a result to the people who will run it, without leaving the builders holding it.
7.2 Retrospective and Evaluation
Running a review that changes what happens next, rather than one that fills an hour.