Managing critical issues

We've talked before about problem-solving (see for example this post here), but what do you do when everything comes unglued at once—when a problem hits the fan, and suddenly you are fielding calls from reporters and attorneys when you haven't even gotten all the facts yet? Yes, you need a robust problem-solving protocol, but at the same time you need so much more than that! You need to manage the news cycle, because a careless or unguarded comment can turn public opinion implacably against you or ruin your chances in court, even though you haven't finished your investigation yet so you really don't know what happened!  

A few weeks ago, I attended a very thorough presentation on exactly this topic. The speakers were Shubhada Sahasrabudhe and Shalabh Tandon of QuRIuS Consulting LLC, the talk was sponsored by the ASQ Phoenix Section (704), and you can find a link to the YouTube video at the bottom of this post. The overall message is based on their recent book, Don't Panic, Pivot: Managing Critical Issues to Prevent Crises, and it is well worth your time and attention.

The authors start by explaining that a critical issue is not the same as a crisis, though it may cause a crisis if it is not addressed in a timely way. Major disasters can be caused by a succession of seemingly-trivial errors that were ignored, rather than set right; and the authors look at specific examples in some detail, including the Deepwater Horizon explosion, and the collapse of the Francis Scott Key Bridge. In each case, there were small signs in advance that something wasn't quite right. Based on this insight, they define a critical issue as follows: 

• An issue is any unresolved event that disrupts or hampers the normal operation, and that fails to meet the published or agreed-upon specifications.
• An issue is critical if it has time-sensitive impact (financial, safety, functional, etc.).
• And if not addressed urgently, a critical issue can become a crisis.  

Why does it matter? Well of course nobody wants to cause a catastrophic oil spill, or to destroy a major bridge. But the authors are careful to point out that the consequences of such a crisis affect multiple dimensions. Even if you momentarily set aside humanitarian concerns to take a cold-blooded look at the organization's own interests, a disaster hurts the organization in at least three areas: it damages operational efficiency, it can be ruinously expensive, and it soils the brand. (Regarding this last point, I have friends who check their travel plans to make sure they are not flying on Boeing planes, ever since the door blew out of Alaska Airlines 1282.*) So it is clearly in the organization's interest—even its narrowest self-interest—to watch for critical issues and correct them.

How do you do it? The authors sketch a method that looks, in broad outline, a lot like the protocol for handling an 8D. But there are a couple of critical additions.** 

1. Right at the beginning, in D2 (State the problem), evaluate whether this issue is critical. Make sure you understand the severity of the consequences, in case the issue blows up.
2. Then, during the impact assessment (typically also part of D2), make sure you address all relevant impacts: to operations, to finances, to stakeholders, and to your brand.
3. During D3 (Contain the problem), it is not enough to prevent the problem from spreading. You also have to contain the brand damage by making whatever public statements are necessary and appropriate, consistent with what you know at this point. Never speculate in public! Stick to the known facts, and promise you will come back with the full story when you have it. 
4. As you proceed through D4 (Find the root cause) and D5 (Define corrective action), validate your corrections before implementing them. Make sure that they address all affected stakeholders, and that they do not inadvertently cause further harm!

Perhaps the biggest change is that the authors break out Communication as a separate step between D6 (Implement corrective actions) and D7 (Assess risks and learn lessons). This addition confirms the point that harm to the brand can be as damaging as harm to customers or other stakeholders. And the authors give clear advice for all communication: make it timely, make it clear and unambiguous, and make it consistent. All of these points are important, but it is easy to overlook the last one. Or rather, it's easy, but don't overlook it! If you say one thing today and then backtrack tomorrow, people will think you are hiding something and assume the worst.

Finally, the authors break D7 (Assess risks and learn lessons) into two parts, because there is so much important work that has to be done there. On the one hand, they insist on the critical importance of a detailed After Action Review. But then you also have to implement Preventive Measures so that the problem can never, ever happen again. Both steps are important, so they list them separately to make sure neither gets shortchanged.

After all this, there's still a lot in their presentation that I haven't even touched. A single blogpost can do only so much. But check out the YouTube video below; if that inspires you, check out their book. There's a lot of detail here, and a lot of process to follow. But if you ever have to deal with a "critical issue"—even once!—you will be grateful to have a defined process that helps you keep your head amid the tumult. And of course implementing a system will be cheaper than trying to wing it, possibly by orders of magnitude. It's good to be prepared, and these authors can help prepare you.  

__________

* See also this post and the ones following.

