Doesn't anybody know how to play this game?

Quality professionals have to know at least something about a lot of different fields. 

• We don't have to be logicians, but we have to know enough logic to work through a 5-Why analysis or to build a cause-and-effect diagram. 
• We don't have to be statisticians, but we have to know enough statistics to manage processes with a control sheet, or to sort failures with a Pareto chart. 
• We don't have to be experimental scientists, but it helps if we know something about the design of experiments.

We also have to understand organizational behavior and management. Most of the improvements we identify can't be implemented without the help of other people, generally people who don't report to us. So we have to know when and how to introduce changes so they can slide into place with the least disruption. It helps to develop a feel for the organization we work in, so that our colleagues in other departments are disposed to support us rather than to block us. 

That's why I was so startled at the very casual way I learned that ASQ had recently updated the procedure to elect leadership committees (or "Boards") for local geographical sections.

• I first heard an announcement (with no special urgency) that there would be a training class on the updated procedures on July 15. I was going to be out of town that day, so I made a point to listen to the recording as soon as I got back.
• Sure enough, I listened to the recording on July 23. It outlined a complex new procedure but specified no deadlines.
• That evening there was a general leadership meeting, and someone asked what the deadlines were for the new procedure. No one in the meeting knew, so the organizer took an action to find out and let us know.
• Only the next day, on July 24, did the meeting organizer send us a screenshot that the first deadline for the new procedure had been on July 8—more than two weeks earlier!

The discovery that we were already late caused a little consternation among our regional leadership. Our contact in leadership found and supplied two documents to clear up the confusion. Unfortunately they disagreed. One said to hold elections for two weeks, starting in October, with a slate of candidates compiled in August. The other said to hold elections for four weeks, starting in September, with a slate of candidates compiled in July.

Some time later I tracked down a copy of the procedure document itself. Turns out the new version had been released back in February, and the first deadline for the election process is actually July 1. But the first time anybody was told about it was in a training class two weeks later that didn't specify deadlines. As I say, the notification was very ... relaxed.

OK, you might say, so it was a simple bureaucratic mix-up. No big surprise. These things happen all the time. Why should it matter to you so much?

And my real answer is an emotional one, not a reasoned one. But we're ASQ! We're supposed to know better than that. We're supposed to be better than that!

But are we? On reflection it's not so obvious, for at least two reasons.

First, ASQ is an organization like any other. It has to hire staff, like any other. ASQ's members are Quality profes­sionals, but there is probably no require­ment that the Society's profes­sional staff all spend a certain number of years in the Quality trenches before coming onboard. Such a require­ment would be, at the very least, highly unusual; it would also force ASQ to pay well above market rates for office staff. 

Second, even seasoned Quality professionals sometimes make bone-headed mistakes. I know I have.* What we hope for, when working with Quality professionals, is not that they be perfect, but that they be ready to examine their own mistakes openly and dispas­sionately in order to learn from them. And naturally we hope also that they bring with them the memory of past lessons learned, perhaps in the form of a checklist or procedure, so that they don't have to learn from any particular failure more than once. But to ask that they never fail is simply to ask too much.

Maybe ASQ can carry out a root-cause analysis on the mistakes in this roll-out, and then assign long-term corrective and preventive actions. In other words, maybe ASQ can use the current muddle to improve the process for handling updated procedures. That kind of outcome could turn today's jumble and disorder to advantage. Let us hope.

__________

* Tip of the hat to the memory of the great Graham Chapman, in "The Mouse Problem."     

           

Can you be TOO optimized?

There's an old story about a wise man that has some relevance for bloggers as well.

Once upon a time there was an old man renowned for his wisdom. Whenever a discussion got tangled and tempers rose, he always told a parable that resolved the question perfectly. Finally a little boy asked him, How could he unfailingly pull out a story each time that summarized the issue so well? "Ah," said the old man, "you don't understand my method. I don't ransack my brain looking for a parable to match each new conversation. Rather, I introduce a topic of conversation for which I already have the perfect parable."

