Ask three people on a finished project when it closed and you will often get three answers: the day the last deliverable went live, the day the final report went to the board, and the day the team was reassigned. All three are events. None of them is a closure decision, and a project where nobody can name who closed it, on what evidence, is a project that is still quietly open somewhere in the organisation.
Formal closure is a decision. Somebody with the standing to take it examines what is in front of them, concludes that this project or this phase is complete and that everything still outstanding has an owner elsewhere, and records that conclusion. What should happen before that point is everything needed to make the decision defensible.
Close Project or Phase sits at Section 2.1.6 of the PMBOK® Guide among the governance processes, and that placement is the useful signal. Closure belongs with the decisions about authority and oversight, because it is an exercise of authority: the same person or body that authorised the work, or somebody they have delegated to, declares it finished and releases the organisation from carrying it as live.
Two consequences follow. The first is that closure cannot be performed by the project team on its own initiative, however tidy the paperwork. A project manager can prepare a closure, assemble the evidence and recommend the decision, and somebody else takes it. The second is that closure has a date, an author and a basis, the same as any other governance decision, and all three belong in the record. Six months later, when a question surfaces about who owns a residual risk, that record is the only thing standing between the organisation and an argument.
Acceptance comes first and is narrower than people assume. It is a named person confirming, against criteria written down in advance, that what was produced is what was agreed. Where acceptance has been given by whoever happened to be in the meeting, or given against a demonstration rather than a criterion, the closure decision is resting on nothing.
Outstanding items come second, and the test is ownership rather than absence. Very few projects close with a clean sheet, and a closure that waits for one never happens. What matters is that every open change, issue, defect, claim and risk has a named owner outside the project and a route for acting on it. Anything still pointing at a project team that is about to disperse is an item that will be discovered, not managed.
Commercial and financial position comes third. Contracts either concluded or novated to whoever now holds them, final accounts agreed or the dispute handed on with its evidence, retention and warranty positions written down with their dates, purchase orders closed and the residual commitment stated as a figure. This is the part that gets deferred, and it is the part that turns up in an audit.
Records come fourth, and the standard is usability by a stranger. The question is not whether documents exist but whether somebody who was not there can find the decision log, the as-built configuration, the acceptance evidence and the lessons, and understand them. A shared drive nobody can navigate is the same as no records at all, for every practical purpose that matters later.
Most organisations put their closure effort at the end of the project, which is the hardest and least rewarding place to spend it. The team has thinned, memory has faded, and the people who could explain a decision have moved on. Phase closure happens while all of that is still available, and it is skipped almost everywhere.
Closing a phase properly means the same decision on a smaller scale, and it buys two things. It confirms that the next phase is being authorised on a sound basis, because the evidence for what was actually delivered has been examined rather than assumed. And it forces the outstanding items into ownership early, while the person who created one is still in the building. A programme that closes each phase this way arrives at final closure with very little left to do, which is why the organisations that find closure painless are usually the ones doing it repeatedly.
A data centre migration ran in four phases, moving workloads hall by hall. The final phase was declared complete at a steering meeting, the project was stood down, and the closure report recorded acceptance of the migrated services. Eleven months later a finance review found the legacy hall still drawing power under a contract with fourteen months to run, holding one rack that had never been migrated because it served a regulatory archive nobody had listed as a workload. No closure decision had covered decommissioning, because decommissioning had sat in a phase everybody treated as the tail end of the phase before it.
The cost was not the contract, which was recoverable. It was that the archive had been running unpatched and unowned for eleven months, and no one had been accountable for noticing. Knowing which residual obligations have to be named before a closure decision can honestly be taken is a governance judgement a structured PMP exam preparation course works through in situations where the pressure is to declare the thing finished and move on.
For a PMP® candidate, what matters is that closure is an authority decision with evidential requirements, and the question to carry into any situation describing a project winding down is who is entitled to close it and what they would need to see. Work being finished and a project being closed are separate states, and a great deal of practical project management lives in the gap between them.
Writing the closure criteria at authorisation is the cheapest way to make closure survivable. When the phase or the project is approved, agree what will have to be true for it to be closed, and who will decide. That conversation takes twenty minutes at the start, when everybody is optimistic and nobody is defending anything, and it converts closure from an argument about whether enough has been done into a comparison against something already agreed.
Closure decisions get taken under pressure, usually by people who want the project off the portfolio report, and holding the line on evidence takes both judgement and standing. Omega's PMP® Exam Preparation treats closure as the governance decision it is, across phases, contracts and whole projects.
Close Project or Phase and the governance processes it sits beside are described in the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
A090: Project Governance Explained: Who Decides What, and Why
A091: Project Governance vs Organisational Governance: What’s the Difference?
A092: How Projects Create Value Through Governance
A093: Choosing a Project Governance Model
A094: Governance Metrics That Actually Tell You Something
PMP and PMBOK are registered marks of the Project Management Institute, Inc.