Two Models for Solving and Preventing Quality Problems: the PDCA cycle and Practical Problem-Solving Process

Even the best-managed organizations have problems. A problem is any situation in which what exists does not match what is desired, or put another way, there is a discrepancy between the current state of affairs and the one desired. The greater the disparity between the two, the greater the problem. Problem solving in a total quality setting is not just “putting out fires” as they occur. Rather, it is one more way to make continual improvements in the workplace and its products or services. This section contains two models for solving problems in ways that simultaneously lead to workplace or product improvements: the PDCA cycle and Practical Problem-Solving Process.

For this discussion, we will separate problems into two cat­egories: existent and latent. Existent problems are the ones that have manifested themselves as processes that have gone wrong, as defective products, as errors in work, and through other symptoms of trouble. These are the problems that demand our immediate attention. Organizations face and react to ex­istent problems every day. On the other hand, latent problems lie waiting in the wings for the right combination of circum­stances to bring them to life. Because they have yet to occur, they are not obvious until we go searching for them. Like ex­istent problems, latent problems also exist in all organizations.

World-class organizations find ways of dealing with both existent problems and latent problems. Although many of the tools and techniques are the same, the initial approach is different. In the case of the existent problem, the approach to a solution is reactive: a problem has oc­curred, and it must be solved before we can move on. For the latent problem, the initial approach is proactive; if con­ditions are right, this problem could occur, and we need to prevent it. Notice that the existent problem always an­nounces itself. We know that a problem has occurred. The latent problem is silent; it hasn’t occurred yet. We must seek it out. The objective of the solution to both problem types should always be to eliminate the potential for the problem to occur (latent) or repeat (existent).

The best organizations pay a lot of attention to both existent and latent problems. It is not enough just to fix ex­istent problems as they come up because all of those latent problems out there are just waiting to happen. The organi­zation should place a heavy emphasis on preventing future problems as well as solving those that are already obvious. All problem solving should be seen as a continual improve­ment activity. If, for example, a problem “solution” merely returns a process to the state that existed before the problem occurred, then we suggest that it has not been solved at all. Certainly, no improvement has been achieved. The prob­lem will return. On the other hand, if a problem is solved in a manner that renders the same problem unable to recur, then process improvement has taken place. By following this philosophy for every problem, over time processes, products, and services will become better and more robust, and the organization will face fewer and fewer problems. That should be the objective of all problem-solving activity.

1. The Plan-Do-Check-Adjust Cycle

This continual improvement model goes by several names. The Japanese call it the Deming Cycle after Dr. W Edwards Deming, who introduced it to them. In the West, it is com­monly called the PDCA cycle, standing for plan-do-check- act. In this book Here, we have taken the liberty to suggest that the letter A more correctly means adjust.

The PDCA cycle has evolved from that which Deming presented to his Japanese audience in the summer of 1950. The cycle started with design the product, followed in order by production, sales, and market research. His emphasis was on developing products that would be accepted in the world’s markets, and that was precisely the requirement of the moment in Japan. In the design phase, he stressed find­ing out what is needed by potential customers, designing a product to meet the need, and planning sufficient pro­duction to validate the product’s viability. That has become the Plan part of the cycle. The production plan was to be executed in the second quadrant of the cycle. That has be­come the Do phase. After producing the product, the firm was to sell it. Whether it sold well or poorly provided infor­mation on whether the firm had correctly chosen a product type. This has become the Check phase. Having sold the product, the firm was urged to find out from its custom­ers whether the product met their expectations and how the product could be changed to better serve the customer. That has become the Act or Adjust phase. The concept was that a second cycle would commence immediately, taking into consideration everything that was learned from the first cycle; then there would be a third, a fourth, and so on, continually applying information learned to redesign the product and find ways to make production more efficient, always with customer requirements as a very important input to the process.

The PDCA cycle consists of four major components (see Figure 16.1), each of which can be subdivided into the necessary step-by-step problem-solving activities:

