(EN) The Eight Disciplines Problem Solving (8D)—D4

In this series of posts I go through the Eight Disciplines Problem Solving (8D) in more detail. In my last post, I talked about D2: Describe the Problem and D3: Develop Interim Containment Plan. In this post I will go into more detail of D4: Root Cause Analysis and Escape Points. (Now you can probably guess what my next post will be all about too.) Read on!

Recap: Eight Disciplines Problem Solving

Just for reference, here are the eight (nine) steps of the Eight Disciplines Problem Solving (8D).

• D0: Preparation and Emergency Response Actions
• D1: Establish a Team
• D2: Describe the Problem
• D3: Develop Interim Containment Plan
• D4: Root Cause Analysis and Escape Points
• D5: Develop Permanent Solution
• D6: Implement Permanent Solution
• D7: Prevent Recurrence
• D8: Close Problem and Recognize Contributors

D4: Root Cause Analysis and Escape Points

The discipline D4: Root Cause Analysis and Escape Points has two sub parts. The first one should be pretty clear: the root cause analysis. You try to understand the root causes for your problem. The second part with the escape points is a bit harder to understand, but still sensible: figuring out why you did not become aware of the problem earlier. This second point is not included in all 8D structures I have seen, so it may be a later add-on.

But let’s first go deeper into the root cause analysis. In the preceding discipline D2: Describe the Problem, we looked at a lot of data to understand more about the problem. A good understanding gives you the foundation for the root cause analysis. During this problem description you may have already gotten some ideas where the problem may come from. In not-so-good companies, that is what the (presumed) solution is based on. In reality, however, this only addresses the symptoms.

In better companies, however, you dig deeper, trying to find the fundamental, underlying reason(s) that causes the problem. The root cause analysis starts with a list of possible causes of the problem. Note that these are usually not (yet) the root causes, but may often simply be the symptoms or some interim causes. If you have not yet done a fishbone diagram (also known as Ishikawa diagram), you should do so now. You could use the structure Man, Machine, Material, Method, or similar structures. See also my blog post Asking Man—Machine—Material—Method… and Then Some… for the Toyota Practical Problem Solving for more detail.

However, the fishbone is only one possible tool, and you can also use brainstorming, mind maps, or other creativity techniques. Six Sigma also uses a Fault Tree Analysis (FTA), establishing a tree-like-structure from the original problem down, where each new level has the contributors for the level above, including their logical relation. This Fault Tree Analysis is highly structured, but I am worried whether the structure also makes it more rigid and less flexible. But if it works for you, go for it.

Overall, you should have a list of possible causes and hence directions to analyze. These are interim causes, not necessarily root causes. Now, each of these causes need to be checked to see whether they are relevant, and if so what their root cause is. Some causes can be determined as irrelevant easily. But others need more analysis. In this case, checking for its relevance and finding the root cause is the same step; if you don’t find a relevant root cause, the original cause is not relevant.

You are probably familiar with the tool to check for root causes: 5 Why. You keep on asking „why“ until you find what you believe the true root cause, or decide that this path is not fruitful and following up another cause with 5 Why is better. Not every cause in your list of possible causes may be a winner, and some are better ignored, which you will find out by doing the 5 Why. Note that there are not always necessarily exactly 5 Why; there may be more or fewer. Additionally, it may make sense to check the validity of the 5 Why chain using a „therefore“ test. Below is an example of a 5 Why including a  therefore test for a car that does not start.

This search for the root cause using 5 Why should be done for all possible causes you listed earlier. While not every cause results in a good root cause, you should have at least one, and hopefully more root causes that are plausible. If not, continue investigating causes for good root causes.

The second part of the discipline D4 are the escape points. We want to identify the point in the process where the problem should have been detected but was not. It’s about understanding the failure in the control system that allowed the defect or issue to „escape“ to the customer or later stages of the process. Is there a checkpoint or control point between the source of the problem and the customer that should have detected this problem or its root cause? If there is such a checkpoint, why did it fail to do so?

The goal with the escape points is not so much in fixing the root cause of the problem, but rather to improve the reliability of detecting problems. Ideally, your root cause problem analysis and its solution will permanently solve this problem, and you may not need better detection for a problem that (hopefully) will never happen again. On the other hand, while you want the problem to never happen again, reality may disagree with you and the problem MAY happen again, and needs to be detected. You may also have similar problems in the same or also in other products that you have not yet resolved, or may not even know about yet, but would like to find these before the customer finds them for you!

Hence, this discipline D4 not only tries to address the problem at its root cause, but also through better detection of the problem. In my next post I will continue with the disciplines D5: Develop Permanent Solution and D6: Implement Permanent Solution. Now, go out, detect the root causes of your problems and close the escape points, and organize your industry!