Every investigation into a problem includes the question, Have we found the root cause?" followed by an extended discussion about how to find the root cause. Inevitably, someone says, "You have to ask ‘why’ five times,” which draws confirmation from everyone concerned that “5 Whys analysis” is the right thing to do. The 5 Whys analysis is an iterative investigation technique used in Lean (and informally in other continuous improvement methods as well) that asks an analysis team to ask “why” five times in an effort to get to the root cause.
But is it really that simple?
Granted, asking questions is how one resolves problems. Still, despite all the confirmations from the team, no one actually thinks that five is the exact number of questions to ask to get to the root cause, which then brings you back to the original question: How do you get to the root cause? My word, what a paradox! To add to the confusion, you must first identify the symptoms and potential causes before even getting to the “root cause”! So, how do you determine the difference between a symptom, a cause, and the root cause?
Distinguishing between a symptom and a cause turns out to be relatively easy.
Analyze the problem description. If you are describing a characteristic of the problem, you are talking about a symptom. You may be talking about a symptom of a problem or a symptom of a cause, but you are talking about a symptom. If you are talking about making a specific adjustment to a process or piece of equipment (or a need to replace or repair something), you are talking about a cause. Let’s look at an example.
An oven used for curing adhesives does not hold a constant temperature. This is a problem and the fact that the oven’s temperature is not consistent may be a description of the cause for the adhesives not curing. A discussion on the inconsistency of oven temperature will expand to include the symptoms of the problem; for example, the oven temperature drifts higher every 30 minutes, or the oven temperature spikes every 5 minutes.
The key to differentiating symptoms from causes is that you do not fix symptoms; you fix causes.
If you are trying to determine how to control or correct the inconsistent temperature of an oven (as an example), you are focusing on a symptom, not a cause. The inconsistent oven temperature is the cause of the adhesives not curing, but something is causing the oven temperature to drift and that needs to be fixed.
Now we know how to differentiate a symptom from a cause. At this point, we should be able to ask “why” five times to get to the root cause…right? No. Not yet.
The other part of the process that can be confusing is determining the "real" root cause. This is a little more complicated because the answer to the question, "What is the root cause?" is a matter of perspective. Let's take a look at another example:
A customer is unhappy because their cell phone is not working.
According to them, the root cause (the primary reason for being unhappy) is that the battery will not hold a charge. The solution to their problem is to replace the battery (or the phone); from the customer’s perspective, the problem is solved.
However, from the phone vendor’s perspective, the battery getting to the point of not holding a charge is premature because the phone is only three months old. The vendor will contact their supplier (the phone assembly company), who will determine that the battery was part of a bad batch. From the vendor’s perspective, this is the root cause, and they must check the inventory to identify other phones with that batch of batteries so the assembly company can replace them. The vendor’s problem is solved.
The phone assembly company then contacts the battery manufacturer who determined that the machine that filled the batch of batteries with chemicals was not working properly (its root cause), so it fixed the machine. Has the root cause been determined, and the problem solved? Well, not yet. Did the machine malfunction due to incorrect or poor use or maintenance instructions or because of another issue? These questions must be answered to determine the root cause for the battery manufacturing company.
If you asked the customer, the symptom was that the phone was not holding a charge, and the cause was that the battery was failing (as opposed to some other factor that may have been drawing too much power). From the vendor’s perspective, the battery failure after only three months was the symptom, and the bad batch was the cause. Determining the root cause depends on whose perspective you are viewing.
From the assembly company’s perspective, the root cause may be that the battery supplier is unreliable. To fix this root cause, the company stops using that battery supplier. From the battery manufacturer’s perspective, the machine malfunction was caused by an improper maintenance procedure. Fixing this root cause requires a new maintenance procedure.
Getting back to the original question of how to find the root cause:
The advice of “ask why five times,” is not really all that useful. As illustrated in the previous discussion, determining the root cause requires finding the source of a problem at the lowest level of control available from the perspective of the person making the root cause determination. This means that the root cause from the phone supplier will be different from the root cause from the battery manufacturing company.
Asking as many questions as it takes to identify the symptoms and causes at each level of control until you get to the lowest level of control is how you determine the root cause.
For discussions on more manufacturing analysis topics, check out Vokey’s latest book from ISA: CoE: The Key to Data-Driven Manufacturing.