Blogging is a little like that. We bloggers are sure we have the right answer, whatever the question. And by the time you read a post all the way to the end, we've usually made the point pretty convincingly. It almost looks like we're right about everything. (Or I hope it does. 😃) But then, ... who picked the topic for the post in the first place? We did! So of course we're going to pick topics where we think we can win the argument.

But I've been thinking recently about a plant I encountered a few times during my career, where things seemed slightly off-kilter but I could never tell why. I didn't work there, and they weren't part of my normal responsibilities. But I visited a couple of times, to support audits or for other reasons. The audits turned up findings, as audits always do; and the findings were always addressed in the usual way. Somehow, though, I never got the sense that we uncovered anything more than surface issues. It felt like there was something more basic that we were missing.

This plant was located in a town I'll call Riverville, so I can refer to the place as the Riverville plant.

Recently I've been formulating a hypothesis that might account for part of the situation there. So I want to describe the hypothesis, and ask whether you think this could pose a problem in real life? I won't go into a lot of details about how things were at Riverville, if only so that I don't identify it too plainly. But let me know if you think the circumstances I describe could cause some related mis-fires.

Then if it turns out that I'm all wrong, I can go back to questions where I (think I) already know the answer in advance. 😀  

The Riverville plant

Visiting and auditing

The Riverville plant had been in operation for many years. The people were deeply competent, and committed to their work. Also, because these things happen, the plant had undergone multiple changes of ownership throughout the decades it had been in business. Sometimes the new owners ran it as a standalone operation. But occasionally the new owners wanted it to integrate into a larger ecosystem of other businesses that they had also acquired. When I knew them, Riverville had been recently acquired by Octopus Enterprises (not their real name).

Despite the acquisition, though, the plant never felt like the other Octopus plants that I had seen. When visitors started to quote a lot of the normal Octopus manage­ment terminology, I thought I could see the Riverville old-timers smile to them­selves, as if to say, "Sure, we'll play along until you go home. But that's not how it really works." When I audited, I kept turning up forms that I'd never seen at any of the other Octopus plants. "Don't you use the standardized Octopus forms?" "Oh sure, sure, ... mostly we do. But that one's an exception because of the special way we handle [topic] here. It's authorized, though. Let me show you the procedure document!"

And there was always a procedure document to back it up. There were so many procedure documents, in fact. Sometimes I thought it would be an interesting project to collect all of them and paste them together, to try to get a picture of how the whole plant functioned. But of course I couldn't. As I said, I never worked there regularly, so in the normal course of things I would have had no business even raising the question. And in the absence of a total breakdown of their system—which never happened during the time I was familiar with the plant—I could never have made an argument to justify the time and effort. Besides, mostly the folks at Riverville were able to provide the right management deliverables back to Octopus headquarters when asked, and mostly they were able to get their regular work done in a routine way.

Fully optimized

As for those forms? Oh, the forms were awesome! Someone had put a lot of time into these. There were links to data sources on the internal network, so that when you needed to fill in fields 5-15 you just clicked a button on the form. Then you added a little more data by hand and clicked another button, and right away the form routed itself to the next person in line. None of this was managed by some overall data management tool. It was all hard-coded into the forms with URLs that pointed to archive repositories where project information was stored in suitably-structured Word and Excel files. 

Rebuilding the engine in flight.
This is not recommended.

In fact, the forms were the key to my recent hypothesis. I think the Riverville plant was too optimized to change! They had worked together for so long that they had optimized every single transaction in a large and diverse factory. But they optimized them all according to the outlines of the old Riverville management system. If a new owner let them run themselves, and just showed up at the end of the year to collect the profits, there was no harm done. But when Octopus Enter­prises tried to make them integrate with the Octopus manage­ment system, the only way they could do it was to run two systems in parallel. They couldn't stop using the old forms, because everyone relied on them. They couldn't stop using the old data­bases, because the forms pulled data from them. They couldn't stop working in the old way, because everyone in the company depended on every step of the old system. To replace the old Riverville system with the new Octopus system would have meant rebuilding the airplane engine in flight. 

