project_closeout v1.0.0

---

name: project_closeout description: Close out a project or client engagement properly: build acceptance evidence against the final scope (original scope plus approved changes only), check every deliverable, hand over every open item to a named owner with a date, reconcile the final invoice to the cent, record lessons learned, and archive the project so a stranger can audit it later. Use when a project, phase, contract, or client engagement is ending, when a client asks for final sign off or a final invoice, when work is being handed to operations, or when an engagement ended badly and needs an honest paper trail. For a blameless review of what went wrong use project_postmortems. For handing a work session between agents use session_handoff_docs.

---

Project Closeout

Purpose

Projects rarely fail at the end. They leak. A deliverable nobody formally accepted, an open item owned by "the team", a final invoice that almost reconciles, records scattered across inboxes. The leak shows up months later as a dispute nobody can settle, because the paper trail cannot answer basic questions.

This skill closes a project or engagement as one system, producing a single closeout pack (template: assets/closeout-pack-template.md) that goes through six gates in order:

1. Freeze the final scope.
2. Prove acceptance deliverable by deliverable.
3. Hand over everything still open to named owners.
4. Reconcile the money exactly.
5. Record lessons while memory is fresh.
6. Archive so a stranger can audit it.

The method follows the closing discipline in the PMBOK tradition: confirm requirements were met, get formal acceptance, do financial closure, write the final report, document lessons learned, archive the records, hand off the result, and release the team last. Two points from that tradition do real work here. Acceptance must be formal and written; verbal acceptance is not sufficient to close a project. And archives are only useful if they are indexed, so the archive is a manifest, not a folder dump.

Scope boundary: this skill is about ending the work cleanly and proving it. Running a retrospective meeting about causes belongs in project_postmortems. Delivering creative files to a client belongs in client_video_deliverables. Selling a finished asset belongs in digital_asset_exit. Closing vendor contracts you hold as a buyer is part of this pack when they belong to the project; a standing renewal register for all company contracts belongs in contract_renewal_radar.

Ships: assets/closeout-pack-template.md (the pack), scripts/closeout_check.py (the gate checker), references/checklists.md (six sweeps), references/worked-examples.md (one clean close, one messy close after a dispute).

Workflow

1. Freeze the final scope before judging anything

Write the scope baseline into section 1 of the pack: the original contract, SOW, or charter, plus every approved change, each with its source and date. That sum is the final scope. It is the only thing acceptance is measured against.

Work that was done but never approved in writing is recorded as a note. It is not a deliverable owed, and it does not go on the final invoice. Closeout is the worst possible place to argue that verbal approval was real; the pack states the fact plainly and lets the lessons learned entry carry the process fix.

If the scope documents cannot be found, stop. A closeout built on remembered scope is fiction. Finding or reconstructing the baseline, with the gaps labelled as gaps, comes first.

2. Build the acceptance matrix and gather evidence

One row per deliverable in the final scope, in section 2 of the pack. Each row carries:

• The criteria source: the SOW section, spec, or change order it is judged against.
• Evidence a stranger can open: the final file, a test result, an inspection record, a reconciliation sheet. "Done" and chat approval are not evidence.
• A status: ACCEPTED, PROVISIONAL, REJECTED, NOT_DELIVERED, or WAIVED.
• For accepted rows, the named person who accepted it and the date. The acceptor must have authority to accept. A friendly user saying thanks is not acceptance of a contract deliverable.

Run the acceptance sweep in references/checklists.md section A. Two status rules matter:

• Provisional acceptance is real but conditional. Record the condition and the date for final acceptance, and carry final acceptance as an open item in section 4. Where the contract holds money back until final acceptance, say how much and what releases it.
• A REJECTED or NOT_DELIVERED row blocks a clean close. Do not soften the status to make the pack prettier. The row becomes the blocking reason in section 8 until the decider resolves it.

Minor defects that do not block acceptance go on the punch list in section 3, each with an owner, a due date, and any money held against it. The punch list pattern comes from construction practice, where a written list of items to complete or correct is agreed before final payment, and it works the same way for any deliverable with small leftover faults.

3. Hand over every open item to a named owner

Sweep everything still open at closeout into section 4: unfinished work, pending decisions, unresolved change requests, support questions, closing cost codes, releasing retainage, all of it. For each item:

• A named person as owner. A team, a department, or TBD is not an owner. An item with no named owner has not been handed over, it has been abandoned, and the pack must not pretend otherwise.
• A due date in ISO format.
• Exactly one next action, small enough to start tomorrow.
• Written confirmation from the receiving owner that they have taken it. File the confirmation in the archive.

Also settle operational ownership in the pack: who runs the delivered thing now, who supports it, who pays for it, and where a user reports a problem. Add support or warranty periods with start and end dates when they exist. Run sweeps B and D in references/checklists.md for vendor closure, access revocation, and knowledge transfer.

4. Reconcile the money to the cent

Fill section 5 of the pack with plain numbers. Six lines: adjusted contract value, invoiced before final, final invoice, credits, retainage held, retainage to release.

