Why your SOPs are out of date before anyone reads them

A procedure is a photograph of a process. The process keeps moving. Nothing in an ordinary operation makes the photograph move with it — so the gap opens quietly, from the day it is written.

The usual diagnosis is that people are lazy about maintenance. That diagnosis survives because it is unfalsifiable and because it puts the blame somewhere convenient. But consider what maintaining a procedure actually requires: somebody has to notice that the work changed, remember that a document describes it, locate that document, and care enough to edit it — all at a moment when they are busy doing the changed work. Every step in that chain is a place to fail, and none of them has an owner.

Meanwhile the cost of the gap is deferred and diffuse. Nobody is harmed on the day the SOP goes stale. The harm arrives months later, when a new hire follows it and produces a wrong result, or an auditor asks for evidence of a control and the document describes a process the business no longer runs. By then the connection to the original drift is invisible.

Four reasons procedures decay

01They were written from memory, not from the work

Most SOPs are written by asking someone to describe what they do. What comes back is a cleaned-up account: the happy path, in the order it makes sense in retrospect, with the exceptions omitted because they did not come to mind in a meeting. The document is out of date on day one, not because the process changed, but because it never matched.

This is the same gap between the stated and operational accounts of a business described in the four sources of truth. A procedure written from one source inherits that source's blind spots.

02They describe tools, not intent

A procedure that says "click the green Approve button in the top right" breaks when the vendor moves the button. A procedure that says "the operations lead approves the order once the credit check has cleared" survives a redesign, a migration, and a change of vendor. The first kind reads as more helpful and decays an order of magnitude faster.

The test: if you replaced the software tomorrow, how much of this document would still be true? Whatever survives is the actual procedure. The rest is a screenshot with words.

03Nothing connects the document to the work

In most operations the procedure and the process live in different worlds. The work happens in a scheduling system, an inbox, a spreadsheet; the document sits in a drive nobody opens unless onboarding someone. There is no mechanism by which changing one prompts a look at the other. Two artifacts describing the same thing, with no link between them, will diverge — that is not a failure of will, it is just what happens.

04Nobody finds out that they drifted

Stale documentation produces no error. A broken report fails loudly; a procedure that no longer matches reality fails silently, and keeps failing silently for as long as it takes for someone to follow it literally. Any fix that does not create a moment where the drift becomes visible is not a fix.

Finding out which of yours are still true

Before rewriting anything, find out how bad it is. This takes an afternoon and it is worth doing before you commit to a documentation project, because it usually changes the scope.

• Pick five procedures at random — not the five you suspect are worst. A biased sample tells you what you already believe.
• For each, find the last three real instances in whatever system actually records the work. Not what people say happened. What the records show.
• Walk the document against the records, step by step. Mark each step matched, changed, skipped, or absent — where "absent" means the records show a step the document never mentions. The absent ones are the interesting category.
• Note who last edited the document and when. Compare that date to the last material change in how the work runs. The distance between those two dates is your real documentation lag, and it is usually the number that ends the argument.

Five samples is enough to tell the difference between a folder that needs editing and a folder that needs replacing. Most operations discover they have the second problem and had been budgeting for the first.

Writing ones that survive

Three properties separate procedures that stay true from procedures that rot:

• Write from the record, not the recollection. Build the first draft from what the systems show actually happened across several real instances, then have the person who does the work correct it. Correcting a draft surfaces the exceptions that describing from scratch never does — people recognise what is missing far more reliably than they recall it.
• Name an owner per procedure, not per folder. "The ops team owns the documentation" means nobody owns any particular document. One name against each one.
• Give it a review trigger that is an event, not a date. Annual reviews get deferred and then batch-rubber-stamped. "Review when the underlying process changes" is better, if — and only if — something notices the change. Which is the hard part, and the reason most documentation efforts fail on their second year rather than their first.

What actually closes the loop

The durable version stops treating the document as the record. When the work itself emits a record of what happened — each run, each decision, each approval, appended and not overwritten — the documentation stops being a separate artifact maintained out of goodwill and becomes something you can check against reality on demand. Drift is then a query, not a discovery.

That is what the document → build → govern → audit → improve loop is for, and why audit and improve are steps rather than aspirations. A procedure that is reviewed against its own execution record every week cannot quietly drift for eight months, because the disagreement shows up the first week it exists. Getting there is more work than writing an SOP. It is considerably less work than rewriting the folder every two years and getting the same result.

Where this came from

We ran the sampling exercise above on our own proving ground before we ever offered it to anyone — four multi-state operating companies with field crews and seasonal hiring, over two years. The finding that shaped the method: the procedures that had drifted furthest were not the neglected ones. They were the carefully written ones, full of specific tool instructions, that had been correct and thorough on the day they were finished.

← All writing