Featured Product
This Week in Quality Digest Live
Quality Insider Features
Master Gage and Tool Co.
Why it matters for accurate measurements
Ian Wright
MIT and ETH Zurich engineers use computer vision to help adjust material deposition rates in real time
Scott A. Hindle
Part 4 of our series on SPC in the digital era
Etienne Nichols
It’s not the job that’s the problem. It’s the tools you have to do it with.
Lee Simmons
Lessons from a deep dive into 30 years of NFL and NBA management turnover

More Features

Quality Insider News
Exploring how a high-altitude electromagnetic pulse works
High-capacity solution using TSMC’s 3DFabric technologies
EcoBell paints plastic parts with minimal material consumption
August 2023 US consumption totaled $219.2 million
New KMR-Mx Series video inspection system to be introduced at the show
Modern manufacturing execution software is integral for companies looking to achieve digital maturity
Study of intelligent noise reduction in pediatric study
Results are high print quality, increased throughput

More News

Davis Balestracci

Quality Insider

Wasting Time With Vague Solutions, Part 1

Helping management deal with common cause

Published: Friday, September 14, 2012 - 11:05

Let’s revisit two scenarios from my July 2012 column, “The Sobering Reality of ’Beginner’s Mind.’” First, a medical center’s Harvard MBA COO insisted on nothing less than 100-percent computer uptime, no excuses. His IT department’s inability to get 100-percent uptime consistently has resulted in yet another monthly “account for results” meeting.

The agenda: Get the result for the past month; show some type of table or bar graph summary (typically a red/yellow/green assessment accompanied by a variation on “this month, last month, 12 months ago”); listen to the predictable litany of excuses for why it didn’t happen the past month; and come up with the (latest) plan on how to fix it... until the next unexpected thing happens.

As an alternative, I showed a run chart and its analysis, which demonstrated the behavior to be common cause. The monthly meeting to discuss that specific month’s downtime and “do something” is a special cause strategy. Based on the run chart, there is no evidence of improvement so far, but do you think some complexity might have been added during this time? Let’s go a little further.

Because the run chart showed no evidence of a “shift” (that is the main purpose of a run chart), one can now proceed to construct a control chart using all the data for the average:

Since the calculated upper process limit was > 100 percent, which is impossible, the upper limit has been set at 100 percent. Using the standard nine special cause tests, there is no further evidence of any special causes, and this chart confirms that the occurrence of 100 percent is within the natural performance of the process.

So, do we have to accept these limits and stop blaming the workers until management does something about it? Or, as some improvement “experts” say, “Because it’s common cause, we need a total redesign of the process, but need management’s support in implementing it.”

Second scenario: Here is the chart looking at a healthcare organization’s “never event” occurrences:

Knowing what you know now, the “zero” quarters are within the natural variation of the process, and there are no special cause tests triggered. (Of the 29 events that occurred during this time period, how effective have their 29 individual “root cause analyses” been?)

So, what is typically done in these two cases?

• Tell management they need to accept this level of performance because “Deming says” that it’s their job to do something about it. Then ask them, “Do you want to do something about it?” (Not recommended—I hope your résumé is up to date.)

• Use the, “It’s common cause, so we need a totally redesigned process” strategy. Explain to management, “We need a new process. Even though Deming says it’s your job, we’ll do it, but we need your support every step of the way, especially as we benchmark and implement the new process.” (Been there? Care to predict how this will end?)

• Say that your department will “own it,” and put these two key issues on the organizational A-1 priority improvement project list—which is already awfully long. (When you bring it up to your staff, they’re all “too busy” to take on any more work.)

• Be a truly accountable professional and facilitate it yourself. Create a team of middle managers—who, alas, are also “too busy,” so they arrange to send one of their best workers. An “emergency” comes up for many of these workers the day of the scheduled meeting (besides, they’re also “too busy”), so they ask a frontline person to go in their place because “Deming says that the frontline has all the answers.” (I’ve done this and first meeting, it’s not unusual to observe a sea of hostile faces. I go around the room and ask, “Do you know why you’re here?” and most answer with an angry, “No!” or, “I was told to be here.” Déjà vu?)

• If you’re in healthcare, lucky you! You can join one of those Institute for Healthcare Improvement (IHI) collaboratives, for which executives seem all-too-willing to pay to show that they’re “behind” quality (some even get w-a-a-ay behind it and virtually disappear until the “account for results” and their expense item shows up on the agenda at the next executive meeting). Be sure to have your five-minute summary “showing results” ready for the next exec meeting—provided you don’t get bumped by the latest financial crisis or patient complaint that “shouldn’t have happened.”

Regardless of all the barriers thrown your way, you somehow manage to get these projects started. If nothing else, some type of improvement team is put together for at least a brainstorming session, and you facilitate an Ishikawa cause-and-effect fishbone diagram answering, respectively, for our two examples above:
• What causes downtime?
• What causes never events?

I’m willing to bet that everyone reading this has at one time or another been involved in producing “the fishbone diagram from hell.” Brian Joiner has a wonderful saying: “Vague solutions to vague problems yield vague results.” Joseph Juran said it many times: “There is no such thing as ’improvement in general.’” And they are both fond of the Pareto principle. Before you get too many (busy) people involved, is there something you can do to focus such vague issues?

One could ask: “What is the 20 percent of this process causing 80 percent of the problem?”—and then doing a cause-and-effect diagram.

But wait: Don’t jump to the tempting “simple, obvious... and wrong“ special data collection from hell to find the 20 percent, either. (Mea culpa.)

To be continued in part 2.

Discuss

About The Author

Davis Balestracci’s picture

Davis Balestracci

Davis Balestracci is a past chair of ASQ’s statistics division. He has synthesized W. Edwards Deming’s philosophy as Deming intended—as an approach to leadership—in the second edition of Data Sanity (Medical Group Management Association, 2015), with a foreword by Donald Berwick, M.D. Shipped free or as an ebook, Data Sanity offers a new way of thinking using a common organizational language based in process and understanding variation (data sanity), applied to everyday data and management. It also integrates Balestracci’s 20 years of studying organizational psychology into an “improvement as built in” approach as opposed to most current “quality as bolt-on” programs. Balestracci would love to wake up your conferences with his dynamic style and entertaining insights into the places where process, statistics, organizational culture, and quality meet.

Comments

This is great reading -- very

This is great reading -- very thought-provoking. Keep up the good writing.

Process capability challenges

Although not a perfect solution, in the downtime example I have to wonder if sufficient reliability techniques of redundancy wouldn't save some face to demonstrate progress while new processes can be designed.  You'll suffer from COO disatisfaction of getting closer to, but not achieving 100 percent availability. But maybe get some credit for improvement. I guess I ust want to point out fault removal isn't the only way to improve -fault tolerance has a place in the toolkit.

Process capability challenges

Although not a perfect solution, in the downtime example I have to wonder if sufficient reliability techniques of redundancy wouldn't save some face to demonstrate progress while new processes can be designed.  You'll suffer from COO disatisfaction of getting closer to, but not achieving 100 percent availability. But maybe get some credit for improvement. I guess I ust want to point out fault removal isn't the only way to improve -fault tolerance has a place in the toolkit.