Insights / Perspective / SOP optimisation and continuous improvement
PerspectiveStandard work is what makes improvement possible
You cannot improve what is done a dozen different ways. Standards are not the enemy of improvement; they are the baseline that makes it measurable.
Standardisation has a poor reputation in some organisations. It sounds like rigidity: thick manuals, box-ticking and a ban on initiative. Leaders who want an improvement culture sometimes avoid it for that reason, encouraging teams to find their own best way instead.
We think that gets the relationship backwards. You cannot improve what is done a dozen different ways. Without a shared method, there is no baseline, no way to tell whether a change helped and no way to spread a good idea beyond the person who had it. Standard work is not the opposite of improvement. It is the precondition.
The problem with a dozen good ways
Picture a finance team where each person closes their part of the month in their own way. Some reconcile daily, others at month end. Some use the system report, others a spreadsheet they built years ago. Results vary, and when the close runs late, nobody can say why with confidence. Was it volume, a system issue, a new joiner or simply a different method?
Now suppose someone finds a faster way to match transactions. In a team without a standard, that improvement stays with them. There is no agreed method to update, so the idea spreads only by chance, if at all. Meanwhile, a manager who wants to test a change has no stable reference point to compare it against.
Variation of this kind is not creativity. It is noise. It hides the signal that improvement depends on.
It also makes people problems out of process problems. When results differ and methods differ, the natural conclusion is that some individuals are better than others. Sometimes that is true. More often, the difference lies in the method, and a shared standard is the only way to find out which. Teams that standardise often discover that a struggling colleague was simply using an older, slower way that nobody had ever corrected.
Define the baseline
The first job is to agree one way of working and measure it. That does not mean writing a perfect procedure. It means the team agrees the current best method, writes it down simply and starts recording a few measures: time, errors, rework, whatever matters most for the task.
The agreed method will not be ideal, and that is fine. What matters is that everyone follows it, so that results reflect the method rather than the individual. Within a few weeks, the team has something it has never had before: a reliable picture of how the process performs when done one way.
Test changes against it
With a baseline in place, improvement becomes an experiment rather than an opinion. Someone proposes a change. The team tries it on a defined slice of work for a defined period. Then they compare results against the baseline to see whether the change helped.
This discipline guards against two common errors. The first is adopting changes that feel better but make no measurable difference, which adds disruption without benefit. The second is rejecting good ideas because a single bad day made them look poor. A baseline lets you see past both.
Keep experiments small
Change one thing at a time where you can, and test it on a limited scope. If you change three things at once and results improve, you will not know which change did the work.
Update the standard and tell everyone
When a better way is proven, change the standard and tell everyone. This step is where many improvement efforts fall down. The pilot team adopts the new method, but nobody updates the written procedure, the training material or the system guidance. Within months, the organisation is back to several ways of working.
- Revise the written standard as soon as the change is confirmed, and withdraw the old version.
- Brief everyone who does the task, in person where possible, with a short explanation of what changed and why.
- Update training material and any guidance built into systems.
- Reset the baseline, because the new standard is now the reference for the next improvement.
Done well, this creates a ratchet. Each proven improvement becomes the new floor, and performance moves up in steps rather than drifting back.
Who owns the standard matters
Standards fail when they are written by people far from the work and handed down. They become a compliance exercise, and teams develop unofficial methods alongside them. The standards that hold are the ones the team helped define and has the authority to improve.
That shifts the role of managers. Their job is less to write procedures and more to make sure a standard exists, that it is followed, that results are visible and that proposed improvements get tested promptly. It also means giving teams a little protected time to run those tests, which is the most common thing missing.
Once we all did it the same way, the problems became obvious. Before that, every issue looked like someone else’s mistake.
Team leader, shared services client
Where to begin
Choose one process where results vary and the team is open to change. Agree the current best method in a single session, write it on one page and measure it for a month. Then invite the team to propose one improvement and test it against the baseline. The first proven change, written into the standard and shared with everyone, is usually what convinces people that standard work is on their side.
Source: Intelliversal analysis.
