What's "proportionate"?

When the ISO 9001 standard requires you to take action to address your risks and opportunities, it includes this admonition in clause 6.1.2: Actions taken to address risks and opportunities shall be proportionate to the potential impact on the conformity of products and services.

OK, I guess that's fine, but what does it mean? What does it take for your actions to be "proportionate" to the risks they address?

The word is never defined—or at any rate, neither ISO 9001 nor ISO 9000 define it. But intuitively I think we all have a sense for what it means, don't we? The basic idea is ancient: Nothing in excess.* If you face a risk that might, at worst, cost you $100, then it is foolish to spend $1000 to prevent it. That cost, or that level of effort, is disproportionate to the $100 downside that you face from the unmitigated risk. Most of the time, we probably don't need a definition more exact than that.

But "sometimes the clearest way to explain what a rangatang [sic] is, is to 'tell what it ain't.'"** A couple of months ago, I stumbled upon a blog post from 2016 that explains the concept of disproportionality with crystal clarity. The author of the post—Quinn Dunki of Blondihacks—just wanted to set up an automated cat feeder, so that her cat would be fed on time and she didn't have to watch the clock every day. Simple, right?

Turns out her cat had a different idea. Her cat's idea was, "How do I get this machine to give me more food than Quinn wants me to have?" So Quinn had to make some adaptations to her automated cat feeder, to protect it from the prying paws of her cat. As she says at the opening of her blog post, "The trick is to be smarter than the animal with a brain the size of a walnut."

But of course, Quinn worked on this problem part-time, and her cat worked on it full-time. 

You can read the results here.

In the end, Quinn won. But I'm pretty sure nobody would say that the effort she expended was proportional either to the benefits she gained or to the risks she was avoiding.

Verbum sapienti sat. 

__________

* "Μηδὲν ἄγαν" was one of the three proverbs said to have been inscribed at the entrance to the Greek temple at Delphi. See here for more information.  

** Owen Ulph, The Fiddleback: Lore of the Line Camp (San Francisco: Browntrout Publishers, 1995), p. 23.      

How do you prove "consideration"?

How many times have you seen departments do things that don't help them any, just because it's easier for the auditor once a year? I've seen it too often to count, and it's never the right thing to do. Oh sure, in a sense I appreciate it when I'm the auditor. But also, it's really unnecessary. I've audited a lot of departments over the years, and they've done things a lot of different ways. If it works better for you the other 364 days of the year to do this rather than that, … well, as long as it meets the rules I can probably figure it out.

I was thinking about this recently while talking to someone about the rules for management review. Right now, ISO 9001:2015, clause 9.3.2 states, "The management review shall be planned and carried out taking into consideration"—and then there follows a long list of topics, (a) through (f), where item (c) is further divided into seven subtopics. It's a comprehensive list. Anyway, my friend was saying he wishes the ISO would change this requirement to say that management review must explicitly include all these topics, because "How are you supposed to prove consideration to an auditor?" What he meant, of course, was that if the agenda for management review were required to include every one of these topics and subtopics, it would be easy to show that you had "considered" them all.

Long-time readers may remember that I think this is a terrible idea! The biggest risk in any management review is that the participants are likely to get bored. To avoid boring them, cut out everything you can. Discuss only the pain points that have to be resolved by the specific participants of this meeting. That means that if your internal audits or your supplier evaluations are all green, it's enough to wave your hand and say so; you don't have to drag the attendees through an itemized list of each one. Spend your time instead explaining that it's time to buy a new widget-stamping machine, because the old one slides out of alignment once a month like clockwork and the rework costs are eating you alive. 

But of course you still have to pass that audit once a year, so how are you going to do it? It's all very well for me to say that you shouldn't rearrange your whole management review just for the convenience of the auditor, but you are going to have to show some kind of objective evidence. What will it be?

Do it like this.

First, as you prepare the meeting, go through every single one of those topics listed in clause 9.3.2, and document where it stands right now. (You have to do that anyway in order to find out where your pain points are, since those are the topics you will discuss.)  

Second, while you are conducting the meeting, keep all this material handy where you can reach it. Maybe this means it's stored electronically just one click away, or maybe it's on paper in a notebook on the desk next to you. But just in case someone brings up a question about one of those topics you thought you could afford to skip, make sure the data is immediately available.

Third, store all this data as a permanent Quality record, together with the minutes from the management review meeting that it supported.

