PMP Project Closure: Completion Criteria, Transition, Lessons Learned and Closing Contracts

Managing project closure means formally finishing a project or one of its phases: confirming that the agreed criteria are met, getting completion approved by the right authority, handing the outputs to whoever will own them, and concluding the administrative work (lessons learned, contracts, finances and people) so nothing is left open. Closure is planned work, not something that happens when the last deliverable ships.

The PMP Examination Content Outline lists the enablers for this task, and this lesson follows them:

1. Obtain project stakeholder approval of project completion: from the person or body the charter, governance plan or contract names.
2. Determine criteria to successfully close the project or phase: measurable conditions, agreed early, that say when the work is done.
3. Validate readiness for transition: evidence that the operations team, or the next phase, can take over.
4. Conclude activities to close the project or phase: final lessons learned and retrospectives, procurement closure, financial closure and the release of resources.

The same steps apply to a phase as to a whole project. A phase closes at its gate; the project closes once, at the end. They also apply whatever the delivery approach: an agile project still needs an agreed reason to stop, an approval, a handover and a tidy finish. And they apply to a project that is cancelled part-way, which is still closed rather than simply abandoned.

Closure draws on other tasks without repeating them. Accepting individual deliverables belongs to scope management, settling a contract dispute uses the procurement processes, and measuring benefits after go-live belongs to value delivery. Closure is where those threads are checked and tied off.

Closure criteria are the measurable conditions that must be true for the project or phase to be declared complete, agreed with the key stakeholders during planning and recorded in the project management plan, the charter or the contract. Defining them early is the main defence against arguments at the end about whether the project is finished.

Good closure criteria are:

• Measurable: a test anyone can check, such as all deliverables accepted, a measured performance level reached, or documentation handed over and acknowledged.
• Agreed by the people who will judge them: the sponsor, the customer and the receiving operations owner, not just the project team.
• Achievable before the project ends: conditions the project itself can meet, such as training delivered, records archived or final costs reconciled.

That last point matters. Many projects exist to produce benefits that only appear months or years after go-live, such as higher member retention or reduced energy use. Those benefits belong in the business case and the benefits management plan, and are tracked after closure by the sponsor or the business owner. Making a long-term benefit a closure criterion would keep a finished project open indefinitely. The closure criteria instead confirm that the project delivered what the benefits depend on and that someone owns measuring them.

Using the criteria to settle disputes

When a stakeholder refuses to accept completion, the first move is to go back to the agreed criteria and the evidence against them, and review both with that stakeholder. If the criteria are met, a new expectation raised at closure, one that was never part of the agreed criteria, is a new requirement. It is handled through change control or as follow-on work, not by silently extending the project, and not by overruling the stakeholder either. Issues found after completion are routed through whatever after-completion support the agreement already provides, rather than by reopening the project. If the criteria genuinely are not met, the project is not finished, whatever the schedule says.

An adaptive project ends when its product goal or release objectives are met, or when the value of the remaining work no longer justifies its cost, not when the product backlog is empty. A backlog usually never empties: new ideas and nice-to-haves keep arriving. Using an empty backlog as the end condition would fund low-value work indefinitely.

The product owner is best placed to weigh what each remaining item is worth, and the team can forecast what it would cost. The project manager's job is to put that value-versus-cost picture in front of whoever the charter says decides. It is a governance decision, not a matter of the team's preference. Charters for adaptive projects often state their end conditions explicitly, including a value-based stop, so the decision has a clear owner and test.

Remaining backlog items that still matter, such as items with a compliance or contractual driver, are not lost when the project ends. They move to the backlog of whoever owns the product afterwards, with that owner's explicit agreement (see the transition section below).

Approval of project completion is a separate, formal decision from accepting individual deliverables, and it must come from the authority that the governance plan, charter or contract names. Accepting a deliverable says one output meets its acceptance criteria; approving completion says the whole project or phase has met its closure criteria and may be closed.

Two consequences follow:

• Every deliverable being accepted is not the end. When all outputs are accepted, the next step is to obtain formal completion approval from the named approver, then conclude the closing activities.
• Approval comes from the named authority, not the most convenient person. On agile work the product owner accepts increments, but completion is approved by whoever the charter or contract names for that decision. Statements of satisfaction from other people, however senior or well informed, are evidence, not approval. If the named approver is not yet available, the project manager schedules the decision with them and continues the closing work that does not depend on it.

