Content By Davis Balestracci

Davis Balestracci’s picture

By: Davis Balestracci

In my last column, I showed how hidden special causes can sometimes create the appearance of common cause, but the purpose of common-cause strategies is to deal with this and smoke them out. When there's an underlying structure to how these data were collected, or when one can somehow code each individual data point with a trace to a process input, stratifying the data accordingly can many times expose these special causes.

Even the simple coding of individual points on a graph can be every bit as effective as the more formal tool of a stratified histogram. I’m going to take the issue of understanding variation in count data further in the next couple of columns. I’ll begin here by looking at two scenarios.

‘What's the trend?

I once consulted with a medical center and attended its monthly meeting on medication errors. Right before the meeting, I was handed the 24 monthly reports from the previous two years. Not being sure what to do, I noticed something in the top right corner of each: a small table citing the number of errors for this month, last month, and same month last year.

Davis Balestracci’s picture

By: Davis Balestracci

I was teaching a class and asked participants to create a control chart of an indicator that was important to them. A lab supervisor presented me with a chart on the number of procedures her department performed and told me that it wasn’t very useful.

She wanted to use the chart for staffing purposes, but the wide limits were discouraging to the point of being ridiculous:

I know that a lot of you have access to software with the classic Western Electric special cause tests programmed in. In this case, none of them were triggered. On the surface, the chart is exhibiting common cause. For what it’s worth (and as you will see, it isn’t worth much), the data also “pass” a Normality test with a p-value of 0.092. Lots of statistics. And the subsequent action is...?

Davis Balestracci’s picture

By: Davis Balestracci


Author's note: To my non-U.S. readers, I apologize for using the sport of baseball to make my points today—and during the World Cup, no less! It’s a perfect context, however, and I hope you will be able to understand the main points.

In my last column, I talked about the different types of control charts and encouraged the use of the individuals chart almost exclusively. I also mentioned that p-charts (percentages) and u-charts (rates) can be very useful for stratification. I’m going to pursue that more in the next couple of columns, but today it’s “back to basics” to set up their foundation by talking about count data.

Count data seem intuitively simple

Let’s begin with a common issue: tracking complaints. How do you count them? Do you count the number of complaints received each month, or do you count the number of customers who complained? The people tallying such data will certainly need careful instruction before you can begin to collect useful count data—lurking “human variation” can seriously compromise the quality of the data and its use.

Davis Balestracci’s picture

By: Davis Balestracci

Do you still insist on asking, “Which chart do I use for which situation?”

I’ve seen many flowcharts in books to help you answer this question. They’re all some variation of this:

I find them far too confusing for the average user and have never taught this in my work. Besides, you get no credit for choosing the technically correct chart or computing the right numbers—only for taking the right action.

Your ‘Swiss Army knife’

For any initial chart for process assessment, the data should be in its naturally occurring time sequence, preferably as a run chart. Next, the control chart of choice with which to start is virtually almost always the I-chart (individuals chart), which uses the moving range (MR) between consecutive points to determine its common-cause limits. The I-chart is the “Swiss Army knife” of control charts. As I have discovered time and time again, it usually approximates the “correct” chart under most conditions, and its use is easier to explain.

I can hear the chorus: “So, what are the conditions when it isn’t correct?”

Davis Balestracci’s picture

By: Davis Balestracci

My recent columns have emphasized the need for critical thinking to understand the process that produces any data. By just plotting data in their naturally occurring time order, many important questions arise about the data’s “pedigree” (a term coined by my respected colleagues Roger Hoerl and Ron Snee), including question one: “How were these data defined and collected?”

That simple time plot can easily be converted to a run chart—a time-ordered plot of data with the median drawn in as a reference line. This helps to answer question two: “What was the state of the process that produced these data?”

Two intuitively simple rules can be applied to the chart to determine whether a process has exhibited significant shift during the plotted period:

Davis Balestracci’s picture

By: Davis Balestracci

In my last column, I considered two of the most common questions faced by a statistical educator and the deeper questions that need to be addressed. I encouraged people to consider their everyday reality for the necessary context. Predictably, some become frustrated by my lack of concise answers and try to distract me by asking, “Well, even though I can’t think of a situation, how many data points do I need to have a good chart?”

This predictable question is once again met by my predictably vague reply, “How much data do you have?” It’s usually not very much.

Despite the pedantic proclamations many of you have encountered in favor of waiting for anywhere from 15 to 25 data points, I have found that useful limits may be computed with much less data. As few as seven to 10 observations are sufficient to start computing limits, especially if it’s all you have—something that happens to me frequently. What else are you going to do? I dare you to find a more accurate way to assess the situation.

Davis Balestracci’s picture

By: Davis Balestracci

In my column, “The Universal Process Flowchart × Four,” I challenged you to look at the everyday use of data as a huge source of hidden waste. I suggested looking at a sample of any routine meeting’s raw data and asking eight questions, the last of which could be the most important of all: Does a plot of these data in their naturally occurring time order exist? How could you construct one?

Here is some wisdom from Dr. Donald Berwick—offered almost 20 years ago during his 1995 Institute for Healthcare Improvement Forum plenary speech, “Run to Space”:

Davis Balestracci’s picture

By: Davis Balestracci

Critical thinking does not necessarily result from using a practitioner’s toolbox framed within a formal improvement structure such as Six Sigma, lean, lean Six Sigma, or the Toyota Production System. It’s very easy to get seduced by all the fancy tools, acronyms, and Japanese terminology—and promises. I’d much rather have far fewer tools used in conjunction with critical thinking to understand variation—in one’s native language. So again, it’s time to apply critical thinking to rapid-cycle PDSA, the plan-do-study-act method for learning and improvement developed by Walter Shewhart. If you find yourself confused and frustrated in your current applications, there’s good reason.

Davis Balestracci’s picture

By: Davis Balestracci

To summarize my last three articles, most improvement approaches come out of the same theory and are based on the assumption that everything is a process.

The universal process flowchart in Figure 1 sums it up beautifully. The boxes at the top are how executives think the process works. The frontline’s frustrating reality is charted underneath and is how it really works, which is why it needs improvement.

Figure 1: Universal process flowchart

In my last article, “Finding the Unnecessary and Everyday Variation,” I challenged you to give serious consideration to “the current everyday use of data” as a process, one that needs improvement. So let’s apply a tool common to all approaches—a high-level flowchart (shown in figure 2).

Figure 2: A high-level flowchart

Davis Balestracci’s picture

By: Davis Balestracci

This is the last in my series making the case that the various improvement approaches are all pretty much the same.

There are seven sources of problems with a process. The first three help frame the situation:
Source 1: Inadequate knowledge of customer needs
Source 2: Inadequate knowledge of how the process currently works
Source 3: Inadequate knowledge of how the process should work

In my last column, I talked about:

Source 4: Errors and mistakes in executing procedures
• How about isolating and focusing on the 20 percent of a process (vague problem) where most of the variation is occurring? This would be the time for more detailed flowcharting.