I was never able to dig deeply enough to prove that the Riverville personnel were running two systems in parallel—I mean, as opposed to adapting the Octopus system by adding "just a couple" of the old Riverville forms—but it would make sense of my general observation that somehow things were a bit off. As we discussed last week, running the Octopus management system as a Potemkin system would have been a perfectly natural response, if the Riverville management felt that they were being forced to make changes that didn't help them any. 

The problem, of course, is that working in two parallel systems takes twice as much effort as working in one. Also, if you have data in two places, it is almost impossible to keep them both consistent. Whatever options Riverville faced, this one cannot be called The Easy Choice.

End of the Bronze Age

My thinking about Riverville has been supported in an interesting way by an article that appeared in LinkedIn around the end of March. The author is Marco Nutini, a risk-management expert from Brazil, and the title is "1177 BC Called. We're Not Listening." 

It's a fun article, and not long. Read it, if you have a few minutes. Nutini starts off summarizing his thesis with admirable brevity:

In the late Bronze Age, the Eastern Mediterranean was a marvel of interconnection. Egypt, the Hittites, Mycenaean Greece, Ugarit, Cyprus — linked by trade routes, diplomatic marriages, and supply chains that moved copper, tin, grain, and luxury goods across vast distances. It was, by the standards of the era, a globalized world.

Then it collapsed. Not from a single cause, but from all of them at once.

His point is that the highly interconnected world of the late Bronze Age was optimized for current circumstances. Assuming that the world stayed at peace, that the rain fell reliably, and that no major population centers were wiped out by earthquake or volcano—assuming all that, the world ran just fine. But when those assumptions failed—when drought, famine, and earthquake came, when cities revolted and the Sea Peoples were landing on every shore—the finely-calibrated economy of the late Bronze Age could not withstand the shocks. It fell apart, collapsing into the Greek Dark Ages. Optimization for normal times is not the same thing as resiliency in trying times.

Admittedly, having your factory bought by Octopus Enterprises shouldn't be as devastating as having your seacoast raided by pirates, or your island explode. But either way, I think there is a risk that over-optimization can make you fragile and unable to adapt when circumstances change.

If I'm wrong, feel free to tell me so! 

            

Action and reaction

How do companies learn?

We've discussed this question on and off for years, and mostly it's not easy. Two years ago, in the middle of a series of posts on Boeing, I wrote about data falsification scandals at Toyota and suggested that it can be phenomenally difficult for a company to learn new attitudes. Two weeks later I backed off to say that it's possible but not easy. And just last month I wrote about Robert Cole's study, Managing Quality Fads, about how American companies learned quality methods from the Japanese during the 1980's. So yes, it's possible but not easy. 

That conclusion just brings us back to the original question: If it's possible, then how? And here it can be useful to look at success stories—companies that did learn a lot from others, and improved their operations accordingly. One advantage of Cole's book is that he gives a lot of detailed data about the period he describes, including a number of case studies. Of these, the first big success in adopting the new quality methods was Florida Power and Light (or FPL).

What made their success possible?

Cole sets the stage by explaining: "FPL [began] its quality improvement ... in 1981. In 1985, it became the first large American company ... [to start] learning directly from the Japanese. It entered into a deep exchange relationship with Kansai Electric and other ... Japanese companies[,] and worked closely with Japanese professors...."* But there were a number of special factors that supported FPL's quality initiative.

• FPL was in the same line of work as Kansai Electric, but they were not direct competitors. So neither company feared accidentally revealing trade secrets to the other.
• FPL and Kansai Electric used the same equipment—they both used Westinghouse-designed nuclear plants. So FPL trusted Kansai's reported metrics, rather than waving them aside as "apples and oranges." When they learned that Kansai's Mihama plant reported 10% as many quality problems as FPL's Turkey Point plant, they looked right away for management and operational differences that could explain such different performance from the same infrastructure.
• FPL and Kansai set up an extensive program of travel and visitation, so that personnel from each company could build personal contacts with their counterparts.
• Crucially, the CEOs of the two companies built a strong personal rapport. It soon became flatly unacceptable to express anti-Japanese sentiments at FPL.**   

