This morning's post is about standard operating procedures, and why most of them fail: the document lives in one place and the work lives in another. It made me look at my own rules, because I run NexBDM on a written set of them, and I realised I had never told anyone where they come from.
None of my rules came from a plan
I would love to say I sat down and designed a clean operations manual. I did not. Every rule I run on exists because something went wrong first, and I wrote the rule down afterwards so it could not go wrong the same way twice.
Here are three, told by what happened, not how they work.
A run that never started left no trace. One morning a scheduled job did not fire at all. Nothing errored, because nothing ran, so there was nothing to find. I only noticed because the output was missing. The rule that came out of it: every run now writes a line the moment it begins and another when it finishes, so a gap in the record is itself the alarm. And the thing that checks for gaps is not allowed to run at the same time as the thing it watches, because a check that starts at the same moment as the failure is taken down by it.
A finished batch of work sat unused for two weeks. A whole set of finished material was made somewhere that nothing else knew about. It was good work, and nobody was using it, because no system pointed at it. The rule: anything made anywhere has to be registered in the place the daily run reads, on the day it is made, or as far as the system is concerned it does not exist.
A check I had to stop waving through. I had a safety check that kept raising false alarms, so I kept overriding it. Overriding it by reflex meant it was no longer protecting anything. The rule: a gate people pass by habit cannot stop a real mistake, so a check that cries wolf gets fixed, not bypassed.
Why a document was never going to be enough
Each of those rules would have been easy to write in a document and ignore. What made them stick is that none of them lives only in a document. They are part of the work itself. The record is written when the run starts, because starting is the trigger. The registration is required because the run reads from it. The check cannot be waved through because the decision is built in.
That is the same idea as the post this morning: a procedure people follow is one that is inside the work, starts on its own, and leaves a record that it happened.
The honest part
I still have rules that live only in my head, and they are the ones that fail. The pattern holds every time. The ones I wrote down and also built into the work have not repeated. The ones I only remembered have.
This is exactly what the Business Operating System is for in a client's business: take the way the work really runs, put the steps inside the system where the work happens, and stop relying on the owner remembering. If you want to see where your own business runs on memory, that is what the free Business Autopsy maps. This morning's post has the practical version.
Frequently Asked Questions
Where do your operating rules come from?
From things that went wrong. Each rule was written after a specific failure so it could not repeat. I did not design a manual up front, and I would not trust one that was designed that way.
Why not just write the rules in a document?
Because a document is easy to ignore. The rules that held are built into the work itself: they start on their own, require the step, and leave a record that it happened.
What is the Business Operating System?
It is a system built around how your business actually runs, putting customers, tasks, documents and money in one place. The procedures live inside it, so following them is part of the work.