Search around on the web for Root Cause Analysis, and you're likely going to find article after article discussing the Five Whys (or 5 Whys, or 5Y) technique. This method is especially popular in manufacturing, where the main concern is often productivity -- maximizing production rate and minimizing rejects. I've heard many Six Sigma and Lean practitioners talk about this as one of their favourite tools. I can understand why, too... it's easy to remember, simple to apply, and gets deeper than traditional problem solving. However, it also contains some traps.
For reference, here is one fairly detailed procedure for performing the 5 Whys: (link). In summary, you simply ask "why did this occur", and after you answer that, you ask "why did that occur", and so on. You keep going until you get to something fundamental, or until you reach something that's completely outside your control. A rule of thumb seems to be that 5 iterations is a reasonable average, but this is not a hard rule... it may take only 3 levels of "why", or you may still be asking "why" 5 weeks from now. It just depends on the problem.
Now, can you spot the problems in the procedure summarized above? I can think of a few, but there are two that I think are really important. First, there is the assumption that a single cause, at each level of "why", is sufficient to explain the effect in question. This is rarely the case! Most often, you need a set of Necessary and Sufficient causes to create any single effect. Second, what if one of your "why" answers is wrong? Maybe your answer was possible, but what if the actual cause (i.e., set of causes) was something else entirely? Even worse, what if your seemingly plausible answer was completely out to lunch?
One of the advantages of the 5 Whys is that it gets you to fairly deep, underlying causes. A major disadvantage is that if you make a mistake answering just one "why" question, your entire analysis gets thrown off. Even worse, the earlier your mistake in the process, the further off your root cause is going to be. At that point, it won't matter if you ask "why" 5 times or five million times.
If you want to avoid these problems, try modifying the questioning process as follows. Once you've finished your initial line of questioning, go back to your answer for the first "why" and ask some other questions.
- What proof do I have that this cause exists? (Is it concrete? Is it measurable?)
- What proof do I have that this cause could lead to the stated effect? (Am I merely asserting causation?)
- What proof do I have that this cause actually contributed to the problem I'm looking at? (Even given that it exists and could lead to this problem, how do I know it wasn't actually something else?)
- Is anything else needed, along with this cause, for the stated effect to occur? (Is it self-sufficient? Is something needed to help it along?)
- Can anything else, besides this cause, lead to the stated effect? (Are there alternative explanations that fit better? What other risks are there?)
The point of these questions is to establish existence, necessity, and sufficiency. Keep asking these five questions for every cause, at every level of questioning. If you diagram all this, you will end up with a tree of causal factors leading up to the original problem. Some may be less important than others, but you will have a much more complete picture of the causes leading up to your problem. Even better, you may find a more important cause than previously considered. At the very least, you will have avoided the "straight-line causation" trap.
I hereby dub this modified process the Five-by-Five Whys (5x5 Whys). Feel free to share it with anyone you think might be interested.
Note: If you want to expand a Five-by-Five Whys analysis into something more robust, try upgrading to a Causal Factor Tree Analysis... it's the next logical step, and it's not much more work.
Christian Paulsen at Lean Leadership has a great article on a Multiple Path 5 Whys method. It basically implements a "tree of causal factors" similar to what I suggested above, and the examples provided illustrate very well how such a thing would look. It does have one potentially significant problem, but luckily, we already have the means to solve it. In Christian's own words:
The difference with the Multiple Path 5 Why is that there will be more than one answer to some or all of the why’s. My suggestion is that you only include the answers that you believe are contributing to the issue. The 5 Why can spin out of control and become too complex if you include every conceivable possibility.
The 5 questions provided by the current article (to prove existence, necessity, and sufficiency) provide the means to limit what gets added to the analysis. By filtering out items that don't pass the logical tests encoded in the questions, you can keep the analysis under control and on track.
by Bill Wilson
Interesting post. Your 5 questions are good ones and can be used to help validate the root causes. Thank you!
Chris, Thanks for stopping by and taking the time to consider what I proposed. In addition, thanks for your article on Multiple Path 5 Whys. It is a perfect companion to this article, so much so that I decided to update it to reference yours (see last few paragraphs). I think the two methods would work perfectly together!
The actual root, not the cause:
Birmingham Jug Band
Bill Wilson had a baby
You could hold ‘m in the pad of your hand
Says the last word I heard the baby cry
Wanna be a wagon drivin’ man, Lord
Bill Wilson had a woman
Say the dress she wore was red
Say the last word I heard that poor gal say
I’m gowine where poor Billy fell dead, Lord
Bill Wilson went to the mountain
It was so tall and high
If I can’t climb this mountain, Lord
I’m gonna lay at the feet and I’ll die, hey
Thank you Forester, for the slightly odd comment… but I like it! 🙂
This comment sucks. It answers no questions. Just asks more!!!!
Hi Randy, are you talking about a reply to this blog post, or the blog post itself? Regardless, my reply to you is: the road to better insight is paved with questions… and the more questions you ask, the further you can go.
Hi Bill, your 5X5 Whys model sure adds validating questions to what is otherwise a fragile analysis. Thank you for that!
On your comment on my blog post, you mentioned high-risk work like nuclear power plants requiring more robust root cause analyses, which is a great counter-point to low- or medium-risk work that many Agile software teams perform.
I wonder if this more robust 5X5 Whys model would be accepted by those sorts of Agile teams, and if not I hope at least that the validating questions will be held as heuristics in the course of a more standard 5 Whys.
Have you had a chance to try this in dev shops or have heard of it being used? I’m curious as to how it has been received, and if any modifications were made by those teams.
Thanks for visiting and for leaving a comment. I don’t know if anyone has taken this up as common or expected practice. However, of all the things I’ve written about on my blog, this is the one that has been referenced the most by others in blogs, reports, journals… even a book or two. To be honest, my intention with this blog post was not necessarily to create something that would supplant 5 whys as a problem-solving method, but rather to point out that the “single path causation” model embedded within it is a trap. One need not remember the proposed 5 questions in detail in order to avoid the trap… even just the idea that a “why” question can be answered “this -and- this” is enough to arrive at a much better result.