iSixSigma

Root Cause Analysis Depth

Six Sigma – iSixSigma Forums General Forums Tools & Templates Root Cause Analysis Depth

This topic contains 9 replies, has 5 voices, and was last updated by  Alan Berow 9 months, 2 weeks ago.

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • #55942

    Alan Berow
    Participant

    My organization uses the 5-why tool for root cause analysis. I have not been able to find a bright line rule to know the team has found the root cause. For the time, my team has developed guidelines to help other teams decide when to stop. l would appreciate any thoughts people might have on either a rule or the quality of our guidance.

    – Cannot get information needed to answer the why – people have left the company, no records kept, problem cannot be reproduced
    – Further analysis or corrective action is outside the company’s control and the source is not willing to assist.
    – The responsible person, with adequate information, made a business decision.
    – The cost of deeper analysis is not justified by the potential gains.

    The last is an easy way out for teams, so we ask the team to adjust its composition to ensure it contains people who could answer the question. For the most serious issues, we form an ad-hoc, cross-functional team to review the analysis.

    #202292

    Liam
    Participant

    I agree 5 whys is a guide but you will need to go deeper sometimes. What defines the stopping point is when there is a commonality on the causes. A Fish bone (https://www.isixsigma.com/tools-templates/cause-effect/cause-and-effect-aka-fishbone-diagram/) then helps to see that commonality and determine what to target.

    #202293

    John
    Participant

    A couple thoughts on this, first I see a lot of WHO in your analysis…This is a dangerous pitfall in using the 5 why tool.

    Conventional problem solving stops asking WHY (why did this problem occur?) when the answer is a WHO (Who is the culprit? The person or group who is accountable.).

    When we focus on a “who” instead of a “why” the investigation will not uncover the deeper and SYSTEM-WIDE sources and causes of problems, but focus only on the superficial and LOCAL sources and causes. This is what I see in your description above when you stop going deeper.

    Even if people are gone, or have made business decisions, there is always a process happening that you can map to truly track down the ‘WHY’ behind issues and barriers. Creating a process map, using a fishbone diagram or other discovery tools can augment and assist in breaking through the progress when stuck. 5 Why’s is a tool, and just like other tools, has pro’s and con’s to use. One size does not fit all problems.

    In answer when to stop this is the criteria I use when mentoring teams on this tool…

    Continue questioning until you get to something “actionable.”

    What is considered “actionable”?
    · Something that can be controlled
    · Something can be done that will, if fixed, prevent or reduce the likelihood of the problem existing or recurring

    A team has identified a root cause if it can answer yes to these two questions:
    · If the probable root cause is eliminated or corrected, would it prevent the problem from existing or occurring?
    · When the probable root cause occurs, does the problem occur?

    Hope that helps.

    #202296

    Alan Berow
    Participant

    Hi Liam. Thanks for the feedback. Unfortunately, it went right over my head.

    We are doing root cause analysis on single, significant failures and use fishbone diagrams to find potential causes and contributing factors, then use 5-why to drill down to what we hope is the root cause. I can’t figure out where commonality of cause comes in. If you are so inclined to invest more in assisting me, could you go into more detail or take a different approach?

    Hi John. Thanks to you also. If I gave the impression that we are looking for someone to blame, I failed to communicate clearly. Our RCA facilitators strongly resist placing blame. We assume that the organization has failed the person who introduced the defect by creating conditions that allowed this to happen. In the case of stopping the analysis because the right person, having adequate information made a business decision, the decider is usually a product manager, who balanced the needs of the market and our customers against knowledge that the product may not have all of the features we hope to deliver. We accept that a defect escaped.

    We formerly used “actionable” as the criterion for stopping, but found that we were fixing the cause, not the root cause. We did a cause on / cause off check, where possible, to verify the problem was fixed.

    Other than not having information to answer, getting the answer or acting on it being outside our control, or accepting that the defect escape was acceptable, we can always ask “why?” again. I agree that we need to balance investment in analysis with impact of failure and risk identified by the analysis. Our conundrum is figuring out that balance.

    #202314

    Rob Ratcliffe

    Alan,

    I read your responses to Liam and John and wanted to add something you may be missing. “Validation” of your 5-why analysis may be something that helps you determine if the solution your team has arrived at makes sense. Once you’ve gotten to a root cause (actionable item), try doing a sanity check by “swimming back upstream” all the way from the root cause the original problem in the fishbone. Take the last WHY and say, “(this) causes (Why #4), which causes (Why #3), which causes…” until you reach the intial Cause leading to the problem itself. If that validation flow makes sense, you’re likely on track and can take action that removes the problem permanently.

    #202315

    Eric Dickes
    Participant

    Alan,
    The 5-Why technique is powerful and very easy for most teams to understand and apply. It can address many of the issues that affect organizations. It is well suited to uncover apparent, direct cause-and-effect relationships that those involved in the process can see.
    For issues that are more subtle, a different tool may be more apporpriate. Some example situations are: problems involving interactions with other parts of the process, problems having very low defect rates, or problems that are caused by an earlier process step – but are not detectable until a much later process step. These would be hard to solve using 5-Whys.
    There are many problem solving tools used in industry – including DMAIC, Fault Tree Analysis, Cause and Effect Charting, and 8D methodologies. My favorite for difficult problems is Structured Problem Solving. It has the benefit of capturing all time, location, extent, and problem characteristics and providing a method to rapidly filter potential causes down to the true root cause.
    No matter which tool you are using, determing when you have found the true root cause can be challenging. The most reliable way I have found is to locate the root cause that: 1. Is consistent with all the problem dimensions of timing, extent, location, and characteristics; and, 2. the one that can be turned on/off and predictably make the problem appear/disappear. You do not always have the luxury of being able to turn the problem on/off, but if you can, that is very powerful supporting evidence you have found the problem. Eric

    #202316

    Mike Chambers
    Participant

    Hello Alan,

    I’m thinking we might be over complicating this a bit. To digress a moment, I’m a big fan of Pareto, the Italian philosopher/physicist. One of the things Pareto developed was the 80/20 rule. Examples might be 20% of your customers generate 80% of your business. 20% of the school children give you 80% of the problems in a classroom.

    Where I’m going is Lean follows the 80/20 rule. That is, spend 20% of the effort and get 80% of the benefit. 5 Why is the same. Expend a limited effort (say 20% of what you could versus a multi-functional, multi-shift, multi-disciplined team) and satisfy 80% of the problems.

    Understand 5 Why, like most every other tool, will not solve all problems. But it will solve 80+%. So, rather than getting bogged down in the details, have the operators and mechanics in groups of 2 or more give it a try. This way you will be solving/resolving 80% or more of the problems. Those problems that persist can then be pursued with a more rigorous approach that may utilize another tool like Kepnor-Tregoe or Toyota’s 8 Steps.

    Hope that helps!

    Best regards,

    Mike

    #202320

    Alan Berow
    Participant

    Hi All. Thanks for your input and my apologies if my comments come across as being argumentative rather than grateful. I work for a company that manufactures data using software and hardware tools we create. We also sell real-time services based on that data, again requiring creation of software. We apply root cause analysis to all of these areas. I am developing guidance for the most severe cases, when a customer encounters a defect level outside our SLAs. We need to improve as we are moving into areas where defects can cause deaths.

    Rob – I did not mention it, but suggest to teams that they traverse the whys in reverse order, using “therefore” to tie them together and checking whether the analysis continues to make sense. We also use cause-on/cause-off whenever we can, which is rare. The problem of knowing when the analysis has gone sufficiently deep remains.

    Eric – I agree that applying 5-why is difficult in many of our situations. It may take months before defects are discovered and the analysis may move from team to team as each why is answered. If I understand correctly, DMAIC is better suited for common cause issues. The immediate causes of most of our problems appear to be special causes, though knowing the cause at a deeper level might show they actually are common cause. We use Pareto analysis to identify areas in which to invest.

    I believe (please correct me if I am wrong) that fault tree analysis, cause and effect, and structured problem solving, while valuable tools, find the true cause of a failure, not the root cause. I agree on the value of looking for something that meets the characteristics you described. Unfortunately, once again, I see that as the cause, not the root cause.

    Mike – Our RCA teams tend to be small. Part of our problem is an unwillingness to turn responsibility over to another team (and accept responsibility) if the cause is found to be with another team. As noted earlier, we use Pareto to categorize our problems, causes, and what the teams describe as root causes for investment in addressing common cause issues.

    We have a multi-layer approach to defect management, ranging from fix the problem (programmer hits the wrong key, notices it or a unit test fails, and the programmer corrects the error), through permanently fixing the immediate cause of the defects being produced (process did not lock modification of data the operator was not qualified to modify – fixed by adding a look-up of the operator’s qualifications), to root cause analysis. I have not used Kepnor-Tregoe; however reading a description of it and Toyota 8 Steps, I see root cause analysis used in both.

    To offer an example, I came across a drawing on the Internet that purported to use 5 whys to find a root cause. I won’t share it as it may be copyrighted. The defect was that a machine stopped. The 5 why steps were:
    – Overload tripped
    – Insufficient oil on shaft
    – Oil pump inefficient
    – Pump drive shaft worn
    Root cause: Oil filer blocked with crud
    Replacing the oil filter will not necessarily prevent the problem from coming back. The root cause lies deeper…why was the filter clogged? Guessing, I could have “PM to replace the filter skipped”, “contaminated oil used”, “no standard to select filter to use”, “no check for remaining filter life”, etc. I can ask “why” for each of these.

    Thanks for reading the rant.

    #202321

    John
    Participant

    Reading your response prompted a remembrance of the Jefferson Memorial 5 why video on YouTube. Worth a watch if you have time as the initial solution didn’t go far enough. More work was needed.

    If you are chasing special, or infrequent, causes it can be frustrating as a new set of issues pops up. The key will be that you have greatly reduced or eliminated the original root cause.

    I go back to the response I posted earlier.

    Continue questioning until you get to something “actionable.”

    What is considered “actionable”?
    · Something that can be controlled
    · Something can be done that will, if fixed, prevent or reduce the likelihood of the problem existing or recurring

    A team has identified a root cause if it can answer yes to these two questions:
    · If the probable root cause is eliminated or corrected, would it prevent the problem from existing or occurring?
    · When the probable root cause occurs, does the problem occur?

    #202328

    Alan Berow
    Participant

    Hi John – Thanks. I remember the monument example. It is a good example of how the root cause can take you far away from the original complaint. It is also a good example to show the team how the analysis can branch – why were harsh chemicals used, why weren’t timers used to save money in the first place, etc. The stop point matches one of the criteria we came up with – further analysis or corrective actions were outside the scope of the organization.

    Unfortunately, we have found that stopping when something is actionable is not adequate, especially for the defects for which we use this escalated analysis. In the example I gave before of the machine shutting itself down..
    – Overload tripped
    – Insufficient oil on shaft
    – Oil pump inefficient
    – Pump drive shaft worn – actionable, why did we continue?
    Root cause: Oil filer blocked with crud – actionable, why didn’t we continue?
    – (assume) PM process does not include a check of filter – actionable, why not continue?

    I see your two rules as establishing when the cause is found.
    · If the probable root cause is eliminated or corrected, would it prevent the problem from existing or occurring?
    · When the probable root cause occurs, does the problem occur?

Viewing 10 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic.