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.      

A management system just for show

A few days ago I was browsing through LinkedIn, and I found a link to a video called "3 Signs Your Management System Is Just for Show." Well the title was intriguing, so I watched it; and it was three minutes well-spent. The information won't be new to regular readers of this blog, but it's expressed in compact points that any viewer can easily digest and carry away.* 

The basic message of the whole video is that your management system shouldn't be something special that you have to think about. It should just be The Way You Do Things. Did you get a customer complaint from the field? Open an 8D, because that's how you handle customer complaints. Are you making a big change to your manufacturing process? Schedule an FMEA, because that's how you evaluate the risks in production changes. Does someone have an idea for a cool new product? Call together a project team, because that's how you develop new products. The place you want to get to is one where you don't have to wonder, "What does our process say we're supposed to do?" or "What does the ISO standard require?" because you just know that this is how we do things here.

The video makes this message more precise by calling out three specific red flags:

• Senior management does not know what is happening with the management system.
• Audits are performed solely to maintain certification.
• The team does not know what the management system is for. 

These are concrete points you can look for. But in essence they all mean that you aren't really living your management system. 

If senior management doesn't know what is happening with the management system, it means they haven't been showing up for Management Review. But Management Review is the key to the whole organization, the place where you make system-level interventions so that the day-to-day work can move forward by routine without requiring senior management to fire-fight every little issue.

If an organization treats audits as no more than an emergency interruption to ensure certification, they won't get the real benefits of the audit program. We've discussed at length that audits shouldn't require you to do anything different from what you normally do every day. And experience with an audit program can help grow a Quality mindset.

And if a team doesn't even know what the management system is for, ... well, they can't be living it, can they? And the system won't do anyone any good if it just sits on the shelf gathering dust.

As I say, the lessons from this video aren't going to be new or shocking to regular readers. But I do like how they presented it all in such a compact way. I hope you do too.   

__________

* The video was produced by an organization called QMS Certification. I've never heard of them before, and know nothing about them. So this post does not constitute any kind of commercial endorsement of their services. But I liked the video.       

"How's our Quality?"

One of the risks in a mature Quality system is that there are a lot of details to master. So when you've mastered all the details, you think you know what's going on. But sometimes when all those trees crowd together you can lose sight of the forest.

I remember once, years ago, I worked for a company that had a very mature system. It seemed like they had metrics defined for everything but the coffee pot. When I first started there I had to learn the whole system pretty quickly, and my boss focused on the fine-grain details. Then suddenly we reorganized: instead of reporting to a functional expert located far away, now I reported to the General Manager in my own location.

For my first meeting with him, I brought along all the charts and metrics that my former boss had always wanted to review, but the GM waved them away. Instead, he asked me, "So how is our Quality?"

I fumbled for a minute and started to explain, "We measure that in a lot of ways. Now this chart, for instance, shows that ...."

The GM cut me off. "How's our Quality?"

I couldn't tell what he wanted to know.

"Look, I know that the guy you used to work for asked for all these dozens of metrics. He used to present his charts to me and I couldn't make head nor tail of them. I just want to know how we are doing."

Whatever answer I gave didn't satisfy him. So when I got back to my desk I pulled out all the metrics and tried to look at them from a high level. I realized that they fell naturally into three buckets:

• metrics related to our product performance and customer satisfaction;
• metrics related to how well we complied with the formal procedures mandated by Headquarters;
• and metrics that tracked internal administrative activities—these weren't as important as the other two, but I had inherited them as part of the system so I still calculated them.

The other thing I realized was that the performance inside each bucket was pretty consistent. When I saw that, I knew how I was going to report the results to our GM.

Next week was my next meeting with him. And sure enough, he started by asking, "How's our Quality?"

This time I had an answer. "Our product quality is great, and our customers are very happy. Those metrics are all green. Our process adherence is lousy. Those metrics are all deep red. And our internal functions are kind of wishy-washy, not great but not terrible. You can call those yellow, if you like."

The GM grinned. "Thank you. That's what I was looking for. Also it's pretty much what I expected. Now go fix the ones that aren't already green."  

"Aye aye, sir." 

We communicated a lot more easily after that. And I learned, never lose sight of the big picture. Ultimately all those details are there only to support and flesh out that big picture. But if you can't see the big picture, you don't know where to start work.

      