Approval is normally recorded in writing (a signed completion certificate, a sign-off in the governance record or minutes of the decision) so that the closure is auditable.

A phase closes at a phase gate (also called a stage gate, kill point or phase review): a governance review that checks the phase's exit criteria and decides whether the project continues to the next phase, continues with changes, or stops. The next phase should not start until that decision is made, however ready the next team is. Starting early bypasses the governance the organization put in place to protect its investment.

At the gate the project manager presents the phase results against the exit criteria, along with the updated forecast, risks and the readiness of the next phase. The decision belongs to the body the governance plan names, often a sponsor or steering committee. Typical outcomes are:

• Go: the exit criteria are met; the phase is closed and the next one is authorized.
• Go with conditions or a change of direction: proceed, but with actions, a revised plan or a change in scope.
• Hold or repeat work: the criteria are not met and the gap must be closed first.
• Stop: the business case no longer holds, and the project moves to closure.

When a criterion is not met, the project manager does not waive it, quietly redefine it, or decide alone whether to proceed. They analyse the shortfall (how big it is, why it happened, what it puts at risk in the next phase and what options exist) and present that analysis at the gate so the decision-makers can choose.

Closing a phase also includes the smaller closing activities for that phase: capturing its lessons, closing any contracts that ended with it, and releasing people who are not needed in the next phase.

Validating readiness for transition means confirming, with evidence and against criteria agreed with the receiving owner, that the operations team (or the next phase) can run and support what the project delivered from the first day it takes over. A deliverable that works is not the same as a deliverable someone can operate.

The strongest evidence is the receiving team doing the work itself:

• Trained staff who have completed the agreed training, not only attended it.
• Supervised dry runs in which operations staff carry out real tasks, such as handling a representative day of live service requests end to end, while the project team observes.
• Accepted support procedures: runbooks, support processes and escalation paths that the operations owner has reviewed and accepted as sufficient.
• A transition checklist or set of entry criteria, agreed in advance, walked through with the receiving team.

Weaker evidence includes a test passed by the project's own engineers, documentation that was delivered but never reviewed, a training schedule rather than completed training, or the project team's confidence. Where the agreed criteria say who must demonstrate something, only that demonstration meets the criterion; a substitute result, or someone's willingness to sign anyway, does not change what was agreed.

Responding to readiness gaps

Gaps often surface close to handover. The first step is to understand the gap with the receiving owner: what exactly is missing, why, what it risks and what it would take to close it. Only then choose a response, and take any decision on timing to the sponsor with that analysis. Options include closing the gap before handover, adjusting the handover date, or handing over with a mitigation.

A common mitigation is hypercare: a time-boxed period after go-live in which the project team provides extra support or covers a specific function, with clear exit criteria for when operations takes over fully. Hypercare suits a gap that is understood and limited, and only with the receiving owner's agreement. It is not a way to hand over something nobody is ready for.

Open items and remaining backlog

Customers often accept a deliverable with a short list of minor open items (a punch list). Closure does not lose them: each item gets an agreed owner and completion date, accepted by the customer or receiving team, and the list is referenced in the closure documents. On agile work, remaining backlog items that still need doing move to the product's ongoing owner's backlog with that owner's explicit agreement, not simply left in a backlog that nobody will look at after the project ends.

Final lessons learned consolidate what was learned across the whole project into a form that future projects can use, and are archived in the organization's lessons learned repository as an organizational process asset. They build on the lessons register kept throughout the project; they are not a single meeting held from scratch at the end.

At closure the project manager:

1. Consolidates the lessons register, including the outputs of iteration retrospectives, into project-level themes.
2. Reviews it with the team and key stakeholders so it reflects every perspective, not only the project manager's.
3. Archives it in the organizational repository, where future project managers and PMOs will look.

Lessons learned must be honest and complete and written in neutral terms: they describe what happened, the cause and the effect on the project, not who to blame. If a stakeholder asks for an uncomfortable entry to be deleted, the right response is to discuss it with them and reword it neutrally (describing the event, its cause and its effect rather than attributing fault), not to remove a lesson the organization needs.

The final retrospective

A project's final retrospective looks back across the whole project and its purpose is to help future teams and the organization, not to choose improvements for the next iteration, because there is no next iteration.

