Know your own procedures!

Who needs to understand the procedures in your department?

Well, I suppose you do, for a start. The other people in your department should understand them too, or anyone else doing the same work. The people who interact with your department should understand enough that they can work with you. If you work with the public, then they need to know enough to do their part: the Information desk is here, and the Returns counter is over there.

How about your boss?

Of course. The boss established all the procedures, so of course he understands them.

How about his boss? How about top management?

Umm ... I guess. Maybe not in detail, but overall. Why? What's your point? 

You'd be surprised.

In a sense, maybe it shouldn't be a surprise when top management doesn't know the procedures that run their own company. Most of their day is spent doing other things. Still, it can be awkward. These are the people, after all, who decide on the company's strategic direction. But what if the new direction points somewhere that the procedures aren't designed to go?  

It sounds like a frivolous or captious question, but it has been known to happen. Robert Cole tells the story that in 1983, Ford's CEO instructed the company to improve relations with their supply base, as a key to improving their suppliers' performance.

"Based on this, [L. M.] Chicoine [Ford's vice-president for purchasing and supply,] publicly called for increasing the number of long-term contracts (greater than one year) with Ford. To his surprise six months later, he found there was no change. Because Ford rules called for extensive bureaucratic approval for any contract greater than one year, no supplier was interested in tackling that."* 

Sometimes the disconnect between management direction and corporate behavior is more subtle. Another story from Cole tells of ongoing discussions in the early 1980's between Intel and one of their major suppliers, the Japanese firm Kyocera. Intel argued that they got poor service and poor terms from Kyocera, compared to Kyocera's other customers. 

"The Japanese managers responded with a riddle to Intel queries: 'To Kyocera, the customer is always king. But reliable kings have reliable servants.' The Intel managers finally figured out that the point of the riddle was that although the customer (Intel) might be king, it nonetheless had to act in certain ways to produce reliable supplier behavior. Above all, that meant no order cancellations, level production, and an overall predictable environment for suppliers."**

In the story about Ford, top management genuinely did not understand what steps were required by their own procedures. In the story about Intel, top management did not understand how their normal behavior was perceived by others. But both cases represent a kind of disconnect between the strategic direction that top management wanted to go, and the organization's ability to get there.

I have tried to think about my own experience, and can't recall any disconnects as significant as these ones. But I have certainly seen how easy it is for top management to miss realities on the ground, because the people around them shield them from inconvenience. Once I worked for a company where the management held periodic Town Hall meetings, to get feedback from those of us in the trenches. At one of these meetings, someone complained that the IT department needed more resources, because whenever his PC broke it took three weeks to get it fixed or replaced. The vice-president who fielded the question genuinely didn't understand the issue: he explained that whenever he had a problem, IT always fixed it the same afternoon!

This phenomenon—this disconnect—is why it is so important for top management to get out of their offices and understand how the work is done. It is why John Seddon says that his first step when working with a new client is to send the management staff out to the front office to watch a single order come in, and then to track that order through its whole life-cycle. It is why Taiichi Ohno invented the Gemba walk.

The terminology differs, but the basic idea is the same. Before you can make decisions about what to do next, you have to understand what you are doing today. And that's not always easy. 

__________

* Robert E. Cole, Managing Quality Fads: How American Business Learned to Play the Quality Game (New York, Oxford: Oxford University Press, 1999), p. 112. 

** Ibid., p. 113.       

           

What IS strategy, anyway?

I always appreciate feedback on these posts, especially when it shows me that I need to do better. In that sense, the best comment I got on last week's post (on "Strategic process definition") was one that showed me I failed to explain a critical point. One reader wrote that the post "didn't engage ME--it seemed to pertain only to large corporations with formally-defined management systems.  I like better the ones where I can see the immediate application to Martha's burger shack (or other mom-and-pop businesses, like the one where I work), and/or where you make that application apparent."

Oh my goodness, did I fail to explain that part? It's true that sometimes I write about issues that show up only in formalized management systems, or in large bureaucratic companies. But last week wasn't one of those times. So let me unpack this topic a little better.

What about small, mom-and-pop companies?

Last week's post is about defining your processes so they align with your strategy: not all your processes (or not necessarily) but the right ones, the ones where such alignment is appropriate. So in principle the discussion applies to any business that has processes and that also has a strategy.

But everyone has processes. Remember that they compose your management system. And we have discussed earlier (for example, in this post here) that every organization necessarily has some kind of management system, because the management system is the constitution or the nervous system that ties the organization together. The organization's processes and management system might be informal or unwritten. But they are still real, for all that. The processes and the management system are all the things you do that make you part of the organization.

• 
  Wear your company t-shirt when you are on duty.
• Record sales here, and in this way.
• Sell this kind of product.
• If a customer complains, respond like this.
• Log your hours here, in this tool or this database.
• Collect your check here. You'll be paid every week, or every two weeks, or monthly.
• If you need supplies, get them from this cabinet. If you take the last of something, tell this person so we can order more.

• It is (or is not) acceptable to use company printers for personal use, to print personal emails or a cute cat meme.
• If you want to plan vacation time, request it like this.
• If the building catches fire, exit promptly but calmly and meet here in the parking lot.
• And so on.

Each of these is a process. Taken together, they constitute a management system. They may not be written; people may just think of them as The Way We Do Things Around Here. But they are absolutely real.

And when I suggest aligning your processes with your business strategy, all I mean is that The Way You Do Things should support your big goals. Don't shoot yourself in the foot.