** When I worked for Bosch, we had a similar procedure for similar circumstances. But this one is published, and to my knowledge the Bosch procedure has not been published yet. So I am happy to discuss this procedure.  

           

Managing quality fads

Recently I've been reading a book about the history of our field, Robert E. Cole's study, Managing Quality Fads: How American Business Learned to Play the Quality Game. The book came out in 1999, so whenever Cole talks about "current practice in industry today" I had to remind myself to reset my mental frame by a quarter century. But mostly the book is a history. Cole examines the period when American manufacturers learned to rethink their approach to the Quality discipline, in the face of strong and successful competition from Japan. He starts his story in the early-to-mid-1970's, when American manufacturers first began to face serious competition from Japanese firms offering superior product quality. Then he brings it up to "the present day" (1999), by which time the awareness of Quality had become normalized in American industry and American manufacturers—some, at least—could once again compete with their Japanese counterparts on a level playing field. It's a big story, with a lot of moving parts. And ultimately Cole organizes his material to address one large, overarching question: How do organizations learn?     

The book is not one to read quickly. Cole writes for an academic audience more than for a business one, and there is a lot of detail. Often it seems that Cole is telling us everything he knows about a topic, even when he could make his point more clearly by saying less. And there are many places where he describes a Quality initiative in a certain company, only to start the next paragraph by saying (in effect), "Of course there were other people in the same company doing the exact opposite." It takes him a long time to paint the full picture.

In one sense, though, Cole's presentation is relentlessly true to the facts where a clearer storyline would distort them. When American firms were first successfully challenged by Japanese companies that reliably produced higher quality products, they didn't know what hit them! Cole makes it clear that the American manufacturers didn't understand what made the Japanese products better—and not only did they not know how to improve their own operations, but they didn't even know what "improve­ment" might mean. Cole's slow, methodical "on the one hand ... but on the other hand" exposition can be frustrating if you want answers: What finally worked? How do organizations learn? But the players at the time felt that same frustration too. There were a lot of false starts, a lot of "quick-fixes" that went nowhere, and a lot of confusion all around. Cole's very deliberate approach to his story helps the reader to feel that, and to appreciate it in retrospect.

The other advantage to Cole's presentation is that it is rich in detail. There are a lot of little nuggets that are worth exploring for their own sakes. Over the next few weeks I plan to pull out some of these nuggets and write about them. Oh, I'll write about other things too. But I expect to come back to this book several times in the blog, before I finally put it back on the shelf. There is a lot here.

For today's post, I'll limit myself to summarizing Cole's final conclusion, in an abbreviated form. (I can write another post later with more detail, if there's interest.) Cole introduces the last section of his last chapter in a way that feels distinctly unpromising:

[The] question is often posed: how do managers learn to identify best practices and diffuse them across an organization? Survey data suggest the answer is, not very well.*   

But then he describes the approach which, in the long run, seemed to be the most productive. He focuses his results in two ways. 

• First, his attention is on large organizations with many divisions: partly, no doubt, because those are the companies he got to know through his consulting practice; but also, I think, because those present the most difficult case for organizational learning. The size of such companies means that any organizational transformation has to be adopted by many people; since the number of affected individuals is large, progress is necessarily slow and the institutional inertia is enormous.
• Second, he is writing specifically about how large corporations learn "under conditions of uncertainty and incomplete information"**—exactly the conditions that characterized the Quality challenge from Japan. 

In that context, Cole identifies the most robust approach to be a collaboration between a central function at headquarters and implementation in the "periphery" (i.e., the operating divisions).

• The central function sets high-level goals, targets and incentives, but does not specify exactly how they should be implemented. This is because the prevailing "uncertainty and incomplete information" mean that headquarters doesn't really know how they should be implemented!
• The operating divisions figure out methods that work for them. Since they are the ones who actually do the work, they will have a much better understanding than headquarters does of what methods are practical and what are not.
• But then the central function monitors the innovations and the results, "to identify, synthesize, and diffuse best practices; otherwise the mutation process [i.e., local innovations in the operating divisions] will lead to dilution and degeneration."***

During the twenty or thirty years when American companies were relearning how to think about Quality, there were many different approaches. But this one seems to have been the most robust, involving shared responsibility across the organization: with central guidance and local adaptation. 

In fact, Cole argues that the same center-and-periphery topology describes how Quality knowledge spread across the country as a whole, from early-adopting industries even to those that were more protected from the challenge. But that, as they say, is another story. 

__________

