I spent years as the chief financial officer of a manufacturing company in Michigan, and before the title, years on the floor writing the procedures myself. What I learned is that the difference between a procedure people follow and one they ignore is almost never the quality of the prose. It's who the writer had in mind.
What is a standard operating procedure?
A standard operating procedure is a written set of steps that produces the same outcome no matter who performs the task. It covers one task, in the order the work actually happens, at the level of detail the person doing it needs. Nothing else belongs in it.
That definition rules out most of what gets filed as an SOP. A document explaining why a department exists is a policy. A document listing everything a role touches is a job description. An SOP is narrow on purpose: calibrate this scale, close this month, onboard this vendor. If the title needs the word "and," you probably have two procedures.
Why do most SOPs end up in a binder no one opens?
Simple answer: because they were written for the person who wrote them. Someone who knows a task compresses it without noticing. Four physical actions become "verify the settings," and the reader is left in front of the panel guessing which settings, and how you verify them. Cognitive science calls this the expert blind spot. On the floor it's simpler than that: the writer already knows the next move, so she forgets to say it.
The second reason is that nobody tested it. A procedure written at a desk and filed without a trial run is only a draft, because it has never met its reader.
What does a failing SOP actually cost?
Far more than the hours spent writing it. The cost arrives as the same question asked for the fortieth time, and it accumulates quietly:
- A supervisor pulled off her own work to explain a step that is technically documented
- Errors that repeat because the correction lives in one person's memory (or in the dusty binder that no one ever opens)
- Training time that never drops, no matter how many people you hire
- Audit findings on procedures that exist but do not match what the floor does
- Institutional knowledge that leaves with a retirement
None of that appears as a line item. All of it gets paid.
What belongs in an SOP that works?
One task, one reader, and steps a person can perform without interpretation. In practice: a purpose line, the scope, what the reader needs in hand before starting, numbered steps in the order the hands move, decision points with the answer for each branch, and who to contact when the procedure stops matching reality.
Two fields matter more than people expect. An owner, so revisions have somewhere to go, and a revision date, so a reader can tell whether what she is holding is current. A procedure with no date is a rumor.
Write for the least experienced person who will ever perform the task, on her first day, with no supervisor at her shoulder. That reader is the standard. Anyone more capable will simply move faster.
How do you know whether an SOP works?
Hand it to someone who has never done the task, and watch. Do not help. Every question she asks is a defect in the document, and every place she hesitates is a step you compressed without realizing it.
The test takes twenty minutes, and it's the step almost everyone skips. It also ends arguments about detail level without anyone having to win one. If a new person got through it alone, the document is detailed enough.
What should you write first?
The procedure that gets explained out loud most often. Not the most complex process, and not the one an auditor asked about last year. The task someone interrupts a colleague about every week is where a written page returns the most time, and it gives you a template the rest of the set can follow.
Start with one. A single procedure that a new hire follows without help teaches you more about your own documentation standard than a project plan for forty of them.
When should someone else write them?
When the people who understand the process are too valuable to spend on writing it, or when they have tried and stalled. Documentation is a translation problem more than a writing problem. The job is to sit with the expert, ask the questions her reader would ask, and put the answers in the reader's order rather than the expert's.
That translation is the work I do on the technical writing side of my practice: procedures, manuals, and process documentation for companies whose systems live in three people's heads. If what you have is close but unusable, that is editing rather than a rebuild. Questions about scope and process are answered on my FAQ page, and if you would rather talk it through, book a discovery call and we will look at what you have.
Frequently asked questions
What does SOP stand for?
Standard operating procedure. It is a written set of steps for a single task, written so that anyone who performs it gets the same result.
Why do most SOPs fail?
Most fail because they were written by someone who already knows the task, for a reader who does not exist. Steps get compressed, decision points go unstated, and the document is never tested on a new person.
What is the difference between an SOP and a policy?
A policy states a rule or a position. An SOP tells one person how to perform one task, step by step. Policies explain what is required; procedures explain how the work gets done.
How detailed should an SOP be?
Detailed enough that someone who has never performed the task can complete it alone. The way to find out is to hand the draft to a new person and watch where she stops.
