What Makes a Project Officially Done

Most Projects Don't Close — They Just Stop

Many projects don't formally close. They fade out. The last deliverable ships, the sponsor sends a congratulatory email, and the team quietly moves to the next assignment. Nobody schedules a closure meeting. Nobody signs off on anything. The project just stops. And six months later, someone sends an email asking about a feature they assumed was still in scope. Or a vendor submits a final invoice for work the project manager thought was settled. Or a team member is still technically assigned to a project that stopped running eight weeks ago. These are not edge cases. They are the predictable consequences of treating the end of work as the end of the project — which it is not.

Project closure is not the natural consequence of finishing the work. It is a deliberate sequence of steps that formally ends the project, establishes a clear record of what was delivered and accepted, and transfers accountability from the project to whoever is responsible for what comes next. Without it, work that felt done becomes work that is disputed. Deliverables that seemed accepted become deliverables that need rework. Budget lines that should be closed stay open for months. The difference between a project that stopped and a project that closed is not just administrative tidiness. It is the difference between a clean record and an open question that resurfaces at the worst possible moment.

Delivered, Done, and Closed Are Not the Same Thing

Three words describe different states at the end of a project, and collapsing them together is one of the most common mistakes in project management. "Delivered" means the work product has been handed over. The software is deployed. The construction is complete. The report has been submitted. Delivered is about physical transfer. "Done" is a judgment: the work meets the standard agreed during planning, and the PM considers the scope complete. Done is about conformance. "Closed" is a formal status: the authorized recipient has accepted the deliverables in writing, the organizational record has been updated, and the project's obligations are formally concluded. Closed is about authorization.

A project can be delivered and not done — if the work doesn't meet acceptance criteria. It can be delivered and done but not closed — if no one has formally confirmed acceptance and concluded the administrative record. All three states need to be true before a project is genuinely finished. The most common gap is between done and closed: the PM believes the project is complete, but no formal acceptance has been obtained and no closure activities have been conducted. The project exists in an ambiguous state where its obligations are technically still live, even if no one is actively working on it. That ambiguity is where disputes are born.

What Triggers Formal Closure

Two conditions must both be true for formal closure to begin. First, the scope has been completed: all deliverables defined in the project scope statement have been produced. Second, and this is the condition most projects skip, those deliverables have been formally accepted by the person with the authority to do so. Not finished. Not shipped. Not praised by the sponsor in an email. Formally accepted, which means a documented acknowledgment from the right person that what was delivered matches what was agreed.

That second condition is worth spending a moment on, because it is where the gap almost always appears. A piece of software that works is not the same as a piece of software the sponsor has formally accepted. A building that passed its final inspection is not the same as a building the client has signed off on. One ends the work. The other ends the project. The distinction matters because "we built it" and "they accepted it" carry different legal, contractual, and organizational consequences. When a dispute arises later, the relevant question is not whether the work was done. It is whether the authorized party formally confirmed it was acceptable. That confirmation is what formal acceptance documents.

Projects Also Close Without Completing

Not every project reaches closure through successful delivery. Projects are terminated for reasons that have nothing to do with the team's performance: the business case no longer holds, the market shifted, funding was redirected, a better solution emerged, the sponsoring organization restructured. Early termination is a valid form of closure. It still requires the same steps that a successful close requires: documenting what was delivered up to the point of termination, releasing vendors and resources properly, capturing lessons learned, and archiving the project record. The difference is that the final project report describes what was accomplished and why the project ended, rather than confirming complete delivery.

An early termination record should document each of the following, even when the project ends before completing its original scope:

• Reason for termination. The decision, who made it, and when.
• Work completed. What deliverables were produced and formally accepted before termination.
• Work not completed. What scope was not delivered, to prevent future claims.
• Costs incurred. Final budget reconciliation including committed and accrued costs.
• Vendor and resource obligations. Status of active contracts and team assignments at the point of termination.
• Disposition of deliverables. Where completed work is stored or transferred; who is responsible going forward.
• Lessons learned. What the organization should know from the project even though it did not complete.

The reason early termination requires the same closure rigor as successful completion is that the ambiguity problem doesn't disappear just because the project stopped. A terminated project without a formal close still has vendor contracts that may be technically active. It still has team members who may not know their obligations have ended. It still has organizational questions about what was paid for and what was delivered. Closure answers those questions regardless of how the project ends.

