Most projects do not end. They fade. The work runs out, the team moves on, something is never quite handed over, and three months later someone calls with a question nobody can answer any more. Proper closure is cheap — usually a week — and it is the only point at which a project leaves the organisation something beyond the deliverable itself.
When is a project actually finished?
- The deliverable is accepted — not "done", but confirmed by the client.
- Ownership is handed over — a named person now maintains the result.
- Obligations are closed — contracts, invoices, warranties, reports to the funder.
- Knowledge is retained — documents archived, lessons written down.
If any one of those is missing, the project has not finished — it has merely gone quiet.
Acceptance: "done" needs a definition
Acceptance runs against the acceptance criteria agreed during planning. Without them it becomes a matter of taste, and the project never ends — every review produces a new wish.
The practical answer is a simple list of deliverables with three columns: what was promised, what was handed over, who signed it off. Shortfalls go on a separate list with a deadline and an owner — and the project counts as closed when that list is either empty or consciously accepted.
Handover: who owns this now?
| What is handed over | To whom | What it requires |
|---|---|---|
| The result itself | Owner or administrator | Documentation, access, training |
| Ongoing operation | Support or maintenance | An agreement: who, when, at what cost |
| Open risks | The responsible manager | An extract from the risk register, not a verbal warning |
| Documentation | The organisation's archive | A findable structure, not someone's folder |
A final report without fiction
The final report answers four questions: what was promised, what was delivered, what it cost, and what went differently. The fourth is the most valuable and the most often missing. A report that only says everything went well is not worth writing — or reading later.
In a grant project the final report is also a legal document, bound by the funder's form, deadline and evidence requirements — see grant reporting and the audit trail.
Lessons that someone actually uses
- Collect them as you go. Write a lesson down when it happens, not at the end from memory.
- Be specific. "Communication could be better" helps nobody. "Supplier sign-off took 3 weeks, not 3 days — put that in the schedule" helps.
- Turn them into rules. A lesson that never reaches a checklist, a template or an estimating method is just a memory.
A good closing retrospective asks three things: what worked and should be repeated; what did not and would be done differently; and what surprised us — because surprises are the input for the next project's risk register.
A cancelled project also needs closure
A project that is stopped needs the same process: what was produced and where it sits, what was spent, what is still recoverable, what can be reused later. A cancelled project without closure is a double loss — the money is gone and the knowledge goes with it.
Closure checklist
- Deliverables accepted, shortfalls agreed
- Handover done, owner named
- Contracts and invoices closed, final budget position fixed
- Report submitted to the funder and approved
- Documents archived for the required retention period
- Open risks transferred with an owner
- Lessons written down and folded into a template or checklist
- Team released and the work acknowledged
The last item is not sentimentality. A team whose project simply faded starts the next one with less commitment.
How Projektiassistent helps
When schedule, budget, risks and decisions live in one place throughout, closure is a matter of summarising rather than gathering. The decision and change logs show what shifted and why — a better input for a retrospective than anyone's memory. And the next similar project starts from an existing structure instead of a blank page.
Summary
A project ends when the deliverable is accepted, ownership is transferred, obligations are closed and knowledge is retained. Collect lessons as you go, phrase them concretely and push them into a template or checklist — otherwise you repeat the same mistake in the next project with exactly the same confidence.
If you want the next project to start with the last one's lessons, start here: projekt2.projektiassistent.ee.