Search the Elsmar Cove!
**Search ALL of** with DuckDuckGo including content not in the forum - Search results with No ads.

5Why vs. 8D - Problem Solving

Bev D

Heretical Statistician
Staff member
Super Moderator
Kiran - there are a few misinterpretations in your statements.

First 5-why is a method for determining the causal mechanism, while 8D is a total framework for solving a problem, only 1 step is focused on determining root cause. Other steps focus on containment, solution validation etc. In other words 5-why is an available ‘tool’ for 1 of the steps in the 8D process. Kenner-Tregoe’s Approach can be used with 5-why (they are not mutually exclusive)

5-why is not necessarily fast if done correctly (Miek S is correct, the failure of any of these tools belongs to the ‘user’ not the tool)

Dorian never said you had to get all 3 X’s. He merely stated that it was of course possible that any Problem could have a primary, secondary and even tertiary causal mechanisms that were main effects. he stated that most problems could be reasonably resolved by finding the ‘dominant’ cause or the red x. He was not a proponent of the ishakawa (fishbone) diagram. Indeed he dedicated his life to the elimination of it. Dorian essentially used 5-why but with much more rigor and specific analytical tools to answer the 5-why questions.
Paid Advertisement - Forum Supporter

Coury Ferguson

Moderator here to help
Staff member
Super Moderator
We use the 5-Why as an initial Root Cause tool. We also use various other tools in the RCA tool box. We usually issue a 5-Why for internal issues. The 8D is used to respond to an external complaint and issue to the Supplier base. The 5-Why is just another tool that can be used in determining RCA. Each has it's own value. Just my opinion here.

Jim Wynne

Super Moderator
Normally the 5 Why technique leads to a ‘single’ dominant root cause, which serves the purpose if the organization is in a hurry. Or when the problem solvers are junior employees not well versed in scientific methods. However, as Dorian Shinin recommends, one needs to find and eliminate at least three root causes, which he calls as Red X, Pink X and Pale Pink X, in order to solve the issue near completely. That could be only be done thru’ methods like Ishikawa Diagram; applied to Occurrence as well as to Detection. So, best is to use both the methods preferably supported by Kepner Tregoe method to isolate the real causes.
In nearly all cases, the ideas here are gross overcomplication. All of this boils down to something H. L. Mencken wrote in 1920: "Explanations exist; they have existed for all time; there is always a well-known solution to every human problem—neat, plausible, and wrong." A good example from history is the ancient belief that the Earth is at the center of the solar system (geocentrism) as opposed to the Sun being at the center (heliocentrism). Geocentrism was based upon the best evidence available at the time, thus the explanation was "neat, plausible and wrong." What we have to get past in manufacturing is the idea that solutions that are neat and plausible are always correct. This is where things like 5-Why come in.

We also need to get past the idea that people who are untrained ( "...when the problem solvers are junior employees not well versed in scientific methods") are good candidates for jobs that involve deductive reasoning, and may be poor candidates after training. Some things can't be taught to everyone. I think that 5-Why can be a serviceable training tool, but as general practice it usually indicates incompetence on the part of the people who are expected to use it.


A Sea of Statistics
To add yet more to this contentious issue, practical experience informs many, not all, that one can have a variety of "effective tools", yet many sit unused, they only provide value if used....have witnessed and intervened on many a "Root Cause" process, and most of the info is verbal, no structure, no form to capture and memoralize the important details of the supposed Root Cause...and associated CA near term and a word "discipline"


Quite Involved in Discussions
Would a capable person with experience in your company's processes come up with a better RC without tools than a novice with tools?
Basically it's not the tools but the person's ability that is really the way to get to the real RC? A mix of knowledge, experience and integrity.
I might be wrong but it seems sometimes tools are given too much credit or importance.

Bev D

Heretical Statistician
Staff member
Super Moderator
I’ve written about this before. The ‘need’ for tools is really dependent on the complexity and type of the Problem to be solved. First scope matters: I am not talking about world problems like hunger or terrorism or climate change, I am talking about ‘quality’ problems in the industrial and service industries. There are really two basic types of problems that we think of when we discuss 5-whys and 8D and other ‘tools’ and frameworks. People process problems and physics process problems. People problems are defects created incorrect actions that. People take (things like putting the wrong label on a box) and physics problems are defects and functional failures of products and equipment (things like a porous membrane that inhibits the flow of blood through it’s length). These systems can intersect at times. But more frequently this intersection is improperly invoked: physics problems are blamed on people (if only those operators would do their jobs properly...).

