Over the last two decades various quality, compliance and regulatory frameworks have required evidence of how you do what you do – the SOP (Standard Operating Procedure). It’s meant SOPs have spread from engineering to all industries. Internal and external audit teams love them. And even process excellence implementations (Six Sigma and similar) often degrade into process documentation fests, just as the Quality movement did in the 1990s. All this means SOPs are everywhere.
Process maps and procedures can be good. They’re great for training, for revealing nonsense activities that people have always done, and for making sure accountabilities are clear. They’re a great user guide for a team. They can also be bad. They can freeze processes unnecessarily, standardise when customer service may require you to customise, and tend to undermine the efficient exercise of judgement that makes the work, work. But here I’m not arguing the pros or cons of procedures in general.
Rather, I have an issue with the orthodox SOP epitomised by the image above. They’re ugly, they privilege admin over action, they can stall innovation, they take an eternity to get to the point. They don’t highlight, or even mention, the concrete aim of the activity they’re documenting. But most importantly, they’re written for auditors and process geeks, not the people who do the work.
Writing Procedures for the Wrong People
People who do stuff just want to know what to do, when, how and why. In any sensible world, this would be the primary purpose of SOPs. It isn’t.
Just look at the auditor/process geek/regulator stuff in the average SOP. Authorisation chains, requirements for sign-off, change logs, risk-control matrices, compliance obligations, issue dates, review dates, version numbers, headings with “None” or “nil” under them. There are lots more. And don’t start me on the language that gets pushed on people.
These might all be important and necessary. Might be. But on the ground they’re just a bureaucratic distraction from the content that matters. SOPs elevate metadata to data and create so much noise that the real data is obscured. When it does this, the document design itself privileges administration over action.
Process projects generally have documentation as an outcome – Yes! Our 40 processes are documented to template standard! As though that means anything, when the real purpose has to relate to how the work gets done. Ticking a documentation box doesn’t change the work.
Essentially this approaches forces people to use documents that aren’t even designed for them. Add the other ways SOPs can get things wrong, and it would be impossible to create a better way to piss people off.
The Aim of the Work
SOPs rarely identify the motivating purpose of the work they’re documenting. That heading Purpose is usually a boilerplate restatement of the procedure title, identifies an activity, or explains the purpose of the document itself.
That matters, because it is only by referring to the real purpose of the work that you can know if the process makes sense, if it’s likely to deliver what it should, and if every step is contributing something of value.
It matters because success measures for the process – and for the person following the SOP – must relate to its real purpose. Otherwise, what’s the point? And if that concrete purpose isn’t written clearly for everyone so they can use their judgement to shape their actions, it all goes to admin-driven sh*t.
Getting Real About Purpose
Take the example in the image:
To clearly document a nonconformance found by test or task completion inspection, monitor its disposition status, and to record its disposition.
Set aside the jargon and -ion word pretension. Try this on for a first edit (eliminating the jargon):
To report on items that fail inspection and how they’ve been dealt with.
It sorta gets there, but doesn’t really explain the purpose of the work. To report something? That’s not why we’re doing it, that’s the activity. If I make up some purposes, since this isn’t from one of my clients:
To report on items that fail inspection and how they’ve been dealt with, so we have the information we need to reduce the number of failures in the process.
To report on items that fail inspection and how they’ve been dealt with, so we can sack the people responsible for them.
To report on items that fail inspection and how they’ve been dealt with, so we can prove that we inspect stuff.
To report on items that fail inspection and how they’ve been dealt with, so we meet holding company process targets.
Ahh, so now the real aim (whichever one you want to choose) is clear. And the people doing the work can use that to exercise their judgement against that standard and to change things to meet it better. At a higher level, making purpose explicit allows sensible discussion over whether it is the right purpose, and whether the process is needed at all.
SOPs, KPIs and Process Measures
If you do insist on KPIs (and I’m not necessarily a fan), at least with a clear real aim you know what the KPI has to measure.
Too often managers miles up the hierarchy from the work itself see an activity title, pull a measure and a target from their backsides, and never consider if that KPI actually supports the process purpose. It’s especially difficult if no-one’s actually identified that purpose.
So you get an SOP that stipulates how you do what you do, and a KPI that means the SOP isn’t the best way to meet what’s measured. Rigidity in the documentation and a misdirected KPI puts a handbrake on your capacity to exercise your judgement and get things done for the real process purpose. And you wonder why people groan about procedures.
Then you start reporting on those KPIs for all your processes. And maybe you don’t quite meet them, and you know where this is going. A process created for one purpose morphs into something that acts against that purpose. All because the KPI came from on high, and the real purpose was never considered.
Information That Isn’t Beautiful
Design matters. It makes information absorption easier or harder. It can allow for ‘at a glance’ understanding or can require the line-by-line reading of a Supreme Court case.
Technology matters. It can hide metadata, control versions implicitly, provide graphic or video explanation…this is in place in organisations that take it seriously. Generally, those are the old ‘dirty’ jobs where people can get hurt and processes really do matter.
Audience focus matters. How people use information, how literate they are, what speed they need…again, those old, dirty jobs are way ahead.
But office work? Don’t bet on it. SOPs like those above are just phoned in; they’re ugly and lazily designed in an era when it is well established that beauty helps understanding. The model above looks like something from 1960s massive manufacturing, written on a manual typewriter, stuck with tape on a teak-laminated partition next to a catalogue card drawer.
Simple. If you’re going to spend team time or consulting costs on SOPs, don’t do them old school. Make ’em pretty. Make purpose more important than how you meet it.
Get the skills or systems to build SOPs that make the work easier, clearer, more on-purpose.
Build in capacity to exercise judgement.
Think twice about rolling out KPIs.
But most important, get the process purpose clear before you start. If everyone agrees on that and takes responsibility, you won’t need half your SOPs and KPIs anyway.