Fourth, ask your internal auditors to look for this data when they audit the management review process, just to keep you honest. 😃 Naturally whoever audits the Quality function doesn't work for you—do they??—so if you make a mistake they won't be shy about writing it up.

And finally Fifth, when the external auditor visits, pull out all this stored data as proof that you really did consider all the topics listed in the standard. Then you can explain why you tailored the agenda to address the problems that really needed management attention, and why you skipped over all the topics that were functioning smoothly because they were just business as usual. 

Simple. Straightforward. And you don't need to "include" all those topics in the review in order to "consider" them. 

      

"Lazy compliance" and unintended consequences

Last week, a friend of mine got a new electric stove. But that was only the beginning of the story.

Once it was installed, she learned that her new stove wasn't compatible with her cookware. I didn't know that was possible, but she explained it to me as follows: 

Turns out all electric stoves manufactured since 2018 need to meet a safety standard to reduce fire risk which cycles the burner off when a pan is not in contact with it. 

In complete contact with it; to work on my "sensi-temp" burners, pans have to have a completely flat bottom.

My only 2-quart saucepan was warped.

So, this morning I purchased a new one.  Stainless steel, $28, sigh.

But at least I can cook rice tonight!

This is the kind of outcome that makes people believe conspiracy theories. To her credit, my friend didn't start yelling that the stove-manufacturers must be in cahoots with the cookware-manufacturers to drive up sales—at least, she didn't say it around me—but I would have understood if she had. For myself, I began to wonder how such a defective outcome came to pass in the first place. 

Should I take a minute to explain what it is that makes this update to new stoves an impairment and not an improvement?

It's unexpected. Maybe there was coordination inside the kitchen-appliance industry, but I don't remember seeing any communication to the general public back in 2018 that stoves were changing in a fundamental way. Nor does my friend, obviously.

It requires additional actions from consumers, unrelated to the stove itself. When the auto industry introduced anti-lock brakes, they didn't insist that drivers start braking differently. Rather, they started from the known facts about how drivers react in panic situations, and redesigned the brakes to fit the drivers. By contrast, telling home-cookers that they have to buy new cookware to fit their new stoves is completely backwards. 

It requires additional and unexpected costs. This is basically the same point, hitting your wallet as well as your habits.

It's going to break. Every feature that you add to a product is one more thing that can break. But what happens if the sensor breaks on this new stove, while the shutoff-mechanism for heating elements remains intact? Then the stove will fail to detect a pan on the burner even when a pan is there, and the burner won't heat up. Result: the stove won't work. Any change that makes a product more fragile and less resilient is an impairment and not an improvement.

Sure enough, people hate it. There are long discussion threads on Reddit (see here, for example) about how to replace your brand-new "sensi-temp" burners with the old style, where to buy old-style burners as replacement parts, and so forth. Of course, buying old-style burners from some random site on the Internet means you have to spend even more, but plainly some people think it is worth the expense. 

Ironically, I bet that dismantling your stove to replace the heating elements with ones you ordered online may introduce some safety risks into your day; and yet I guarantee that when GE and other manufacturers did a safety analysis on this change before implementing it, they never considered the risks from home retrofits by angry customers. But this change to stoves has created a market and a community for exactly this kind of home retrofit. 

Why did they do it?

I wish I knew. I would love to see the FMEA carried out on this change before it was implemented.

It would be easy to blame ignorance. Maybe the engineers never actually do their own cooking, and didn't realize that this new feature could pose a problem. But that can't be the whole story, because GE (at least) provides an information sheet that warns explicitly about non-compliant cookware. You can download this sheet from the GE website here. (Also I have archived a copy locally here, in case the GE site is ever rearranged.) 

At the most basic level, the change appears to have been introduced in response to an update of the safety standard UL 858, "Household Electric Ranges." [You can buy the standard here.] Based on other informational material provided by GE, the thinking appears to have run something like this:

• Stovetop oil and grease fires are bad.
• To prevent them, we have to prevent pans on the stovetop from getting too hot.
• To measure how hot a pan is, we have to have a sensor touching the pan.
• But this approach could fail if the sensor doesn't touch the pan. So to avoid that case, if the sensor doesn't touch the pan we will cut off power to the burner. (According to this article, the stove should not cut off power completely; but my friend's experience was exactly that.)

It's logical, as far as it goes. But the whole line of reasoning exemplifies what another friend has called "lazy compliance": that's "where they make changes required for safety without bothering to make compensatory changes so the thing works as well as it did before."

Of course, you might think, So what? It's safer, and that's what counts. And to some extent, naturally that's true. But in the rest of our lives, we are often willing to make trade-offs where we sacrifice a measure of safety to secure nothing grander than convenience. 

For example, if all automobiles had to observe a strict maximum speed limit of 20 miles per hour, the number of fatal car crashes in a year would drop to nearly zero. Shall we take a vote? Never mind, I guarantee the measure would fail. Even though "car crashes are the leading cause of death in the United States for people ages 1 to 54," we'll never get a voting majority willing to eliminate those deaths by lowering the speed limit so far.

So why stovetops? And why didn't those of us who use stoves regularly get a vote? (If you remember last week's post, that's called "stakeholder engagement," and it's important.)  

I wish I knew. If you know more about it than I do, please leave a note to help explain.

     

Know your stakeholders

Change can be hard. This is true for many reasons; but at an organizational level, one of the main reasons is that the people involved in or affected by a change may resist it. Maybe the change will be too hard for them to learn, maybe it deprives them of benefits they were getting under the old system, or maybe … well, they could have all sorts of reasons. But if a few of them dig in their heels, the whole job of implementing even a minor change becomes exponentially harder.

Of course this is why change management is a field, and why stakeholder engagement is one of the main topics in that field. Over the years, practitioners have discovered that some methods work better than others to win people over to your side when you are trying to implement a change. Today there are organizations, like the Change Management Institute, that focus on nothing else.

Yesterday I had the opportunity to attend a webinar sponsored by the Quality Management Division of ASQ, which introduced the CMI's Body of Knowledge (CMBoK™). The webinar was presented by Douglas Wood and Sandy Furterer, both of ASQ. Of course, in a single hour the presenters could touch on only a very few topics, but I found it useful all the same. And for those already looking ahead to next year, Wood and Furterer promised they will be back in 2025 to present an overall change management approach for middle managers. Stay tuned! (Yesterday's webinar was part of a series that began last month with "The Faces of Change Management.")

I want to talk today about a tool that Furterer described for evaluating your stakeholders and planning how to engage with them. Conceptually it is very simple; but that simplicity makes it useful and powerful, because it is so straightforward to apply.

The tool is just a table that lists all the stakeholders involved in a particular change initiative. It has six columns, as follows:

Stakeholder: List each stakeholder by role, not by name. Use the structure of the subject process to identify every single role that is affected in any way. List them all. 

Type: A role that is directly affected or impacted by the change—one that actually touches the process or system or technology—is primary. All others are secondary.

Primary role: What does this stakeholder do in this process? Why are they listed here?

Potential Impacts/Concerns: What does this stakeholder care about? What are their fears, or concerns, or issues? What matters to them? Note that sometimes when you do this analysis, you'll find that one of your roles has several unrelated concerns. Maybe you identified "Customers" as a stakeholder, but it turns out that domestic customers have very different concerns from customers abroad. If that happens, it's a sign that you need two rows. You have just learned that Domestic Customers and Foreign Customers are actually two different categories of stakeholder.

Initial Receptivity: What does this stakeholder think about this change today? Where are they now? Are they for it or against it? Furterer's example included three ratings: Strongly support, Moderately support, and Neutral. (I suppose that for completeness your table should also allow for Strongly opposed and Moderately opposed, although naturally we'd all like to avoid that case if possible.)    

Future Receptivity: Here is the critical planning question: Where do you need this stakeholder to be (with respect to this change), before your plans can go forward? Note that you don't necessarily need strong support from every stakeholder. It all depends on the details. Of course you hope to avoid strong opposition from anyone; but for some stakeholders it might be enough if they are neutral, so long as they do not actively interfere. For others, if you do not have their strong support you will get nowhere. So work out what target state you need to achieve in the mind of each stakeholder. 

Now look at the differences between your last two columns: Initial Receptivity and Future Receptivity. Those differences tell you where you have work to do, before you can launch your change initiative in earnest. Identify which stakeholders you have to win over, and how far you have to win them over. Then look at what they care about, in order to figure out how best to approach them.

For example, if one stakeholder is currently opposed to the change and all you need is for them to be neutral, you can focus on addressing their fears. Find out why they oppose the change, and then show them how those concerns have already been considered in the planning. You might not get their active enthusiasm; but if you can show them that their fears are ungrounded then you may move them from opposition to neutrality.*