Findings that sit outside the team's control, such as an organizational process or policy that slowed the work, go to the owner of that process and into the lessons learned, so the organization can act on them after the team has disbanded.

Every contract must be formally closed before the project itself is closed. A supplier who has finished the work and been paid has not necessarily been closed out: formal closure confirms that all obligations on both sides are complete and records it.

Closing a contract typically includes:

• Confirming in writing that the supplier's obligations are complete: deliverables accepted, documentation and warranties provided, as the contract requires.
• Settling every payment the contract ties to completion: including any amount the contract holds back until a stated condition is met, released once that condition is satisfied, and the final payment.
• Resolving open claims and disputes through the process the contract defines, preferably by negotiation and then by any agreed alternative dispute resolution, before the contract is closed. A contract with an open claim is not closed.
• Sending formal notice of completion and completing the contract file, which is archived with the project records.
• Where the organization requires it, a procurement audit or review of how the procurement went, feeding lessons learned.

If a project is cancelled while a supplier is still working, the contract is still closed, using the termination terms it provides. A termination-for-convenience clause is the usual name for terms that let the buyer end a contract without the supplier being at fault, normally paying for work done and agreed costs. The project manager applies the contract's terms rather than simply stopping payment or walking away.

Planning and running procurement belong to the procurement task; closure is where the project manager makes sure each contract reached a formal end.

Financial closure means reconciling all project costs, closing the project's cost accounts to further charges and returning unused funds, so the project's final cost is known and nothing more is charged to it. Releasing resources means formally returning people, equipment and facilities to their owners as the work that needed them ends.

Financial closure

• Reconcile before closing. Expected costs that have not yet been billed, such as committed costs that have not yet been invoiced, are reconciled before the cost accounts are closed. Closing early would misstate the final cost.
• Close the cost accounts. Once the work is finished, the accounts are closed so that no further time or costs can be booked to them.
• Return unused reserves. Contingency reserve held for risks that did not occur, and any unspent budget, go back to the organization through its financial process. Leftover money is not a fund for adding scope at the end; a new feature request is new work and follows change control or a new funding decision.
• Report the final financial position in the final report: final cost against budget and the main variances.

Releasing resources

• Release people as their work ends, formally, back to their functional managers in a matrix organization or to the resource pool, rather than letting them drift away or holding them longer than needed.
• Honour transition commitments. People named in an agreed transition or hypercare plan are released when that commitment ends; others can go as soon as their closing work is done. Requests to release people sooner are negotiated against that commitment, with the receiving owner involved, rather than settled by quietly dropping it.
• Give performance input. In a matrix organization functional managers usually run appraisals, so the project manager gives them input on each person's contribution, and recognizes exceptional work.
• Return physical resources such as equipment, facilities, licences and access rights.

The final project report is the closure document that summarizes how the project performed against its objectives: whether it met its scope, schedule, cost and quality objectives, how it delivered value, and how major variances, risks and issues were handled. It is produced for agile and hybrid projects as well as predictive ones; on agile work it summarizes how the product goal and value objectives were met and explains variances against the release plan and budget.

A final report typically covers:

• A summary of the project and its objectives, and whether the closure criteria were met.
• Performance against scope, schedule, cost and quality, with explanations of significant variances.
• Value delivered so far and how the remaining benefits will be tracked after closure, and by whom.
• Transition status: who owns the product, open items and their owners.
• A summary of the main risks, issues and lessons learned.

Archiving project records

Project records are archived according to the organization's retention policy and any contractual or legal obligations. These can differ: a contract or data-protection obligation may require certain information to be returned or disposed of at the end, while other records are kept for the organization's retention period. The project manager meets both obligations rather than applying one policy to everything.

Closing a terminated or cancelled project

A project that is ended early, because the business case no longer holds or the organization's priorities changed, is still formally closed. The closure is simply adapted to the state of the work:

• Record the reason for termination and the state of each deliverable or increment when the project stopped.
• Hand over completed or usable deliverables (designs, surveys, increments) to an owner who can use them, and agree who supports anything already in production.
• Close or terminate contracts under their terms, close the finances and release resources.
• Capture lessons learned; a cancelled project often has some of the most valuable ones.
• Obtain the sponsor's formal acknowledgement of the closure and archive the records.