Skip to contentSkip to navigation

Are There Limits to Total Quality Management?

Many of the problems associated with quality programs are the result of increased complexity. The half-life concept, a new tool, strives to make complexity more manageable. By doing so, learning is accelerated and improvement becomes continuous.

(originally published by Booz & Company)

After nearly four years of rapid quality improvement, progress at Analog Devices Inc. began to plateau. A diagnosis carried out by the 21-member executive group singled out the root cause as lack of demonstrated commitment to Total Quality Management (T.Q.M.) by this very same group. As vice president of quality and productivity improvement, I was expected to come up with possible corrective action. My solution was that each member of the group take the most critical issue facing him and apply T.Q.M. methods and tools for its resolution. The resulting success stories would dramatically demonstrate to the entire organization that top management practices what it preaches.

My suggestion was met with universal skepticism. Although they all were unable to explain their opposition, the group members expressed their instinctive rejection of the idea. "My take is that that's exactly the wrong thing to do," one of them said. "I don't have the time to waste on something that I know will not work," another said. Such views were nearly unanimous. I had given them a standard T.Q.M. response, and they had emphatically turned it down. I knew that understanding what was behind their instincts to reject T.Q.M. was a key to returning us to our path of continuous improvement.

Shortly after that, I was a guest at a two-day T.Q.M. training session held at a company that had won a Malcolm Baldrige National Quality Award. The instructor was an outside consultant from one of the largest and most prestigious T.Q.M. organizations in the United States. During the final question-and-answer period, I asked the instructor whether he felt there were any problems that were not solvable using T.Q.M.'s seven management and planning tools (the subject of the training course). His answer was unexpected. He assured us that there were no limits to these tools. "In fact," he went on to say, "I believe that we could quickly cure cancer if we could only get the research community to use these tools."

This answer was in sharp contrast to a response I had received a month earlier to a similar question. That time I was participating in a meeting of senior executives who were studying and applying Hoshin Kanri (another T.Q.M. tool) in planning and implementing breakthroughs in their organizations. Our instructor was a Japanese expert in T.Q.M. The subject of discussion was the applicability of the seven Quality Control (Q.C.) tools to some of the more difficult problems that the participants were experiencing. I asked, "We have experienced many serious recessions; could we make a Pareto diagram (a graphical form of rank ordering) of the root causes of these recessions?" The professor's terse answer ended the discussion. "T.Q.M. doesn't work on those kinds of problems," he said.

How can there be such differences in the views of two T.Q.M. experts? Are there indeed limits to T.Q.M. as practiced today? More important, can we distinguish between situations where T.Q.M. is appropriate and those where it is not? The answers might help explain my experience with the Analog Devices executive group.


In 1988, I introduced the concept of the "half-life" associated with continuous process improvement.1 After benchmarking nearly 100 examples of exemplary use of the P.D.C.A. cycle (Plan-Do-Check-Act), I observed that for each process being improved, the rate of improvement was constant. The (constant) time it took for each 50 percent reduction in defect level (I called this the half-life) depended on the complexity of the process. I developed the matrix in Exhibit I, which summarizes these data.

These data clearly showed that as process complexity increased, the rate of continuous improvement declined (the half-life became larger). Furthermore, organizational complexity was far more important than technical complexity in slowing the rate of improvement. In fact, it had nearly three times the effect that increased technical complexity produced. Since the observed rate of improvement slows with increasing complexity, we are led to the obvious question of whether there exists a complexity level above which improvement fails and the half-life becomes infinite.

I have continued studying the relationship between T.Q.M. and process complexity. I have presented the half-life concept at dozens of conferences and numerous business school classes. It is the subject of a Harvard Business School case study2 and has been described in several recent books on the subject of performance measurement.3, 4, 5 I have also benefited from discussion with many T.Q.M. practitioners at companies that include Allied Signal, Bell Labs, Cummins Engine, Cypress Semiconductor, GEC Ferranti, Hewlett-Packard and MEMC Electronic Materials, who have used the half-life method for goal setting and improvement process diagnosis. My observations in this article are a synthesis of our mutual experiences.