If another stakeholder is neutral—or even opposed—and you need their support, you have a different job. This time you have to show them how they will positively benefit from the change you have in mind. Answer for them the basic question, "What's in it for me?" Presumably you already have a good answer: you wouldn't be doing this change if it weren't on balance a benefit for everyone. But make sure that your stakeholders understand what it is before you ask for their support.

It's a simple tool. But it shows you at a glance what your stakeholder strategy has to be.  

__________

* I assume that their concerns really have been addressed in the planning already! If you've made these plans without even thinking about their concerns, maybe it's time to go back to the drawing board. 😀  

     

Why are you an auditor?

Over the years, I've worked with many third-party auditors. And often, over lunch, they start talking about their work. I like to ask how they got into auditing as a profession. Many of them started in very predictable ways: they worked as Quality managers or engineers for some company, and then made the sideways move into auditing. Sometimes it was because they wanted more variety in their work; sometimes they lost their jobs (or retired) and needed a new job that drew on some existing expertise. Many of the stories were variations on that basic model.

But one of the most interesting stories I heard was very different. This man's background had not been in Quality. He was an engineer, and a would-be entrepreneur. And he told us he had invented a product that he thought would sell itself.

Let me call him Amir. (I no longer remember his name, but I'm sure that's not it.)

Anyway, Amir quit his job, bundled all his savings into starting a new company to market his new invention … and promptly went broke. Oops. 

So far, it's not an unusual story. A lot of people try to strike out on their own and then fail. What was special is what he did next.

When his company failed, Amir did a systematic root-cause analysis of the failure. And he determined, after careful scrutiny, that the reason his company had failed is that he had no idea how to run a business!

So he set out to learn. He reasoned that the best way to learn how to run a company was to look at a lot of them, successes and failures alike. And therefore he sought out work as a third-party auditor, which would let him see a wide range of companies. His hope was that through his experience as an auditor, he could learn which management practices worked, and which ones didn't. 

His long-term plan was that, once he had saved up some more money and learned how to run a business, he was going to quit auditing and go back to restart his company so that he could finally market his invention.

I lost touch with him years ago, so I have no idea whether his career ever worked out as planned. But I was always impressed by the systematic thinking behind it.  

       

Have you used the Five Hows?

The August 2024 edition of Quality Progress contains a brief article about the Five Hows, and I'd love to know if you have used them yet. Leave me a note to tell me your story!

Most of us have already heard about the Five Whys: it's the simplest tool for root-cause analysis. I describe it in multiple earlier posts: for example, I explain how the concept works in this post here. And recently I applied it (purely as a demonstration) to a current question in American public policy in this analysis here. (I discuss it in other places too, including here and here.) 

In principle the Five Hows are exactly the same thing, except that instead of asking "Why did that happen?" you ask "How will we do this?" So they look forward rather than backward. They are for planning rather than diagnosis.

So far, so good. But the documentation I have found up till now has been awfully thin on examples. The article in Quality Progress is only one page long and it's written entirely at the level of theory. I have found a few other articles, but the information they provide about how to use Five Hows are not consistent with each other.

For example, this article that Dennis Henry posted in LinkedIn (from November 2023) treats the Five Hows strictly as a supplement to Five Whys: the idea is still to find the root causes of a problem, but Henry says that by asking "How ... How ... How ...," we can uncover detailed technical root causes instead of managerial ones.

This article from Quality One (undated, no author listed) still restricts the Five Hows to problem-solving, but applies them to brainstorming corrective actions. In other words, once you have found the root cause of a problem, you next ask "How ... How ... How ..." in order to fix it.  

Back in my first article on Five Whys, I worked an example that started with "My car won't start," and the root cause turned out to be "I didn't maintain the car according to the schedule in the manual." (This was a fictional example.) So in that case, the Quality One article would propose that I next ask, "How can I make sure to maintain my car according to the schedule in the manual?" The answer would probably involve adding reminders to my calendar, or something similar.    

Then there's this article in Medium, that George Spasov wrote back in February 2017. Spasov tells us that he actually invented the Five Hows method independently. And he also gives one detailed example of how to use it outside of traditional problem-solving.

His remarks on inventing the method are as follows:

This technique was developed by… well … me.

I was trying to figure out a way to achieve a very specific goal for my work. By being a heavy user of the 5 Whys I knew that there must be a way to reverse the process. To be honest, I don’t know whether somebody else had drawn the same conclusion as me. If you know a similar concept and the person behind it, I would love to hear about it and collaborate on the matter.

