Which processes to document first

Documentation tends to be judged by volume, because volume is easy to count. The measure that matters is whether a document changed what someone did. A low-frequency, low-risk procedure may be a lower priority than a weekly handoff nobody has written down, while a rare process with a severe consequence, in safety, compliance, or recovery, can deserve documentation first because it is rehearsed so seldom.

1. Frequency. How often does the work happen? A weekly process accumulates more variation and more retelling than an annual one, and improvements are felt sooner.
2. Cost of getting it wrong. Consider rework, customer impact, compliance exposure, and the time needed to recover. A rare process with an expensive failure can outrank a frequent one with a trivial one.
3. Number of roles involved. Single-owner processes can be learned by sitting next to the owner. Every boundary where work changes hands is a place where an assumption gets made, and written expectations reduce that.
4. Concentration of knowledge. If one person is the only route to the work being done, the process is a dependency rather than a procedure. That risk is often invisible until the person takes a holiday.

Score each candidate simply, high, medium, or low, on all four. A process that scores high on three criteria is a clear first choice; one that scores high on frequency alone usually is not. Where two score similarly, start with the one producing a decision or an external commitment, because errors there are hardest to reverse.

• Work that happens once. Project work usually needs a plan rather than a procedure, though it may still need decision records, safety or compliance requirements, and a repeatable checklist.
• Work that is mostly judgement. Where the value is in reading a situation, a checklist can narrow the thinking rather than support it. Describe the criteria for a good decision instead.
• Work that changes shape monthly. Record the stable frame and the owner, and leave the step detail to the team until it settles.
• Anything nobody will maintain. A document without an owner is a historical record from the day it is published.

1. One process, one page, written with the person who runs it rather than about them.
2. An outcome sentence, the trigger, the finish, the decisions, and the exceptions.
3. A named owner and a review date on the document itself.
4. A test: someone who has not run the process follows it and records where they stopped.
5. A short list of the next candidates, ranked with the same four criteria, kept where the team can see it.

For the writing itself, the companion guide on SOPs people actually follow covers what a usable procedure contains. Where the process crosses a team boundary, the notes on operational handoffs describe what each boundary has to state.

The example below is hypothetical and describes a pattern, not a client engagement.

• Ranking is a judgement, not a formula. Two people scoring the same process can reasonably disagree. The value is in the argument the scoring forces, not in the number.
• Documented processes can drift. A written version of a changing process becomes wrong quietly, and wrong documentation is followed with confidence. Review dates and named owners mitigate it, not cure it.
• Written work can shift ownership. Some teams read a procedure as permission to stop thinking about the process. Explicit decision rights keep that from happening.
• Coverage will stay partial. Most organisations never document everything, and a plan assuming full coverage gets abandoned rather than finished.

Choosing and writing procedures is the substance of SOP documentation, one area inside the wider Operations & Systems capability. Where the process has never been decided, documentation records the disagreement rather than resolving it, and that work comes first.

More guides on process, measures, and systems are grouped in the resources library.