The placebo effect in Quality

I have long argued that Quality means getting what you want. But people want all kinds of things. And sometimes a person's "wants" don't make a lot of sense. Are all these things still Quality?

• 
  A friend of mine recently overheard a conversation in a grocery store. A customer was buying baking soda. She couldn't find the expensive commercial brand she wanted, so she reluctantly settled for the cheaper commercial brand instead. She flatly refused to buy the store brand. But baking soda is a pure chemical—sodium bicarbonate, or NaHCO₃. It's the same chemical, regardless of the packaging.
• Years ago, when my dad was a boy, the local grocer in his town told him a story. This man sold coffee, which he ordered in huge sacks and then poured into little paper bags sealed with tape for retail sale. The bags came in two sizes: 8 ounces (sealed with green tape) and 12 ounces (sealed with blue tape). But then he priced the smaller bags so that they cost more than the larger bags. It was the same coffee, and he never claimed they were different! But some customers always bought blue, and others always bought green. Once a customer who always bought green let him know that the shelf was empty. He told her, "Well, I get my next shipment tomorrow. But in the meantime I do still have some of the blue coffee, if you would like to try it." She answered, "No, I tried that once and it just doesn't compare. I guess I'll come back tomorrow, when you've got your shipment in." 
• 
  For years, IBM repairmen famously wore suits with white shirts and ties, and they carried their tools in attaché cases. John Molloy tells the story* that this uniform was established when computers were still large and expensive, and had not been widely adopted. The stereotype among companies that were just starting to buy computers was that they were unreliable and always breaking down. So IBM dressed their repairmen to look absolutely reliable, to persuade customers that the computers themselves were just as good. 

What do these stories tell us? They tell us that customer perceptions of Quality can be influenced by factors other than the objective content of the product or service itself. Presentation, expectation, packaging, and even price—all these contribute to the customer experience, and therefore to the customer's ultimate judgement (positive or negative) about the product or service.

So does that mean that we can stop worrying about making our products any good? Can we sell defective products and still call them "Quality" so long as the packaging is shiny enough?

No, of course not. If you sell defective products that break as soon as they're out of the box, your customers will catch on quickly enough. Then they'll tell their friends, and your reputation will be in tatters. Understanding the placebo effect is no excuse for sloppy workmanship.

What it does mean is that you can't stop with the product itself. Precisely because customers evaluate the presentation and packaging and the rest as part of their total experience, you have to take care with those things too, so that the total customer experience is as good as possible. 

• If you are selling a product, make it easy to use and attractive to look at. 
• If you are selling a service, make it transparent to the customer. 
• Either way, make sure your advertising sets accurate expectations so that the customer isn't surprised later. 
• Since you are selling the sizzle as well as the steak, ensure that the sizzle is appetizing even while you also ensure that the steak is nutritious.

When you take as many pains with the presentation as you do with the content, you signal to your customer right away that she is in good hands. You encourage her peace of mind. And peace of mind, as Robert Pirsig points out, is the heart of Quality.

"Peace of mind isn't at all superficial .... It's the whole thing. That which produces it is good [work]; that which disturbs it is poor [work].... The ultimate test's always your own serenity."**  

__________

* I read this years ago and have lost the reference. So it is possible that I may misremember details of the story, since I can't check it. But I believe it is true in broad outline.  

** Robert Pirsig, Zen and the Art of Motorcycle Maintenance (New York: William Morrow & Company, 1974, 1999), p. 165.    

       

Giving your stakeholders a real stake

We've talked before about why it's important to know the stakeholders of your organization—I mean both the people who can affect your decisions, and those who will be affected by them. This is the kind of information every business needs to know,* and at some level you probably already do. The ISO 9001 standard goes so far as to require you to determine who are "the interested parties that are relevant to the quality management system" and what they want from you, and then also to "monitor and review information about these interested parties and their relevant requirements" as they naturally change in the future.**

Who speaks for your stakeholders? Mostly, you do. Depending on which stakeholder you have in mind, there are multiple ways of collecting their input: customers might bring you complaints (or praise!), local governments might send around inspectors, employees might communicate their opinions through their managers or through company meetings. But one way or another some degree of stakeholder input is channeled into management, and then management decides what to do with it. If these inputs conflict—maybe shareholders want larger dividends at the same time that employees want higher wages—the organization's management makes a decision and then the stakeholders mostly live with the results.

But what if you want your organization to serve some higher purpose—for example, a charitable purpose or something similar? What if you want one of your stakeholders to have an actual stake in the success of your business, so that they are sure to prosper as long as you do? If it's a small business and you are the owner, it's easy enough: just decide that every year you'll give them a percent of the profits, and then don't change your mind. But as soon as you involve more people in running your organization, the answer becomes more complicated.

It's an interesting question, though, and it turns out that there are several ways to do it. Strictly speaking this isn't a question about Quality, so normally I would stay away from it. But it is a question about governance, which is a closely related topic. So with your indulgence I'd like to take a few minutes to describe some of the common answers to this question. I can address a more recognizable Quality topic next week.

To be precise, the question I have in mind is this one:

"How can I ensure that my company supports a cause or beneficiary that is important to me, even if I bring in other shareholders or even after I die? How can I prevent the situation where future stockholders force future boards of management to neglect my cause or beneficiary so they can squeeze out the maximum short-term profit?"

I have found three answers to this question. In practice they can overlap, but there are important differences between them. One answer is to certify your business as a B-corporation. Another is to make it a benefits-corporation. (These are not the same thing.) And there is a third approach which appears to be called "steward-ownership." I explain the differences below.       

B-corporations

A B-corporation is a for-profit corporation that has been certified for its social impact by B-Lab. B-Lab is a private, non-profit organization that has been set up explicitly to offer this certification to qualified companies. To qualify for certification, an organization must score at least 80 out of 200 on a detailed questionnaire that covers five general areas: governance, workers' rights, community impact, environmental impact, and customer care. Then the organization pays an annual fee to B-Lab, based partly on its location and gross annual revenue, and recertifies every three years.

B-certification is not a legal status, and it does not (by itself) offer any legal protection against lawsuits by disgruntled shareholders. In some ways it is like ISO 9001 certification, in that it represents compliance to a voluntary standard which a company adopts either because of the discipline it imposes or as a marketing tool. (Or both, of course.) That said, certification does require companies to incorporate stakeholder commitments into their governing documents; in some cases these documents might offer legal protection that B-certification itself does not. Certified companies must also adopt a certain measure of transparency concerning their public impact.  

Benefit corporations

By contrast, a benefit corporation is a legal status, at any rate in jurisdictions that have passed the legislation. As of the most recent update to the Wikipedia article, forty-one American states plus the District of Columbia allow for-profit businesses to incorporate as benefit corporations. Outside the United States, benefit corporation status (or something similar) is recognized in the province of British Columbia, and in the nations of Colombia, Israel, Italy, and the United Kingdom.

This special legal status was created to offer some protection from the normal presumption in American law that a corporation exists for the financial benefit of the shareholders. Because of this presumption, directors sometimes conclude that their fiduciary duty to shareholders requires them to ignore the claims of any other stakeholders or beneficiaries, and to make decisions on the basis of profitability alone. Therefore benefit corporations explicitly define the fiduciary duty of the directors so that they are required to consider the interests of other stakeholders. Wikipedia explains:

The benefit corporation legislation ensures that a director is required to consider other public benefits in addition to profit, preventing shareholders from using a drop in stock value as evidence for dismissal or a lawsuit against the corporation. Transparency provisions require benefit corporations to publish annual benefit reports of their social and environmental performance using a comprehensive, credible, independent, and transparent third-party standard.      

What is the difference between a benefit corporation and a B-certified corporation? They overlap, and some companies are both. The biggest difference is that establishing your company as a benefit corporation gives it a legal status, while seeking B-certification does not. Other than that, there are detailed differences in the exact requirements around transparency and other topics. 

Steward-ownership

The third approach, steward-ownership, is rather different. It requires no special legislation, and no external certification. But it does require some planning in advance, and it's not really compatible with selling shares in the stock market. To use this approach, you have to restructure the ownership of your company in a special way.

I first encountered this model when I worked for Bosch, and for a long time I assumed they were the only company that used it. Bosch's governance structure is no secret, and they discuss it in some detail on their website. The basic idea is that they issue shares of stock, like other companies, although those shares aren't sold on the open market. But they distinguish sharply between voting shares and paying shares. Normally, if you own stock in a company then you have a right to vote those shares at shareholder meetings (though it might be impractical to do so in person), and you can also expect the payment of dividends on a certain frequency as long as the company is making a profit. But Bosch separated those two functions. Voting shares give you the right to vote on the company's governance. Paying shares pay dividends. And they are not the same.

