Project closure: finishing properly instead of drifting to a stop

Project closure is the set of things that have to happen for a project to be genuinely finished rather than merely quiet. Most projects do not get closed; they trail off, with two open issues nobody owns, a supplier invoice still to come, and a team that has drifted onto other work while remaining nominally assigned. The cost of not closing is not tidiness — it is that the budget stays open, the lessons are never captured, and nobody can say whether the thing actually worked.

What project closure has to complete

• Acceptance: the deliverables signed off against the criteria agreed at the start, by whoever agreed them.
• Outstanding issues: each one closed, transferred to an owner in the receiving team, or explicitly accepted as a known limitation.
• Handover: documentation, access, and the operational knowledge the people running it will need — which is a handover document rather than a folder link.
• Financials: final invoices received, purchase orders closed, remaining budget released rather than quietly available.
• Contracts: supplier engagements formally ended, retentions and warranty periods noted with dates.
• The team released, with their next assignment known — the most common reason closure is postponed is that nobody wants to have that conversation.
• Records archived where they can be found, at the retention period the organisation requires.

The two reviews that are not the same

1. The closure review looks backwards at the project: was it delivered to scope, time and cost, what went well, what did not. It happens at the end and the team is still available to answer.
2. The benefits review looks forwards at the outcome: did the thing deliver the value the business case claimed. It happens months later, usually needs different people, and is the one that almost never happens.
3. Schedule the second one at closure, with an owner and a date, or it will not occur. This single step is what separates organisations that learn from ones that repeat.
4. Feed both into the lessons learned record rather than into a slide deck that is presented once and archived.

Closure is where scope disputes surface, because it is the first moment anyone has to say the work is complete. That is not a reason to avoid it — the dispute exists either way, and having it while the team and the evidence are still available is considerably cheaper than having it in six months with a supplier who has moved on.

Why projects do not get closed

• Nobody owns closure: the manager has moved to the next project and the receiving team did not ask for the work.
• A small piece of scope is unfinished, so the whole project stays open rather than closing with a documented exception.
• Fear of the acceptance conversation, particularly where the outcome is arguable.
• No closure step in the process at all — projects have a start gate and no end gate.
• The budget is useful open, which is a governance problem wearing a convenience costume.

Where closure lives

Ettex Boards is where the closure checklist belongs as a short list of items with owners, because closure fails as a document and works as a set of tasks somebody is assigned. Keep the acceptance record, the handover and the outstanding-issue decisions together, and put the benefits review on the calendar as a dated item rather than an intention. It links back to the project charter, which is where the success criteria you are now testing against were written. Ettex does not manage budgets or contracts — the financial and procurement closure steps happen in your finance system; what this holds is the list of them and whether they are done.