Processes 2: Owning them

 Along with defining a process, you have to name one person as its Process Owner. To be clear, I don't mean there is only one Process Owner in the whole company: that might happen somewhere, but it's not the normal case. What I mean is that each process has one Owner. Depending how things work at your place, it's possible that one person might end up owning a couple different processes, or possibly not.

The Process Owner is the go-to person for all issues, problems, or discussions related to that process. In more formal terms, the Process Owner is the (one) person who has authority to define the process or to change it, and who also has the responsibility to ensure that it works. Let's unpack this.

First, I say the Process Owner has the authority to define the process (or change it).I never say that he has to have the knowledge or expertise all by himself. 

Of course he might. I once worked at a place where the Warehouse Manager knew the status of every order, every planned shipment, and every piece of inventory; he also knew more about the ins-and-outs of storage and shipment than anyone else in the company. He was awesome.

But it's not always true. I've also seen cases where one process (in this case, the product development process) was so fantastically complicated that there was a whole department devoted to keeping it current. The Process Owner was the overall VP of Engineering, but he had to rely on his experts to discuss the details.

It might happen that one process touches many departments, so that the Process Owner has to get multiple people to buy in before he can finalize his process and publish it. He probably has to align with the owners of the other processes that provide inputs into his, or of those to whom he provides his outputs in turn. All of this is possible.

But at the end of the day, there has to be one person who is responsible. If there isn't one Owner responsible, then in practice nobody is responsible. And in that case, if the process ever fails – or breaks down, or proves dysfunctional (and one day they all do) – nobody is really responsible to fix it. Yes, the organization will find ways to ignore the process or work around it. Work will still get done. But the official goals will all be missed and the formal indicators will all be red. And by then the process will have become just an obstacle, instead of a tool.

Second, I say that the Process Owner has the responsibility to ensure that the process works. This responsibility entails a couple of different things.

On the one hand, when the Process Owner defines the process, he had better insert steps to make sure associates are really following the process and the daily work is on track. These steps might be as simple as filling out a checklist or signing off a traveler, but they could also be a lot more complex if necessary.

On the other hand, the Process Owner also has to check the process performance, to make sure the company is getting the expected results. Then once he has checked the process performance, he has to report to Top Management. If the process is giving the results it is supposed to give, life is roses. If not, he had better find out why not. It might be just a routine blip in performance, a normal statistical deviation that doesn't worry anyone. Or it might be a sign that something is wrong, that the process no longer meets the company's needs and has to be adjusted. Of course you don't want to change your basic processes for light and transient causes; so in the first case it's probably best to sit tight and see if next quarter is better. But no process is perfect, and no process lasts forever. Sooner or later, they all have to be adjusted, reworked, or scrapped. Watch closely so you can tell when this has come to pass.

My third post in this sequence is about how to measure process performance. Reporting to Top Management takes place during Management Review, and I'll discuss that in the future (probably some months from now). 

In other words, this post covers the basic What of the Process Owner's job. In the next post we'll start to discuss the How.

      

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.

        

Is Quality really "everyone's job"? (or, In praise of clerical staff)