That sounds fine, but wait a minute: Do small, mom-and-pop businesses have strategies?   

What is a strategy, anyway?

Good question. How can you tell? What is a strategy, anyway?

Once again, I'm going to turn to Roger Martin, who answered this question in an article last year.* Martin starts by pointing out that any business has to make a lot of choices. Some of these choices really have to go they way they do; other choices could have been made differently, but weren't. 

• For example, you might choose how to pay your suppliers (cash on delivery, net 30, net 60, or whatever), but you can't choose whether to pay your suppliers! Obviously you have to pay them. The choice whether to pay your suppliers has to be Yes. 
• On the other hand, you might focus on one group of customers instead of another. If you sell office supplies, you might focus on business customers or you might focus on students at the local college. That decision could go either way. But depending which you pick, you will probably decorate your store differently; you might make other choices differently too.

Martin says it is only the latter kind of decision that counts as strategic. The other decisions are important too, but he calls them Operating Imperatives.

Martin describes the distinction this way.

[I was reading a list of business choices that one of my IT clients is planning to pursue, when ...] I realized that the single list contained two very different kinds of items. And the distinction revolves around the question ...: Is the opposite of your choice stupid on its face?

For some on the list, the answer is yes: the opposite is stupid on its face. For example, one item on the list was ‘suitability,’ i.e., the IT solutions need to aim for suitability for the internal users it served. Nobody strives for unsuitability in their IT solutions. That would be stupid.

For some, the answer is no: the opposite is not stupid on its face. And that is demonstrable because other players in the industry make the opposite choice and it doesn’t prevent them from succeeding. For example, another item on the list was ‘modularity.’ Many other players attempt to achieve their desired IT outcomes with systems that are more integrated and not modular at all.

I realized that I could go down the list of items and pretty quickly categorize them as yes-the-opposite-is-stupid or no-the-opposite-is-not-stupid.

The latter meet my definition of a Strategic Choice. Since the opposite isn’t stupid, it represents a real choice to do something meaningfully different than some or all competitors/peers. The former don’t meet the definition. Does that mean they are unimportant and shouldn’t be mentioned in a strategy document? No. This is what I have come to call an Operating Imperative. Because it is smart and there is no other obvious approach, we will fall behind if we don’t do the positive thing that everybody else is doing.

We make Strategic Choices when we want to gain an advantage over our competitors. That doesn’t happen when we do the same things as competitors. We follow Operating Imperatives when we want to avoid falling behind competitors on a meaningful dimension.

 Don't get hung up on the word "opposite" or the word "stupid." Martin isn't saying that Strategic Choices have to be contrarian or oppositional. Not at all! His point is just that strategy is when you make choices about your business that are real choices—choices that might have gone the other way. But once you make them, they make a difference in everything else you do after.

Big company examples

Let's look at some examples.

In his classic book Up The Organization, Robert Townsend tells the story** that when he took over as CEO of Avis Car Rental in 1962, he relocated his headquarters to Long Island, in between JFK and LaGuardia Airports. His idea was that if Avis rents cars without drivers, they have to go where they can find drivers without cars—and he wanted his head­quarters easily accessible by his working managers. 

Townsend's decision was a Strategic Choice for Avis, because it could have gone another way. At the time, the headquarters of their competitors were bottled up on the island of Manhattan, which proves that the opposite of Townsend's choice was not stupid. But it was a choice that worked for Avis.

Or consider any of Martin's examples from last week's post. We saw that Progressive Insurance has chosen to get "settlements to its customers so quickly that lawyers don’t get into the middle of the process." Could that choice have gone the other way? Sure—and many other insurance companies do, in fact, make the other choice by requiring longer in-house review and adjustment of a claim before paying it. 

Progressive has chosen to optimize for speed, and this choice has consequences. Last week we saw that it requires Progressive to manage its investment portfolio in a special way, to emphasize short-term liquidity even at the expense of growth. But Martin's article also makes clear that Progressive "empowers [their] claims-people to make settlement decisions and cut checks for customers at accident sites rather than having to go through a time-consuming head-office claims processing ritual."***   

Thus does strategy make a difference.

Small company examples

Finally we come back to the question, Do small, mom-and-pop businesses have strategies?

Of course they do. Small businesses have to make decisions, just like big ones. Some of those decisions could go either way. Those are the strategic decisions. And when I advised last week to align your processes with your strategy, all I meant is that you shouldn't let your daily operations undercut the decisions you've made about how you want to do business.

What does this look like in practice?

Let's say you run a small, local business in some line of work where customers need a little bit of technical knowledge (but not too much) in order to succeed—something like gardening. So let's say you run a nursery. There are a lot of things you have to do. You have to pay your suppliers on time. You have to service your customers. You have to comply with all the local laws for small businesses. In Martin's terminology, these are Operating Imperatives.

Other decisions could go either way. For example, people always come into nurseries asking, "How can I make my garden better?" Often they have follow-on questions. They talk to you for an hour about their problems. Then sometimes they buy something and sometimes they don't. What do you do about these people?

You can decide either way. Some stores act as Local Experts, and talk willingly. Other stores won't talk to these people unless they buy something. Either way the store should set a policy, so the choice isn't left up to each sales clerk each day.

But notice one consequence: If you decide that you want your sales clerks to answer questions for the community as Local Experts, then they really have to become experts. That means your hiring practices should favor people who already know something about gardening, and your personnel policies have to give your employees the chance to learn more once they are on board. If you don't adjust your hiring process and your personnel process, you risk undercutting the strategic decision you have made to serve your community as Local Gardening Experts.