Let me now make an assertion, though it is a generalization and subject to exceptions, that will form the basis for what follows: The complexity of processes most in need of improvement in an organization increases with the organizational level of the process executors.

Exhibit II is a graphical representation of this assertion. The x-axis is complexity, ranging from uncomplex to very complex. I have avoided the word "simple" since an uncomplex process may not appear to be simple to its owners. The y-axis is organizational level. It ranges from nonexempt workers to the entity leader or C.E.O. The diagonal band represents the region into which most processes tend to fall.


The construct provides a useful road map for the historic evolution of T.Q.M. and a possible indicator of its future direction. T.Q.M. had its origins in Japan in the 1950's with the landmark visits of W. Edwards Deming and J.M. Juran. It was also during that decade that the Quality Control circle had its roots. Under the leadership of the famed Kaoru Ishikawa, Q.C. circle activities have grown to become the foundation of the Japanese T.Q.M. movement, the extent of which is far more widespread than in the West.

A Q.C. circle consists of a first line supervisor and all of those who report directly to him or her. They constitute a team that has complete ownership of a subprocess. In general, the improvement activities of Q.C. circles are limited to the team's local work area. The subprocess is usually independent of external processes.

Each Q.C. circle then follows a seven-step process (see article, page 38). This process -- collecting data, discovering root causes, implementing corrective action -- has been utilized successfully to improve subprocesses in manufacturing and other operations for more than 40 years. For successful Q.C. circles, adherence to the process -- not just finding a solution -- is seen as critical. Data collection and root cause analysis break processes down into components and causal relationships that describe the subprocess.

When these steps are skipped, solutions often result in unintended consequences or fail to have an impact on root causes within the subprocess.

When there are interactions outside of the team, they tend to be limited in scope and highly visible. Usually, they involve the previous process step (supplier) and the next process step (customer). With cellular manufacturing, both are in very close physical proximity and real-time communication is easy. One system, kanban, that is used extensively in Japan assures speedy communications of problems both upstream and downstream of the subprocess, before a large inventory of defective output accumulates and while the trail is still warm enough to identify a root cause. By the nature of these subprocesses, they are uncomplex. The level of complexity, as we will see, is central to the current limits to T.Q.M.

In terms of the complexity map, it seems fair to say that the first 20 years of T.Q.M. activity in Japan were focused in the lower left hand corner. The teams were Q.C. circles, the method was seven steps and the tools were the seven Q.C. tools. The problems that they solved were additive, noninteractive and static in nature. I call them Type I problems. (See Exhibit III.)

1 Schneiderman, A., "Setting Quality Goals," Quality Progress, April 1988, pp. 51-57.

2 Cooper, R., and Kaplan, R., "The Design of Cost Management Systems" (Englewood Cliffs, N.J.: Prentice Hall, 1991), pp. 226-239; Harvard Business School Case 9-190-061; and Harvard Business School Teaching Note 05-191-103.

3 Dixon, J.,Nanni, A., and Vollmann,T., "The New Performance Challenge, Measuring Operations for World-Class Competition" (Homewood, Ill.: Dow Jones-Irwin, 1991), pp. 140-150.

4 Howell,R., Shank, J., Soucy, S., and Fischer, J., "Cost Management for Tomorrow, Seeking the Competitive Edge" (Morristown, N.J.: Financial Executives Research Foundation, 1992), pp. 127-149.

5 Lynch, R., and Cross,K., "Measure Up!, Yardsticks for Continuous Improvement" (Cambridge, Mass.: Basil Blackwell, Inc., 1991), p. 137.


The clear success of the Q.C. circle movement in Japan led to the natural desire to move improvement activity to the ranks of management. But Q.C. circles were trained to avoid, if possible, problems that involved human behavior, particularly when the behavior was that of others outside of the team, and to focus instead on machines, materials and methods. The reason was that the seven Q.C. tools did not prove useful in uncovering root causes when the problems had a significant human element (behavior) to them.

Also, the fundamental assumption in asking "why" five times is that a large problem is the sum of many independent small problems. Many of us have seen the failure of this assumption when an apparently significant improvement in one subprocess produced a more than offsetting degradation of another subprocess somewhere else in the system. I would speculate that much of the hundreds of millions of dollars, even billions of dollars, of cost reductions attributed to "cost of quality" improvements that mysteriously fail to appear at the bottom line, has been absorbed elsewhere in the system as a result in large part of the interdependency of processes.

In many systems, the whole is not the sum of its parts. The system takes on its nature by the interactions of its parts. This is particularly true of the problems encountered by management. It was believed that the P.D.C.A. cycle and the seven-step problem-solving process were still valid. What was needed was a new set of tools that helped identify the interactions between the subprocesses that make up the more complex processes encountered as we move up the diagonal.

The Japanese Union of Scientists and Engineers (J.U.S.E.) embarked on a process for developing a set of tools that would be more useful in solving increasingly complex problems. The results of these efforts were first published in 1977. Because they proved to be very successful, they were published in English in 1986.6 Kaoru Ishikawa's foreword to the 1986 publication describes the relationship of the "old" and "new" tools:

"This issue features the seven management tools for Q.C. The seven management tools for Q.C. (7M tools) were proposed in 1977 by the Committee for Developing Q.C. Tools by selecting various conventional techniques for creativity and management. These 7M tools are used in Japan today to implement T.Q.M.

"Now the seven quality control tools (7 Q.C. tools) -- i.e., Pareto diagram, cause and effect diagram, stratification, check sheet, histogram scatter diagram, graphs and control charts -- were proposed about 30 years ago and are widely used to solve more than 90 percent of the problems in Japanese enterprises.

"Recently, in Japan the 7M tools are sometimes quoted as the 'new 7 Q.C. tools.' But this is not to be misunderstood that the 7 Q.C. tools have become old. On the contrary, the 7 Q.C. tools are still the most important set of techniques in Japan. Rather, the 7M tools should perhaps be called 'supplemental seven Q.C. tools,' and in this sense, it is recommended that these methods should be learned after the 7 Q.C. tools have been well mastered."

Real understanding and knowledge of the seven management tools is very limited outside of Japan. Efforts to teach them are often confounded by their apparently overwhelming level of detail. Quality Function Deployment (Q.F.D.), for example, is based on the structured use of four of these tools. Many organizations that have tried the formal version of Q.F.D.7 have found themselves bogged down in a level of detail that tries the patience of most Western managers.

I have been a student of these tools for more than a decade. I have had the opportunity to apply some of them as a member of a 13-person team that spent full time over a five-week period designing the Center for Quality Management, a network of organizations implementing T.Q.M. In this effort, we were guided by Prof. Shoji Shiba of J.U.S.E., the University of Tsukuba and the Massachusetts Institute of Technology.8 I offer some observations about these tools based on my experience:

Unlike the usual analytic tools that deal with a series of numbers, the seven management tools deal with language-based data. They are tools for fact processing, rather than numerical data processing. A typical piece of language data9 is a statement of a fact, for example: "25 percent of the policy committee meetings in 1995 started more than 15 minutes late." Because of their dependence on language, a shared understanding and use of the science of semantics is a prerequisite.

The tools attempt to identify the interrelationship among the various elements of a problem. They identify causality and assess the relationship between all of the "whats" and "hows" of a problem. In one case, I was part of a team that spent the better part of a day determining the strength of the relationship for each element of a 4,000-cell matrix.

They focus on detailed planning as a precursor to flawless execution. It is said that the Japanese spend five times as much time in planning as we do, yet complete the whole process (plan + do) in less than half the time.10

They make formal use of right-brained (that is, creative or intuitive) processes as part of problem solving.

They force consensus through their structure. They are totally egalitarian and democratic: everyone has equal access to inputs and the "one person, one vote" rule is employed whenever votes are taken. The consensus nature of the seven management tools attempts to subjugate individual instinct to the view of the team. Many managers have found that the consensus view is in conflict with their own intuition, particularly when the team is made up of their subordinates and the problem is complex. Yet one set of ground rules establishes as a requirement "integrity -- in that people commit to use the outcome of a long process rather than just go through the exercise." I know several senior executives, who reached their position through good judgment and instincts, who have told me that they will never subject themselves to the seven management tools again. The destructive effect of overruling a team that has spent days reaching a consensus view was unacceptably disempowering to them.

They force a solution to the problem. Under the assumption that doing something is better than doing nothing, they will lead a team to the best collective guess as to what to do.

They are incredibly labor intensive.11 The use of the tools cannot be effectively delegated since they rely heavily on the personal knowledge of all of the team members. Therefore, they are very expensive to use. Proponents believe that the cost is justifiable in terms of the quality of the results compared with other processes for making decisions.

There is widespread acceptance and use of these tools in Japan. Judging from the results, in terms of cycle time reduction (particularly in new product development), product integration and other factors, they appear to be very effective, particularly when applied to cross-functional processes. Experience in the West is more limited. Companies like Milliken, Procter & Gamble, Xerox and Ford speak very enthusiastically about their successes with these tools. Other companies have had disappointing results as their managers reject outright their mechanical detail and rigidity.

In terms of our construct (see Exhibit IV), we can describe the seven management tools as a tool set for cross-functional teams dealing with increased problem complexity. Several of the tools (e.g., kj diagram, tree diagram, matrix data analysis) form the basis of Q.F.D., the front end of which is called the Voice of the Customer (V.O.C.). Intermediate complexity problems have static interactions and very visible causal relationships. I refer to them as Type II processes.


One management area in which the Japanese have made significant progress in recent years is in synchronizing or aligning corporatewide activity in the accomplishment of a few, clearly defined, organizationally complex breakthrough objectives. The tool that they have developed for doing this is called Hoshin Kanri (or policy deployment, as it is known as in the West). Its most important elements are:

The deployment of both goals and the means for their achievement throughout the organization.

A process known as "catchball" in which the required means are balanced against the available resources and know-how.

An integration of top-down (goals) and bottom-up (means) planning processes.

The use of detailed implementation plans that focus on the 5W's + 1H: what, why, when, how, where and who.12

A modification of the P.D.C.A. cycle called the "C.A.P.Do" (Check-Act-Plan-Do) that reviews quarterly progress against goals and takes necessary corrective action to put the project back on track.

The kind of breakthrough projects for which Hoshin Kanri is used tend to be high in organizational complexity, but low in technical complexity. The need is more for synchronization and resourcing than for technical innovation. Also, the goals often call for 10-times or 100-times annual improvement rather than 2-times (12 month half-life) improvements that result from the continuous incremental improvement activities described earlier. This accelerated improvement is more the result of increased resourcing of the P.D.C.A. process than extraordinary breakthroughs. I understand that today any Deming Prize winner must have a working Hoshin Kanri system in place.

6 Reports of Statistical Application Research, Japanese Union of Scientists and Engineers, Vol. 33, No. 2, June 1986.

7 See for example: Akoa, Y., editor, "Quality Function Deployment, Integrating Customer Requirements into Product Design" (Cambridge, Mass.: Productivity Press, 1990).

8 Shiba, S.,Graham, A., and Walden, D.,"A New American T.Q.M." (Cambridge, Mass.: Productivity Press, 1993).

9 It is useful to distinguish three types of data. Type I data are numerical data that are continuously generated by a process. This type of information is used to control a process. Type II data are numerical data collected specifically to test a hypothesis; for example, does machine A produce more defects than machine B? Type III data are language data. This type consists of statements of fact. They are data in that they can be confirmed by others.

10 King, B., "Better Designs in Half the Time" (Methuen, Mass.: QOAL/QPC, 1992).