1. Plan. Before any corrective action is taken on the problem at hand, a number of activities should be undertaken. The problem must be defined, relevant in­formation gathered, the root cause of the problem iden­tified, possible solutions developed and considered, and the best alternative selected for implementation. All of this needs to be done by people carefully selected on the basis of their association with the process involved and their special relevant knowledge, skills, experience, and so on.
2. Do. Implement the solution chosen as best. (Note that in the real world “best” often means “most likely” to produce the desired result.)
3. Check. Monitor the implemented solution and gather data relevant to the original problem and any other areas of concern—for example, concerns about unintended consequences of the solution. Analyze the data to determine whether the implemented solution eliminated the problem (or made it much less likely to recur).
4. Adjust. If the Check step confirmed that the prob­lem has been eliminated and that it is not likely to recur, then the job is done. If, however, it was found that the solution did not accomplish the intended re­sult or that there is still a possibility of recurrence, then it will be necessary to “adjust” the implemented solu­tion. Adjust can also mean discard the implemented solution and try a different approach. Whether the implemented solution has failed completely or does not quite measure up to expectation, the conceptual adjustment will be carried forward to the Plan step of another PDCA cycle.

This cycle can be repeated as many times as is necessary to eliminate the problem successfully. If progress is not evident after several cycles, however, it would be a good idea to stop, stand back, and take another look at the original problem, perhaps aided by some new viewpoints (i.e., from new peo­ple added to the problem-solving team). Never let a team be­come bogged down.

The PDCA problem-solving technique is equally useful whether you are reacting to an existent failure event or pro­actively seeking a means to head off a latent problem that has not yet happened but that can happen. The PDCA cycle is a kind of generic, basic format for bringing order and logic to the problem-solving process. As you can see from Figure 16.1, it is not detailed in terms of the specific steps of problem solv­ing but is intended to put all the steps into a logical sequence and then to start a simple cycle that is allowed to continue until a solution’s results match the planned outcome.

2. General Procedure for Problem Solving

Whether you are reacting to an existent problem that has just come up or working to prevent future problems, it will be help­ful to follow a procedure that defines the methodology of prob­lem solving and establishes an order of execution of the critical
steps. Figure 16.2 shows a flowchart of the problem-solving process employed by one of the great manufacturers. “Practical Problem-Solving Process”¹ is said to have seven main steps, al­though the number of steps may depend on one’s definition of “step.” Note that Step 2, for example, is broken into several sub­processes. Regardless of how the process steps are counted, the process is appropriate for almost all situations, including both latent and existent problem categories. The following step-by­step discussion explains the problem-solving model. You may want to refer to the flowchart in Figure 16.2 and to Figure 16.3, which presents a textual overview of the process.

Figure 16.2 Practical Problem-Solving Process.

Step 1: Perceive the Initial Problem The action in Step 1 simply perceives that a problem (latent or existent) exists. One may be brought to that perception by an alarm, a failed inspection, a limit being breached, a search for po­tential future failure modes (as with FMEA), or many other events. Existent problems will usually be obvious and must be dealt with expeditiously. Latent problems are often dis­covered by improvement teams searching processes and product or service designs for vulnerability. Their method is typically an examination of key processes and designs, looking for potential weaknesses, trouble spots, areas of too little or too much control, illogical operations, or steps that add no value. Most of the total quality tools may be used, but especially useful are FMEA and flowcharts constructed to illustrate how the processes actually work (as opposed to how they should work). If the team perceives that a process or a product design contains a latent problem, the “unborn”
problem is listed for possible problem-solving action and continual improvement.

Step 2: Clarify the Problem Before action can be taken, problem solvers must “grasp the situation.” Experience has shown that grasping the situation thoroughly before pro­ceeding with the problem solving is vitally important, but it is a very difficult concept to teach. Most of us are too eager to jump to conclusions and get on with it. That approach is not allowed—even if a production line is stopped. Before a solution can be offered, the problem must be defined and objectives for improvement set. To do that, Step 2 takes us through substeps 2a through 2f.

Substep 2a Observe with an open mind. This is a re­minder to refrain from assuming anything relative to the problem at this point. Rather, be an unbiased observer of the facts surrounding the problem.

Substep 2b Compare the actual situation to the stan­dard. This requires the problem solver to compare the ac­tual data from the process or product with that specified in the relevant standard. The word standard is used to denote the recognized, approved procedure, specification, or other document. Process operators are expected to adhere to the instructions contained in the standard that applies to the process. The engineer is expected to design a product that conforms to the established product requirements and speci­fications. If there is a problem, the comparison of the actual process or product to the standard will reveal a variance.

Substep 2c Does a variance exist? If there is no variance, then either the situation is problem free or the problem is not what it seemed to be. In either case, it is necessary to take another look at what the problem really is. The No output of substep 2c takes us back to the beginning of Step 2 for a new attempt at identifying or describing the problem. On the other hand, if a variance is found, we proceed to substep 2d.