What did they do?

With this background as a framework, FPL adopted Kansai's Total Quality Control (TQC) measures almost intact. The successes were dramatic enough that four years later (in 1989), FPL was the first non-Japanese company to win the Deming Quality prize.

Perhaps more to the point, FPL's success got the attention of other American companies. Soon FPL was giving seminars on quality improvement; and in 1986 they spun off a subsidiary (Qualtec) as a for-profit consulting firm. In the end, Qualtec could not keep up with the demand for its services, so FPL sold it to the Marshall Group in 1995.

What happened next?

Newton's Third Law of Motion famously says that to every action corresponds a reaction, and I'm not the first author to apply the same phrase metaphorically to human organizations as well. In 1989, James Broadhead took over as FPL's new CEO; and after the company won the Deming Prize, he began to dismantle much of the quality superstructure and documentation requirements. He argued that this structure and these requirements were too extensive to be cost-effective, and therefore that they were inconsistent with FPL's overall business objectives.

But it is important to understand that Broadhead did not rip out the company's quality measures root and branch. And FPL's overall quality levels did not suffer under his administration.*** What he did was to integrate the quality measures into normal operations, so that they became "just how we do things" rather than adding them as special steps administered by the Quality Department. As that integration took place, he could also shrink the size of the Quality Department because there was no longer a need for so many extra staff. He found that FPL had implemented a lot of documentation requirements because they were demanded by the Deming Prize; but in fact, no one ever looked at the documents again after the prize committee left. So he eliminated those requirements that had no use. He continued to support benchmarking, self-managing teams, process reengineering, and employee empowerment. So while the American business press described Broadhead's administration as a massive rejection of Japanese quality principles, it was nothing of the kind. He kept what worked—all the measures that reduced downtime and outages and disruption of service—because they worked! All these measures were profitable. He just made them unremarkable enough that they no longer drew special attention.  

Points to take away

The original question was, How do companies learn? So concretely it is fair to ask, How much of FPL's experience can apply to another company?

Obviously FPL faced special circumstances that gave it almost a perfect framework for learning from someone else: for starters, the partnership with Kansai, who was not a competitor and who used exactly the same equipment.

But I think there are three points that have a wider application, and it is important to remember all three.

1. Any learning initiative—really any change initiative of any kind—has to have strong and consistent executive support. The forces opposing change are always powerful; so without reliable pressure from the top, it is likely that nothing will happen.
2. 
   The more widely you spread information about the initiative or the new way of thinking—and the more personal you make it—the better your success will be. One of FPL's big successes was their travel initiative, that brought so many of their employees face-to-face with their counterparts at Kansai. Once they made friends, it was easier to talk about problems at work—and to listen to the answer.
3. Unless there are external measures to guarantee the change is permanent (for example, if one company has bought another), there will be a backlash in time. Don't waste effort trying to fight or avoid it. The better strategy is to make sure that all the most important parts of the change are fully embedded into normal practice by the time that the backlash arrives. Let the new managers pull down some posters or eliminate other symbolic reminders of the change initiative. But make sure the new methods themselves are so routine and so profitable that no one thinks of changing them.   

If you remember all three points, is that enough to make it easy for your company to learn? Probably not. But they are sure to help.

__________

* Robert E. Cole, Managing Quality Fads: How American Business Learned to Play the Quality Game (New York, Oxford: Oxford University Press, 1999), p. 66. This whole story comes from the same work, pp. 66-71. 

** If I remember the early 1980's correctly, FPL's attitude could not yet be reliably assumed across the country as a whole. 

*** So James Broadhead's career at FPL does not foreshadow that of (let's say) Harry Stonecipher at Boeing, a few years later.   

           

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