11 There are an increasing number of software packages available to ease the "drafting" requirements of these tools. However, the need for the team to look at every possible interaction remains. Even in Japan, the need for T.Q.M. CAD tools is well recognized. Of the 260 employees of J.U.S.E. and its subsidiary organizations, more than half are working on T.Q.M. software development.

12 Some of the readers may remember Kipling's 1902 story called "The Elephant Song." In it appeared the words: "I keep six honest serving men (they taught me all I knew); their names are what and why and when and how and where and who." This is another Western invention borrowed by the Japanese.13 House, C., and Price, R., "The Return Map: Tracking Product Teams," Harvard Business Review, vol. 69, no. 1, January-February 1991, p. 92.


The Type II processes are moderately complex and have static interactions. They are the current frontier of T.Q.M. and the seven management tools. Type I processes that are independent and static are the proven world of Q.C. circles. This leads us to the final version of our complexity map, Exhibit V. The top circle represents the complex interactive and dynamic processes that occupy much of the time of top management. These are the processes that are often counterintuitive in their behavior. Should they be the realm of individual intuitive managers who rely on mental models? Or can teams of people address these issues? What tools should they use? These Type III processes currently lie outside of the boundary of T.Q.M.

I mentioned earlier that the seven management tools look at the interactions of the various elements of the total process. In using these tools, we ask such questions as:

Does A cause B to happen?

Will the effect of A on B be very strong, moderate, weak or nonexistent?

Which has more of an effect on C -- A or B?

What is the relative importance of A, B and C on D?

What could go wrong, and what is the best countermeasure?

The more complex a problem, the more difficult it is to answer these questions. Often, the answer depends on other aspects of the process: A will cause B to happen if C is close to D, and E happens before F. Furthermore, in dynamic systems the answers to these questions are time dependent. No individual or team can assess these interactions in their heads or even on dozens of sheets of paper.

At the beginning of this paper, I mentioned one such problem, periodic recessions and the associated unemployment. No one would deny that excess unemployment is a defect associated with our economic process. What are the root causes of unemployment? What, even, are causal factors? Do high taxes cause unemployment? Unfavorable balance of payments? Excessive national debt? Lack of education, training and skills? Not only do we lack a rank-ordered list of root causes, we lack a consensus on the causal linkages themselves, including their direction. And, we certainly cannot blame this on a shortage of data.

Does it even make sense to talk about the P.D.C.A. cycle for these types of problems? If we lack the tools to identify causality, how can we tell if our corrective action worked or not? Maybe some other factor made things look better or worse. Some might argue that if you get enough data and analyze them, you can find the causal relationships.

That argument fails in two ways. First, the scientific methodology that we have used for 500 years states that before you can design an experiment, you need to have a hypothesis that the experiment will either confirm or deny. Only then will you know which data to collect. The world of data is infinite. And, unlike quality, data are not free. It is easy to overlook the cost in both time and money of collecting and analyzing data, particularly data about complex systems.

Second, to understand dynamic processes, you need several cycles worth of data with the process held relatively fixed. We hardly ever have that situation. I recently heard of a study that showed that the average United States corporation reorganizes every four years. It spends two years planning and two years implementing each reorganization. Therefore, the average United States company is reorganizing all of the time. It may be that causality in many important management processes is both unknown and unknowable.

We need not go as far up the complexity diagonal as our national economic processes. Even within our organizations, top management is struggling with critical processes in which the causal linkages are at best obscure.

One example is the new-product generation process. In many industries (automotive, semiconductor, industrial equipment, for instance) cycle time or time to market is of the order of three to five years. Often, the success of the product in the marketplace cannot be assessed for another couple of years. Let us apply the P.D.C.A. cycle to that process. We plan the product, we do it and then we are ready to check what we did by comparing actual results with the plan. But more than five years have gone by. What can we learn from the check? Much of the disparity is caused by wrong assumptions and forecasts made half a decade ago. Even if we learn what we did wrong back then, how applicable would it be to today's rapidly changing world?

P.D.C.A. cannot be applied to processes that have a cycle time that is long compared with the time in which the environment (that is, the external processes to which it links) changes. In fact, the way to improve the new product generation process is to focus on the planning process itself, not on the results of the process. Design a standardized process that is most likely to produce good results. It will probably include subprocesses that:

Require proponents to be explicit about their assumptions. This will guarantee that they have thought about such critical issues as customers, costs and competitors. Hewlett-Packard's Break Even Time (B.E.T.)13 is a superb vehicle for assuring that those closest to the process and the related subprocesses (manufacturing, marketing and sales) have thought through the issues and assessed the sensitivity of the resourcing decision to the assumptions. The B.E.T. system -- that is, the process of calculating a value using all subprocesses -- is powerful. However, the resulting B.E.T. as a performance measure is of questionable value, because it may foster less risk-taking or innovation.

Introduce frequent design reviews into the process to formalize milestones and to foresee future problems and their potential solutions.

Introduce parallelism into the process wherever feasible.

Long-cycle-time processes inherently rely upon good instincts for their design. They also require the use of process metrics rather than results metrics.14 The number of new products introduced, time to market and new product revenue are ineffective metrics for a long new-product generation process. Process metrics -- like percent of scheduled milestones missed, number of engineering change orders or number of schedule changes this month -- are much more effective drivers of improvement. Follow the process and you will maximize the probability of product success.


In the semiconductor industry, we faced complexity issues in designing VLSI circuits. On a single tiny chip, we can now produce the functionality that required a room or even a building worth of equipment only a few decades ago. The dense packing of the various elements produces interactions that could be identified and eliminated only by costly trial and error. Today our designers rely on simulation modeling to reduce the time and cost to market. In fact, the need for better simulation tools is a current bottleneck in the development of many of our most advanced products.

Simulation modeling allows us to characterize the dynamic relationship between the various elements of a process. It demonstrates that the changes in a system are driven not only by these relationships themselves, but also by the state of the various parts of the system relative to their desired state. It captures the inherent time delay between cause and effect that masks the underlying leverage points in the process. Most important, it holds the promise of reducing the complexity of the seven management tools by pointing to the vital few interrelationships, often hidden, that really drive the behavior of complex systems. As a complement to the seven management tools, it provides a more palatable approach for senior managers.

Simulation models provide a laboratory in which P.D.C.A. can be performed on long-cycle-time processes. Since simulation models are often based on managers' perceptions of the structure of a problem, they can incorporate mental models with a high right-brain or intuitive content.

It is time that we re-examine simulation modeling as a tool to be added to the T.Q.M. tool set in order to move the boundary of its applicability up the complexity diagonal. I say re-examine because simulation modeling of complex, interactive, dynamic systems was introduced by Jay Forrester of M.I.T. in the early 1950's.15 Mr. Forrester recognized the role of feedback loops in determining the dynamic behavior of complex systems. His landmark research appeared in the Harvard Business Review in the late 1950's.

A team can build a simulation model and identify the leverage points (root cause equivalents) for corrective action intervention. They can validate the model by comparing the behavior of the model with their real-life experiences with the real system. They can apply the P.D.C.A. cycle by observing the results of their corrective actions and changing the simulation model as appropriate.


Yes, there are there limits to T.Q.M., for now. T.Q.M. is a means for achieving improved organizational performance. It is a product and it must meet the same customer quality requirements as any product in today's world:

It must meet specifications.

It must be fit for the use to which it is put by the customer.

It must be low in cost, relative to its benefits.

It must change to meet the latent (unstated) needs of its customers.

We need to determine the "specs" of T.Q.M., to help the customer to use T.Q.M. in accordance with its specs and to improve the tool set to make the tools more user friendly.

We are beginning to understand a new T.Q.M. tool set, the seven management tools. They appear effective for dealing with the Type II medium-complexity cross-functional problems that are omnipresent in the middle of our organizations. We need to understand their region of usefulness and assure that they are used thoughtfully, rather than mechanically. They are an extremely costly set of tools (in terms of time). Furthermore, we must always remember that consensus does not always lead to the best answer.

Finally, we have the Type III problems. These are highly complex, interactive and dynamic and seem to create the greatest amount of pain both inside and outside of our organizations. The T.Q.M. mandate to "manage by fact," interpreted literally, gives short shrift to innovation and insight as a legitimate problem-solving method. People who repeatedly make good decisions in highly complex situations based on their experience or gut feelings have significant contributions to make. Even if they cannot explain the workings of their mental models of a situation, it does not mean that those models are incorrect. Often they are better than the descriptions that we force to fit into our analytical frameworks. Holistic problem-solving finds the right balance between data collection and analysis and the undescribed mental models of effective problem solvers.

Our ability to form mental models of complex situations, however, has not kept pace with the rate of increase in complexity. We have had to devise project planning systems to coordinate the many tasks associated with complex logistical efforts. Building a modern skyscraper or putting a man on the moon requires coordination of the activities of many people and organizations. The division of labor involved in these types of projects is made possible by the ability to specify fully the timing and required interactions among the various players. Detailed "specs" exist that fully characterize the interfaces among the various parties involved in these projects. These specs do not yet exist for Type III management processes.

Type III problems are outside of the current boundary of T.Q.M. I have shown how T.Q.M. practitioners have augmented their tool set to allow them to deal with increasingly complex problems. I have also proposed simulation modeling as a means for further extending the boundary of applicability of T.Q.M., by developing specs that characterize the complexity of Type III processes. Should that happen, we will again be faced with the question: are there limits to T.Q.M.? I will then be hard pressed to define what is left of management outside of T.Q.M. Perhaps it is time for us to face up to the reality that there is a fading distinction between Total Quality Management, total management and management itself (i.e., T.Q.M. = T.M. M.)

13 House, C., and Price, R., "The Return Map: Tracking Product Teams", Harvard Business Review, vol. 69, no. 1, January-February 1991, p. 92.

14 Schneiderman, A.,"Metrics for the Order Fulfillment Process, Parts 1 and 2," Journal of Cost Management (Summer 1996): pp. 30-42, (Fall 1996): pp. 6-17.

15 See for example: "Collected Papers of Jay W. Forrester" (Cambridge, Mass.: Wright-Allen Press, 1975).


The seven-step method followed by the Q.C. circle is a special case of the P.D.C.A. Cycle (see Exhibit). The rigorous adherence to this problem-solving process avoids several common difficulties encountered by teams.

Solving the wrong problem.

Step 1 and the associated prework assures that the team has an important and clearly defined problem and that the other six steps can be completed by the group. I have found that in well over half of the cases in which teams fail to solve a problem, it is because they chose the wrong problem to solve or because there was a lack of agreement among the team members on what the problem was. For this reason, when I am doing seven-step training, I spend one-third of the time on step 1.

Jumping from problem statement to solution.

If you ask successful people for the keys to their success, they almost always have problem-solving skills near the top of the list. But it is remarkable how often even good problem solvers are wrong. That is because we have a natural tendency to jump from the problem statement (step 1) to a solution (step 4) without bothering to collect data and analyze the causes of the problem. Steps 2 and 3 are there to improve the odds of coming up with the right solution.

It is not my job to implement.

Have you ever received one of those memos that say "I've studied your problem and here is what you should do"? Steps 4 and 5 are there to assure that the objective is not a solution. The objective is an implemented improvement. All members of the team own the entire improvement process.

I know this will work; let's just do it.

Often, proposed solutions are implemented without a test of their effectiveness. Step 5 requires the completion of a pilot or test of the proposed solution. If improvement results, then the solution is implemented on a full-scale basis. One of the major parts of process redesign and re-engineering is the elimination of steps that do not add value. Often, these steps were created to improve the process, but without the completion of step 5, they had no effect on the problem they were intended to eliminate.

We're too busy to waste time on paperwork.

Without step 6, solutions reside in volatile human memory. Organizational learning is quickly followed by organizational forgetting. Processes drift back to their pre-improvement performance levels.

