Can We Please Stop the Guru Wars?

The universal road map for improvement

Published: Tuesday, February 11, 2014 - 10:19

The various improvement approaches are, in essence, all pretty much the same. Any competent practitioner would neither want to be called a “guru” nor have any problems dealing with another competent practitioner of another improvement philosophy.

In my opinion, any approach should also involve the use of data in some way, shape, or form. I once had a lean sensei (local “guru”?) vehemently make the point that lean does not involve data at all. I'll let you decide. Would you rather be effective or right?

Unfortunately, data conjure up the dreaded word “statistics”... and a huge misconception. The influence of W. Edwards Deming has created the mistaken belief that mass training in statistics will cure all quality ills. We all know the monster that has created.

Not ‘statistics’ but ‘variation’

I believe that one of Deming’s most profound statements was: “If I had to reduce my message to management to just a few words, I’d say it all has to do with reducing variation.” Reduced variation ultimately yields a more predictable process. But let me first expand your conception of “variation.”

Taking the “respect the process” theme of my last column, let’s look at it from an even larger perspective: How deeply has the concept of “process” permeated the very fabric of your organization?

In any organization, there is no lack of raw material needed for improvement: enthusiasm, focused attention on key issues, and good, hard-working people with good ideas. They may be necessary, but they are not sufficient. They need the catalyst of critical thinking inherent in process-oriented thinking.

The universal road map for improvement

The original version of The TEAM Handbook (Oriel, 2003) was published in 1988. Its process orientation provides the most robust framework within which to consider any improvement process—summarized beautifully through the elegant and logical road map provided by its “Sources of Problems with a Process” (now updated from six to seven). Here are the first three:
1. Inadequate knowledge of customer needs [added in the 2003 edition]
2. Inadequate knowledge of how a process does work:
• Variation in people’s perceptions of how things currently work
• Variation in training delivery or comprehension
• Individual preferences (variation) evolving from undocumented reactions to unforeseen inputs or situations
3. Inadequate knowledge of how a process should work:
• Variation in people’s perceptions of how things should work
• Given the current process state or objective: poor process design
• Naive or obsolete design
• Poor training
• Expansion beyond initial needs and capacity

Key question: What is actually happening vs. what should be happening?

Let’s consider this “gap” as variation: What we know vs. what we don’t know.

Here is a brilliant observation by Henry Neave in The Deming Dimension (SPC Press, 1990):

“[S]ystems are unlikely to be well-defined in practice unless they are both suitable and adequate for the jobs for which they are intended, and are written down in a way comprehensible to all involved.... [T]here can be big differences between what is written down—the way the system is intended, or thought, to operate—and what actually happens. Incidentally, the acquisition of this latter information can be difficult if not impossible in an unfriendly work environment. But, even in a constructive environment, it may still turn out to be almost impossibly difficult to complete a flowchart or other description because what is going on is so unsystematic. To be blunt, if a system cannot be written down, it probably doesn't exist: That is to say it probably functions more on the basis of whim and ‘gut feel’ rather than on any definable procedure. This surely implies that the variation being generated is some scale of magnitude higher than really necessary, with the resulting (by now) well-known effect on quality.”

Human variation is a huge factor in these first three steps. Documentation—i.e., flowcharting—reduces variation in perception of the situation. But even with this variation reduced, as the project moves forward, the additional problems of human variation still remain in both the improvement process itself and any subsequent data collection.

So, one could say:

Reduced human variation = higher quality improvement process = higher quality data collection.

It has been my experience that, the closer one gets to the frontline, the more difficult it is for those workers to see the bigger organizational picture. They are working very hard—and make sure you know it. And, to them, that’s quality. I’ve seen the pride as many tell me how they, in essence, treat every interaction in their job (whether customer, patient, department, or work colleague) as a special cause. They have minimal awareness that interacting with an internal or external customer is a process yielding “predictable”—and to them, many times frustratingly chaotic—results. No problem: Many have also proudly developed their own, individualized workarounds (read: special cause reactions) when these “unexpected” things occur. These add compexity in the form of human variation but no value.

Questions to ask about a process

In almost any project, as you inevitably deal with frontline processes, you will either have to get workers to see their job(s) as a process or talk to them so that you can then understand their jobs as processes. If the latter, you can educate them to that fact as a project progresses and solutions are implemented. I might suggest using the following script (developed by Joiner Associates and contained in The TEAM Handbook) at the beginning of a project, which would yield mutual benefit:

The process being studied is (fill in the blank).
1. Who are its external customers? What individuals, groups, or systems outside our organization rely on, or could benefit from, this process? Who has (or could have) expectations about this process?
2. How do we know what the external customers like or don’t like about this process? What satisfies or dissatisfies them?
3. Who are its internal customers? Describe those within the organization who do (or could) rely on the successful operation of this process or the resulting product or service.
4. How do we determine what the internal customers like or don’t like about this process? What satisfies or dissatisfies them?
5. What are the operational definitions of quality in this process? What specifically determines whether the process is working well or poorly?
6. What records are kept regarding quality? Who uses this information? How do they use it? Are these record formats suited to how they are used?
7. What are the most common mistakes or defects that occur? What is the operational definition for each mistake or defect? What proportion of these is commonly assumed to be a worker’s fault? What proportion do we usually attribute to the system? How do people arrive at these conclusions?
8. By what process do we inspect, evaluate, and report problems regarding:
• Planning required for this process
• Incoming materials, supplies, and information critical to this process
• The process itself
• The final product or service received by the external or internal customer
9. List the critical elements of this process: materials, components, parts, information, etc.
10. List the suppliers or vendors of each critical element.
11. Describe the company’s procedures for purchasing materials or services brought in from outside the facility. To what extent is “low bid” a governing factor in our purchasing decisions?
12. Describe the impact of the most common mistakes or defects in this process. What do they cost in time, money, customer loyalty, or worker pride?
13. Who is responsible for quality in this process? Who is responsible for detecting mistakes or defects? Who is responsible for identifying and correcting the causes of mistakes or defects?

I can’t think of a better experience for educating a culture in probably the most important concept to grasp in improvement: process-oriented thinking.

By the way, the above is the “plan” of any initial PDSA.

Challenge: How is human variation compromising your improvement efforts? Have you ever thought about your organizational quality education and training as a process? How about your overall “improvement” process? Do Henry Neave’s comments apply?

If you have any “aha!”s, please share them with me.

About The Author

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.