His example goes like this:

• How can I improve my brand positioning? By getting more quality exposure to my target audience.
• How can I get more quality exposure to my target audience? By communicating the right messages to the right people.
• How can I communicate the right messages to the right people? By first understanding what these messages are and who is my target audience.
• How can I understand what these messages are and who is my target audience? By first making an analysis of my existing clients and their interests.
• How can I make an analysis of my existing clients and their interests? By making a drill-down of this data from the analytics.

Someone might say that "improving your brand positioning" is a kind of "problem" that Spasov is solving with this analysis, but it's certainly not traditional problem-solving! This is somehow more like corporate strategy than it is like traditional corrective action, and I'm excited to think that Quality tools can be as useful in the boardroom as they are in the laboratory or on the production floor.

I only wish I had found more examples of this kind of usage.

So tell me your stories! Have you started using Five Hows? And if so, what kinds of problems have you used them to solve? Do you find them most useful to supplement traditional root-cause analysis? Or have you been able to deploy them—as Spasov did—to build corporate strategy as well?

Drop me a note. I'd love to hear from you!

   

Embrace your failure!

Earlier this month, I published two posts that were directly connected to current political issues in the United States, first here and then (as a follow-up) here. The political issue in question was illegal immigration. My focus in the articles was: first, to review the results of the Administration's recent "root cause" policy on immigration; and second, to suggest how the Administration's root cause analysis could have been improved—possibly to support a more effective policy, but at any rate to be completer than it was. And my overriding imperative was to handle the subject in a non-political way.

After I published the first article, a good friend argued that if I really thought I could keep the discussion non-political, then I was fooling myself. More exactly, her argument was as follows:

• Since Vice President Harris was put in charge of the "root cause" policy, any evaluation of the policy will necessarily be construed by others as an evaluation of her. If I say that the policy failed, readers will construe me to mean that she personally failed.
• Any personal evaluation of the success or failure of a candidate for the Presidency—if expressed during the middle of a campaign—will necessarily be construed by others as a partisan statement, either an endorsement or an attack. If I say that a candidate failed at something, readers will construe me to have attacked the candidate.
• Therefore I shouldn't publish such an article unless I am prepared for my writing to be used as artillery in the campaign by one side or the other.

We talked about it for a while, and I told her I disagree for at least two reasons. In the first place, I simply don't have that wide a reach. Mostly my posts are read by a small pool of people interested in aspects of the Quality business. And it's highly unlikely that anything I say about the technicalities of root cause analysis will drive you to change your vote. I assume you already know how you are going to vote, and nothing I say will make the slightest difference.

More importantly, the whole point of Quality analysis is that we can learn from our mistakes by analyzing them, so that we do better next time. In this sense, it is critical to embrace your failures, and not hide them! Because when we fail at something, it's never on purpose. Always we think we are doing the right thing; we have a plan of some kind, and we are following it with the intention of reaching a goal. This is what deliberate behavior looks like. But the consequence is that the very next time we have another goal, we'll do exactly the same thing—unless something stops us. Unless we intervene with ourselves to make a change.

If our plan is right and we succeed, of course that's fine. But if we fail—that's when it gets important to pay attention. If we fail, that means the plan wasn't right, which in turn means that there was something we missed when we analyzed the situation. If we aren't careful, we'll miss the same thing again next time and fail in the same way. Conversely, if we don't want to fail the same way next time, we have to figure out what we missed last time and take care not to miss it again.

This is why we have to own our failures and understand them.

As for the Administration's "root cause" policy on immigration, when I say that it failed that's no more than a historical fact. The plan was that by taking these actions, the Administration intended to bring about those outcomes. But in fact the actual outcomes were very nearly the opposite of what the Administration had in mind. (I explain the details in my article, and give links to external documentation that substantiates all the historical data.) 

OK, fine. This happens all the time, to administrations from both parties. There's nothing partisan in recognizing the facts. The next step should be to look at the analysis and find the flaw, so that the next time around will be better.

Of course, there are a lot of moving parts in any political situation. And right now we are facing an election. It is unlikely that today's Administration will launch a major new initiative in the last months of this year. Maybe something will be done next year, but at this point we don't know who will be responsible then. So it's hard to know what to expect.

But understanding your failures is still a really valuable thing to do.