Substep 2d Is there more than one variance? If only a sin­gle variance is indicated, the No output of this diamond takes us directly to the last element of Step 2, substep 2f, bypassing the need to prioritize. However, if upon examination more than one variance exists, then the Yes output of the diamond takes us to substep 2e.

Substep 2e Prioritize. When improvement teams ana­lyze processes, it is not uncommon to find multiple possi­bilities for variances. Usually, some will be more important than others. Since it is impossible to solve them all at once, it is important to rank them so that the most significant is solved first. Pareto analysis² is employed to establish priority. As we saw in Chapter 15, Pareto analysis is very simple, yet extremely powerful. The FMEA techniques are also useful.

Substep 2f Set an improvement objective. We arrive at this block with a single problem in mind, either because there was only one problem or because we deliberately selected the most important of a set of problems. At this point, you will notice that we do not have a solution in mind, nor do we necessarily have a handle on what is causing the problem. Knowing only that we have a problem, what do we want the eventual problem solution to accomplish? If we simply want the production line to start moving again, then our objective might be to find a quick fix and go back to work. However, notice that the model does not say “set a repair objective” or even “set a solution objective.” Instead, experts use the phrase “set an improvement objective” A problem that is merely a fix or repair to the previous state or that is anything less than an improvement is unthinkable. Depending on the kind of problem being worked, the objective might be to make the relevant process step foolproof (in Japanese, poka-yoke) so it is impossible for the problem to recur or to make a product more reliable.

Step 3: Determine the Point of Cause (POC) Armed with a problem definition and an improvement objective from Step 2, we now have to determine the location, geo­graphically and within the process or product, of the prob­lem’s cause. Where did the problem manifest itself? Was it in a production process? Was it in the test department? Was it in a review of a process or design? The intent of this step is to move our attention upstream to where the problem’s cause took life. That could be far removed from where the problem was first detected.

Answers to these questions lead to the next step.

Step 4: Determine the Root Cause Using the Five-Why Analysis Caution must be taken at this step. It is often easy to determine a cause that seems to fit the problem perfectly and yet does nothing to prevent the problem from recurring. Remember, in addition to eliminating the imme­diate problem, we want to improve the process in a manner that will prevent a later recurrence of the problem.

The following case illustrates the Five-Why methodology:

A firm discovers that it has been purchasing materials that are not actually required. In addition to the cost of purchasing, these unneeded materials represent an expen­sive inventory that requires warehousing, handling, and tracking. All of those costs translate directly to the firm’s bottom line as loss of profit. A team is established to de­termine what is causing the problem and to develop a solution.

We pick up at Step 4 of the Practical Problem-Solving Process, as the team is beginning to employ Five-Why analy­sis to determine the real cause of the problem.

First Why By asking “Why are we buying materials that we do not need?” the team quickly determines that the un­needed purchases are the result of purchasing department purchase orders. These purchase orders are being issued in response to material requests from the company’s two-year- old enterprise resource planning (ERP) system. The team’s collective reaction is “Aha!” The team has heard many hor­ror stories of flawed implementation of ERP (and MRP II, ERP’s predecessor) at other companies and is leaning toward the conclusion that their new ERP is yet another automated system run amok. But is a faulty ERP system really the cause?

Second Why To understand the problem more fully, the team members have to understand how ERP works, so they ask, “Why does the ERP system issue requests for material?” The answer takes them a layer deeper. An ERP system plans material purchases by comparing anticipated demand to on- hand inventory. If the comparison shows a demand that can­not be satisfied by materials on hand, ERP generates material requests to the purchasing department to fill that shortage. For example, if the ERP knows that the factory is to produce 100 widgets next month and it knows that in order to do that manufacturing will require 100 X assemblies and 300 Y as­semblies, ERP will check inventory to see how many X and Y assemblies are in stock beyond current demand. (“Current demand” refers to assemblies already set aside for another purpose.) If the inventory shows 116 X assemblies and 240 Y assemblies in stock beyond current demand, then ERP will recognize that the stockroom has 16 more X assemblies than needed but has a shortage of 60 Y assemblies. ERP will then generate a material request to notify the purchasing depart­ment that 60 additional Y assemblies must be purchased. ERP is doing exactly what is intended: it is making certain that when a production schedule is activated in the factory, the necessary materials are on hand to support it. Still, a large percentage of its material requests are subsequently found to be invalid, and the stockroom is becoming bloated with ma­terial for which there is no known future demand. The team agrees that it does not yet know the cause of the problem.

