Project closure process flowchart: delivery to sign-off
A project closure process flowchart: acceptance against criteria, snag list, handover and support, final invoicing, contract closure and sponsor sign-off.
What the project closure process flowchart: delivery to sign-off process is
A project usually ends twice. It ends in practice on the day the last deliverable goes live and the team starts talking about what comes next, and it ends formally weeks later, when the final invoice is settled, the purchase orders are closed, the records are archived and the sponsor signs. The gap between those two endings is where closure goes wrong. People are reassigned, the person who knew which contract was still open moves to another programme, and a project everyone considers finished carries on drawing cost codes and licence fees. Writing the closure process down is mostly about shortening that gap and giving each of the remaining tasks an owner.
This chart starts after delivery, not before it. It is not the launch decision: whether to release at all is a readiness judgement, and the go/no-go decision tree at /templates/go-no-go-decision-process covers that gate. It is not the route for altering scope while the project is still running, which belongs in the change control process at /templates/change-control-process. And it stops where the deliverable becomes somebody's day job: once operations own it, faults go through incident management at /templates/incident-management-process and further alterations through change management at /templates/change-management-process. What sits in between those neighbours, and is usually the least documented part of the project, is what this page maps: acceptance, handover, money, records, learning and sign-off.
The flow crosses five lanes, Project manager, Project team, Customer / sponsor, Finance and PMO, over five stages: closure trigger, acceptance, handover, commercial closure, and learning and sign-off. Two choices in the layout are deliberate. Both a completed project and one stopped early enter through the same trigger, because a terminated project still needs its part-finished work accepted, its contracts closed and its lessons recorded; it simply has less scope to close. And the sponsor's final sign-off is a decision with a route back rather than a formality, so outstanding actions rejoin the snag list that is already in the chart instead of being waved through or tracked in a second list nobody maintains.
What this flowchart covers
In this template
- Five swimlanes, Project manager, Project team, Customer / sponsor, Finance and PMO, laid out over five stages: Closure trigger, Acceptance, Handover, Commercial closure, and Learning and sign-off.
- One entry point for two triggers: "Closure type?" answers Delivered or Terminated, where Terminated routes through "Agree termination scope and cut-off" in the sponsor lane before rejoining the same deliverables register and acceptance path.
- Acceptance as a test rather than a meeting: the deliverables register is reviewed against the acceptance criteria, and "All deliverables accepted?" answers Accepted or Gaps, with Gaps logged on a snag list, cleared by the project team and re-checked before the acceptance record is signed.
- Handover with a support arrangement attached: deliverables transfer to operations and the sponsor agrees the support and warranty period, so the date the service desk takes over is fixed before the project disbands.
- Commercial closure in the Finance lane: the final invoice is issued and costs reconciled, then "Contracts and POs closed?" sends Open items to the project manager to settle claims and orders, and only a Closed answer releases the team and reassigns assets.
- A PMO close-out that ends in a real decision: lessons learned workshop, archived project records and a scheduled benefits review, then "Sponsor signs off closure?", where Actions open returns to the snag list and Signed reaches "Project formally closed".
When to use this template
- Projects in your portfolio are finished in practice but never closed on paper, so cost codes stay open and the portfolio report still counts work that stopped months ago.
- Deliverables are handed over without a written acceptance, and the argument about whether something met its criteria starts after the team has been reassigned.
- Operations inherit the output with no agreed warranty or support period, and every post-launch defect is negotiated case by case.
- Lessons learned workshops are held, written up and never read, because nothing connects them to an archive anyone searches.
- You are standardising closure across a PMO and need one diagram that covers completed projects and cancelled ones without maintaining two processes.
How it works
Rename the lanes to your delivery model
Replace Customer / sponsor with whichever applies: an external client signs acceptance under a contract, an internal sponsor signs under a business case, and the evidence you need differs. Merge Finance and PMO if one person does both, and keep the Project team lane separate from the Project manager lane even in small organisations, because the remediation work and the chasing are done by different people.
Settle the acceptance criteria before you use the chart
"Review against acceptance criteria" is only meaningful if the criteria were written at the start and marked mandatory or desirable. Record them deliverable by deliverable in the register the chart compiles, so acceptance is a check against a list rather than an opinion formed in the review meeting. Where a criterion was never agreed, log it as a lesson instead of renegotiating it during closure.
Define what a snag is and who may waive one
Draw a line between a defect, which goes on the snag list, and a change, which goes back through change control and is not a closure item at all. Then name who is authorised to accept a deliverable with an outstanding snag, what has to be recorded when they do, and the date by which the remaining work is completed. Without that, the snag list becomes the place closure quietly stalls.
Write the support and warranty terms into the handover
State the length of the warranty period, who fixes defects inside it, who pays, and the date support transfers to the service desk or the business-as-usual team. List what has to move with the deliverable as well: runbooks, administrator credentials, licence and subscription ownership, monitoring, and the named person who accepts it on the operations side.
Close the money before you release the people
Set an end date for the project cost codes at the same time as the final invoice, so late bookings do not move a reconciled budget. Work through open purchase orders, accruals, retentions and subcontractor claims explicitly, because these are what keep a project financially open long after it looks finished. The chart releases the team only after "Contracts and POs closed?" answers Closed, and that ordering is intentional.
Hold lessons learned while the team is still together
Run the workshop before people disperse, not after the reports are written, and record decisions and causes rather than sentiments. Archive the project records for as long as your contract, tax and audit obligations require, in a place people actually search. Give the benefits review a date, an owner outside the project and a baseline measure now, then publish the chart and capture the sponsor's sign-off against it.
Frequently asked questions
What is the project closure process?
It is the sequence that turns a finished or stopped project into a closed one. In this chart it runs from a closure trigger, through checking deliverables against their acceptance criteria and clearing any snags, handover to operations with an agreed support and warranty period, final invoicing and cost reconciliation, contract and purchase order closure, release of the team and assets, a lessons learned workshop, archiving of the project records and a scheduled benefits review, ending in formal sign-off by the sponsor. The individual tasks are rarely difficult. What makes closure fail is that each one belongs to a different function and none of them is anybody's priority once delivery is done.
What is the difference between project handover and project closure?
Handover is one step inside closure, not a synonym for it. Handover moves the deliverable and its documentation to whoever will run it, and settles who fixes defects during the warranty period. Closure is everything that has to happen for the project itself to stop existing: acceptance recorded, invoices raised and costs reconciled, contracts and purchase orders closed, resources released, lessons captured, records archived and sign-off obtained. A project can be fully handed over and still be open for months because a purchase order was never closed, which is why the chart keeps the commercial stage separate from the handover stage.
How do you close a project that was cancelled or terminated early?
Through the same process, with a smaller scope. In this chart the Terminated branch adds one step, "Agree termination scope and cut-off", which fixes what will be finished, what will be abandoned and the date work stops, and then rejoins the normal path. Everything after that still applies: whatever was built is accepted or formally written off, contracts are closed under their termination provisions rather than their completion provisions, costs including any cancellation charges are reconciled, and lessons are recorded. PRINCE2 makes the same distinction inside its Closing a Project process, which separates preparing a planned closure from preparing a premature closure.
What should a project closure checklist include?
Deliverables checked against agreed acceptance criteria and the outcome recorded; snags either cleared or accepted with a named owner and date; handover to operations with documentation, credentials and licence ownership transferred; the warranty and support period agreed with a date for service desk takeover; the final invoice issued and credits applied; costs reconciled and project cost codes closed to further bookings; contracts, purchase orders, accruals and retentions closed; the team released and assets, licences and access reassigned; a lessons learned workshop held; records archived; the benefits review scheduled with an owner; and formal sign-off recorded.
Who signs off project closure?
The sponsor or customer, on a recommendation from the project manager. It is worth separating two signatures that often get merged. Acceptance sign-off says the deliverables meet their criteria and is given by whoever owns those criteria. Closure sign-off says the project itself can stop, which also requires the commercial and administrative work to be finished, and is given by the sponsor who authorised the money. In this chart they are two different steps in the Customer / sponsor lane, with the PMO holding the record. If the sponsor withholds sign-off, the outstanding items go back on the snag list rather than into an email thread.
Where does project closure sit in PMBOK and PRINCE2?
The PMBOK Guide sixth edition names it Close Project or Phase, a process within Project Integration Management; the seventh edition moved to principles and performance domains and no longer lists it as a discrete process, though the same work still has to be done. PRINCE2 has a Closing a Project process covering planned and premature closure, handing over products, evaluating the project and recommending closure to the board. This chart is compatible with either and tied to neither: it is drawn as swimlanes so the roles are explicit, which is the part both methods leave you to define for your own organisation.
When should the post-implementation benefits review happen?
After the deliverable has been in use long enough for the benefits in the business case to be measurable, which is usually months rather than weeks and depends entirely on what was promised. The point of scheduling it during closure is that this is the last moment anyone still owns the question. Fix the date, name an owner in the business rather than in the project, and record the baseline measure while the people who know it are still available. A review with no date in the diary is the closure step that most reliably disappears.