With that distinction as background, the global corporation Robert Bosch GmbH has three shareholders:

• Robert Bosch Industrietreuhand KG is a steering committee that makes general governance decisions (the way a "shareholder's meeting" would for some other company). They hold 93% of the voting shares and no paying shares.
• Robert Bosch Stiftung GmbH is a non-profit charitable foundation that funds the Robert Bosch Hospital, schools and daycare centers, and peaceful social initiatives around the world. They hold 94% of the paying shares and no voting shares.
• The Bosch family (the descendants of Robert Bosch) own the remaining shares: 7% of voting, and 6% of paying. This way they are not forgotten, but neither can they wrest control of the company to do something crazy.

As I say, for a long time I assumed this structure was unique to Bosch. But when I began researching this article, I discovered that a few other companies do the same thing. In September of 2022, Patagonia reorganized around a similar model.*** IKEA uses another variant of foundation-ownership, including benefits to a charitable foundation, although the IKEA governance structure is much more complicated than that of Bosch or Patagonia. And there are other examples as well. 

Again, for a small company with a single owner, these tools are probably more than you need to think about. But if you want to build a legacy, or if you want your company to support a beneficiary or a cause, these are among the ways to do it.   

__________

* See, for example, the discussions here and here. 

** ISO 9001:2015, clause 4.2. 

*** This article in Medium goes into some detail.     

    

In praise of roundabouts

The first time I ever noticed roundabouts, I was on vacation in the UK. This was many years ago, but they seemed to be everywhere. At first I thought it was just one more peculiar feature of local transportation, along with narrow roads, streets that changed their name with each new block, and driving on the left. In fact, I didn't realize how much they improved the flow of traffic until I found myself immobilized in a column of cars for what seemed a very long time, only to realize we were all stopped for a traffic light.

That afternoon I saw why roundabouts were so common in the UK, and I began to wonder why they aren't just as common everywhere else. Of course rebuilding an existing intersection is time-consuming and expensive. But the statistics comparing roundabouts to traditional intersections are remarkable.