The identity must hold exactly: invoiced before final + final invoice - credits = adjusted contract value.

If it does not hold, do not adjust a number quietly to force it. State the gap, why it exists, who owns closing it, and what event triggers the missing money. An explained gap owned by a named person is a valid closeout state. A hidden gap is a future dispute. The checker flags any mismatch; the pack must answer the flag in words.

Final invoice rules:

• It bills accepted work only. Rejected or undelivered work is not on it.
• All project costs are charged before it goes out.
• Retainage to release never exceeds retainage held, and its release condition is written in the pack. In construction contracts retainage is commonly 5 to 10 percent of each payment application, held until completion conditions are met. Whatever the range, the contract in front of you governs, not the common practice.
• Vendor and subcontract final claims are settled, disputed in writing, or carried as open items. Project cost codes are closed, or closing them is an owned open item.

5. Record lessons learned within days, not weeks

Hold the lessons session soon after final acceptance, while the people who did the work still remember it. PMI's lessons learned method asks three questions: what went right, what went wrong, what needs to be improved. Answer each with a specific example, not a mood.

Write the answers in section 7 and file them in the shared lessons repository, not only inside this project's archive. A lesson that the next project cannot find is a diary entry. Include the scope change history and how changes were handled, the real schedule and cost drivers, and any risk that arrived unlisted, because those are the entries future estimates actually use.

Keep blame out of the wording. "Change approvals were given verbally twice" is a process fact a future team can fix. Naming a person as the problem teaches the next team to hide problems instead.

6. Archive against the stranger test, then write the final report

Build the archive manifest in section 6: one line per record group with a location a stranger can reach. Scope and contract, approved changes, acceptance evidence, final deliverables at final version, financial records, the handover register with takeover confirmations, lessons learned, final report. State the retention period and who can access the archive. Keep credentials and personal data out.

The archive passes when a stranger, given only the manifest, can answer five questions without asking anyone:

1. What was owed?
2. What was delivered, and where is the final version?
3. Who accepted it, against what criteria, and when?
4. What was left open, and who owns it now?
5. What money moved, and does it reconcile?

If any question fails, the missing record group is the fix. Run sweep E in references/checklists.md.

Then write the final report: overview, deliverable status, performance against time and cost with the real reasons for variance, stakeholder feedback, lessons learned, recommendations. Keep it short enough to be read. File it in the archive and link it in section 8.

7. Run the checker and take a verdict

Run the gate checker on the completed pack:

python3 scripts/closeout_check.py closeout-pack.md

It verifies the eight sections exist, every acceptance row has evidence, a named acceptor, and a valid status, every open item has a named owner, an ISO due date, and a next action, the finance identity holds to the cent, retainage release does not exceed what is held, and the archive manifest lists at least six usable record groups. Exit 0 is a pass, exit 1 lists hard gaps, exit 2 means the file could not be read.

Fix hard gaps in the pack or in reality, never by editing the pack to hide them. Then take exactly one verdict in section 8:

• Clean close: every deliverable accepted or waived, no open items except dated follow ups that an owner has confirmed, money reconciled, archive passes the stranger test.
• Close with handover: delivery is accepted, and a written register of owned, dated open items transfers with named owners who confirmed takeover. This is a good outcome when it is named honestly.
• Blocked close: acceptance is refused, a deliverable is missing with no agreed handover, or the money cannot be reconciled or explained. Record the blocking reason and the named decider. A blocked close is a report, not a failure of the process; hiding it would be.

Both sides sign section 8: the sponsor or client, and the delivery lead. Only after sign off, release the team, close the project in the management system, cancel its recurring meetings, and close its trackers. Release comes last because the records and lessons work needs the team that did the job.

Output Contract

Deliver the completed closeout pack: scope baseline, acceptance matrix with evidence and named acceptors, punch list, handover register with confirmed owners, financial closure with the identity verified by the checker, archive manifest that passes the stranger test, lessons learned, and a signed verdict of clean close, close with handover, or blocked close with its reason.

Also deliver the checker output. A pack reported without its checker result is an unverified claim.

For a closeout review of someone else's pack, deliver the gap list instead: each hard gap, which gate it belongs to, and what record or decision would clear it.

Never report a close as clean when the pack shows provisional rows, unexplained money gaps, or ownerless open items. Name it what it is.

Operating Rules

• Final scope means original scope plus approved changes. Nothing else is owed, and nothing else gets billed.
• Acceptance is formal, written, and from a named person with authority. Verbal acceptance never closes a deliverable.
• No owner, no handover. Every open item carries a named person, a date, and one next action, confirmed by the receiver.
• Money reconciles to the cent or the gap is explained in the pack with an owner and a trigger. Quiet adjustments are forbidden.
• The archive is an indexed manifest that passes the five question stranger test. A folder dump is not an archive.
• Lessons are filed where the next project can find them, within days of acceptance, worded as process facts without blame.
• One verdict, honestly named. Clean close, close with handover, or blocked close. The pack and the checker output decide which, not optimism.
• Release the team and close the systems only after sign off.