Processes 1: Writing them

If we agree that formalizing your processes can be useful in some ways, what's next? Two things: define or document each process (so far as you need to), and then manage or control it. Managing a process, in turn, also requires at least two things: that the process have an Owner, and that it be measured in some way.

Originally I tried to fit all this information into one post, but it got long and ugly. So I'm going to break it into bite-sized pieces, to keep the topic light and easy:

1. Documenting a process
2. Process Owners
3. Measuring a process

Then I'll add a fourth post as an appendix, about some of the risks to watch for in process measurement.

Sound fun? 😀 Let's do it.

What do you say?

When you document a process, say only what you truly need to say and then stop. 

• If something is a legal requirement, spell it out.
• If something is a safety guideline, spell it out.
• If something is complicated enough that you don't want people improvising, spell it out.

But when you get to the point where it really doesn't matter how somebody does something so long as the thing gets done – in that case spell out the What and stay silent about the How. Again, say only what you need.

There are a couple of reasons for this. 

• It makes the documents shorter, so they are easier to write and easier to read.
• Therefore it makes them easier to follow.
• Therefore your documents will feel like less of a burden. 

Most people already roll their eyes when they are faced with too much documentation. If you can keep it simple, your people can focus on their real work rather than scratching their heads over subparagraph 17(a).

At a minimum, you should list the inputs into your process, and the outputs from it. And try to answer the basic question, "What are we doing here?"

It can also be helpful to point out how one process interacts with another, and what resources each one requires. (These latter points are required by the ISO 9001 standard; so if you want certification, be sure to do them. If not, do as much as you find helpful..) 

How do you say it?

Along with keeping your documents short, keep the language direct. Use the second person (like I'm doing here). Use active verbs wherever they fit. In fact, maybe it's simpler if you just get The Elements of Style, by Will Strunk Jr. and E. B. White, the pre-eminent style guide for American English. If you follow their advice in writing, you don't need mine.

Who does the writing?

As I discussed previously, the content has to come from your experts in the task at hand. But generally they'll be grateful if somebody else can help them with the wordsmithing and the typing.

Where do you store the documents when they are done?

Wherever the people who have to use them can find them later. If they all have access to a computer, then an online document repository is great. If they don't, you might need to store them on paper. Remember that if you store the documents on paper, there has to be some way for people to get copies at the same time that the master is kept safe; also, if you distribute copies on paper you have to be sure to collect them all when the document gets updated so that nobody is following out-of-date instructions. That's one reason that online repositories are so popular -- because they make updating easier. But they only work if everyone can reach them.

Depending on what you are doing, document management can get a lot more complicated. But these are the basics. So let me follow my own advice and stop here for now. If you'd like to see more detail later, please leave me a Comment to say so. 

"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.