"If only you have the right process …."

Some stories you just can't make up. You think, "No one would believe it if I told a whopper like that." Then it happens in real life.

That's how I felt when I was sitting in a meeting one day. The Big Boss from the home office was berating us for our failure to follow the finer points of the company's product development process. And then suddenly he said:

"Don't you understand why this is so important? If only you have the right process, and if you follow it carefully enough, you are guaranteed to succeed!"

Guaranteed? Really? If we follow the process closely enough, then our ideas don't have to be any good, our implementation doesn't have to be efficient, we'll never have an accident, and our competitors will go out of business?

Cool.

Also absurd. In the first place, there's no such thing as the perfect process. And to be fully clear, no company anywhere ever earned a dime by following a documented process.*

But if following your process carefully doesn't guarantee success, why do it? When we do audits we always check that people are following their processes, and we write nonconformities when they aren't. Why do we care?

First, a documented process is just a tool. Following a written procedure won't guarantee you Quality, any more than it will guarantee you success. On the other hand, remember that Quality just means getting what you want, and if you use the right tool for the job you are a lot more likely to get what you want in the end. So – what job does a documented process help you accomplish?

There are a couple that are easy and obvious, plus one that is a little harder to see until you take a step back.

The simple reasons for documenting a process are:

1. to help you remember it,
2. to make it easier to train others.

These reasons are obvious when the process itself is complicated, but sometimes I've been lulled into forgetfulness even when the job was simple. As for training, there have been any number of times I've taken over a job from someone else who "just knew" how to do it, and the first thing I always do is to write a checklist (even if only for myself).

The third way you can use a documented process comes into play when you are trying to get your arms around your business as a whole – either to make things more efficient or because something, somewhere, just isn't working. To do that you have to know what is going on – to know what everyone is really doing. And to do that, you refer to a written procedure.

Fine, those are the reasons to write a process; but why the obsession with enforcing it? It depends. 

In some cases it really makes a difference. Cleanliness and sterilization procedures in health care can mean the difference between patients getting better and patients getting seriously worse. Precision and process control in aeronautics can mean the difference between flying and falling. And in any other highly-regulated industry, strict process enforcement can mean the difference between legal compliance (on the one hand) and the government shutting your doors (on the other).

What about when the consequences of non-compliance are a lot milder? In the first place, if it truly doesn't matter how you do a task, rewrite the procedure so that it only says what to do (what your output should be) and not how to do it. In the second place, even then process enforcement still matters if only because: If you don't enforce the process, you have no way of knowing whether the things you wrote in it are true. And if you don't know whether it's true, the process is just waste paper. 

Notice that in this last case you are not ensuring the quality of the outcome or work product; in this specific case you are ensuring the quality of the written document itself, so that you can then use it for all the tasks described up above. What this means is that if you try to enforce the process and find out halfway through that the procedure as-written is wrong, you have to be ready to change it. Never force someone to do something wrong** merely to guarantee formal compliance*** with an internal document. But be ready to update the document so that what it describes is right, and enforce that. Only then is it a functional tool.

 __________

* In fairness, this particular Big Boss wasn't usually a foolish man. I think maybe he was having a bad day. Or else we had really frustrated him.

** The definition of "wrong" depends on context, but includes (for example) anything illegal, immoral, or impossible. It should also include anything impractical, with the caveat that sometimes a requirement looks impractical until you step back to see how it fits into the bigger picture.

*** I speak here of formal compliance, not legal compliance. Legal compliance is non-negotiable. A breach of legal compliance counts as "wrong," as explained immediately above.