The reason it is hard to see this alignment in small companies is that very often the decisions are made unconsciously.**** The immediate needs of today's issues always press very hard on small businesses, so it is often true that no one can afford the time or perspective to articulate the company's strategy in words—much less to check all the (probably unwritten) processes in the (unwritten) management system to make sure they align with that strategy!

But the processes exist anyway, even if nobody has identified them by name. 

The management system exists anyway, even if nobody has written it down. 

And the strategy exists anyway—as the collection of Those Business Decisions Which Could Have Gone Otherwise—even if nobody has ever checked to make sure that it is consistent, and that it is supported by the management system.

All this is to say that it can be very hard to do this sort of analysis in a small, mom-and-pop business. But if you can ever find the time, it surely matters.     

__________

* See "Is or Is Not The Opposite Stupid on its Face?" in Medium, February 5, 2024.  

** See "Mars, Man From" in Robert Townsend, Up the Organization: How to Stop the Corporation From Stifling People and Strangling Profits (New York: Alfred A. Knopf, 1970), p. 106. 

*** See "The Role of Management Systems in Strategy" in Medium, October 5, 2020. 

**** Of course I don't mean that literally.         

Strategic process definition

How do you align your business processes with your "strategic direction"?

It sounds like a good thing to do, and in fact ISO 9001 requires you to do it. In four different clauses,* the organization (or its top management) is required to make sure that the quality system is compatible or consistent with the business's overall strategic direction. And that's great, of course, ... but what does it really mean? How—in concrete terms—are you supposed to make this alignment happen? 

• You probably have a hiring process. But isn't hiring a well-understood activity? Is your hiring process really going to look that different from everyone else's?
• Maybe you sell widgets, and you package them before shipping them out. How do you align your packaging process with your business strategy? Is there really that much more to say besides, "Put the widget in the box, add the packing peanuts, and tape it closed"?
• Pick a couple more examples at random, and you might think that this requirement was included just because it sounds good, rather than for any more practical reason.

But it turns out you'd be wrong to think that. Process definition can support your strategic direction. It's just that most companies haven't thought through how to make the connection.

The other day, entirely by accident, I ran across the work of Roger L. Martin (LinkedIn), a writer, strategy advisor, and former professor. It turns out that he addressed exactly this topic in an article in Medium, back in 2020, called "The Role of Management Systems in Strategy." It's a delightful article that systematically works through examples of companies who have, in fact, used their overall strategic direction to make fundamental decisions about how to design their business processes. In fact, my biggest criticism of the whole article is terminological, because Martin regularly uses the phrase management systems to describe what could (I think) be better called business processes.** But that's a small cavil indeed.

Let me quote a few of Martin's examples, to show you how this strategic alignment works in practice:***    

Four Seasons Hotels & Resorts seeks to win with a kind of service that is unique and that needs to be carried out by experienced Four Seasons hotel staff (as opposed to hotel staff experienced at other hotels), but in an industry that experiences 60–70% annual turnover. To get this kind of experienced hotel staff, Four Seasons has a management system that drives disproportionately huge investment in recruiting/hiring. To be hired, a recruit needs to have three successful in-person interviews, the last of which is with the hotel manager. This would be an unthinkably large expenditure of resources for other hotels, but sensible and necessary for Four Seasons desired capability. This [process] is rigorously enforced and adhered to. In addition, its career development [process] is disproportionately invested in because after recruiting the very best, Four Seasons wants and needs to keep them for a long career, which it does with turnover below 10%.

Progressive Insurance seeks to win, in part, by getting settlements to its customers so quickly that lawyers don’t get into the middle of the process because Progressive knows that on average when a lawyer is involved, it costs Progressive more and the customer gets less due to the high fees charged by the lawyer. In order to be in a financial position to pay claims quickly, Progressive has a management [process] for its investment portfolio that invests disproportionately in short-term liquidity at the cost of earning higher investment returns.

Procter & Gamble, when CEO AG Lafley took the helm in 2000, switched its basis for determining incentive compensation from market total shareholder return (M-TSR) to operating TSR (O-TSR). M-TSR, which measures performance based primarily based on movements in the company’s stock price, is the standard measure used across public companies. But it has the effect of encouraging management teams to focus on short-term fluctuations in stock price and the drivers thereof rather than on the long-term performance of the company, which O-TSR more closely measures by focusing on sales growth, profitability and cash conversion.

These are only a few examples. Martin's article gives ten more examples besides these, and I'm certain that his research includes plenty of others as well. 

So if it is possible to align your business processes with your strategic direction, why doesn't everybody do it? I haven't studied the rest of Martin's research, but I assume that the first answer is that figuring out the right alignment is hard to do. I'm pretty sure there is no simple paint-by-numbers approach that will generate your business processes automatically when you feed in your strategy. Like with any other strategic decision, you have to understand your industry really well, and then to understand your place in it. 

What can you do better than any of your competitors, and what does it take to enable you to do it? 

What risks can torpedo your efforts, and how can you neutralize them?   

These aren't easy questions. But then, they aren't easy for your competitors either. So if you can get a solid grip on them, and then derive unique business processes that play to your strengths, you'll be miles ahead.

__________

* In ISO 9001:2015, these requirements are found in clauses 4.1, 5.1.1(b), 5.2.1(a), and 9.3.1. 

