Posted by
Tailchi Ohno, the creator of the 5-Why technique, is quoted using the following example to demonstrate using 5-Why’s for root cause analysis:
1. “Why did the robot stop?”
The circuit has overloaded, causing a fuse to blow.
2. “Why is the circuit overloaded?”
There was insufficient lubrication on the bearings, so they locked up.
3. “Why was there insufficient lubrication on the bearings?”
The oil pump on the robot is not circulating sufficient oil.
4. “Why is the pump not circulating sufficient oil?”
The pump intake is clogged with metal shavings.
5. “Why is the intake clogged with metal shavings?”
Because there is no filter on the pump.
What do you think? Is “NO FILTER ON THE PUMP” a root cause?
Let me know your comments.
And if the inventor of 5-Why’s uses this as an example, should people call 5-Whys a root cause analysis technique?
Category: Root Causes
51 Comments »
RSS feed for comments on this post. TrackBack URL
Well, I guess you have to know the why-why analysis by taichi emphasis on resching five levels which means that “No filter on the pump” may be the solution, but if it is taken to the sixth step then probably the answer or solution would be “Bad Design of the Pump”..which means back to the drawing board.
Sometimes solutions may be within your control on the 5th why, going on to further levels may lead you to a solution that may have implications on the cost, time and etc…we can keep on doing the why-why’s till there’s no end..so I guess taichi may have looked into solutions that can be handle resolved within constraints…
Comment by Anthony — August 21, 2007 @ 1:34 am
Regarding the example: weak. Indeed. Maybe 5 more of these and you’ll be getting close to a root cause (maybe maintenance, maybe design, maybe something else, who knows…).
More generic: I’ve said this before (I believe even on this blog in a comment to Mark’s earlier root cause/5 Why article): people who think that 5 Why is actually a “technique” or “method” should wake up and smell reality. It’s sometimes a good help to get a bit further, but it should be applied with extreme care and NEVER be relied on as the sole tool.
Comment by Carsten — August 21, 2007 @ 8:59 am
And why were there metal shavings?
Mark
Comment by Mark Paradies — September 11, 2007 @ 9:37 am
Is “NO FILTER ON THE PUMP” a root cause?
This depends if the oil condition (amount of metal shavings) is normal / reasonable to anticipate. If the oil is as expected, this would work as a root cause. Otherwise, you should continue the “whys”
Comment by Bontjes — September 11, 2007 @ 9:43 am
Don’t miss my point.
This is the guy who INVENTED the 5-Why technique and this is his example of how 5-Whys should be used.
I can’t imagine so many metal shavings that they clog a pump without a problem that causes the metal shavings.
But more importantly, this is really a troubleshooting example … not a root cause analysis example. Once we finish troubleshooting and find the cause of the shavings, we will be ready to start to identify the Causal Factors and then START the root cause analysis.
Actually if I knew more about the robot, this might be a good Equifactor® troubleshooting example.
Comment by Mark Paradies — September 11, 2007 @ 9:49 am
The 5-Why is a useful exercise to track a single line of cause and effect but it seems to lead to a causal factor rather than a root cause.
In the example we end up with “No filter”. Because of the linear model, we left the metal shavings halfway up. The metal shavings are indicative of a problem in the system (robot) that is not corrected by a filter.
If we only pursue the “filter” fix, we only correct a symptom.
There could be many hidden causal factors and root cause that have been bypassed in a single line of cause and effect.
Are there metal shaving because the robot is lifting beyond its capabilities?
The design without the filter may be adequate if the machine is not operated outside its design parameters.
The advantage of a technique that examines mutiple causal factors is the ability to capture unrelated symptoms of the actual root causes by asking more questions in parallel cause-effect chains.
Comment by Chris DeMott — September 11, 2007 @ 9:50 am
Yes! But one more thing to consider…
The 5-Whys don’t lead you beyond your current knowledge.
Current knowledge in this simple example might have been … use a filter!
Human error problems are even more challenging when all you have is current knowledge and 5-Whys!
Comment by Mark Paradies — September 11, 2007 @ 10:03 am
To quote from the Wikipedia: “The five iterations are not gospel; rather, it is postulated that five iterations of asking why is generally sufficient to get to a root cause. The real key is to encourage the troubleshooter to avoid assumptions and logic traps and instead to trace the chain of causality in direct increments from the effect through any layers of abstraction to the first or root cause.”
Additional thoughts: Before you are too critical of Toyoda you have to look at the context and the time frame. Toyoda didn’t invent asking Why. He may have been the first one to put write it down as a “tool” with a cut-off on the number of why’s that “generally” lead to a root-cause.
Asking “Why” -without a limit on the number of times – was taught to me as an anlysis tool almost 40 years ago. We were also taught to be critical of our own work, avoid assumptions, seek expert advice and to verify our findings, especially if the answer came too easily or too quickly.
Comment by Jim Conroy — September 11, 2007 @ 10:45 am
Thanks for the comment.
Yes – Sakichi Toyoda was the developer of 5-Whys and probably started it more than 40 years ago (at least by 1950).
I agree that for the age – 1930′s – 40s – 50s … 5-Whys wasn’t too bad.
The problem is that many people are still using 5-Whys as their main root cause analysis tool and think that results like “no filter on the pump” are root causes. Thus, use of 5-Whys doesn’t get people to root causes … rather it is a toubleshooting tool that gets them to a single Causal Factor (and maybe not the only Causal Factor).
These Causal Factors need to have a systematic analysis that gets people beyond their current knowledge to find real, fixable root causes.
That’s the reason that I posted this example. To demonstrate the limitation of the tool EVEN when used by a master (Taiichi Ohno). If he doesn’t get it right, what chance do others have?
Comment by Mark Paradies — September 11, 2007 @ 11:07 am
’5 Whys’ is not an effective tool to use to determine systemic/process problems with an event/incident. Although for certain situations it does work – the example is probably not a good example. There is also a question about the definition of root cause. Root Cause for 5 Whys is the same as immediate cause for TapRooT.
I use 5 Whys as a back check to see if I’ve determined the correct investigative path for an incident. If it passes 5 Whys then it reinforces my position on the incident case.
Comment by Bob Cargill — September 11, 2007 @ 11:10 am
The fact that there is no filter on the pump is not the root cause. The root cause lies mainly in the fact that a pump was in place that was not built correctly and was not tested prior to use. How many other pumps are out there without filters? What is the quality control check process like before pumps are put out for use?
Comment by Terri Sharp — September 11, 2007 @ 11:13 am
Bob – I agree the example is not good.
Here’s another example (this time from Wikipedia):
My car will not start. (the problem)
1. Why? The battery is dead. (first why)
2. Why? The alternator is not functioning. (second why)
3. Why? The alternator has broken beyond repair. (third why)
4. Why? The alternator is well beyond its useful service life and has never been replaced. (fourth why)
5. Why? I have not been maintaining my car according to the recommended service schedule. (fifth why, root cause)
This example (reviewed by many on Wikipedia) still has problems…
I’ve NEVER seen a service schedule for replacing an alternator … But let’s assume there is one.
The question still begs the answer:
1. WHY would someone not follow a schedule?
2. Would following the schedule have prevented the problem?
3. Should an alternate last longer and never require replacement for the life of the vehicle?
4. What is causing the alternator to age and can that be prevented?
5. Why didn’t the operator (driver) notice that the alternator was not functioning before the battery was dead?
Again, we are back into troubleshooting … This example doesn’t cause us to understand WHY the failure occurred and yet this example is another “standard” example used to explain the 5-Why technique.
Again – If the standard examples don’t work … Shouldn’t people be looking for a better technique?
Does anyone have a good 5-Why example for anything except an extremely simple failure?
Comment by Mark Paradies — September 11, 2007 @ 11:30 am
Posting for Lane LeClerc (The 5 why’s link did not function…)
There is more to the robot story.
I would have to ask question # 6 – Why was there no filter on the pump?
May lead to further questioning
Lane LeClerc
Comment by Mark Paradies — September 11, 2007 @ 3:25 pm
And one more comment …
Why are people still teaching 5-Whys (or asking a certain number of Whys (5-6-7-8-100) as a recommended root cause analysis practice?
Shouldn’t instructors (root cause experts) know better?
If asking Why 5 Times seldom produces a good root cause analysis, shouldn’t anyone who is knowledgeable teach people something more robust?
If someone is teaching 5-Whys as root cause analysis, should a reasonable person wonder about the teacher’s level of knowledge or sincerity about solving problems?
Comment by Mark Paradies — September 11, 2007 @ 3:39 pm
5 Why’s is being rolled out as a problem solving technique as part of Lean implementation on our site. The process is sound and leads quickly to a cause but can focus on one line of investgation.
I have highlighted to the consultants on our site that the advantage of Taprrot is that it does not discount lines of investigation early and can lead to a more thorough outcome that can truly prevent reoccurence.
Comment by Steve Armitage — September 11, 2007 @ 6:35 pm
OK I get the point, inventor, poor examples, however I tend to agree with Jim Conroy… It’s very easy for me to understand and even more importantly explain 5 Whys. I haven’t been to 5 Why’s training but my first exposure it was presented to me as a starting point for an organization who has no root cause process – it’s simple and requires no software. Perhaps asking just more than one why in some cases would be a good starting point. How many fuses you think were replaced before looking elsewhere? When do you think the pump problem was found? Before or after the robot bearing was replaced? When you are in reactive maintenance mode with pressure from operations and management to get it back running it is difficult to perform any root cause diagnostics, but to at least ask to one’s self why a few times may avoid you having to return. I see 5 Whys as an introduction to simple root cause for events that happen everyday. If I had invented 5 Whys or when my organization gets to a point where they determined it was/is flawed I would/will be ecstatic…they get it!!! Ok guys it is flawed, how do we fix it…let’s not limit it to 5 rather let’s get to the right answer and sometimes we may have to create teams, analyze data, review equipment history, put science to the investigation and yes maybe even use software to help document and illustrate the results.
One can argue the first example given is actually 7 Whys. Note: Why stopped? Blew fuse. Why Fuse blew overloaded ckt.. …Why? Locked up, Why locked up? Lubrication (it could have been several reasons). I think the conclusion of insufficient lubrication is a bit presumptuous but if accurate one would have to say the questions and answers given after that were wrong. Something happen before the pump clogged and this is a symptom not the cause. That is, unless normal operations calls for there to be filings produced in the bearing system…and design engineers forgot the filter… but I think not?)
In the second example, again wrong questions/ answers: 2. Why? The alternator is not functioning. (second why) The 3rd’s question’s answer should have been…3. Why? The alternator is well beyond its useful service life and had not been maintained according to my car’s recommended service schedule.
4. Why? Because I couldn’t afford replacing it and determine I would risk it? (fourth why) Stop or…5. Why? I have a crappy job and don’t go to work as much as I should. (fifth why, root cause)
Mark goes on but I would argue – Does this failure or even Root Cause matter? Can an applicable value added maintenance schedule, predictive or otherwise be developed? For me, it doesn’t matter and I have no motivation for getting a better job – run to failure. So why go on trying to figure out how to extend service, etc.? To an ambulance service, fire department maybe it does matter; depends if backups exist? I guess.
Lastly, I’ve been involved with only a few detailed root cause analysis investigations and look forward to further training and learning opportunities but I deeply believe that it would be very short sighted of me to say only performing a detailed RCA for every failure provides value as well as saying the 5 Why’s approach provides no value or is the answer in every situation. Each has its place it just depends and sometimes no root cause analysis is the best approach. Thanks for the discussion…
Comment by David A Martin CMRP — September 12, 2007 @ 12:50 pm
On Star Trek Spock said:
“An easly understood falsehood is better than an incomprehensible truth.”
However, this IS NOT the choice we are faced with.
The choice faced by people trying to solve problems is: HOW MUCH EFFORT IS NEEDED TO FIND A REAL, EFFECTIVE SOLUTION TO A PROBLEM? IS IT WORTH MY TIME?
My point is that 5-Whys are EASY and easy-to-understand but often don’t get us to an effective solutions. Thus no matter how easy the technique is, most people are wasting their time but they THINK they are doing effective analysis. What they are really doing is trying solutions and seeing what works.
I can’t remember who told me:
“Don’t mistake activity for progress.”
But I think that it could be applied to 5-Whys. People have activity (they are asking questions) but that doesn’t mean that the questions are helping them understand the problem and develop effective solutions. Instead, they are guiding the questions to get to answers THEY ALREADY KNOW. They then apply these answers which may work or which may appear to work (because the incident doesn’t repeat in the near-term).
The less likely the failure, the more likely people are to mistake activity for progress when the real problems have NOT been fixed (and are now dormant waiting for the right time to recur).
Another famous saying:
“Even a blind squirrel finds a nut now and then.”
Perhaps the people using 5-Whys are lucky that some of their answers work without actual root cause analysis and they make some progress without real understanding. That’s what I believe success with 5-Whys looks like.
Also, really smart people (experts) already know the answers to simple or familiar problems. They are just making 5-Whys get to the point that their brain has already arrived at. Thus, they make progress based on their knowledge. Unfortunately, this technique is NOT transferable to others without the knowledge.
Can anyone tell me how 5-Whys would get someone to an answer they didn’t already know? How would you ask the right WHY when you don’t already understand the cause-and-effect relationship?
That’s just one of the basic problems with 5-Whys.
Comment by Mark Paradies — September 12, 2007 @ 3:22 pm
Dear Mark:
First all the word “WHY ” must not be used in a Root Failure Analysis.
Use the words how, when and others not related directly to human behavior.
We must follow always the Root Failure Analysis tree and the Equifactor
Comment by SEIDEL MURIEL — September 14, 2007 @ 3:56 pm
I know this is way behind the times, but here it is anyway…
The greatest power to the 5-whys is that it provides an easily comprehensible presentation to people who are not knowledgable regarding specific RCA methods. To try to ‘sell’ an analysis with its charts and so on to a group of managers who’s last, or maybe only exposure to RCA methods was barrier analysis 25 years ago, is a waste of time and effort. You need to present something they can easily grasp and follow, and, regardless of what methods you use to do the analysis, they can usually follow 5-whys.
Trying to show them the snap chart and the tree is an exercise in futility. Unless, of course, the management staff has attended RCA training of sufficient depth to enable them to understand what you are talking about. I don’t find that scenario to be very likely.
So, use the RCA tools that get you a solid analysis that you can justify, then present it in a way your audience can understand. (I’ve got one management team that can’t understand anything but barriers, so after all of the analysis is done, it is translated to barriers so they can understand what happened and what needs to be done. They don’t care that the actual analysis is not barrier, that’s just how they want to see it.)
Does that make 5-whys a root cause method? Nope. But, it does make it a pretty good presentation tool.
Comment by Greg Prior — October 2, 2007 @ 9:54 pm
Greg
Thanks for your comment and I agree that 5-Whys and Why Trees aren’t very hard to present to management. I also agree that 5-Whys is not a good root cause tool. That said …
I’ve never had trouble presenting TapRooT results to management. SnapCharTs are easy for managers or factory floor folks to understand with zero training. In fact the usual response I’ve seen is … “We need to get our people to be able to investigate and present so clearly!” And we’ve have many on-site courses after managers saw a presentation and insisted that more people get trained.
Don’t underestimate the understanding of your audience. People on the factory floor and in the corporate boardroom are quick learners.
To me, your argument just proves that it would be a wise investment to get your management some advanced root cause analysis training. Otherwise, they might just decide to change the answers to the “Whys” on your 5-Why chart and get answers theat they like better.
And one more note … One of the things we teach in all our courses is presentation of a root cause analysis. We always teach NOT to use the tree as a presentation tool … that’s not what it’s made for.
Thanks again,
Mark
Comment by Mark Paradies — October 3, 2007 @ 10:57 pm
While there has been much conversation on when and how to use the “5 why’s” method, one perspective seems to be missing. Are the questions meaningful and applicable? I have seen and been involved in projects where all the companies’ particular change and analysis tools were used but the true root cause was not found. By not understanding the true system, by not having the right subject matter experts, and by not following a structured “why process” with identical parameters agreed upon, the process failed. I can use a wrench for many uses correctly and incorrectly, but does that mean a wrench is a bad tool?
Comment by Chris Vallee — October 17, 2007 @ 11:59 am
It is realy good article and explained in in detail.
I would like to receive your articles periodiclly through my e-mail ID.
Thanks and best regards,
B.S.RAO
Comment by B.S.RAO — April 1, 2008 @ 6:00 am
5-Why has been in existance for from the time I was a student of 1st grade, almost 65 years ago. Whenever I was late for the class or didn’t finish my home work, the WHY WHY was the routine method of determining the root cause. It normally ended on the second why and I was punished. This is because coming late or not doing home work was considered a punishable offence.
Similarly in industry, where I have been responsible for quality management of an enterprise manufacturing tractors, railway equipment or defence products, many a times when a defective was detected in the supply from vendors – no why why, but reject the material.
Yes, when defects occured in the products in manufactuirng in the plant, we undertool a detailed analysis of many causes based on cause and effect study, brainstorm, on-shop observations, reference to other institutions, process capability studies, tool wear study, product life validation etc, to come to some useful conclusions which would lead ot prevention of reoccurance of defect noticed.
Yes some why why was also part of the analysis. But the real solutions never came from why why. It was mostly for containment actions that why why was used.
I ssalute Taichi Ohno for making finding solutions look so easy. He forgetting that bombing the Peral Harbour resulted in Atom Bomb on Japan. Not even one WHY was asked.
So let us agree that WHY WHY is good as long as it meets your predetermined instinct.
Comment by Ajay Kumar Raman — March 24, 2009 @ 4:33 am
this thread leaves me pondering… WHY is toyota on top of the game now? they still use this “crude” tool daily though… crude 5-whys but no chapter11 in sight… just wondering..
Comment by tristan — June 3, 2009 @ 3:30 am
A crude tool is better than no tool.
And all the major auto companies now use fault trees, 5 Whys, and fishbones.
The question SHOULD BE when will one auto company see a competitive advantage to leapfrog the rest by applying advanced root cause analysis?
PS: Toyota also has the advantage of NOT having been the successful GM of the 1960′s and 1970′s and NOT having their legacy costs.
Comment by Mark Paradies — June 3, 2009 @ 5:45 am
Tristan,
In order for these “crude” tools to be effective you have to truly understand your process, your company, your culture, and your problem. Many of the tools developed early on were developed and enhanced AFTER they observed their own processes. The ready made improvement tool package sold as a commodity with small to no gains on ROI shows that people do not have a good understanding of what to ask and how to close the loop with good corrective actions using these “crude’ tools.
People often forget that they have to do their homework first to make the “crude” tool work. If you don’t have the right people in the room and if you don’t ask the right question, then you will not be successful. It has gotten even worse in industries where they have removed apprenticeships with new people training new people. This is why the “Crude” tool is not very effective in the long term. Look up the Red Bead Exercise to see what happens when make changes without a good basis.
Comment by Chris Vallee — June 3, 2009 @ 9:05 am
I have to say that I am totally agree with Chris Valley.
We can’t understand why a missing filter can become the root cause because we are not apart of the process, we just an outsider. But as long as adding a filter can solve the problem, I would say that it is the root cause.
You have to give the tools to the right person, even a crude tools would be useful, and in contrary even the most effective tool can be useless in the hand of the wrong person.
That also could answer why Toyota is still one of the biggest company even tough they are using a crude tools.
Comment by Gusti Ngurah — June 22, 2009 @ 2:45 am
I don’t disagree with Chris but I think that a tool doesn’t work if you have to understand the problem before you analyze it. (See Chris’ comment above.)
Toyota is lucky. The competition in the auto industry isn’t using better tools so they aren’t being pressured to improve.
Imagine what Toyota could achieve if they had better problem solving tools…
Comment by Mark Paradies — June 22, 2009 @ 7:43 am
Perhaps your original question should be thought about in reverse. Let’s start with a known “true root cause” and work backwards up the stream.
It’s difficult (I still can’t think of one) because “true root causes” are very subjective. What I see as a root cause, someone else may see different.
When I think of Lean Implementation, I think of one of the first things taught…that Lean begins with a foundation, and that foundation should be Standardization.
So, when we think of root causes, we should think, “What standard is not being followed?” Afterall, the standards we set create the business we do. If one finds a “root cause” outside the realm of the standards, then they are actually reshaping the business! Maybe that is actually what we want, or how businesses grow and innovate.
But all in all, things only go wrong because a standard was not conveyed. We have to see what how the standard was taught (visually, orally, etc), what the communication level was (100%?), and what the expected outcome is. [even the Matrix had it's Zion]
Comment by Dan — June 22, 2009 @ 9:39 am
Dan
You are getting close to the ideas behind TapRooT®.
However, TapRooT® not only helps you find where standards are not being applied effectively, it also helps you discover standards that you need to improve or standards (we call them “best practices”) that you have not yet discovered but need to apply.
We base this on proven human factors and equipment reliability research and best practices.
Thus we have a “foundation” that is not subjective and helps people go beyond their current knowledge … Something that 5-Why’s doesn’t have.
Perhaps that’s why people who are 5-Why users really have their eyes opened at a TapRooT® Course.
Comment by Mark Paradies — June 22, 2009 @ 9:55 am
I just went back and re-read all the comments above.
What a good discussion on the philosophical/practical arguments surrounding 5-Whys.
To summarize:
5-Whys is simple and easy to explain but may not get you to a workable answer unless you:
1. Keep asking questions beyond 5.
2. Already know the answer.
3. Have a simple problem (not multiple causal factors).
Therefore, 5-Whys should only be used as an analysis tool if you are a very smart person and already know the answer to a simple problem.
Am I being unfair?
Comment by Mark Paradies — June 22, 2009 @ 10:18 am
Gusti,
Mark could not put it any simpler than above. With the limitations of the 5-why’s in the hands of a process and non-process expert elaborated on in the above discussions, what would a useful and effective problem solving tool look like?
1. A tool that forces experts to push for data before making a decision.
2. A tool that allows a person not familiar with the process that they are investigating to ask questions about data. Questions based on research and best industry practices…. note that the expert who is asked to answer the questions still must support their answer with facts.
3. A tool that uses a closed loop process to tie root causes with causal factors with corrective actions….. you can’t just pick your favorite cause just because it sounded good and we all voted on it.
4. A tool that forces someone to verify that the problems are no longer occurring… this is another limitation of using the 5 why’s because this last step is usually delayed or never happens. Kind of like the old theory that the prescribed medicine must be the answer after years of experience because the patient never comes back.
So does the investigator/problem facilitator need to understand the process they are investigating if using the right problem solving process… no! The good process will map out the process they are investigation and force a deeper structured dive into the facts before why even comes in the picture. A good facilitator is able to lead the experts using a good process.
Comment by Chris Vallee — June 22, 2009 @ 4:16 pm
I have read the article and all the comments. Then I have already some other articles related to this. I found something interesting at this following website:
http://www.scribd.com/doc/5444000/5-Why-method-metodologia-5-porques
at page 14-18. It will give us the right point of view of the 5 Why Analysis by Taiichi Ohno above.
At the website, Why 6-8 are continued:
(6) Why the filter was not installed
Because the machine designer didn’t realize the necessity of the filter
(7) Why the designer didn’t realize?
-Because he/she had no thoughts about metal shaving
-Because there was no system to feed problems occurred
at a plant back to equipment design Department
(8) Why Designer didn’t realize the treatment of Swarf?
Because he/she didn’t care about issues other than the conditions for product processing
Comment by Irvan Saut Martua Pasaribu — July 7, 2009 @ 4:00 am
I continou:
After reading the web address, then I can conclude:
5 Why from Ohno is enough for root cause at factory floor.
When we want to continuo until design level, we can ask more why.
During my Job as TPM coordinator, I realize that 5 Why analysis will lead to weak analysis if we do not focus on these things:
1. From one why to the following why must be supported with strong and accurate data provision that will lead into real fact
2.Production problem should be identified by the process error in production floor rather than the design error.
3. Analyze as quick as possible from the incident. Train the shift mech or electrician to gather information as much as possible when facing a problem. Sometimes this is quite difficult because of the time limitation pressure on him. But we can be smart by providing them with camera, etc.
4. One meeting is not enough to create strong 5 Why Analysis. Ussualy what I do is create a draft together with team, then we assign each member to collect data (supplier manual, benchmark with other company in a group, internet, etc)
Comment by Irvan Saut Martua Pasaribu — July 7, 2009 @ 5:47 am
Irvan
I liked you link and your ideas but – it doesn’t address the basic problems with 5 Whys.
It’s tough to convince someone who is an expert in one technique that there may be a better way to analyze a problem and find its root causes.
Perhaps you should attend at TapRooT® Course and then you could experience what I am talking about?
See:
http://www.taproot.com/courses.php
Comment by Mark Paradies — July 7, 2009 @ 9:16 am
I am so glad you featured the 5 why, so many professionals find this easy to use, and it comes to nice and tidy answer, but I think as your demonstration proves, it can leave the real root cause hidden and result in false sense of solving the issue, when in fact the problem remains.
Comment by Virgil Pattarino — July 14, 2009 @ 4:04 pm
5-WHYs is a very interesting approach – it has helped me a lot not in settgin the goal; but rather direction of inquiries (diagnostic reasoning). it is even more powerful if integrated with (i) data analysis; and (2) model of the diagnosed system.
If interested in application for 6-sigma Root Cause Analysis in Automotive Body Assembly processes – you might see our website: digiPLM.or and the following work
2. Ceglarek, D., Shi, J., 1995 “Dimensional Variation Reduction for Automotive Body Assembly,” Manufacturing Review, Vol. 8, No. 2, pp. 139 – 154.
Comment by Darek Ceglarek — July 15, 2009 @ 10:18 am
Thanks for your comment and Great Work!
Here’s the link to download your paper:
http://digital.warwick.ac.uk/Download-document/3-Dimensional-Variation-Reduction-for-Automotive-Bodv-Assemblv.html
I liked your work and I’m certainly not being critical of it but I think our definitions of “What is a root cause?” don’t match.
Some of your work looks more like troubleshooting and most of the things called “root causes” in your paper would be “Causal Factors” in TapRooT®. Causal Factors are where we start the root cause analysis in the TapRooT® Process.
Perhaps a more detailed example of a “root cause” of a particular failure might let me see the depth of your root cause analysis.
Perhaps attending one of our courses in the UK might be helpful to see how we approach finding the fixable root cause of things like “tooling installation problems” or “maintenance related problems.”
For an example of our root cause analysis tool, see:
http://www.taproot.com/wordpress/2006/09/12/how-does-taproot®-work/
Thanks again,
Mark
Comment by Mark Paradies — July 15, 2009 @ 10:49 am
Here’s one more idea from a Toyota Exec. See:
http://www.taproot.com/blog/2007/03/teruyuki_minoura_toyota_exec_t.html
Comment by Mark Paradies — July 16, 2009 @ 10:18 pm
Mark,
What is done by us is not starting they Why from the functional failure, but from the failure mode. For example: The functional failure is no torque is generated at pump B, and we derivate (with team) the failure mode: The motor is burned out.
We start the question: Why the motor is burned out instead of why there is no torque with pump B?
It does help and strengthening our problem solving with 5 Why. In fact, the shift mechanic has already identified and can show the fact that the motor has burned out when he solve the problem. We don’t have to start with the pump.
Perhaps you are right that Toyoda is not perfect when creating this tool. But everything is developed right? The fact that the first plane is created doesn’t mean that plane is not good transportation..
But still, according to me he is still right. At shop floor, when we do problem solving at the root cause led to external parties, where we can’t do nothing about it (for example about vendor design), it gave stress to them, stop until factory problem solving (ex. Modifying by adding filter)
Maybe we can continuo the why:
(6) Why the filter was not installed
Because the machine designer didn’t realize the necessity of the filter
(7) Why the designer didn’t realize?
-Because he/she had no thoughts about metal shaving
-Because there was no system to feed problems occurred at a plant back to equipment design Department
(8) Why Designer didn’t realize the treatment of Swarf?
Because he/she didn’t care about issues other than the conditions for product processing
But: Is it necessary at operational shop floor?
Comment by Irvan Pasaribu — July 31, 2009 @ 2:55 am
Revise: The fact that the first plane is created not perfect doesn’t mean that plane is not good transportation
Comment by Irvan Pasaribu — July 31, 2009 @ 2:56 am
Irvan,
Let’s start with equipment troubleshooting first. Originally TapRooT® did not focus on equipment because the shop floor mechanics are experienced with their own equipment. Who were we to step into this world when human performance was our area of expertise. Problem is, human error crept its nose in this error too.
Any mechanically field expert has developed cues for the most common symptoms and causes. Problem is that we depend on these clues and through confirmation bias mentally block out other infrequent but very important clues to what happened. In a recent case study concerning doctors, it was determined that 75% of the cases reviewed for subsequent injury or death resulted from premature conclusions and closure of the case. Applying this to equipment troubleshooting, this is called a broke fix mentality. This is why we started Equifactor® equipment troubleshooting.
Second issue, why should the shop floor be concerned with the other factors outside of his/her control? Easy, because they are effected by others downstream and they affect others upstream. The Silo (stovepipe) impact of troubleshooting often fails to correct the system and places the blame on the person adjacent to the point of discovery in the time line of the fault. Often, the last person who signed off the aircraft forms in the aviation world is blamed.
I watched a mechanic get chewed out and accused of signing off a fuel control valve leak check without doing it when the valve leaked and grounded the aircraft. A 16 year mechanic with integrity! He went out under observation and reinstalled the same valve as procedure called out and leak checked it. It passed! Until the next day. So what are the common problems on the shop floor:
1. Incorrect part
2. Wrong o-rings
3. In correct torque on the mating surfaces
4. Foreign objects
Guess what? None of these were the issues. The part was a correct replacement with a new part number. It met all of the specifications as requested. Problem was that the valve body was just a little larger and binded in this one position in the aircraft. All other positions worked fine.
The more that the shop level worker is able to identify the system problems the better the fix is going to be. Workers usually inherit problems and are the first line of defense in fixing the real problem… why limit them and encourage silo and possible bias induced broke fix solutions?
Comment by Chris Vallee — August 3, 2009 @ 8:35 am
Irvan,
A tool is good when it is used for the correct purpose and problem. Everything gets improved and updated with User input, TapRooT® uses this same concept and gets better every year in small refinements; refinements that do not change the concept and foundation, just make it easier.
The point is I can make refinements to a screwdriver to make it a better pry bar (never done this myself :) ), or just get the right tool in the first place. 5 why’s is a great place to start and easy to use when you have nothing else, but you soon outgrow it like your first pair of shoes. It is verified when the problem continues to repeat because just a symptom was fixed.
Comment by Chris Vallee — August 3, 2009 @ 8:41 am
I work for a company that builds flight simulators for the government.
In the real world It works like this.
Why doesn’t the engine power indicator light when I turn on the switch.? It worked yesterday.
One technician troubleshoots (binary search and conquer style)
Is the lamp good ? yes
Is there voltage turning on and off on the base of the lamp with the switch throw ? no
Is the I/O card toggling with switch throw ? no
Is the I/O computer getting the message from the simulation computer to activate the I/O line? yes
Is the output of the buffer chip between the I/O computer and the lamp driver FET toggling? No
Is the input of the buffer chip between the I/O computer and the lamp driver FET toggling? Yes
Is there a short between the I/O computer and the buffer chip? YES intermittent short to neighboring line that is off.
Now the fun begins,
Two quality engineers and a RCA guy ask
WHY?
Solder bridge
Why?
Operator put to much solder on the IC leg
WHY?
Operator was tired
Why?
I don’t know
2 QC engineers and RCA guy say “That is not good enough!!! We need to determine corrective action.
QC engineer “How about the Operator was tired on Tuesday”
Where do you draw the line? How much does it cost when your QC guys only read the first 6 pages of the six –sigma book
What is the cost of pondering quality
Comment by Michael — January 20, 2010 @ 1:44 am
Michael,
I enjoyed your post and just want to elaborate on a few things. This phrase “binary search and conquer style” was great, just do not forget to put… replace the easiest part to get to first and then use the troubleshooting guide based on the schematic for the system if the first choice did not work (using the schematic is better than the filling in your own blanks in the five whys chain). This method works on real aircraft too, not just simulators.
Cost of Quality Models or is it Cost of Poor Quality Model…. it depends on which end of the food chain in manufacturing/flightline you lived as to which phrase you drove or which phrase drove you. A quick broke fix band aid always looks good to the customer the FIRST time it breaks… but then it happens again. Where do you draw the line. using an FMEA, what is the worst outcome of not getting it right? What work get stopped to fix an emergency work order? The list goes on and on.
Of course we could stop at anything dealing with human behavior; that can always be fixed with discipline…. that has worked for the last 1000 years, right? I enjoyed your post Michael and thought I was sitting in an old IPT meeting solving the last repeat write up.
Comment by Chris Vallee — January 21, 2010 @ 8:42 am
I’ve been trying to find a decent article about this for a while now. Would you mind if I Copy’ed your article I’ll give a link back to your site of course!
Comment by Williams Schaedler — January 28, 2010 @ 1:10 pm
I enjoyed reading this post and more the logical connections of the example it provides. It is unfortunate that I read this post today when only last night I published a presentation entitled “Extend the five whys to eight whys!Why?”
The link is
http://www.slideshare.net/hudali15/extend-the-five-whys-to-eight-whys-why
In this presentation I question the validity of using only logical reasoning when many problems exfoliate because of emotional problems. A hidden cause is lack of emotional intelligence. An unhappy worker might build up frustration and his frustration might cause hell of problems.
The eight- wave structure of the whys is briefly explained in the presentation
Comment by Ali Anani — October 1, 2010 @ 12:17 am
Good day…
It’s been a month that I’ve searching for a Root Cause Analysis Tool and I’ve found out that 5-Why is the most easy one with a lower cost involve. For me, this 5-why is one of the useful tool in investigating the root cause and it will be ended until the root cause of the problem will be corrected and it will not recurred. If the problem will still recur after the 5th-why, be patient and continue to the 6-why. The author give to us his example to lead us use this 5-why tool but never avoid us to continue to the 6-why or even more.
“We can be more effective if we continue and patiently enough to investigate more”
Jeffrey Rabasto
Comment by jeffrey rabasto — October 29, 2010 @ 8:15 pm
If 5 different people look at the same event you will get at least 4 different answers using 5-Whys.
Not only that, but it it’s likely at at least 3 of the answers will be worthless (and sometimes 4).
That doesn’t seems acceptable.
Comment by Mark Paradies — October 29, 2010 @ 9:16 pm
Hi,
Sorry guys, a good engineer don’t really need any RCA. It’s just a reflex to go on the quest of a good and permanent solution.
So how do we push engineers to become good engineers. Numberone, there are absolutely no RCA tool that can make one engineer to come to a root cause and corresponding solution that he/she don’t know about. So they need training in their job, exposure to real problems and it’s solutions, and get the feel of reoccuring problems,
But, there may be tools that are pushing a TEAM of engineers to a RC+solution that is different from what they initially though would be the answere. This is still a RC+Solution that at least one in the team knows about, but either he/she didn’t think this was the RC or he/she wouldn’t manage to convince the rest of the team without a good systematic and visual tool.
Yes, if you put up a dynamic modell and do causal analysis, you might get answeres no-one thought were true, but to be honest, to use the time to put up such models are usually far away from real life. And I’ve seen more money wasted on such work, than I’ve seen saved.
The claim that using 5W gives meaningless answeres, is a bit unfair. The right people might give the right answeres using 5W or any other RCA tool. But no way the wrong people would give the right answeres, even using the best RCA-tool in the world. Sorry, I understand you are all really committed to RCA, but it’s just one of many tools in the tool box.
RIGHT ATTITUDE AND RIGHT COMPETENCY is the key.
Comment by Jostein — January 3, 2011 @ 11:42 pm
Hi Joestein
Thanks for your comment and this is where I started out almost 30 years ago. I was wrong then, realized it, and put the work in to develop a first cut on the model that people needed.
Many engineers think that technical competence is the key. But many solutions lie outside the arena of technical competence. They are human factors solutions to human error problems. This is knowledge that many engineers never learn.
People can be led to solutions they have never considered before. I see it every time we teach a course. Quite amazing.
Attitude and competency are important. However, they aren’t the solution. The right root cause analysis system (TapRooT®) + attitude + competency + management support is the key.
Hope you make it to a course some day so you can see what you are missing.
Mark
Comment by Mark Paradies — January 6, 2011 @ 1:25 pm