• The Federal Highway Administration estimates that replacing a traditional intersection with a roundabout reduces the number of fatal and injury crashes by about 80%. (That's 82% for a two-way stop-controlled intersection, and 78% for a signal-controlled intersection.)*
• When collisions do occur, they are generally side-to-side collisions from merging or changing lanes, rather than head-on or right-angle collisions. On the whole, side-to-side collisions are less damaging and less often lethal than the other kind.
• Not only are they safer for cars, but roundabouts have 10-40% fewer pedestrian or bicycle crashes than traditional intersections.
• Since cars typically don't have to wait as long at roundabouts as at traditional intersections, they contribute to reducing air pollution from idling engines.    

And all these benefits stem from one root cause: Roundabouts are far simpler than traditional intersections. In this context, simplicity is measured by counting "conflict points." These are points in the intersection where a collision can be foreseen. A traditional intersection of two roads, each supporting two-way traffic and crossing at right angles, has 32 conflict points. If those same two roads meet in a roundabout, the number of conflict points drops to eight. No wonder the roundabout is safer!

Why am I writing about traffic this week? There's no special reason, except that it illustrates in a dramatic way another important Quality principle: when other things are equal, simplicity is better than complexity. In other words, if you have two solutions to a problem and they both solve it equally well, choose the simpler one. The complex tool has more parts; the complex procedure has more steps; the complex intersection has more conflict points. In all events, this means that the complex solution has more ways to go wrong: more parts that can break, more steps that can be mis-executed, more collisions that can happen. From the perspective of risk management, the complex solution is always—again, other things being equal—more fragile and more at risk of failure.

Years ago, a colleague at work was telling me about the cup holders in his cars. He owned two cars, and the cup holders were very different. One car had a sleek and elegant design. The cup holder was tucked discreetly out of sight until you pushed a button; then a little motor gently unfolded it for you. But at the time we talked, a tiny part had broken in the motor, so it had stopped working. He had contacted the dealership, but it would be several weeks before they could get the piece in stock.

The other car wasn't nearly so elegant. But it had a piece of plastic in arm's reach, molded to hold a cup. The overall look wasn't nearly as sleek and beautiful as the first car, but there was nothing that could break. From the perspective of customer satisfaction, the simpler solution clearly had the higher Quality. And it's often like that.

__________

* You can find more detailed numbers, for example, here.    

Quality in the checkout line

Writing this column once a week, I find myself looking for Quality aspects in many of the things I do each day. From one perspective, this makes sense: I have argued, after all, that Quality isn't really a set of rules or procedures (though it uses both those things), but rather is an awareness of what it takes here and now to do this task correctly. If that's the case, then Quality might just be applicable to anything you do.

Anything? Pretty close. 

The other evening I went out to get groceries. Everything was fine until I got home, when I found that they had failed to scan a dozen eggs and a package of butter. In effect, they undercharged me by $9.98. It was too late to go back that night, but I went back the next morning to tell them about the mistake and to make up the difference. They thanked me for letting them know, and said they would update their inventory; other than that, they sent me on my way. "Call it our gift to you." 

What does this story have to do with Quality? I see two principles that it is important to remember.

Don't disrupt a working process

Why did the mistake happen in the first place? The checker was in the middle of scanning my groceries when a second checker came up and offered to help. I think the second checker moved things in the cart; then the first checker concluded that if the eggs and butter were here instead of there, they must have already been scanned. It's a simple mistake to make, but the point is important: if somebody is in the middle of a procedure and it's working for them, don't interrupt without making very sure of what you are doing. It's easy to throw them off their count, or mix up their stacks, and then the procedure might be ruined. 

Of course if you are using formal, written procedures and interacting with machines that require fixed inputs, it's harder to get mixed up that way. But often you aren't, especially in small or medium-sized enterprises, or in service functions (as distinct from manufacturing). 

Keep corrective actions proportional to the problem

When I went back the next day, the store thanked me for my report but didn't take my money. Of course I appreciated their kindness, but they aren't in business to be kind. How can they afford this?

The answer is that it doesn't happen often, so they had no procedure or mechanism to make the correction. What's more, any method they tried to improvise to allow them to take my money would have cost them more than $9.98 to implement. It was—quite literally—not worth it to them to correct this particular shortfall.

Sometimes that happens, and it's good to recognize when it does. Focus your work where it matters.

So yes, there are Quality aspects even to a simple mistake in the checkout line. The awareness of the task—including awareness of what might go wrong, how to avoid it, and when not to bother—is always the most important part.  

    

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.         

      

Podcast with Quality Magazine!

We've been talking lately about how formal processes can avoid catastrophic mistakes and I've got more to say on the subject. But this is a timely interruption. 

A while ago, I sat down with Michelle Bangert of Quality Magazine, when they published my article about the Seven Quality Management Principles. Originally, we were just going to talk about the article itself, and maybe to recap it for people who prefer podcasts to blog posts. But the conversation unwound itself according to its own internal rules, the way any good conversation does. After forty minutes we had discussed at least a dozen topics; in some ways it felt like we had been talking all day, and in other ways it felt like we were just beginning to scratch the surface. Among other things, our conversation touched on topics like the following:

• How I came to write the article on the Seven Quality Management Principles.
• When to expect the upcoming changes to ISO 9000 and ISO 9001.
• How blogging is different from kvetching.
• How to use blogging as a branding tool.
• Why I am delighted when people argue with things I've written. 
• (As a bonus, I describe two different times I've had to retract something I'd written because feedback from readers showed me I was wrong: I mean here and here.)
• How lessons from parenting also apply to Quality.
• How my career in Quality started, and why you shouldn't imitate me.
• Career highlights and stories for audit nerds.
• Comparing Stuttgart with Santa Barbara as wine countries.
• The hidden message of German architecture.
• Why do I anonymize my stories, and when do I not?
• Where is the other column that I write, and what is it about?
• What is the difference between rules in young/small organizations, and rules in old/large ones?

Anyway, two days ago the podcast was published. You can find it here. (Here is an alternate link.)

So take a listen, and let me know what you think. 

• If you think I'm wrong about anything (or everything!), please let me know: like I say above, I'm always thrilled when someone argues with me.
• And if you like it, contact Michelle Bangert at Quality Magazine to ask her to have me on again! 😀

    

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