September 6, 2026 · 7 min read
TL;DR: A project cancelled mid-flight still closes formally: contracts settled, resources released, finances reconciled, lessons recorded. Closure questions test sequence, so read the stem for what has already happened. And a closed project has no budget, no team, and no baseline, which is why post-closure defects go to the maintenance contract rather than back to the project.
Closure gets the least study time and shows up as some of the most reliably missed questions on the exam. Part of that is timing, since it is the last thing anyone revises. The bigger part is that closure questions are almost never about what to do; they are about what order to do it in, and about what is no longer available once a project is closed.
Yes, and the exam asks it in a form designed to make you say no.
A mobile-app project is cancelled because of a strategic shift. The executive team wants all resources moved to a new initiative starting next week and tells you to wrap up fast, since there are no deliverables left to finish. The senior instruction, the tight timing, and the apparent logic all point at complying.
The keyed answer is to request the time to properly close out contracts and equipment and to complete the final financial reconciliation. Close Project or Phase finalises all project activities regardless of why the project ended: contracts are settled and closed, resources are released, financial records are reconciled, and final status and lessons learned are recorded as organisational process assets. Skipping it leaves the organisation carrying open contractual and financial exposure that nobody is now watching. "No deliverables left to finish" is true and irrelevant, because closure work is not deliverable work.
Common trap: treating stakeholder reluctance as an administrative obstacle. At the end of an internal project, several key stakeholders including the sponsor are hesitant to accept the deliverables and close. Closing formally and letting them work it out afterwards is the wrong step, and the exam sometimes asks it as a NOT question to catch candidates skimming. The reluctance is information: something is unresolved. Surface the open issues, discuss the underlying reasons, and gather feedback, then close. Across this bank's 44 closure questions, the answers that push toward formal sign-off while leaving a stated concern unaddressed are among the most consistently chosen wrong ones.
Sequence is the whole game in this task, so read the stem for what is already done.
The canonical scenario: a project manager convenes the final review meeting to capture lessons learned, with all key stakeholders present. The deliverables have been validated, accepted, and audited for compliance. What next?
Upload the lessons learned register and the final report to the organisation's central repository. Everything else on offer, re-confirming objectives, re-running the compliance check, asking again for acceptance, has already happened according to the stem. The distractors are not wrong activities, they are activities in the wrong place, which is a harder thing to spot than a plain error.
| Step | Activity | Why it sits there |
|---|---|---|
| 1 | Validate deliverables against acceptance criteria | Nothing closes until the work conforms |
| 2 | Obtain formal customer or sponsor acceptance | Acceptance is a decision, separate from conformance |
| 3 | Close out procurements: collect, index, file records | Contract closure precedes administrative closure |
| 4 | Reconcile finances, release resources | Requires the contract position to be settled |
| 5 | Capture lessons learned with stakeholders present | Needs the full picture, including how closure went |
| 6 | Issue the final report | Summarises performance for the whole project |
| 7 | Archive to organisational process assets | The last act; makes the records findable later |
Procurement closure deserves a note because it has its own document set. Closing a contract means collecting, indexing, and filing all procurement documentation: contract schedule, scope, quality, and cost performance, change documentation, payment records, inspection results. That indexed package is what supports lessons learned and the evaluation of contractors for future contracts, and the exam names it as "the collected, indexed procurement records" rather than by any single-document title.
The final report has a distinct job too. When a business stakeholder wants to judge whether the initiative succeeded, what they need is the key performance indicators documented in the final report. A status report describes a point in time rather than the whole initiative. The lessons learned register is written for future projects rather than for assessing this one.
Anything requiring a budget, a team, or a baseline, because it has none of the three.
A booking system goes live, a maintenance contract is signed, and the customer then reports that the date picker breaks on tablets, a case testing never covered. The project is formally closed. So the team fixes it under the terms of the maintenance contract, because an agreement already exists for defects found in live operation. That testing missed the case is a lesson learned, not a route change.
Reopening the project is the tempting answer, and it is worth understanding why it appeals. The miss feels like the project's fault, so making the project fix it feels like accountability. But a closed project has no baseline to change, no funding to draw on, and no team assigned. Reopening it would mean re-chartering, which is a heavier act than a warranty ticket and gets you a worse outcome slower.
The same reasoning settles the whole family: once a project is closed, questions about who handles a live problem are answered by whatever agreement governs operations, not by the project management plan. Knowing which artefacts survive closure and which stop existing is what makes the difference on these, and it is exactly the kind of distinction a bank of worked scenarios teaches faster than a reading list does.
Does a cancelled project still need to be formally closed? Yes. Contracts are settled, resources released, finances reconciled, and lessons recorded, exactly as on a completed project. Skipping it leaves open contractual and financial exposure.
What is the last thing that happens when closing a project? Archiving the lessons learned register and the final report into the organisation's repository. By the final review, validation, acceptance, and compliance auditing are already done.
What happens if a defect appears after the project is closed? It goes to the maintenance or warranty agreement covering live operation. A closed project has no budget, team, or baseline; the missed test case is a lesson learned, not grounds to reopen.
What do you do when stakeholders refuse to accept the deliverables? Surface and resolve the open issues first. Reluctance signals something unresolved, so discuss the reasons and gather feedback before pushing to formal closure.
The 44 closure questions in PMP Practice sit in a bank re-certified against PMBOK 8 and the July 2026 Exam Content Outline, and every wrong answer comes with the reasoning that makes it wrong, explained rather than just marked. Start the free 20-question sample with no card and no signup.
Related: What replaced Process Groups and Knowledge Areas · Procurement contract types · Process study guide
Sources: PMI — PMP Examination Content Outline, 2026 (PDF) · PMI — PMBOK Guide standards
Does a cancelled project still need to be formally closed?
Yes. A project terminated early goes through Close Project or Phase exactly as a completed one does: contracts are settled and closed out, resources are released, financial records are reconciled, and final status and lessons learned are recorded. Skipping that leaves the organisation carrying open contractual and financial exposure, which is why the project manager negotiates for the time to do it even when executives want people moved immediately.
What is the last thing that happens when closing a project?
Archiving the lessons learned register and the final report into the organisation's repository, where future projects can find them. By the time the final review meeting happens, the deliverables have been validated and accepted and compliance has been audited, so what remains is moving the records into organisational process assets. Anything else at that point repeats work already done.
What happens if a defect appears after the project is closed?
It goes to whatever agreement covers live operation, usually a maintenance or warranty contract, not back to the project. A closed project has no budget, no team, and no baseline to work against. That testing missed the case is a lesson learned, not a reason to reopen. Reopening is the tempting distractor because the miss feels like the project's fault.
What do you do when stakeholders refuse to accept the deliverables?
Surface and resolve the open issues before closing, rather than pushing to formal closure and leaving them to sort it out afterwards. Reluctance at the end signals something unresolved, so discuss the underlying reasons and gather feedback first. Formal closure with unaddressed stakeholder concerns is the wrong step even when every deliverable technically conforms.