* Emphasis mine. The quote is from Robert E. Cole, Managing Quality Fads: How American Business Learned to Play the Quality Game (New York, Oxford: Oxfor University Press, 1999), p. 243. 

** Ibid., p. 246. 

*** Ibid., pp. 245-246.      

           

Goals that your people understand

You're at work, it's the middle of the morning, and suddenly everyone is called into the largest room you have, for a presentation. The CEO and senior management have just finished their new strategic plan, and they are going to share it with the rest of the company.

Do you get anything out of the next hour? Or do you just spend the time trying to look awake?

I've been in too many presentations where the latter was true. The CEO starts off by saying, "We have two main goals over the next three years: to become the number two supplier of refrangulated widgets, and to reach a market capitalization of twelve gazillion dollars. Here is how we are going to do it ...." Then the rest of the speech might as well be in Babylonian, for all that I under­stand it. I'm sure the CEO is following advice he read somewhere, that he should make all employees "partners" in the company's "strategic thinking." But because the message is in terms I don't know, the only thing I get from the meeting is that I am now an hour behind on the day's work.

It doesn't have to be like this.

What does a better way look like?

There is another way to roll out corporate goals, one that makes them meaningful to every employee. It takes a little more work up front, but this is the kind of work that the management team is paid for in the first place—so it's fair to ask them to do it. Also, if they run into problems in the preliminary setup, that's a key indicator that there are problems with the strategy itself. So it is worth the effort.

The method is called Hoshin Kanri (Japanese: 方針管理, "policy management"), and it draws a straight line between the company's long-term goals and the work I have to do tomorrow. This helps me understand the company's goals, because I can see the effect they have on my job in particular. But it also helps me see how my job fits into the big picture.

Ironically, I saw the method used long before I learned it had a name. I just thought of it as "The way That Company does goals," and I wondered "Why doesn't everyone do this?" But of course I couldn't ask my next employer, "Why don't we do goals just like that other company I used to work for, that you've never heard of?" It was a relief to learn the name.

How do you do it?

The whole process unfolds in several steps. Some people use a special matrix to organize their work, but I won't do that here. The logic is the important part, and you can organize it however you choose.

Define your strategic goals

First, you have to define your long-term strategic goals. Where do you want your company to be in five years? Be careful not to define too many goals, but focus on the handful that matter.

You may also identify your most important operating imperatives at this point. But again, be careful not to cloud the picture with too much noise. (For the distinction between strategic goals and operating imperatives, see the discussion in this post, under "What is a strategy, anyway?".)

How are you going to get there?

"A goal without a plan
is just a wish."

Next, plan out very concretely what you have to do to reach those goals. A familiar aphorism attributed to Antoine de Saint-Exupéry says that "A goal without a plan is just a wish." So define the actions you will have to take, and the milestones that will prove you are on track.

In the first instance, this means defining annual goals as progress towards your long-term targets. But it also means spelling out what your goals will look like, concretely, when you have achieved them, and then identifying what it will take to cross the gap from Here to There. If you want to be—let's say—the number two supplier of refrangulated widgets, what does that tell you about your warehousing and logistics systems? What level of performance do they have to reach, in order to support the overall corporate goal? But also, what is their performance today, and how far does it have to improve? Can you spell out achievable interim milestones towards which your logistics and warehousing personnel can aspire, that will get them where you need them at the right time?

And of course reaching this goal isn't even primarily about warehousing and logistics, though doubtless those play an important role. Every single department in the company should contribute to these goals somehow. So the CEO has to delegate to the respective department heads the task of working out maps for each of their functions which will support the common strategy.

As an aside, you should check that each department map is consistent with all of the others. If Engineering plans to develop the Next Generation Widget in Year Two using a special technical tool that IT doesn't plan to install until Year Four, somebody has to change his map!

Cascade downwards 

It doesn't stop there, but the next steps are pretty straightforward. You as a department head (or functional VP, or whatever your title is) now have a strategic map for what your department has to achieve in five years, and also in this year. Take it to your section managers or group leads, and go through the exact same exercise. Ask each of them to spell out how their group will contribute to meeting your goals. Notice that they don't have to reach all the way back to the company's goals, because your goals have already been aligned with the higher level. So as long as they support achieving your goals, they are also supporting the company as a whole.

Cascade this exercise down through the company organization, all the way to the shop floor. (Yes, this is exactly the same procedure I recommended three years ago for business continuity planning.)

