Every standard operating procedure is written by someone who already knows how to do the job. That’s precisely the problem. The author can’t see the gaps, because their own knowledge fills them in automatically. A step that says “update the tracker” is perfectly clear to the person who knows which tracker, which column and what counts as updated. To anyone else, it’s a riddle.
This is why an SOP isn’t finished when it’s written. It’s finished when someone other than its author has followed it, successfully, using only what’s on the page. That test is the dry-run, and it’s the single most effective thing you can do to make a procedure reliable.
This playbook covers how to run one.
Why isn’t reviewing the draft enough?
Because reading and doing are different activities. A reviewer reading an SOP nods along, mentally filling gaps the same way the author did. Only when someone actually tries to do the job from the document do the gaps become visible: the missing login, the ambiguous step, the exception that has no instructions.
Review catches typos and unclear phrasing. A dry-run catches missing knowledge. Both are useful. Only one tells you whether the procedure works.
Where does the idea of rehearsing before relying come from?
Many fields that can’t afford surprises practice under realistic conditions first.
Kriegsspiel. In the 1820s, the Prussian officer Georg von Reisswitz developed Kriegsspiel, a war game played on maps with rules for movement and combat, which the Prussian army came to use for training officers. The point was to discover problems in plans and thinking on a tabletop rather than in the field.
Fire drills. After the 1911 Triangle Shirtwaist Factory fire in New York, which killed 146 garment workers, the state undertook major reforms of workplace safety laws. Practiced evacuations became a standard part of building safety, because a plan nobody has rehearsed is only a theory about what people will do.
The dress rehearsal. Theater has long run a final rehearsal under performance conditions, with costumes, lighting and cues, before an audience arrives. It routinely reveals problems that no amount of reading the script would: a costume change that takes too long, a prop in the wrong place.
The shared insight: the cheapest time to find a problem is before anyone depends on the result.
Who should do the dry-run?
The best candidate is someone who could plausibly need to do the job but doesn’t do it today. In rough order of preference:
- A likely backup, the person who’d cover when the owner is out.
- A new team member, who has the least context and so finds the most gaps.
- A colleague from a different role, who’s capable but unfamiliar with this job.
- The owner, following the document strictly, as a last resort.
The owner can dry-run their own SOP if no one else is available, but they must follow only what’s written, which is hard. A second person is far better.
How do you run it?
Six steps:
- Pick a real occurrence. Run the dry-run on an actual instance of the job, or a realistic practice instance, not a hypothetical.
- Hand over only the SOP and whatever access it lists. If the runner needs something the SOP doesn’t mention, that’s a finding.
- Have the runner narrate as they go, or note every point where they pause.
- The author observes but doesn’t help, unless the runner is completely stuck. Every rescue is a gap in the document.
- Check the evidence of done at the end. Did the job produce the result the SOP says it should?
- Log every finding immediately, while it’s fresh.
Step four is the hardest for authors. Watching someone struggle with a step you find obvious is uncomfortable, and the instinct is to jump in. Resist. The struggle is the data.
What counts as a finding?
Anything the runner had to figure out that the SOP didn’t tell them. Common categories:
- Missing access: a login, permission or file location not listed.
- Ambiguous steps: wording that could mean two things.
- Hidden decisions: a judgment call the SOP doesn’t mention or guide.
- Unhandled exceptions: something unexpected with no instructions.
- Unclear evidence of done: the runner wasn’t sure whether they’d finished.
- Wrong order: a step that only makes sense after a later one.
Each finding gets a short note: what happened, which step and the fix.
How do you log the results?
A simple validation log, with one row per finding:
| Step | What happened | Category | Fix |
|---|---|---|---|
| 3 | Runner didn’t know which folder the template lives in. | Missing access | Add folder path to Inputs. |
| 5 | Unclear whether to order a copy when none is on the shelf. | Hidden decision | Add decision rule. |
| End | Runner unsure where to record completion. | Unclear evidence | Name the log and the column. |
The table is illustrative, but the pattern is typical: a handful of small, fixable findings that would each have caused a problem the first time the procedure was used for real.
What does a dry-run actually look like?
Here’s a fictional walkthrough, using the bookstore hold procedure. The morning clerk wrote the SOP. A weekend staff member who has never handled holds is the runner.
The setup. A real hold request arrives by email. The runner gets the SOP and the shared login it lists. The clerk sits nearby with a notepad.
Step one goes smoothly. The runner finds the email, notes the title and customer details. No findings.
Step two stalls. The SOP says “check availability.” The runner checks the shelf, finds nothing and pauses. Should they check the back room? The distributor? The SOP doesn’t say. The clerk writes it down without speaking.
Step three surfaces a permission gap. The runner decides to order a copy, then discovers their login can’t place distributor orders. The SOP’s Permissions section doesn’t mention it.
Step four works. The runner labels a book that turns up in the back room and places it on the hold shelf.
The end is fuzzy. The runner texts the customer but isn’t sure whether to record that anywhere. Evidence of done is unclear.
Three findings in a single run of an ordinary job, each one minor, each one capable of causing a lost sale or an annoyed customer on a busy Saturday. The clerk fixes all three that afternoon, and a different staff member runs it again the following week with no substantive questions.
How do you keep dry-runs from feeling like a test of the person?
Frame them, explicitly, as a test of the document. The runner can’t fail. Only the SOP can. Thank runners for every finding, because each one is a problem they found so a customer didn’t. People who feel judged hide their confusion, and hidden confusion is exactly what you’re trying to surface.
When is the SOP ready?
When a dry-run produces no findings that would have stopped or misled the runner. Minor wording polish doesn’t need another round. But if a finding changed what the runner did, fix it and run again, ideally with a different person.
A practical standard:
- First dry-run: expect several findings. That’s the point.
- Second dry-run, after fixes: expect a few small ones.
- Ready: a runner completes the job, produces the evidence of done and has no substantive questions.
How often should SOPs be re-validated?
Whenever the process, tools or people change, and otherwise on a regular cycle that suits how critical the job is. A procedure that was perfect a year ago may now reference a tool you stopped using. A short dry-run catches that before a backup discovers it on their first day covering.
What mistakes undermine dry-runs?
Six common ones:
- Using the author as the runner, when anyone else is available.
- Helping too early, which hides the gaps the dry-run exists to find.
- Running a hypothetical instead of a real or realistic occurrence.
- Not logging findings, so fixes depend on memory.
- Skipping evidence of done, so success is never actually checked.
- Stopping after one round when the first run found substantive problems.
What’s in the kit?
The Process-to-SOP Interview Kit treats validation as a required step, not an afterthought. Its workbook moves from Interview Guide to Observation + Gaps to SOP Draft, with a completeness check across the eight elements (trigger, owner, inputs, decisions, exceptions, permissions, outputs and evidence of done), and then to a dedicated Validation tab for structuring and logging the dry-run. A fictional Book Hold example from an ordinary bookstore shows the full path, and Markdown templates include a validation checklist you can reuse.
Quick answers
How long does a dry-run take?
About as long as the job itself, plus a few minutes to log findings.
What if nobody else is available?
Follow the SOP yourself, strictly, as if you’d never done the job. Then have someone else run it when you can.
Can a client do the dry-run?
For SOPs you deliver to clients, yes. Having the client’s own staff dry-run the procedure is an excellent final step.
Test it before you trust it
An SOP that’s never been followed by someone else is a draft, however polished it looks. One dry-run turns it into a procedure people can actually rely on.
Get the Process-to-SOP Interview Kit and dry-run one procedure this month, with the person most likely to need it when you’re not around.
The Interview Kit, including the Validation tab for the dry-run, is on Content & SEO Workflows.
Leave a Reply