** For example, Martin writes (in his fourth paragraph): "every company has numerous management systems. It has an order-entry system, a system for putting together its regulatory filings, a system for announcing new executive appointments, a capital appropriations system, etc." When I write about business systems in this blog, I would call each of these activities—order entry, regulatory filing, announcing appointments, and capital appropriations—a business process, in accordance with the definition in clause 3.4.1 of ISO 9000:2015: "set of interrelated or interacting activities that use inputs to deliver an intended result." But as I say, that is a very small and highly technical quibble.   

** All these examples are direct quotes from Martin's article cited immediately above. But I have replaced the phrase "management system" with the phrase "[business process]" (in square brackets, as shown) wherever I think it is clearer.      

Hierarchy of hazard controls

When I find that I've interrupted myself—twice in a row!—to make a disclaimer that's no part of the main post, maybe I need to pay attention. Maybe it's time for me to discuss the topic on its own, to get it settled, rather than pushing it off into footnotes.  

My last two posts—last week and three weeks ago—were about how to use written procedures. In both articles, I explained that written procedures should be regularly enhanced with the lessons learned from mistakes or disasters, so that the organization learns from those mistakes and doesn't repeat them. And both times I had to include a little caveat, to the effect that updating procedures is often not the best way to prevent safety problems.

Why did I bother to say this—especially twice? Also, what is the best way to prevent safety problems?

For the first question: I bothered to say it because updating procedures is probably the easiest way to address safety problems. Typically it costs less than any other approach, and it usually takes less time. But it is also one of the least effective ways to address safety problems, because people forget what they read, or decide to ignore it, or never get around to reading it in the first place.

For the second question, ... well, it depends. Classically there are five options, but they aren't always available in every case. So you have to see what you can do in each specific situation.

By Original version: NIOSHVector version: Michael Pittman
https://commons.wikimedia.org/w/index.php?curid=90190143

Elimination 

The most effective way to control a hazard is to eliminate it completely, but this isn't always possible. If your workplace has extension cords stretched across walking areas, those constitute a trip hazard. Get rid of the extension cords, perhaps by installing power outlets where you need them or by rearranging your workstations, and you have eliminated the trip hazard. If some work is being done high above the ground, there is a falling hazard. If you can relocate the work to ground level, you have eliminated the falling hazard. Again, this is the most effective approach—the hazard is gone, after all!—but sometimes it is not practical.

Substitution

The next-most-effective approach is to substitute something less dangerous for the original hazard. A common use-case for substitution involves the use of hazardous chemicals, because sometimes there is a less-hazardous chemical that will do the same job. Some operations have replaced the solvent benzene, a carcinogen, with toluene; others have replaced lead-based solder with lead-free solder. These substitutions generally cannot be done overnight: lead-free solder melts at a different temperature than the lead-based original, so converting a printed circuit board to lead-free solder requires sourcing new components and re-laying out the board. Still, it can be done. 

Engineering controls

Engineering controls do not remove the hazard, but isolate it. The easiest example is a guard rail or shielded enclosure to keep fingers out of machinery, or a ventilation hood to shield people from breathing noxious gases. Lockout-tagout mechanisms serve a similar purpose by ensuring that a machine cannot be serviced until it has been powered off and disconnected. In all these cases the hazard still exists, so if someone went out of his way to override the engineering controls there is a theoretical chance he could be injured. But he would have to go out of his way. In normal operation, engineering controls should keep people from getting hurt.  

Administrative controls

This is where we talk about updating your procedures! Administrative controls are all the measures that rely on telling people not to do things that can hurt them: they include written procedures, but also training, signs, and warning labels. Other administrative controls could include job rotation or work schedules, to reduce the exposure of each individual worker to a certain hazard; preventive maintenance programs, so that the equipment functions properly; scheduling certain tasks during off-peak hours, when fewer workers are present; or restricting access to hazardous areas. All of these measures are important, and they certainly have a place alongside more effective measures. It may also happen, because of special circumstances at your workplace, that sometimes these are the best you can do. But they all rely on human compliance. And as we have seen, human compliance is not always reliable. That's why administrative controls rank so low on the effectiveness scale.

Personal protective equipment (PPE)

Finally, sometimes you just have to walk in and grab the hazard in both hands. After analyzing it every possible way, you find that you can't eliminate the hazard and can't substitute it; and because the work requires direct human action at that point, engineering and administrative controls are beside the point (because both of those are designed to keep you away from the hazard). Fair enough. Do what you have to do. But at least wear gloves. Or a breathing filter. Or a hazmat suit. Or whatever the right PPE is for this particular hazard. PPE is rated as the least effective form of hazard abatement, because the only time you use it is when you are getting up close and personal with the hazard itself. But sometimes that's what you've got to do, and PPE is just what you need.

Once upon a time, years ago, I was talking to the management team for a mine. (They were mining diatomaceous earth, not coal or gold, but I bet the principles are the same.) I asked them if their employees tended to suffer from emphysema, or other lung ailments. They said that back before the 1950's, yes, that was a big problem. But in the 1950's someone invented a breathing filter which screened out the tiny particles of diatomaceous earth and other rock products, and after that they'd never had any trouble. I asked about enforcement, and they said: 

"Oh, that's easy. We painted a white stripe across the road into the mine. Then we announced that anybody who was found on the other side of the stripe without his breathing filter in place and working would be fired. On the spot. No questions asked. No excuses. No matter who.

"And you know? We haven't had a single problem since then."* 

PPE may be ranked as "least effective" but sometimes it's exactly what you need.

Anyway, that's the hierarchy of hazard controls. That's what's behind the little disclaimers in my last two articles. I hope it helps.