Next problem, please.

Step 7 has a vital element to it that focuses on the improvement process itself. Reflection on the team's improvement experience often uncovers correctable weaknesses in skills, methods or team dynamics. Step 7 helps teams become more effective at problem solving, thus reducing the half-life. The subprocess of step 7 can also be described as deuterolearning:1 learning how to improve the way the team improves in order to accelerate its resulting rate of improvement.

It is important to distinguish the difference between a problem-solving process and problem-solving tools. The process represents a paradigm for discovery. It is an idealized series of activities that should produce the desired outcome. When I was an engineering undergraduate in the late 1950's, a required course was "Philosophy and Scientific Methodology." It taught us the evolution of the modern method of inquiry that we would be using as engineers: the continual journey, back and forth, between the level of thought (theory) and the level of reality (observation). Tools like calculus or microscopes were the means used in carrying out the process.

Steps 2 and 3 -- data collection and root cause analysis -- usually utilize an activity called "ask why five times." In effect, the problem is broken down into smaller and smaller pieces. The tools used in this process are called the seven Q.C. tools. One, the Pareto analysis, is a bar chart that ranks the reasons for each level of "why." The largest bar is the one that the next "why" is targeted to.

As an example, consider the order-fulfillment process. One of its defects is late shipment to customers.

Why 1: Why were 30 percent of our shipments made late to our customers?

Because 1: Because 20 percent of the late lines were held up by the credit department.

Why 2: Why were lines held up by the credit department?

Because 2: Because for 25 percent of those held up, the customers exceeded their credit limits.

Why 3: Why did these customers exceed their credit limits?

Because 3: Because 80 percent of the time when they placed the order, they didn't know that the order would put them over their credit limits.

Why 4: Why didn't they know that the order put them over their credit limits?

Because 4: Because 98 percent of the time we didn't know that the order would put them over their credit limits, so we couldn't tell them.

Why 5: Why didn't we know that the order would put them over their credit limits?

Because 5: Because the order-entry screen does not show current available credit for each customer.

By the time a team answers the fifth "why," both the root cause and corrective action become very clear. Fifth "why" solutions usually involve straightforward reversal of the root cause. In this example, adding "available credit" to the order-entry screen was a simple cure for this part of the problem.

You may have calculated from this example that the solution improved on-time delivery by only 1 percent. To make a major dent on these kinds of problems, you need to have many teams working on the many elements of the problem. Hence, the use of the term "mass movement" to describe Q.C. circle activities.

This process, often illustrated with successive Pareto diagrams, used to be referred to as "peeling the onion." Others call it "drill down." It is also related to the solution to the proverbial question "How do you eat an elephant?" The answer: "One bite at a time." Because each bite may represent a fraction of a percent of the total problem, many teams must be gnawing away at all of the parts of the problem. At Analog Devices, we mobilized more than 50 teams throughout the corporation to work on improving the order-fulfillment process. In the period 1986-1990, they succeeded in reducing late shipments from more than 30 percent to less than 3 percent.

Occasionally, by accident or intent, a genius comes along and solves a problem at the first or second "why" level. These solutions constitute the breakthroughs that most Western companies have relied upon as the basis of their improvement activities. However, the mass movement nature of Q.C. circles can empower the entire work force toward problem resolution and form a more powerful collective genius.

Reprint No. 98204

1Argyris., and Schön, D., "Organizational Learning: A Theory of Action Perspective" (Reading, Mass.: Addison-Wesley Publishing Company, 1978).

Arthur M. Schneiderman,
Arthur M. Schneidermanis a visiting fellow at the Centre for Business Performance at Cranfield University’s School of Management in the U.K., and an independent consultant. As a vice president of quality and productivity at Analog Devices Inc., he developed one of the first corporate scorecards.
Get s+b's award-winning newsletter delivered to your inbox. Sign up No, thanks
Illustration of flying birds delivering information
Get the newsletter

Sign up now to get our top insights on business strategy and management trends, delivered straight to your inbox twice a week.