Most automation projects end the same way: the demo works, the ticket turns green, and everyone moves on. A few weeks later someone asks for a small change — and only one person knows where the credentials live, which inventory is “the real one,” and what breaks if you run the job twice.

That is not a tooling problem. It is a delivery problem. The work looked finished in the backlog, but it never became something operations could own.

Done for the project is not done for the platform

Project teams optimize for a date. Operations optimizes for the next two years of Tuesday mornings. Those clocks rarely match.

So “done” often means: the playbook ran once in a lab, the stakeholders nodded, and the consultant’s calendar emptied. What it should mean is quieter: someone who was not in the project can find the job, understand the risk, run it without calling anyone, and know what “good” looks like afterward.

If that bar feels high, compare it to how you treat a production change elsewhere. You would not accept a firewall rule that only one engineer can touch. Automation that only one person can run is the same kind of single point of failure — just dressed up as progress.

Four signals the handoff is not real yet

Before you celebrate close-out, ask these out loud. The answers are usually uncomfortable, and that is the point.

• Who runs it on leave week? If the answer is a name instead of a role, you still have a hero dependency.
• Where does a stranger start? README in the repo, runbook in the wiki, or “ask me” in Slack? Only the first two count.
• What is the blast radius? If nobody can say which systems the job touches, you shipped a surprise generator.
• How do you know it worked? A green Ansible summary is not enough. You need a check a human or a monitor can trust the next morning.

These questions sit next to how you pick what to automate first. Pain-first selection gets you the right work. A real handoff keeps that work alive after the project ends.

A short definition of done for automation work

Keep the bar boring. Boring travels well across teams.

• Named owner on the ops side — a role or team, not “the project will stay on call.”
• One place to run it — controller, CI, or scheduled job. Not three forks of the same playbook.
• Credentials and secrets outside the author’s laptop — vault, platform, or approved store, with access for the owning team.
• A written rollback or stop condition — even three sentences beat tribal knowledge.
• A second person has run it once — observed, not narrated. Pair on the first production run if you have to.
• Logging and a simple health check — enough to answer “did it do the thing?” without opening a debugger.

None of this requires a perfect platform. It requires treating operational ownership as part of scope, not a favor after go-live.

How project managers keep this from slipping

Delivery leads do not have to write the playbooks. They do have to refuse a soft close.

Put the handoff items on the backlog early — not in the last sprint when everyone is tired. Make “second person ran it” a visible acceptance criterion. Invite the future owner to demos from week one, not as a courtesy invite on the last Friday.

And when pressure arrives to mark the epic complete, ask one more question: If this breaks Sunday night, who gets the page — and do they already know what to do? If the room goes quiet, the project is not done. The demo was.

Checklist before you call it closed

• Ops owner named (team or role)
• Canonical place to run the job documented
• Secrets moved off personal accounts
• Blast radius and stop/rollback written down
• Second person has executed a real run
• Success check exists beyond “playbook returned 0”
• Support path agreed for the first 30 days after handoff

Close the project when that list is honest — not when the calendar says you should. The automation that lasts is the one someone else can run without you.