__________

* Technically this means they used PPE, reinforced by administrative controls (the white stripe).

       

Chesterton's fence

For the last couple of weeks (well, with one brief exception) we've been talking about written procedures: how they help avoid failure, and how to use them to capture the right lessons in case failure comes anyway. Specifically, I argued two weeks ago that when something goes badly wrong with one of your processes, it's good to analyze the failure to find a root cause; then, if the root cause was that someone acted a certain way, update your procedure so that he won't do the same thing next time.*   

But wait—what if you inherit a procedure, instead of writing it yourself? I spent a lot of my career working for small companies acquired by large ones, so that's the case I have in mind. The Home Office says to follow a procedure, but that procedure calls out forms you've never seen, and involves roles you've never heard of. 

Let's make this concrete. The Whizzbang Project is running late, but finally they think they can start testing. The team has met for a review. You have the official Test Readiness questionnaire from headquarters. The first few questions are easy. Then suddenly you read:

Question 17. Has the Whitzinframmer Report been duly refrangulated by the Junior Executive Pooh-Bah?

What are you supposed to do with that? Your office doesn't use that report. In fact you've never seen one. And the nearest person executing that role is across the ocean. Everyone in the meeting is staring at you. Now what?

The temptation is enormous just to skip it. But after all the discussion two weeks and three weeks ago about "procedures written in blood," you know that's not the best answer. On the other hand, you can't answer it as-written. What you need to find out is, What risk was this question written in order to avoid?

The key is that there aren't that many different ways to manage a project, or to fly a plane. Project managers around the world face exactly the same risks, and mostly use the same pool of solutions. Pilots around the world face the same laws of physics to keep their airplanes aloft. I guarantee that if modern project managers and civil engineers could sit down with the people who built the Pyramids, they'd be fast friends before they ran out of beer.**

So when you call somebody at the Home Office to ask about the Whitzinframmer Report,*** you don't need to reproduce every single field. But make sure you understand its purpose. Once you get past the window-dressing, it's sure to be a tool they use in the Home Office to handle some very normal project management risk. Getting that report "duly refrangulated" is how they check that you have enough budget for the next phase of the project ... or maybe it verifies that the test equipment is all working correctly, or something like that. In all events it will be something very normal. Then instead of asking the question literally, as written, ask whether the risk has been addressed. 

This means you say, "Question 17. Do we know if all our test equipment works?"

As a quick aside, I am not a pilot. If you are flying an unfamiliar plane, and if you find that you don't understand some of the instructions in the flight manual, I do not advise you to substitute free interpretations instead. The laws of physics are unforgiving. Also, it is a consistent theme in this blog that your level of effort should be proportional to the risk you face, and flying an unfamiliar plane involves a lot of risk. So it is worth the effort to know what you are doing.

But in more forgiving environments, there is more latitude to apply procedures in ways that make them useful. And the key is always to understand that the procedure itself is a tool for minimizing risk. So if you find that the procedure cannot be implemented as written, make sure you understand the risk that has to be managed. If you can neutralize the risk, that's ultimately the goal you are trying to achieve anyway.   

By the way, the approach that I recommend here is a special case of a principle called Chesterton's fence. Briefly, the idea is that if you find someone has put up a fence in an unlikely place, and you can't for the life of you think why, don't tear it down! They must have had a reason. It might have been a bad reason, or the reason might no longer apply. But until you know what the reason was, you had better leave the fence in place. "Written in blood" is a more dramatic way to say it, but the idea is the same.****

__________

* The current article is mostly about procedures and not safety, but note that procedural controls are not always the best way to address safety problems. I'll talk about this more next week. 

** The ancient Egyptians did brew beer, and each worker on the Pyramids got a daily ration of four to five liters, for both nutrition and refreshment. See Wikipedia, "History of beer" for more information. 

*** You should do this before the meeting!  

**** The full description of this principle comes from the author G. K. Chesterton, and is much more colorful: "In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, 'I don’t see the use of this; let us clear it away.' To which the more intelligent type of reformer will do well to answer: 'Tf you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.'" From G. K. Chesterton, The Thing (London: Sheed & Ward, 1946), p. 29.         

      

Procedures written in blood

Last week I wrote about the Challenger disaster, and about how to avoid the "normalization of deviance" that made it possible. One of the critical topics was to stick to the defined procedures, and I quoted the Air Force maxim that "The flight manual is written in blood." In other words, many of the flight regulations were created only after someone did something else one day, ... and then crashed.

Stories like these are a gruesome way to make the point, but wrapped inside this advice is an important principle on how to write and manage formal procedures:

• If something goes wrong—and especially if somebody gets hurt—analyze the accident to find the root cause. 
• Then if the root cause is something that could have been avoided if only the agent or operator had acted differently, update the written procedure to require future operators to do the safe thing. 

Way back in the first year of this blog, I wrote a post about how to write procedure documents which alluded to this issue but didn't go into details. What I said at the time was just, "If something is a safety guideline, spell it out." What I neglected to say was that often you learn the relevant safety guidelines by studying accidents and figuring out how to avoid them next time.

What is more, this advice isn't limited to safety risks. Any time you see a predictable failure mode that can be avoided by taking preventive action ahead of time, you should consider writing it into your procedures. Do you remember back when I wrote that all of Quality is built on the practice of Lessons Learned analysis? This is what I meant.

Don't go crazy, of course. Sometimes the risk is negligible, and it would take a lot of work to prevent it; in a case like that, maybe it's better to accept the risk and get on with things. But when the risk is substantial or even lethal, updating your procedures is a small price to pay for prevention.