Phase Closure: The Same Logic at a Smaller Scale

Projects structured in phases have an additional closure event that most PM teams undervalue: phase closure. At the end of each phase, the deliverables produced in that phase should be formally accepted before the next phase begins. Resources from the phase may be released or reallocated. Lessons learned in the phase should be captured while the team still has fresh context. Any risks that materialized during the phase should be closed out or reassessed for the next phase. Phase closure is not a scaled-down version of project closure. It is project closure logic applied at a phase boundary, and the benefits are the same: a clean record of what was produced, accepted, and decided, with nothing carried forward as an unresolved ambiguity.

Phase closure applies at any scale where distinct phases exist: a design phase formally accepted before the build begins, a pilot accepted before full rollout, a procurement phase closed before installation starts, or a testing phase approved before go-live. The logic is the same at each boundary: confirm that what this phase produced has been accepted, release what is no longer needed, capture what was learned, and then begin the next phase on a clean foundation rather than an inherited set of open questions.

The practical consequence of skipping phase closure is that the problems of one phase get inherited by the next without being formally acknowledged or resolved. An acceptance question from Phase One that was never answered becomes a scope dispute during Phase Two. A vendor relationship that was left in an unclear state at the end of Phase One becomes a financial dispute during Phase Three reconciliation. Phase closure is worth the time it takes because the alternative is carrying open questions forward into a context where they are harder to resolve and more expensive to fix.

What You Leave Behind When You Skip It

Here is what a project that never formally closed leaves in its wake. The sponsor retains the right to ask for more, because no formal record was created establishing what was delivered and what was accepted. The team stays on the hook, because no one was formally released from their project obligations. The vendor relationships stay technically active, because no one filed closure documentation. The budget lines stay open, because no one completed the financial reconciliation. And the organizational knowledge from the project — what worked, what didn't, what the next team should know — was never captured.

None of these are hypothetical risks. They are the documented consequences that appear in project post-mortems across industries. The irony is that skipping closure is usually framed as saving time: the project is done, the team wants to move on, why spend a week doing closure activities? What the calculation misses is that every unresolved closure item doesn't disappear. It defers. And when it resurfaces, it arrives in a context where the team has moved on, the documentation is incomplete, and the cost of resolution is higher than it would have been during the closure window.

Closure Protects Everyone Involved

Formal project closure is often described as protection for the project manager or the client. It is both, and it is neither exclusively. The closed project record protects the team by documenting that the work was done, that it met the agreed standard, and that it was formally accepted. It protects the client by creating a clear record of what was delivered, what was explicitly out of scope, and what decisions were made along the way. It protects the organization by establishing an authoritative account of what the project cost, what it produced, and what the lessons were for the next project that attempts something similar.

The PM who closes clean is not doing extra paperwork. They are building the evidence base that defines the project's record: what succeeded, what was agreed, and on what terms. When disputes arise — and on complex projects with long timelines and multiple stakeholders, they do — that record is what allows the conversation to start from shared facts rather than competing memories. The closure meeting is not a formality. It is the moment when everyone present establishes, together and on the record, what was built and what was received. Without it, the project doesn't end. It just waits.

Closure Readiness: A Practical Test

Before initiating formal closure, a simple readiness check confirms that the project is actually ready — not just finished in the team's estimation. Each item needs documented evidence, not just a verbal confirmation:

What's Next

The next chapter, The Closing Process, covers exactly what happens during closure: the prerequisites that must be in place before you can begin, the mechanics of formal acceptance, the final review that establishes the project's official record, and the transition that hands ownership to whoever runs the work after the project ends.

Reflect

• Think about a project you were part of that didn't have a formal closure process. What unresolved items surfaced later that a proper close would have addressed? How much time and effort did resolving them require?
• In your organization, who has the authority to formally accept project deliverables? Is that person consistently involved at project close, or does acceptance tend to happen informally through team-level sign-offs?
• Have you experienced a project that was terminated early without a formal close? What was left unresolved, and how was it eventually addressed?
• Phase closure is often skipped because it feels like overhead when the team is eager to move to the next phase. What would need to change in how phases are planned and scheduled to make formal phase closure routine rather than optional?