A Project Closure Checklist That Separates Done From Accepted

Start with the agreement you are closing

The implementation is finished. Someone posts a celebration message. A week later, a small correction is still open and nobody knows whether the project team or the ongoing service team should handle it. The missing step was not another status update. It was an explicit closure decision.

Atlassian's project closure guide distinguishes finishing deliverables from formal closure and handoff. Use that distinction to inspect the accepted scope, final version and remaining responsibilities. This is an operational checklist; commercial or contractual acceptance stays with the authorized owner.

Use three separate checks

Keep the evidence beside the condition it supports. A green task status can support completion of a task, but not necessarily acceptance of a deliverable. A message saying 'looks good' may refer to an earlier draft. Check the speaker, version and scope before recording final approval.

Give every loose end a destination

• Must finish before closure: a missing deliverable or unmet condition that the owner says blocks acceptance.
• Accepted exception: a specifically described limitation accepted by the authorized recipient, with its consequences recorded.
• Transferred work: a follow-up accepted into the receiving team's work queue with a responsible owner.
• New request: work outside the agreed baseline, considered through the normal change process.

These are proposed review categories, not labels an assistant should assign conclusively. In particular, moving an issue into another queue does not prove its new owner accepted it. If a request changes the baseline, use a scope-change review instead of quietly adding it to a nearly closed project.

An example: the website is live, but is the project closed?

Imagine a fictional website migration. The approved pages are live, redirects have been checked and the content owner has approved the final copy. One optional analytics dashboard remains unfinished, and the maintenance team has not yet received its operating notes. The launch is real. Closure is a separate question.

The packet should identify whether that dashboard was an acceptance condition, an agreed later deliverable or merely a suggestion. If it was required, the authorized owner must resolve it rather than rewriting the history. If it can transfer, the receiving team must accept its scope and priority. The operating notes need a known location and a person who can use them.

A conditional closure record can be appropriate when the responsible parties explicitly agree to it. Name the condition, recipient, follow-up date and what happens if it is not satisfied. 'Close now and sort it later' is not a usable condition. The AI should surface the missing decision, not interpret the agreement on the team's behalf.

Ask Mio to assemble, compare and flag

Mio's meeting-notes-to-Linear case shows retrieval, proposed task changes, human edits and approved record updates. It also shows a later correction. Those are useful building blocks for closure preparation, but creating or changing issues is not proof that a project has been accepted.

A bounded request is: 'Prepare an internal closure packet from this approved scope, current work records and acceptance notes. Map each deliverable to its version and acceptance evidence. List remaining issues and any confirmed receiving owner. Flag ambiguous approval and missing handoff material. Do not close the project, archive channels, delete files or contact the client.'

The project lead verifies the packet with delivery and receiving owners. Record the actual closure decision in a decision log, linking the final deliverables and accepted exceptions. Follow existing access and record-retention rules when organizing the project material.

Test the handoff after the project team steps away

Ask the receiving owner to locate one deliverable, explain one accepted limitation and identify the route for a new issue. If they cannot do that without asking the departing project team, improve the handoff before claiming it is complete.

Measure reopened acceptance questions, ownerless residual work and time spent reconstructing context after closure. Keep later business value separate: an accepted project may still need an outcome review. Prepare a reviewable closure packet with Mio.