In short
Standardise where variation costs money and the situation repeats: high volume, predictable inputs, and a clear definition of a correct result. Leave judgement in place where inputs vary unpredictably, where the cost of a wrong standard is higher than the cost of inconsistency, or where the work is still changing. The reliable test is to ask what variation is currently buying you. If the answer is nothing, standardise. If it is the ability to handle the awkward twenty per cent, standardise the eighty and leave the rest alone.
Key takeaways
- Standardisation trades adaptability for consistency. Make the trade deliberately rather than by default.
- Volume and predictability decide it. Rare, variable work rarely repays a standard.
- Standardise the common path and name the exceptions rather than trying to cover everything.
- A standard imposed on work that is still changing gets worked around within a month.
- Persistent workarounds mean the standard is wrong, not that the team is undisciplined.
Standardisation is a trade, not an improvement
Standardisation carries an unearned moral weight. Consistent sounds better than inconsistent, and repeatable sounds better than ad hoc, so businesses reach for it as though it were free improvement rather than what it actually is: an exchange.
What you gain is real. Predictable output, faster onboarding, work that does not depend on who happens to pick it up, and a foundation you can eventually automate. What you give up is also real. A standard encodes what you understood when you wrote it, which means it handles the anticipated well and the unanticipated badly, and it resists change because changing it requires effort that nobody has scheduled.
For high-volume, predictable work that trade is obviously worth making. For rare, variable work it is obviously not. Most of the interesting decisions are in between, and they are made better by asking what the variation is currently buying you.
Before removing variation, find out what it is doing. Sometimes it is inconsistency. Sometimes it is the only reason difficult work gets handled at all.
Four questions that settle it
Four questions, answered honestly, resolve most cases in about ten minutes.
| Question | Standardise if | Leave it if |
|---|---|---|
| How often does this run? | Weekly or more | A handful of times a year |
| How similar are the inputs? | Mostly the same shape | Genuinely different every time |
| Is a correct result definable? | Yes, in a sentence | Only recognisable in context |
| What does inconsistency cost? | Rework, complaints, delay | Nothing anyone can name |
The last question is the one that most often stops a standardisation project that should not have started. If nobody can point at a cost of the current variation, the standard will be maintained at some expense to prevent a problem that does not exist, and it will be quietly abandoned when the maintenance becomes tedious.
The third question deserves care too. Work where a correct result is only recognisable in context, most creative and advisory work, can still have its surroundings standardised: how the brief is taken, how it is reviewed, how it is delivered. The judgement stays; the scaffolding around it does not need to.
Where standardising pays
Four categories reliably repay the effort in a small business.
- Anything with a compliance or money consequence. Invoicing, contracts, data handling. Consistency here is not about efficiency, it is about not being wrong in expensive ways.
- Handoffs. The transfer between people benefits from a standard even when the work either side of it does not, because the failure mode is missing context rather than poor judgement. That is the whole argument in handoffs are where work goes to die.
- The start of a process. What must be present before work begins, standardised as a checklist, removes the single largest cause of rework at very low cost.
- Anything you intend to automate. Automation is standardisation enforced by software, so the standard has to exist first regardless. The sequencing is set out in automation maturity.
Processes is the realistic number worth standardising in a business under fifty people. Beyond that, maintenance exceeds the benefit and the library goes stale, which is worse than having no library because people trust it briefly.
Where it quietly costs
Three situations where a standard makes things worse, and where the damage is hard to see because it appears as compliance.
Work that is still changing. A process being actively redesigned should not be standardised, because the standard will be wrong within weeks and each revision costs credibility. Wait until it has been stable for a couple of months.
Judgement-heavy work with variable inputs. Standardising the decision itself, rather than the process around it, produces work that follows the rule and misses the point. What helps here is writing down the considerations rather than the answer: what to weigh, not what to conclude.
Anywhere the cost of a wrong standard exceeds the cost of variation. If getting it wrong for the unusual case is expensive, a standard that quietly routes unusual cases down the common path is a liability. The remedy is not to skip the standard but to make exception recognition part of it.
- False consistency
- The appearance of a standardised process, produced by people following the letter of a procedure that does not fit their situation. It is more dangerous than open variation, because the deviation is hidden inside compliant-looking work and surfaces only when an outcome is wrong.
Standardise the common path, name the exceptions
The failure mode of enthusiastic standardisation is a procedure that tries to cover every case, becomes long, and is therefore not read. The alternative is to standardise the path most work follows and handle the rest explicitly.
- Establish what share of volume follows the common path. If it is under about eighty per cent, you have two processes rather than one exception.
- Write the standard for that path only, and keep it short enough to be read under time pressure.
- Name the exceptions and how to recognise them. Recognition is the part that matters; a standard that does not tell people when it does not apply will be applied where it should not be.
- Give exceptions a route, usually a named person, rather than leaving them to be improvised individually.
This structure is also what keeps a standard maintainable. Exceptions accumulate over time, and a procedure that absorbs each new one into its body grows until it is unusable. Keeping them listed separately makes it obvious when a supposed exception has become common enough to deserve its own standard.
Checking whether the standard is right
Six to eight weeks after a standard is introduced, ask one question: is anyone working around it, and why?
Widespread deviation is evidence about the process, not about the team. Somebody encountered a situation the standard handled badly, found a faster route, and took it. Treating that as a discipline problem produces false consistency, in which people follow the procedure visibly and do something else in practice.
| What you find | What it means | Response |
|---|---|---|
| One person deviating | Possibly a training gap, possibly a better method | Ask them why. They may be right |
| Everyone deviating in the same place | The standard is wrong at that step | Change the standard |
| Deviation only under time pressure | The standard is too slow to survive a bad week | Shorten it, or accept a fast path |
| No deviation and no complaints | It fits | Leave it and set a review date |
The third row is the one that catches most well-designed standards. A procedure that works comfortably in a calm week and gets abandoned in a busy one has not been adopted; it has been tolerated. That is the same fragility described in why process changes don't stick, and the remedy is the same: make the standard the path of least resistance rather than the path that requires discipline.
The Mayim Ops assessment scores process clarity and consistency separately from documentation, because a business can be thoroughly documented and still have standards that nobody follows, and the two problems need entirely different work.
Frequently asked questions
When should a process be standardised?
When the work repeats often, the inputs are reasonably predictable, and there is a clear definition of a correct outcome. Those three together mean variation is producing inconsistency without producing value, which is exactly the condition a standard fixes.
What are the disadvantages of standardising a process?
A standard encodes today's understanding, so it resists improvement and handles unanticipated situations badly. Applied to varied or fast-changing work it produces either poor outcomes or widespread workarounds, and the workarounds are usually invisible until something goes wrong.
How do you standardise a process without losing flexibility?
Standardise the path most work follows and name the exceptions explicitly, with a rule for recognising them and a route for handling them. Trying to write a single procedure that covers every case produces a document too long to use and a standard that fits nothing well.
Why do people ignore standard processes?
Usually because the standard is wrong for some real situation they encounter regularly, and working around it is faster than raising it. Persistent, widespread deviation is evidence about the process rather than about the people, and the useful first question is what the workaround is solving.
Should a small business standardise everything?
No. Standardising rare or highly variable work costs more in documentation and maintenance than the inconsistency it removes. Most small businesses have somewhere between eight and fifteen processes worth standardising, and attempting more reliably results in a stale library nobody trusts.