A procedure isn't finished when it's written. It's finished when someone who has never performed the task works through it start to end without asking a question. That's a higher bar than most documentation clears, and it's the only one worth writing toward.
Where do you start when writing an SOP?
Start by watching the task performed once, by someone who does it well. Not by outlining at a desk, and not by asking an experienced person to describe the steps from memory. The described version and the observed version are never the same document.
On the manufacturing floor the gap was consistent and it was always in the same direction. An operator would walk me through eleven steps, and I'd count nineteen. The eight he left out were the ones his hands did without consulting him: the tap on the gauge, the second he waited before the reading settled, the tray he moved out of the way first. Those are exactly the steps a new person stalls on.
If watching is impossible, have the expert perform it while narrating, and interrupt every time something happens that he didn't say out loud.
How do you narrow it to one task and one reader?
One SOP covers one task, with one clear trigger that starts it and one clear condition that ends it. Then, name the reader before you write a word: the specific role, in his first week, with no supervisor at his shoulder.
Mission creep is what turns a usable page into a binder section. If the title needs the word "and," you're holding two procedures. Split them and link between them. Readers don't mind two short documents. They mind hunting through nine pages for the four that apply to them.
The named reader settles almost every question that comes up later. Detail level, vocabulary, how much context to give before the first step: all of it follows from who you decided is standing there holding the page.
How do you write steps a person can actually perform?
Every step is one action, written as a command, with the object named. "Set the mixer to 40 rpm" is a step. "Verify the settings" is a heading pretending to be one.
Three habits do most of the work. Start each step with a verb. Split any step containing "and" into two. Then read each one and ask whether a reasonable person could perform it wrong while sincerely believing she followed it. If the answer is yes, the step isn't written yet.
Number the steps in the order the hands move, not the order the process makes sense in a meeting. Those are entirely different sequences.
How much detail is enough?
Enough that the least experienced person who'll ever perform the task can complete it alone. That standard ends the argument about detail level without anyone having to win it.
In practice, always spell out:
- The exact name of the screen, field, button, or physical control, as it is labeled in front of her
- The value or the range, never "the usual setting"
- What a correct result looks like, so she can confirm it herself
- What to do when the result isn't correct
- Who to contact when the procedure stops matching the work
Detail isn't the same as length. Most procedures I rewrite get shorter, because the background explaining why the department cares about the task comes out and the missing physical steps go in.
A note about photos and diagrams
Do it. Photographs and/or diagrams of a work station, showing what is where, what the materials look like, and what to do with them are invaluable. For example, an SOP that contains graphics simplifies the process by showing the panel or screen or machine so that the "Start" button can be easily found. So again, whenever possible, include the diagrams and photos.
What do you do with decisions and exceptions?
Put the decision inside the step, phrased as the reader would encounter it, with the answer for each branch. "If the reading is above 12, do X. If it's below 12, do Y." Never leave a fork with only one side written.
Exceptions that occur a few times a year belong in a short section at the end, not in the main path. A rare case dropped into step 6 makes every reader stop and decide whether it applies to him, forty times a month, for a situation that has only happened twice.
How do you test an SOP before you file it?
Hand it to someone who has never performed the task, and watch him work through it without helping. Every question he asks is a defect in the document. Every hesitation is a step you compressed without noticing.
It takes twenty minutes, and it's the step nearly everyone skips. Skipping it is why so many procedures are technically accurate and functionally useless. Fix what the test exposes, then file it.
How do you keep it from going stale?
Give every procedure a named owner, a revision date, and a rule for when it gets reviewed. A document with no owner belongs to no one, which means no one is responsible for correcting it when the process changes underneath it.
Set the review to ride on the work rather than the calendar where you can: when the equipment changes, when the software updates, when a step causes an error twice. An annual review date is better than nothing, though it tends to become a signature rather than a read.
Writing procedures is a translation problem more than a writing problem. The job is to sit with the person who knows the work, ask the questions his reader would ask, and put the answers in the reader's order instead of the expert's. That translation is what I do on the technical writing side of my practice, for companies whose processes currently live in three people's heads. If your procedures exist but nobody can follow them, that's usually editing rather than a rebuild. Scope and process questions are answered on my FAQ page, and if you'd rather talk it through, book a discovery call and we'll look at what you have.
Frequently asked questions
How long should an SOP be?
As long as the task requires and no longer. Most single-task procedures run one to three pages. If yours is longer, it usually contains either background that belongs in a policy or a second task that should be its own document.
Who should write the SOP, the expert or a writer?
The expert holds the content, but he's rarely the best person to write it, because he compresses the steps he performs automatically. The most reliable arrangement is the expert performing the task while a writer observes, asks the reader's questions, and drafts.
How do you know if an SOP is detailed enough?
Give it to someone who has never done the task and watch him follow it without help. If he completes it alone, it's detailed enough. Every question he asks marks a place the document needs work.
Do SOPs need to be reviewed on a schedule?
Yes, and they also need to be reviewed when the work changes. Assign every procedure an owner and a revision date, and trigger a review whenever the equipment, software, or requirements behind it change.
