The process changes depending on who runs it

Why most SOP projects fail

Not because teams dislike documentation. Because the documents produced are the wrong kind: long, screenshot-heavy, describing keystrokes that change the moment a vendor ships a redesign. Nobody reads them, so nobody updates them, so they become actively misleading — which is worse than having none.

The second failure is location. An SOP in a folder nobody opens is theoretical. An SOP linked from the task that needs it is operational.

Write thin, decision-first documentation

A useful SOP answers five questions and stops. If it is longer than a page, it is describing software rather than judgement.

Trigger

What starts this process, expressed as an observable event.

Owner

The single role accountable for the outcome — not a list of contributors.

Decision rules

The judgement calls inside the process and how to make them, including what to do when the answer is unclear.

Exit condition

What finished looks like, in terms someone else can verify.

Exceptions

The two or three situations that break the standard path and what to do in each.

The SOP template is exactly this shape, with the prompts filled in.

Assign accountability that means something

1. One owner per outcome. If two names appear, neither will act during a busy week.
2. Authority matched to accountability. An owner who cannot change the process or reallocate the work is a scapegoat with a title.
3. Ownership visible where work happens. In the CRM record, the task, the board — not in an org chart.
4. Review at capacity changes. Ownership drifts when people join, leave or change roles. Quarterly is usually enough.

Build the checkpoint into the workflow

Supervision does not scale and it degrades under load. Checkpoints do scale, because they are conditions rather than attention.

1. Choose the two steps that hurt most when skipped

   Not every step needs a control. Pick the ones with expensive, delayed consequences — the ones you discover from a customer.

2. Make the checkpoint blocking where the cost justifies it

   A stage that cannot be exited until its condition is met is a strong control. Use it sparingly; blocking everything produces workarounds.

3. Otherwise make it observable

   The step is optional in the moment but visible as an exception afterwards, with a named owner reviewing the list weekly.

4. Audit a sample, not everything

   Five records a week, reviewed against the standard, is enough to keep a process honest and cheap enough to actually happen.

What to document first

Do not start with the process people ask for. Start with the one that is expensive when it goes wrong and invisible when it does — those two properties together are what make a written standard worth maintaining.

Keeping documentation alive

• Every SOP has an owner and a last-reviewed date visible on the document.
• The SOP is linked from the task or stage where it is needed.
• Changes to a process update the SOP in the same working session, not later.
• Anything unread for two quarters is either wrong or unnecessary — check which.

Related work

Documentation is only half of it; the other half is the boundary discipline in work leaks between teams. Start with the SOP template and the operations audit playbook.