I once worked in an office where we developed a checklist like this very organically. We were a small office that had recently been acquired by a much larger company, and the larger company had insisted we implement stage gate questionnaires to monitor and control our product development process. (I explain project stage gates in this post and this one.) But our administrative and IT landscapes were different from those in the home office, so we used some forms they didn't have, and vice versa. To account for our local forms, I created a local questionnaire with three or four questions on it.

To my surprise, the local questionnaire caught on. One of our projects did something ill-advised that set them months behind and wasted a bunch of money; we called a Lessons Learned meeting to figure out what went wrong. One of the outputs was that the Project Manager had failed to check for this-or-that condition at an early stage of the project. The PM's answer was, "How was I supposed to know we needed that?" And right away another team member said, "It's crazy that we forgot to check for that! Michael, can you put that on your checklist—that the Project Manager has to check for this point at that stage-gate review?"

Sure, I could do that. And over the years, the checklist grew.        

To be clear, updating procedures isn't the only way to prevent accidents. Depending on the risk, sometimes it's not the most effective. If you need to keep people from sticking their fingers into a dangerous machine while it's running, you'll have more success by installing a guard rail or a plastic shield than by writing a procedure that says "Don't stick your fingers in the machine."

But for other operations—flying an airplane, say, or managing a project—we depend on human action. And in those cases, regularly updated procedures are invaluable as a way to learn from the mistakes of the past. As one humorist wrote, "It's a wise man who profits by his own experience, but it's a good deal wiser one who lets the rattlesnake bite the other fellow."

      

Normalization of deviance

A year and a half ago, I wrote about disasters—and about how hard it can be to see them coming. I made the point that when we analyze a disaster retrospectively, we are likely to be led astray because we know how it's all going to turn out. Because of Hindsight Bias, in particular, we think it should have been obvious to everyone that a disaster was imminent, when in reality it might not have been clear at all. It is important to remember this bias when we try to understand a disaster, so we can look at events with the eyes of those who participated in them, to derive working lessons for the future.

But not all disasters are like this. Sometimes the risk of a disaster really is obvious to the people involved at the time, according to data they already have—they see the data, they understand the risk, and then somebody decides just to go ahead and do it anyway.

The Challenger disaster

"On January 28, 1986, Space Shuttle Challenger broke apart 73 seconds into its flight, killing all seven crew members aboard. The spacecraft disintegrated 46,000 feet (14 km) above the Atlantic Ocean, off the coast of Cape Canaveral, Florida, at 16:39:13 UTC (11:39:13 a.m. EST, local time at the launch site). It was the first fatal accident involving an American spacecraft while in flight."*

What happened? It was a cold day, and the rubber O-rings which sealed a joint in the right Space Shuttle Solid Rocket Booster were stiff. So they didn't seal the joint adequately. Shortly after liftoff, gases from within the rocket booster leaked out and started to burn through the larger structure. Now, the space shuttle and all its launch framework were made out of steel—of course. But the rocket boosters burned at 5600℉; and at that temperature, steel boils!** (Not melts—boils.) So naturally the whole assembly burst apart.