The result is that I, as an employee, have personal goals to achieve that are directly related to my job. But if I achieve them, that supports my supervisor in achieving his goals, which in turn supports the department manager in achieving her goals, which ultimately rolls all the way back up to supporting the company in achieving its strategic targets for the year.

End of the year

Then at the end of the year, you evaluate how you did. This means everyone, at all levels. But the point isn't just to assign a grade, like in so many performance review systems. The idea is rather to carry out a root cause analysis on each missed target, to learn why it was missed, and then to update your plans with this new information. This way you—individually and as an organization—keep in touch with reality, learn lessons from experience, and adapt your strategy pragmatically.

I will admit that it is hard to remember to do this last step. Even when I worked at a company that did all the rest of it, that step was sometimes missed. But of course it is important.

           

Make your matrix certificate work

Last week I introduced the concept of a matrix certificate, and I thought it could be useful if I explained the approach in a little more detail. Mostly the idea is self-explanatory, but it is worthwhile to keep one or two points in mind so they don't trip you up.

When ISO first introduced its management system standards, each certificate was tied to a specific location where specific work was done. So the certificate was printed with an address and a scope statement, as in the example to the left.* 

But many organizations have more than one location, and often the processes are identical from one site to the next. There is not a lot of variety, for example, between this McDonald's and that one. So organizations began asking their Certifying Bodies** if there were any way to group multiple locations under a single certificate. Since the CB's, for their part, had to manage a lot of redundant information for all of these sites, they were keen to agree. And so CB's began to introduce the "matrix certificate."

A matrix certificate works just like a standalone certificate, except that the address and scope are replaced by a matrix: Site 1 does this kind of work, Site 2 does that kind of work, and so on. There is no requirement for a literal matrix on the certificate itself, so long as the information is there. A matrix is a convenient format when there is a large number of sites to consider. When there are only two or three, the CB might simply use paragraphs, as in the example to the right immediately below.***  

The other place you see a genuine matrix is in the internal paperwork that supports the certification: at the CB, and at the organization itself. These internal matrices look something like the one that I show at the bottom of this post, and they correlate the infor­mation needed to manage the audit program. This starts by listing the sites and their scopes or func­tions, just like on the certif­icate. But then the internal matrix also tracks how many people work at each site. This is because there is a formula used by all the CB's to determine how many audit-days**** they have to schedule at each location. The formula uses both number of employees and type of work as inputs to the calculation: a big plant needs more audit-hours than a small plant, and manufacturing requires more attention than HR or sales. Finally, the matrix should track how long the audit cycle is for each site. Normally with a multi-site certificate, the company headquarters is audited every year; also, manu­fac­turing is likely to be audited every year. The example I give below has one site for each of those functions. But then it also shows three sites that mostly do engineering or product design, that follow exactly the same procedures, and that are therefore more or less interchangeable. In order to reduce the overall audit costs (and to simplify scheduling), the CB has put each of these on a three-year cycle, so that they rotate. In any given year the CB plans audits in three locations; but over the three years before recertification, they visit all five sites.

On the whole, using a matrix certificate is a good way to control your certification expenses if you are in a situation where it works for you. But of course there are risks. The main risk is that one of the critical entries in your matrix will change: for example, you might have heavy layoffs at one site, or (conversely) hire a whole new department. Either way, you have to make sure to report the change to your CB in a timely way, so that they can recalculate your audit days. One way or another, this might change your plans for the year.

Or you might move functions from one site to another. Since each function makes its own contribution to the calculation of audit days, this move might make a difference to the result even if the number of employees involved is not high. A specialized technical function, for example, might employ only a few people; but it might require a lot of Quality equipment to make sure it operates correctly, and in some cases all that infrastructure might have to be audited.

Finally, there is a risk that two different sites are supposed to be doing the same work according to the same procedures, but one site decides to implement local improvements without telling the other. I have seen this happen, where an organization had two Distribution Centers. One was more or less a glorified shipping dock at the far end of a building that did a lot of other work; the other was a pure Distribution Center with no other functions. Back when the organization first codified their written procedures, someone wrote a single set of logistics documents and told both organizations to use them. But in the intervening years, the Site Manager of the standalone Distribution Center brought in a lot of equipment to modernize his operations. It was exciting to visit, because every time I arrived they had improved something new. But somehow the word never got back to the first operation. I had workers from that one tell me with a straight face, "We have exactly the same procedures they have there," when there was no longer anything in common. And I had to explain, "No you don't. And at the very least your documentation has to be updated to reflect that reality."

