An SOP, or standard operating procedure, is a written description of how a recurring task is done. The useful test is not completeness but whether anyone opens it under pressure. Most SOPs fail because they were written to be comprehensive, which makes them long, which means the person who needs them asks a colleague instead.
In more detail
The purpose of an SOP is to move knowledge out of one person's head so that the task survives their absence. Everything about how it is written should serve that, and length is the main thing that does not.
The version that works is closer to a checklist than to a manual: the steps in order, the decisions with their criteria, and what to do when the normal path does not apply. Explanation belongs in a separate document, if anywhere.
Location matters as much as content. An SOP in a folder somebody has to remember exists is not available at the moment of need. It belongs where the work happens.
What belongs in it, and what does not
| Section | Belongs in the SOP? | Why |
|---|---|---|
| Steps in order | Yes | This is what is being looked up |
| Decision criteria | Yes | The judgement is what varies between people |
| Exceptions | Yes | The reason anybody opens it |
| Owner and last-checked date | Yes | Lets a reader weigh how current it is |
| Rationale and background | No | Interesting once, in the way every time after |
| A screenshot of every step | Rarely | Goes stale faster than the text does |
Where people get it wrong
- Writing for completeness. The audience is somebody in a hurry, not an auditor.
- Documenting the happy path only. The exceptions are the reason people go looking.
- Storing it away from the work. A document nobody can find at the moment of need does not exist.
- Never revising it. Update it when it turns out to be wrong, which is the only moment anyone is motivated to.
The one-screen test
A workable rule: if a procedure does not fit on one screen, it is usually two procedures written as one, and splitting it makes both usable.
The exception is a genuinely long sequence such as a month-end close. There the right shape is a short index linking to short procedures, rather than one document nobody reaches the end of.
Common questions
How long should an SOP be?
Short enough to read while doing the task. If it needs scrolling, it will be skipped in favour of asking someone, which defeats the purpose.
What should an SOP include?
The steps in order, any decision points with the criteria for choosing, and what to do when the normal path does not apply. Background and rationale belong elsewhere.
Why do SOPs go unread?
Length, and location. They are written to be comprehensive rather than usable, and stored somewhere that requires remembering they exist.