Third Why The team members need to determine the cause of the erroneous material requests. They ask, “Why are many of the ERP material requests invalid?” The ERP sys­tem is a computer program with access to various relevant data and information relative to the enterprise. As is almost always the case, the computer has to assume that its informa­tion and data are valid, accurate, and up-to-date. As we have already seen, only two sets of data come into play when the system checks to see what material should be ordered: mate­rial demand and inventory. Either of those being incorrect will result in (1) invalid material requests, (2) the absence of needed material requests, or, more likely, (3) both. The ERP determines material demand based on production require­ments that are entered by the various product lines. The team finds those data accurate. Inventory data are fed by the stockroom directly to the ERP database. The team’s physi­cal spot-checks of inventory associated with several of the invalid material requests reveal inventory errors. The team is now satisfied that the ERP system is not the cause of the problem. The cause instead seems related to inventory ac­curacy. Is inventory accuracy the root cause? No. Something else had to cause the inventory to be inaccurate.

Fourth Why Having determined that the inventory data contain errors, the team asks, “Why are the inventory data inaccurate?” The team is told that for the last decade, the stockroom of over 5,000 line items has maintained an inven­tory accuracy of 95 to 97%. The accuracy level yielded by the inventory control system is a real point of pride among those in the stockroom responsible for charting the inventory data. Indeed, an inventory accuracy of 95 to 97% was probably adequate before the company implemented the ERP system. But with the implementation of ERP’s automation, there is now little human intervention or double-checking of pur­chase transaction validity. What is more, the people who used to do that have been shifted to other jobs or are no lon­ger with the company. It is all left to the computer. With an inventory accuracy of 95 to 97%, it is guaranteed that many, if not most, of ERP’s material requests will be invalid in one way or another. The team concludes that inventory accuracy that had been satisfactory under the old manual system is no longer good enough. When the ERP system was imple­mented, no corresponding upgrading of the inventory sys­tem had taken place. Is this the root cause?

Fifth Why The team members are beginning to think they are almost there, but they decide to probe at least one layer deeper. They ask, “Why wasn’t the inventory system upgraded in concert with the ERP implementation?” The evidence is that when management decided to replace the company’s long-standing manual planning system with ERP, the organization did not understand that a virtually error-free, real-time inventory would be required. Inventory accuracy had not been a problem over the years; hence, no effort was made to change inventory equipment, procedures, or methods. Management had been in the dark. Is that the root cause? The team doesn’t think so. After all, no one—not even experienced, well-paid managers—knows everything. The root cause, as determined by the team, is that the orga­nization has no effective internal planning process in place to ensure that when new systems are implemented, the relevant infrastructure is capable of supporting it. Had such a process been in place, the right people would have found that the existing inventory system was incapable of supporting ERP.

Beyond the Fifth Why Five Why’s will usually lead to a root cause, but occasionally a sixth or seventh may be use­ful. In this case, we could have asked “Why?” once or twice more to find out why the cited procedure didn’t exist, but that would not seem to be very productive.

Step 5: Develop and Implement a Countermeasure Continuing, the team found it easy to articulate their solu­tion (countermeasure). It has four components:

To correct the immediate problem,

1. The team must acquaint the management with ERP re­quirements for inventory accuracy.
2. Management must commit to, and support, the upgrad­ing of the inventory system.
3. Until virtually 100% inventory database accuracy is achieved, the organization must restore manual checks on the system to prevent unnecessary material orders.

To prevent similar problems in the future,

4. A procedure must be implemented to ensure
5. Understanding of the needs of prospective new sys­tems before committing to them.
6. Concurrent availability of suitable infrastructure support for any new systems that are implemented.

Step 6: Determine the Effectiveness of the Countermeasure The team now has to determine whether the improvement objective developed in substep 2f is being satisfied by the implementation of the countermeasure. This may be done by testing and monitoring until the accumulation of data can determine a statistically valid “yes” or “no” answer. Should the answer be “no,” then the team must come up with a different countermeasure. Once the answer is “yes,” the team can proceed to the final step.

Step 7: Change the Standard Whether the “standard” in question is a product specification, a manufacturing pro­cess, or a work instruction, the team must update it to re­flect any change(s) made through the countermeasure. This documents the improvement made and becomes the new standard for the process or product, to which all relevant employees will adhere.

Source: Goetsch David L., Davis Stanley B. (2016), Quality Management for organizational excellence introduction to total Quality, Pearson; 8th edition.