Note that when changes like this take place, it can undermine the logic behind a matrix certification. The justification for auditing Site 3 in place of Site 4 and Site 5 is that they follow the same procedures in all three sites so you'll see the same evidence anyway. Once that is no longer true, it is harder to keep down the number of audits.  

It is also true that breakthrough improvements on such a scale are mostly the exception rather than the rule. And if there is a chance for your organization to make breakthrough improvements, having to replan your audit program is a small price to pay!

__________

* I found this illustration online by searching for "sample iso 9001 certificate." I have no professional, personal, or financial connection to the organization in question. 

** A Certifying Body (CB) is the registrar that send out your external auditor, manages the audit paperwork, and issues your certificate. There are lots of CB's in the world. If you look at the certificates that I posted above as examples, the first is from TÜV SÜD, and the second is from DEKRA. These are both well-known CB's. Just by coincidence, I have never worked with either one.  

*** Again, I found this illustration by searching online and have no connection with the company. 

**** One audit-day means one full day of auditing by one auditor. So four audit-days might mean one auditor for four days, or two auditors for two days, or one auditor for three days plus another who joins him for only one of those days, or any other combination that adds up to four.     

           

How do you certify a big corporation?

Last summer, in the middle of a podcast about something else, Kyle Chambers raised a question: how is it possible to certify a really big company to a standard like ISO 9001? His point was that really big companies have so many parts that they can't all play together. (I mention the podcast in this post here.) Kyle might have meant the question rhetorically, but of course he is right. If you have scores of locations spread across multiple continents—engaged in dozens of lines of work—how can you possibly coordinate them all into a single management system? How can you possibly certify anything so complex?

You can't. So you break it in pieces.

More exactly, you divide your really big company into sub-units of a useful size, and then make each sub-unit responsible for its own certification. Then in your sales and marketing literature you speak of the company as a unified whole, announce that "Con­glom­erated Enterprises has been proudly certified to ISO 9001 since ...," and follow with the date of the first certificate that came through.

How big is "a useful size"? It really depends. I've seen it done several ways.

In general, there are two competing pressures at play in determining the right size for an entity to serve as the scope of certification.

• On the one hand, you don't want the scope too narrow, or you'll have to pay for too many audits. In other words, if three offices that are all in the same city all do exactly the same kind of work, you can save some money by letting them share a certificate. You pay for less overhead at the Certifying Body, and you pay for fewer audits (because all three offices are doing the exact same thing). This all looks good on a balance sheet.
• On the other hand, you don't want the scope too broad, because there's always the risk that someone goes crazy one day. If you have a hundred locations all sharing the same certificate, and someone in a tiny office way out in Far Foodle starts violating an important policy, the next auditor might rate it as a Major Nonconformity. Then that Major might put the certificate at risk for all hundred locations!

Where you draw the line while balancing these two imperatives depends a lot on your organizational culture. I've worked for one multi-site operation whose corporate ethos was entrepreneurial, and who had created a number of sites by acquisition. So there was a distinct chance that two sites might not be on the same page. For that company, each site was strictly responsible for its own certifications. The company had a blanket contract with a CB, because they got a volume discount. But inside that blanket contract, we were on our own. I made the arrangements for my location, but not for the others; I worked with the auditor and tracked the findings for my location, but not for the others. We never had a crisis where one location risked losing certification, but the company's management took no chances.

But then later I worked for another company that bundled eight sites across the United States all into one certificate. We supported the same product line, and we were all in the same geographic region. So the company decided that was enough commonality that it made sense for us to share a certificate, and we could sink or swim together. I made the arrangements for eight locations, tracked findings for eight locations, and flew around the country a fair bit to support audits when they happened. 

This meant I carried out eight internal audits a year, but not nearly so many external audits. We had a "matrix certificate," which meant that the CB did a sampling every year: they always audited headquarters, and they always audited our one factory, but then they would pick one or two other sites randomly and leave it at that. Over the years, of course, they ended up visiting every site; but every spring I had a long discussion with their scheduler to agree where they should go. 

"You visited A last year, and you visited B the year before, but you've never audited C. How about seeing them this year?"

"Wait, we've never been to C? What do you even do at that site?"

"It's basically the same work as B, so I don't expect any significant findings. But you haven't been there yet, so it might be good to visit."

"Sure, I guess. How many people work there ...?"       

As long as the processes and systems really are common across locations, this can be a useful way to proceed. Next week I'll say a little more about how matrix certificates work.