[This post is a bit of a digression from the main theme of discussing management systems, but it makes a point that is very unpopular these days -- even though I'm convinced it is all true. And it does connect to the topic of documented artifacts.]

You often hear people say, "Quality is everyone's job." Is it? Well, in the sense that everyone should do a good job, … sure. Of course. But in the last few posts I've been talking a lot about documented Quality artifacts: design reviews, meeting minutes, training documentation, and the rest. Who is supposed to write all these things and file them?

Years ago, I worked at a place where there was a lot of resistance to implementing formal Quality procedures. And one day I heard a rumor in the hallway that the hardware engineering manager had instructed his whole team to stay focused on their jobs and not to cooperate with the effort in any way. To this day I don't know if the rumor was true, but for all the voluntary support I got from that department it might as well have been. At the time, it made my job measurably more frustrating.

But you know what? He was right. And even if he never gave such an order, he would have been right to have given it.

Peter Drucker points out that "Concentration is the key to economic results."* If you try to do a little bit of everything, the best you can ever achieve is mediocrity; but if you focus your effort where you are strongest, you have a chance to achieve excellence. And indeed our hardware team at that company did achieve excellence. People who knew the products more deeply than I regularly assured me that we had the best hardware in the industry. When we were acquired by a global organization, and our product line was ranged against their much more extensive line so that they could "rationalize the portfolio" … our hardware was always kept, and it was the other, lookalike products that were discontinued. Every time.

Does that mean that our products would have been weaker if I had gotten more support during audits? Obviously there's no way I can know that. But the principle of concentration and focus is a valid one.

But in that case, who is supposed to fill out the forms if not the affected personnel? Who but the design engineers can possibly write Design Review Minutes, or fill out Engineering Change Orders?

Let me draw a distinction:

• On the one hand, the detailed technical information has to come from the technical experts -- for example, the design engineers. No-one else can possibly provide it.
• On the other hand the typing can be done by someone else. The metadata can be filled in by someone else. The routine information that is nonetheless required can all be added by someone else.

And that way the design engineers can focus on the work that no-one else in the company can possibly do.

Back in the 1960's, every company over a certain size had secretaries and other administrative roles. Today those roles are out of fashion. We think we are being lean by eliminating those roles.

But we're wrong. That's not lean. To force an engineer to type his own minutes or make his own travel arrangements is bloat, just like asking him to empty his own trash. It is to require that a very highly-paid resource squander his time on activities that add a very low value, activities that will never pay back the time he wasted on them. How can this be efficient?

Far more efficient is for the engineer to do engineering -- a high value-add activity that justifies his rate of pay -- and let someone who is paid a lot less do the tasks that anyone can do. This arrangement is actually preferable in two ways. First, as noted, the engineer's time is saved for engineering; second, the administrative worker (who is paid less than the engineer, remember) will do the administrative tasks far better -- more accurately and more efficiently -- than the engineer ever could! This is because the administrator does these tasks all day long, every day. He knows the subtleties that the engineer forgets, and so he fills out the forms right the first time. There is less churn in the system, and therefore less waste.

Naturally all this depends on the size of the company. If your whole company consists of three guys in a garage, then you probably don't have enough work to keep one administrator busy. At that point, yes, you probably all have to write your own minutes and make your own travel arrangements.

But as soon as the company is large enough to keep an administrative staff busy, it is to everyone's advantage to hire such staff and let them become experts at the administrative work that has to be done.

__________

* Drucker made this point repeatedly, but see for example his Managing For Results (New York: Harper & Row, 1964), pp. 11-13.     

Design reviews and product liability

In my last couple of posts I talked about documented artifacts: that you should keep them only when you need them, but also that sometimes you need ones you didn't expect. Today I'd like to talk about one special case: design review minutes.

Whenever I've audited engineers (or almost), they've expressed resistance to having to keep written design review minutes – except in those few cases where the project made them use an automated design tool that required design review comments from somebody else before they could check in their work. In general the sentiment seems to be, "Look, I'm an experienced engineer. I know what I'm doing. Besides, I did ask Fred to look it over and we discussed some of the more interesting parts over lunch. Do I really have to write it down too?"

Of course I understand. At the time, it seems like an extra step, and a needless one. Who is ever going to care why you decided to use a 5 ohm resistor in that spot instead of a 10 ohm resistor? 

But let me tell you what a product liability attorney once told me, years ago. And then think about it.

Before I go on, it is important that I make a number of critical disclaimers. I am not a lawyer. It is not the purpose of this blog to offer legal advice, and no statement that I make here may be construed as legal advice. I might have misunderstood what this man told me, or the rules might have changed since then because it really was quite a few years ago. Before you rely on any of the concepts explained here, consult with professional legal counsel on your own. 

Also: Do not try this at home. Take only as directed. Do not bend, fold, spindle, or mutilate. And do not back up: severe tire damage.

Now, all of those things having been said ….

He started off by explaining that product safety law in the United States is a moving target. The general requirement for product safety is that you have to make a product as safe as the technology reasonably allows you to. So when there are improvements in safety technology, new products are held to a higher standard. But there is no requirement to retrofit older products that are already in the field. When anti-lock brakes were finally perfected, that did not trigger a recall of every car in the United States in order to replace the brakes.

Therefore, if somebody gets hurt while using your product and decides to sue the company, the plaintiff has to prove that you neglected to take some safety precaution that everyone else in the same industry was taking, during the time when that product was released. Maybe in the rare case this is obvious, but often it's not.

What happens next? 

Someone from the Engineering department has to testify in court. Now, the design engineer responsible for the product retired to the Bahamas twenty years ago, and died of old age fifteen years after that. So whoever shows up in court really doesn't know the history behind the product design. In particular, he can't answer the question, "Did the design engineer take into consideration all the currently-available knowledge about safe product design when working on this product?" 

What happens next?

Well, if the company can produce one sheet of paper with the words "Design Review Minutes" across the top, a date, a list of attendees, and some notes about the product design, then according to this attorney the Court is likely to rule that the responsible engineers "probably" discussed safety topics as well, since it is clear they were reviewing the design and the safety requirements in force at the time would have been common knowledge to all affected engineers. Therefore the Court is likely to rule that the plaintiff is forbidden to pursue a line of inquiry that vaguely accuses the engineers of some generalized carelessness or negligence. If the plaintiff has something concrete to go after, or some other line of inquiry to pursue, the case can proceed. If not, the case is dismissed and the company is off the hook.

Naturally we all hope that nobody ever gets hurt using your product. And, as noted in the disclaimers above, I can't actually promise it will be so easy in case someone does. But think about saving some basic design review minutes, just in case.

           

It's the little things

One of the things that can make the whole ISO 9001 effort feel dispiriting is that the things we auditors ask for seem so small. The company is making fundamental breakthroughs in neural networks or quantum computing, and we ask for training records. Or the company has just perfected the self-driving car, and we ask for meeting minutes. When some company – maybe next year – finally releases the transporter technology from Star Trek, we'll ask for signed attendance lists from all the design reviews. And so on. It can feel like there is a disproportion between the (perhaps) heroic work being done and the (often) mundane work products that we have to check in an audit. And of course that disproportion contributes to the spread of more jokes and cartoons about ISO 9001.

The point is, all these things matter, or they can. It's not always easy to see why. But sometimes you just can't miss it.

Once upon a time, in a faraway kingdom, there was a company that set some very aggressive goals one year and missed them all by miles. At the end of the year there was a big Town Hall meeting of the whole company to go over the results, and the Big Boss explained how poorly they'd performed. One of the senior employees asked, "How are we changing the targets next year, to make them achievable?"

The Big Boss replied, "We're not changing anything. The targets we missed this year are the ones we'll try to hit next year."

The employee pushed back, asking, "If you do the same thing as before and expect different results, isn't that supposed to be the definition of insanity?"

The Big Boss smiled and said, "But we're not going to do the same things. Next year we are going to keep meeting minutes." 

Then he explained what had gone wrong. All year long the Senior Management Team held meetings to review the company's strategy, and everyone left the meetings thinking that everyone else was responsible for doing the work to get there. So nobody in senior management did anything useful all year, and – since nobody was steering – the company drove into a tree.

The whole difference between success and failure came down to meeting minutes. For want of a nail, a kingdom was lost.

That's why we ask about these little things. Yes, the whole point of the QMS is to get us what we want. Yes, the first question to ask about any artifact should be whether we need it in the Real World, even in the absence of ISO 9001. But often we do. Often it's the little things that make the difference.

          

"One big honkin' binder"

 I'm pretty sure that the casual understanding of ISO 9001 on the part of most non-specialists across the business world is summed up by Scott Adams in his multiple Dilbert cartoons about the subject. Back in the early years of the standard someone tried to summarize the ISO 9001 standard by saying, "Document what you do, and then do what you documented." No doubt the original intention was de-mystify the standard, to show how close it came to basic common sense. But the consequence of this slogan was that everyone focused on documentation. The word went out that ISO 9001 was about documentation. If you have to implement ISO 9001, your first step should be to document everything!

If I had to pick two cartoons that exemplified this point of view, it would be the following. (I'm not sure of the exact limits of fair use, so I will post only links to the cartoons and not copies of them.) The first one shows Dilbert explaining how all the company's ISO 9001 documentation will be collected in "one big honkin' binder." The second shows someone labeling everything because he thinks it's a requirement.

Of course the real requirement says no such thing. In fact, the 2015 edition of the ISO 9001 standard removed all requirements for specific documents. But let me draw a distinction. There are still plenty of requirements that you write things down; what no longer exists is a requirement that you specifically write a Quality Manual, or a documented procedure for records control. Instead of focusing on specific document titles and formats, the requirements now say – in effect – "If you need to write it down, write it down." And then there are a lot of specific paragraphs where they remind you that if your business involves doing this or that, … that's something you need to write down.

So when someone asks me, "Does ISO 9001 require me to document X?" my first step is not to check the standard. My first step is to ask back, "I don't know … would you need to document it in the Real World, even if there were no such thing as ISO 9001?" Nine times out of ten, the answer is, "Yeah, I guess so. Never mind." Then in the rare case where the answer is "No," we can talk about it a little more, check our local company directives, and – yes – look at the standard. But invariably, if the rules finally say "Document it," there's a reason why.

Now that I've made this point – I mean, that ISO 9001 doesn't require you to document everything blindly – maybe it is worth talking in a little more detail about some of the kinds of documentation that auditors often ask for, and why they matter.