But how much of this could we have predicted ahead of time? It turns out the answer is, All of it. Recently I ran across a lecture on YouTube that breaks it down.*** (This lecture is saved in four parts, of which the first two discuss the Challenger disaster from a Quality perspective. The other two parts give valuable advice for managing your career and your life, but I won't focus on them here. You can scroll to the bottom of this post to find links to the lecture itself.)

In summary, the speaker (Mike Mullane) explains the sequence of events. 

• During the initial design reviews, the O-rings were designated at "Criticality 1," meaning that a failure could entail the destruction of the vehicle and the loss of life. "Criticality 1" also meant that any damage to the O-rings constituted adequate cause to abort the mission and redesign the shuttle. 
• Sure enough, after the shuttle's second flight (years before Challenger), the team recovered the parts and detected damage on the O-rings. 
• But for this and that reason the team decided to go ahead with a third launch, and the third flight was fine.
• In future flights, sometimes the O-rings were damaged and sometimes they weren't.
• After-action reports regularly called out the risk posed by damage to the O-rings. Multiple memos, over a period of two years or more, described the O-ring issue as "urgent." 
• But each flight was successful. So the project got the idea that the O-ring problem wasn't that big a deal. Every time the issue was raised, it was granted a standing waiver.
• Until, of course, one day it was a big deal after all ....  

What is the normalization of deviance?

Mullane explains that the "normalization of deviance" stems from nothing more than the natural human tendency to take shortcuts under pressure. We know what the "right" way to do a job is, and when we are relaxed we are happy to follow it. But then time runs short, or money runs short, or something else happens—it could be anything, really—and we get under pressure. So we take a shortcut, to make the job easier.

And most of the time, after we take that shortcut ... nothing happens! The job gets finished with no problem. So the next time we are under pressure, we remember that shortcut and do it again. And then again. Pretty soon, the "shortcut" has become the normal way of working. The "deviance" (a deviation from the defined and approved method) has become "normalized."

We've seen this before. Last year, when I was writing about Boeing, I explained how their cost-cutting drive led them to gut what used to be a robust safety management system. One of the factors at work was exactly this dynamic. I wrote:

They [Boeing management] found, empirically, that they could eliminate one Quality inspection, save a few dollars, and no planes fell out of the sky. OK, good. How about eliminating two inspections? Three? Four? Where do we stop? You can see how, in the absence of visible negative feedback (like an increased accident rate), this could get out of hand quickly.

That's what happened with Challenger. Word for word.

How do you protect against it?

Fine, how do we avoid this?

The short answer is almost too simple: Don't do that! But that sounds obvious, and yet this dynamic continues to afflict people every single day. So really, what do we do?

Mullane lists four points that he thinks are critical:

1. Recognize your vulnerability: Everybody thinks, It won't happen to me. I know all about this problem, so that makes me immune. I watched a video on YouTube. I read a blog post in Pragmatic Quality. I know better than to fall into this trap. Nice try. But the other people, those ones who did fall into this trap? They were plenty smart too. All of them "knew better." But when they felt pressured, their brains reacted automatically. It can happen to you too, exactly the same way. So watch for it.
2. Execute to meet standards: This is the core of it. Plan the work, and then work the plan. Mullane explains the Air Force has a saying, "The flight manual is written in blood." In other words, every instruction in the flight manual was put there because one day somebody did something different and it turned out badly. Don't let the next one be you. If the manual says, "Abort the mission when the red light flashes," and then the red light flashes, ... abort the mission. Simple as that. 
3. Trust your instincts: Mullane makes a big point of saying that we often know more than we understand consciously, and that our instincts are there to keep us alive. So if something just feels ... off, somehow ... wrong, but you can't put your finger on quite why ... trust that feeling. Probably the thing really is wrong, and at some level you even know why. It just hasn't percolated up into your consciousness yet, but it will.
4. Archive and review near-misses and disasters: Learn from other people's experience, so you don't have to go through the same thing. Look at the disasters—or the near-misses, where things came out fine but almost didn't—that your own team has experienced. But then try to find out about other teams as well. Look for the big disasters (or near-misses) in your industry, the ones that make the news. Read everything you can, and then flow down to your team what you have learned.

And then, if we do those four things, are we home free?

I'm pretty sure nobody can promise that. But if you do these things you'll be miles ahead. And you will have reduced the odds of normalizing deviance as far as you can.

If you want more details, Mullane's lecture is a good one.

Mike Mullane's lecture, part 1/4: What is normalization of deviance?

Mike Mullane's lecture, part 2/4: How do you protect against normalization of deviance?

Mike Mullane's lecture, part 3/4: Responsibility: https://www.youtube.com/watch?v=Wuk_DoX-rz8

Mike Mullane's lecture, part 4/4: Courageous self-leadership: https://www.youtube.com/watch?v=DABsxJtNcYg

__________

* Quoted from Wikipedia, "Space Shuttle Challenger disaster." I have used this article for basic information about the disaster.  

** For specifics see this flyer from Northrop-Grumman on the Five-Segment Booster, especially the "Booster facts" on page 1. 

*** The lecture was posted to YouTube about ten years ago, but I don't know when it was given. The speaker is Mike Mullane (website, Wikipedia), an engineer, weapon systems officer, retired USAF officer, and former astronaut. He was talking to the International Association of Firefighters (IAFF) about the "Normalization of deviance."      

        

What is the process approach? — take 2

Yesterday morning, Manufacturing Tomorrow published my article, "What is the process approach?" It's their article now so I won't post the text of it here, but you can find it by following the link. I hope you find it useful!

For those keeping track, this is the article I promised you back in the beginning of April. The publishing process has its own timelines that aren't always obvious to the rest of us. 😀

How do you manage "special responsibilities"?

One of the first things you learn when you write formal procedures is, Don't use personal names! 

Let's say you are writing a calibration procedure. As long as anyone can remember, Dave has been checking the calibration of all your tools on a rolling cycle, so he checks each tool twice a year and records the results in an Excel sheet. Finally you get around to documenting what he does in a procedure. What you must not write is, "Dave checks the tools twice a year on a rolling cycle." Why not? Because if you use Dave's name in the procedure, sure as anything he'll move to Tahiti next month and you'll have to update the document to name someone else.

So you replace Dave's name with a functional title, and write: "The Calibration Coordinator checks the tools twice a year on a rolling cycle." Note that this isn't Dave's job title. In many companies, Dave's job title is something like "Engineer 2" that can be correlated with his pay grade. And you certainly don't want just any old "Engineer 2" to do this job. The person who does it—Dave, or his successor—has to be qualified by knowing about calibration. That's why you create a special functional title just for the sake of this specific document, and you call Dave the "Calibration Coordinator."

As you write procedure documents for your operations, you'll do this several times—half a dozen, maybe more or less, depending on how complex or specialized your operations are. When you are done, you'll have a collection of functional titles that exist only in your procedure documentation, to account for specific roles your quality management system needs. These functional titles identify your QMS's Special Responsibilities. Of course in practice they just point to Dave and Pat and Sue and Sam, who handle the respective tasks. And when the auditor reads your Calibration Procedure and asks, "Calibration Coordinator? Who's that?" right away you say "Dave."

Then the auditor asks, "How do you know?"

Make a list 

One way to manage these assignments is to make a list. Seriously, it can be that easy. Just read through the formal procedures in your QMS, and write down every Special Responsibility they define. Then publish a List of Special Responsibilities (LoSR). For each entry in the List, identify the following four pieces of information:

• 
  Title of the role? (e.g., Calibration Coordinator)
• What document defines the responsibilities? (e.g., Calibration Procedure)
• Who is assigned to that role? (e.g., Dave Smith)
• Who is the Proxy, in case the regular assignee is out? (e.g., Pat Jones)

And that's it. The next steps are just as straightforward: 

• Make sure the List is formally approved by a suitable authority. (Since the list covers roles throughout your QMS, the "suitable authority" is usually your top management.)
• Formally identify the List as part of your QMS documentation.
• Maintain the List through formal change control, so that it is always up to date and so that the assignments are communicated to all stakeholders.

Enhance your documents

There's one loose end, but it is easy to tie up. Remember I said that not just anybody can be Calibration Coordinator? Spell out the qualifications for the role. 

An easy place to document them is in the same procedure document that defines the role in the first place. For example, your Calibration Procedure explains all the steps required to calibrate your equipment; so you can easily add one extra paragraph that spells out the necessary qualifications for the Calibration Coordinator. 

Then Dave's training records include an entry that shows how he met the qualification requirements. Maybe he took a class and got a certificate; or maybe he learned on the job from his predecessor, who sent an email when Dave was ready. Either way, the assignment and Dave's qualifications are fully traceable.

• The List of Special Responsibilites assigns Dave to his role, and references the document that explains it in detail.
• The document also lists the qualification requirements.
• And Dave's training records show that he meets those requirements.

If you have used other approaches you like better, leave me a note in the comments.

    

What is the Process approach?

The fourth Quality Management Principle is the Process approach. And unlike the case with some of the other principles, I have already written a fair bit about it, here and elsewhere. In fact, by a curious synchronicity, I just finished an article for publication explaining the process approach in some detail. If it finally sees the light of day, I'll make sure to post a link in this blogroll, just as I have for other articles I have published in the wider world. 

So instead of laying out the elements of the process approach yet again, I want to take a few minutes to explain why it is so ubiquitous. After all, no sooner do you start working in Quality than you hear about processes. They seem to be everywhere. I have seen companies unironically publish a process on how to write processes.

Why is this? Has everyone just gone crazy?

No, not quite. It turns out that the process approach is a remarkably useful and powerful tool for describing work.

Work can be confusing when you look at it on a large scale, because there are so many people doing so many different things. It can look as crowded and confusing as … well, let's say a county fair.

But look at the same fair through the lens of the process approach, and it all begins to make sense. Everyone is there for a reason. And mostly, everyone's activities can be described with a process.

• The hot dog vendors are there to sell hot dogs. Their process runs something like this: Take an order; prepare the hot dog; give the hot dog to the customer; collect the money. Repeat.
• The cotton candy vendors are there to sell cotton candy. Their process is almost exactly the same.
• The cheese curd vendors are doing the same thing again.
• The team in charge of the Ferris Wheel are selling tickets on the Ferris Wheel, much like the other vendors. But their process interacts with a second process that turns the switch so the Ferris Wheel rotates.
• The 4-H Club is there to show off their animals. They have a different process, but it is still a process that they cycle through several times during the day.
• Even the vacationers, who are visiting just to see the sights, are following a kind of process of their own, though their process has room in it for a little more variation. But roughly it goes something like this: Drive to the fair; park the car; walk down the Midway; go to the first exhibit; go to the second exhibit; get some food; go to the third exhibit; get some more food; go to the fourth and fifth exhibits; walk back to the car; drive home.  

And all of a sudden, this huge, confusing swarm of people makes sense! All you have to do is to look at it as a collection of interacting processes, and the chaos becomes order. This is because the process approach gives us two kinds of information about the activities of every participant: purpose and predictability. That is to say: when you describe everyone's work as part of one process or another, you tell us what they are going to do and also why they are doing it.

If you want to understand work on the large scale—whether you are describing a county fair or a factory building airplanes—there is simply no intellectual tool more effective than the process approach. It's ubiquitous—nay, universal—because it works.

On top of all that, there's another benefit to the process approach. Let's say you've been put in charge of a huge, teeming swarm of work: maybe an aircraft factory (just for example). And let's say you've been told you have to make the operation more efficient. Where do you start?

You start by studying the processes. After all, if you want to make the work more efficient, that means making George's work more efficient, and Sam's work, and Fred's work, and Max's work. You can't do that unless you know what they do. But reading their processes tells you what they do, and it also lets you look for optimizations. 

"Hey Max, why do you walk clear across the plant twice, every single day? Wouldn't it be easier if you rearranged the steps in your job so you didn't have to do that?"

Ask that question a thousand times, and you cut in half the man-hours it takes to produce your airplanes. But you'll never know to ask the question even once until you read the processes. 

These are the benefits of the process approach.

But what are the elements of the process approach?

There are several. I've written about most of them before.

If you want further discussion of what processes can do and can't do, check out this post and this one.

If you want to implement the process approach in your own organization, consider this series of posts on:

• writing processes;
• owning processes;
• and measuring processes. (Consider also this post on how measuring can go wrong.)

When it's time to follow up on your process implementation, the tool for that is management review. I mention that several times; but my most important advice is in this post and this one.

Also (according to ISO 9001:2015, clause 0.1, paragraph 6) the process approach includes two other tools that I would probably have listed separately. But who am I to argue with the ISO? These tools are:

• the Plan-Do-Check-Act (PDCA) cycle, which I discuss at a high-level in this post, and then in excruciating detail (although without using the PDCA acronym, but this is definitely what it looks like in practice) in this post;
• Risk-based thinking, which largely refers to what used to be called "preventive actions" or "lessons learned" (see especially this post here and this post here). I've recently written another article for publication in the outside world on the subject of risk-based thinking. So if it sees the light of day any time soon, I'll link it here as well.