Handing over a working process means handing over the failures too

The steps are the easy part

Writing down what to run, in what order, with which inputs, takes an afternoon and produces a document that looks complete. The person following it will get through a normal run without difficulty, and both of you will conclude that the handover worked.

It hasn’t, and the reason emerges on the first abnormal run. You know that the extraction step produces nonsense when the source file has been exported in the wrong format, that a particular kind of input needs splitting first, and that when the output looks thin it is usually because a field upstream was empty.

None of that is in the document, because none of it is a step. It is a set of learned responses to specific failures, accumulated over months, and it is most of what makes you able to run the process and your colleague unable to.

Write the failures you have actually seen

The most valuable section of a handover document is a list of things that have gone wrong, what they looked like, and what fixed them. Not hypothetical risks — the real ones, in the words you would use to describe the symptom rather than the cause.

The symptom is the entry point. Someone encountering a problem doesn’t know what it is; they know the output is half the usual length, or that a step is taking much longer than normal, or that a column is empty. Index the list by those observations and it becomes usable by someone who hasn’t seen the failure before.

This list can only be written from experience, which is why a handover written by someone who has run the process a dozen times is worth several times one written from the design. It also means the list is never finished, and the person taking over should be told to add to it.

State the judgements and their thresholds

Every running process contains moments where somebody decides. Is this output good enough to send. Is this batch unusual enough to investigate. Should this failure be retried or escalated. You make these calls quickly and without noticing, which is exactly why they do not appear in the document.

Convert each one into something with a threshold attached. Send it if fewer than two items were flagged. Investigate if more than a tenth failed validation. Escalate rather than retrying if the same step fails twice. The numbers do not have to be perfect; they have to exist, so the new owner has a starting point rather than an anxiety.

Say which calls you would rather they brought to you for the first few months. A handover with a named escalation route is a handover; one without is an abandonment, and it usually results in the process quietly stopping or being run without any judgement at all.

Then let them make the calls. A process where the previous owner is consulted on every decision has not moved, and both people will discover that in an inconvenient week when one of them is away.

Access, credentials and the things that expire

The dull half of a handover is the half that fails first. Accounts, keys, permissions, where the files live, who pays for it, what renews and when, which alerts go to which address. Each of these is trivial until it is missing at the moment something has broken.

Anything with an expiry deserves a note saying when and who can renew it. A process that stops working eleven months after a handover, for a reason nobody documented, is a common and entirely avoidable event.

Include the cost, too, and where it appears. A colleague who does not know what a run costs cannot make sensible decisions about running it more often, and cannot notice when a change has made it several times more expensive.

Watch them run it, then stop watching

The only reliable test of a handover is to sit quietly while the other person runs the whole thing from the document, answering questions only when they are stuck. Everything you have to say out loud is a gap, and it should go into the document at that moment rather than afterwards.

Do it twice if the process matters, with the second run on a difficult input rather than a clean one. The clean run tests the instructions; the awkward run tests everything else, which is the part that was missing.

And be honest about the case where a process should not be handed over at all. Some workflows depend on judgement that takes months to acquire, and the right answer there is training with a real timescale attached, or retiring the process, rather than a document that describes the steps and none of the skill.