If the causal system is simple very few tools or methods are needed. In fact the blind application of tools can mislead and/or slow down the diagnostic process. However, if the ‘investigator’ doesn’t have the right mindset and understaninding of causal systems tools and methods won’t help them. There are plenty of examples of this in the continual debate here regarding the role of training and ‘attitude’ of operators in errors. Optimist touched on this very bluntly: I’ve seen far too many 5-why’s filled out in great detail with supposition and bias that concluded that the operator needed to retrained - again - or just fired. Inevitably, the investigator didnt’ understand how people can make errors, didnt’ have nay understanding of the actions that can be taken to prevent errors (and the grand majority of them are NOT expensive - that rationalization is just based on ignorance of prevention systems) coupled with laziness//“i don’t care” attitude. This is a result of the culture of blame. In these cases of simple casual systems, 5-whys is not so much a tool as it is an admonition to dig deep, get off your butt and go study the process with knowledge of the things we can do prevent errors and really get to the deep cause; it is not something to pencil whip and file away. I don’t teach 5-why for these systems - I coach people through them and educate them on simple causal systems through doing. These ar mostly people processes but can be physics processes as well.

Then there are complex causal systems - these are mostly physics processes. I have found that we need several things to get to the causal system: solid statistically sound diagnostic study designs (tools), a framework for decomposing the Problem (I use a progressive Y to X approach), scientific expertises, a cross functional team and discipline to follow the data. Scientific expertise is necessarry but not sufficient. Tools are necessarry but not sufficient.

Anyway this is my experience....

Mike S.

An Early 'Cover'
Scientific expertise is necessarry but not sufficient. Tools are necessarry but not sufficient.
This gets my vote for quote of the day. It's not either/or, it's both.

Imagine having a bad starting capacitor in your HVAC unit at home. You need the process/scientific knowledge to know how to diagnose the problem, how to test the old capacitor, etc. But without the tools to loosen the fasteners on the control panel cover, or to test the capacitor, you're stuck. You need BOTH.

Sometimes the tools can be simple and the science complex, or vice-versa, and sometimes both are simple, sometimes both are complex.

John Predmore

Quite Involved in Discussions
which step should be put in the 8D template as a root-cause for occurrence / non - detection? The first one or the last one?
There is a riddle about why keys (or any lost item) are always found in the last place I look. It's because after I find the keys, I stop searching!

I always thought the idea of "root" cause was a misnomer. In my definition, the root cause of the problem is more a statement of my situation rather than anything to do with the nature of the problem.

For me, my root cause is when I stop searching, because I found an answer where
1) something identifiable happened (or the inverse),
2) changing the something effectively eliminates/diminishes the problem, and
3) changing the something is within my control.
Unless my discovery meets criteria 1-3, I keep searching.

As an example, if I receive rusty parts from supplier A and I don't have that problem with parts from supplier B, then from my perspective the root cause of the problem could be simply supplier A versus supplier B, I don't have to go any further. Everything else being equal, the obvious fix is to buy parts only from supplier B, that decision is within my control, problem solved.

Now if supplier A faces loss of business and he is smart, he will do a 5-Why on his problem. He might notice parts only rust when it rains, and he is tempted to state rain is the root cause. However, whether it rains or not is outside his control, so he has to dig deeper. Maybe rust develops in the storage of parts. Storage conditions is within Supplier A's control, but he still needs something identifiable to change. Supplier A does a study and finds only parts on shelf 103 rust because of a leak in the roof.

Whether Supplier moves shelf 103, or covers shelf 103, or fixes the leak, that answer meets criteria 1-3. Was the root cause the shelf or the location of the shelf or roof leak or fact that shelf 103 was uncovered, it doesn't much matter. Whichever aspect of the problem supplier A fixes, and the problem is effectively eliminated/diminished, that aspect was the root cause. Supplier A's root cause analysis went deeper than the customer's on the same problem, because their situations were different. Thus the idea of "root cause" is relative not absolute.

Bill Levinson

Involved In Discussions
Final cause (Answer after asking last why) is the root cause. And root cause for both occurrence and non-detection has to be addressed in 8D and necessary actions have to be taken to eliminate both of these root causes (Corrective action).
IATF16949 additionally asks to identify root cause related to system as well (If your organization is IATF16949 certified / seeking certification).
This is a very important point, and it is addressed in CQI-20 (Effective Problem Solving) from AIAG. We need to look for the three root causes you describe:
(1) Occurrence root cause (the traditional one, why it happened)
(2) Escape root cause (why the problem reached the next operation, if it did)
(3) Sytemic root cause, why the quality planning system did not foresee the problem.
Top Bottom