Q. 157   While solving problems, root cause analysis is considered as an obvious step. When is it that one should refer to a “cause” as the “root cause”? (or a set of “causes” as “root causes”) 

The most comprehensive answer wins. Do try to consider varying situations. If answers are similar in detail, those with examples will get preference over others. 

 

Note for website visitors - Two questions are asked every week on this platform. One on Tuesday and the other on Friday.

• All questions so far can be seen here - https://www.benchmarksixsigma.com/forum/lean-six-sigma-business-excellence-questions/
• Please visit the forum home page at https://www.benchmarksixsigma.com/forum/ to respond to the latest question open till the next Tuesday/ Friday evening as per Indian Standard Time.  
• The best answer is always shown at the top among responses and the author finds honorable mention in our Business Excellence dictionary at https://www.benchmarksixsigma.com/forum/business-excellence-dictionary-glossary/ along with the related term.

 

 

We use the RCA method in Analysis phase of DMAIC , Plan phase of PDCA & D4 step in 8D approach.

What is RCA? _ Root cause analysis is a class of problem solving methods aimed at identifying the root causes of problems or event. To analyze a root cause, you have to define a problem, gather data or evidence. Identify the issue that contributed to the problem and find root cause using 5 Whys.

Difference between Causes & Root causes _

Simply causes or probable causes can identify easily based on our experience or available data & it's superficial in nature. We can't implement a systematic action which ensures that the action taken on these causes will remove the problem permanently (not proactive - Meaning problem can reoccur)

Whereas identification of Root causes is not comparatively easy as normal/probable causes. To identify it one must have to go on Gemba & validate the Scenario/issue/data by asking “why” several times until we reach the fundamental process element that failed.  Once we identify & implement an action on these RCAs that remove problem permanently meaning no reoccurrence of problem. Also it always leads us to the Process , Control mechanism & system failure oriented RCAs.

Below is the right approach to conduct the 3Way5Why RCA :

1. Generation oriented RCA (Why-why analysis) _ Which gives us the root cause for " Why the issue/problem has generated". It leads us to the Source of issue leading us to "Process or System failure"

2. Detection oriented RCA (Why-why analysis) _ In this mode of investigation we aim to Identify RCA for " Why our Process is not able to catch/detect the issues/problem from product or service throughout our process flow". This leads us towards the "Control Mechanism failure".

3. System oriented RCA (Why-why analysis)

_ As the last step of our investigation, we must focus our attention on the systems that support our processes. Tracing back defects to the systems that may have contributed to the failure will help us improve systematically throughout the organization. This step is just as important as finding out why the product or service failed in the first place and may have more impact on the bottom line.

 

Example of 3Way5Why :

Problem / Issue _  Battery charger failure

1st Way : Occurrence / Generation

1st: Why did the battery charger fail?
- It had a defective flex cable.

2nd:  Why was the flex cable defective?

-The traces at the edge of the overlay opening of the flex cable were cracked.

3rd:  Why were they cracked?

- Excessive force used while manually bending the flex cable  during assembly.
4th:  Why was the flex cable bent excessively?

- No jig to assist the manual operation of bending.

Root cause in this instance?

Not using a poka yoke jig to assist in this manual operation will leave it exposed to variation in the force applied to assemble the product.

2nd Way : Detection

1st: Why was the defective flex cable not detected?

- Invisible trace open in flex cable was not detected electrically.

2nd:  Why was this not detected electrically?

-FVT tester was not able to detect this failure.

3rd:  Why did the FVT tester fail to detect?

- FVT tester did not have the program to check for this failure.

4th:  Why did the FVT tester not have this program?

- The test program was consigned, and was not developed to check for this failure.

Root cause in this instance?

The test program buy-off procedure did not cover this item. This should be addressed.

3rd Way : System

1st: Why did our systems/processes produce a faulty product?

- The flex cable has assembly issues which made it vulnerable to cracking.
2nd:  Why were we not aware of this vulnerability?

-The potential failure mode of cracked cables was not properly assessed.
3rd:  Why was this failure mode not assessed?

- FMEA was performed, but did not consider this failure mode.
4th:  Why did we not consider this in FMEA?

- No training program in place to train QE and ME in correct FMEA completion.

Root cause in this instance?

We need to make or FMEA system more robust with training and accountability.

 

Root causes are at the base level of all causal analysis.  A cause is considered a root cause when solving it can break or prevent the causal chain from being realized.  Many problems are the result of multiple root causes as such there are multiple causal chains that must be broken or prevented.  For example an automated drilling machine having problems accurately locating holes was found to be caused by multiple causal chains including those associated with the software program, the set up of the driller, the cleanliness of the product, the experience of the operator, the capability of the driller to stay on track and the maintenance plan for the driller.  To solve this problem a solution set has to be developed based on the root causes that are actionable causes within each casual chain. 

I find it helpful to think different types of causes as root causes and contributing causes.  Both types can be either actionable (i.e. subject to change), or not actionable (at least by people in the system under consideration).  Actionable causes are almost always effects of not actionable causes.  When looking for root causes and contributing causes, keep asking "why" until you reach a cause that does not seem actionable, e.g. the rock fell due to the force of gravity, then the effect of that cause will likely be an actionable cause.

 

The difference for me between root causes and contributing causes is that the root cause(s) lead to the undesirable condition, whereas the contributing causes can increase the impact of the undesirable condition once it exists.

 

Thirdly, interactions between both types of causes are important.  Sometimes two causes must be present to create an effect (AND) and sometimes one or more causes can create the effect by themselves (OR).  I find it important to capture this logic when doing cause and effect diagrams to ensure logical consistency and clarity those reviewing the logic.

 

Finally, it is usually helpful to review causes determined to ask if there are additional expected effects that were not documented in the original logic.  This helps with clarity, logically consistency and sufficient detail when doing cause and effect analysis.

A root cause is the lowest underlying factor for a particular issue/problem that are specific and actionable, and if addressed, will eliminate (or mitigate) the problem (e.g., improve performance). 

 

Root cause analysis should avoid diving down to very generic, universal causes such as "insufficient budget", "lack of training", "lack of experience"

A cause is considered a root cause when any further analysis of that cause requires assessing problems that are outside of the control of the process. If further analysis calls for assessment of the suppliers antecedent to the main process, then the deliverable of those suppliers is the root cause. Once asking "why" to a cause carries the process engineer beyond the scope of their control, that cause is a root cause. 

A cause can be considered a root cause if it satisfies the below items:

1. The cause is clearly linked to the symptoms of the problem.
2. It is at the lowest actionable level.  If action cannot be taken against the root cause, it is no longer productive to continue going lower in the analysis. 
3. Changes to the identified cause will not create additional problems or problems that are deemed unacceptable.
4. Multiple causes have been considered and the selected root cause(s) is the best fit for the problem.

When is a cause a root cause (or causes the root causes)?

Here are some explanations:

1. The lowest level cause (or causes) that eliminates the problem.  :

     a. The lowest level cause in the cause and effect logic tree that eliminates the problem.

     b.  Another explanation, is the minimum and sufficient causes that eliminates the problem.

2. It is not a root cause if it is a critical cause or x(n) (at level n in the cause and effect logic tree) that is a function of a lower level critical x(n+1) (level n+1) that can be found that eliminates the problem

3. In practicality, if the cause can be eliminated economically, then the pursuit can be stopped at that point to conserve resources, in favor of prioritizing eliminating the problem and validating that the solution if effective.

A cause should be considered a root cause when a common solution can be found to prevent or mitigate all lower level causes.

Root Cause Analysis(RCA) techniques have been there for many years. It is one of the most powerful techniques. Let us see some examples which uses Fishbone diagram,5-Whys ,some popular RCA techniques to take a deep dive answer to the question put forth. Before going into that , we will look into what a 'cause' is about and what a 'Root Cause' is. 

 

Definitions:
Cause: It is the reason because of which something(event) is impacted or happened or someone is impacted by some means (positive or negative).  Or in other words, it is the reason because of which there is a positive or negative effect on something/someone or something(event) has happened . When used in conjunction with root cause analysis , cause normally will portray an adverse situation/effect or used in negative connotation. People normally don't find the causes for things that go well (because assumption is that you know how to make it happen - that is a different subject/topic on its own. Lets not go there for the time being!!) . 

 

Root Cause: It is the primary reason(source) because of which an event would have happened that can be backed by some evidence or per the conclusion made by the person (probably under circumstantial evidence or based on gut feeling or using some custom based or analytical techniques such as 5-Whys, Paretto Chart...or using hypothesis testing.) who would have done the investigation (or done the root cause analysis). A cause can be deemed as root cause, if we are not able to drill down further or break into that (finding the reason for that situation to happen). This is where analytical techniques like  5-whys come into picture. Root cause(s) can also be found out using hypothesis testing (in Six Sigma or other statistical based methodologies).

 

Now when can a cause or a 'set of causes' be deemed as a Root Cause or Root causes? 
When we know that for a problem(effect), if there is cause beyond which we cannot drill down for a source (primary reason due to which the effect or event has happened) or when straight-away know that there is only one cause for a problem, then it can be deemed as the root cause . If there are such multiple causes, then they can be deemed as root causes. We can also make an assumption (hypothesis testing) and with the help of statistical techniques can find the probable root cause(s).

 

Picking a Single Cause (from a set of causes)  to be deemed as a 'Root Cause'

Eg:1Fishbone Diagram: Delayed Delivery of 'Pasta's for a family

There was a 'delivery' agent company  (who delivered Eateries to households in the nearby vicinity). One family in that area, ordered  5 'pasta's to this company and the sales representative said that it will serve(deliver) the order in 30 min.  However after 45 minutes, still no signs of 'Pasta's was getting to that family. The Person who gave the order enquired on this with the customer care cell of the company. Even as the person in the customer care conveyed that her staff  left and was on the way to the destination and should reach out to the person's home(destination) any time,  she started thinking as why there was a delay in delivering. The customer was also thinking why it was taking too late.  Now Customer care person was doing a digging as what really happened(because already the 'delivery' person left) and now she wanted to know where and how it became late. Putting a fishbone diagram she saw the potential causes for delay and tried to rule out each one if she could.  She found  out that everything was okay except for the 'Traffic Delay' which was not neither in her or in her company's hands. She realised that there was a planned protest , done by some protesters for a good cause, on that area where the customer was placed at. So she could correlate that with the 'Traffic Delay'. This was vindicated by another 'delivery' person who went to the same area to a different house for delivering an order. He also went bit late to that area and delivered it late and the customer called her  and gave vent to his feelings. This 'Traffic Delay' cause, became the single Root cause as other potential causes were compliant and functioning as per they are supposed to or destined to and there was either enough or no evidence to support that they were malfunctioning or not in sync with what they are supposed to.

 

 

 

Picking multiple causes (from a set of causes)  to be deemed as 'Root Causes':

Eg1:Fishbone Diagram:   A national cricket team loses the final in a prestigious cricket tournament .

 

The cricket board/management of that country analysed using Fishbone diagram, as why the team failed in the Final. Unfortunately when the board listed out that the potential causes (as depicted below) , it found that all causes had a part to play on different times of the match, right from 2 days before the match(practice) to during the match when batting during evening time the light was poor and sighting the ball was a problem in some of the areas of the stadium. and some team members playing poorly.   As a result, the team lost . Now all of these causes were deemed as 'Root Causes' as in this case, the evidence was there for all these.

 

 

 

Eg2:Fishbone Diagram:   A national Football team loses to a minnows team in a league match in a prestigious Soccer(Football) tournament .  

 

The management team did a root cause analysis using Fishbone diagram and found that there were multiple reasons(causes) to loose the match, which are listed below.  There was enough data (statistics) and visual display of the game (recorded) to see the set of causes which were deemed as 'Root Causes'.

 

Eg:3 Fishbone Diagram:   Production Defects in an IT project

 

A software team delivers an application for an Insurance customer.  After 2 days into Production, quite a handful of defects occurred and the customer was irate.  The team did a root cause analysis using Fishbone diagram. They listed all the possible causes and found that except for the 'data centre' issue which was a one off case(for defects that happened on that single day when the fire ravaged that data centre) , rest of the causes were providing the source for these production defects. Hence they were deemed as 'root causes'.

 

 

Why is the importance given for the causes and root causes? 
Because these causes/root causes are the sources of variation.  You want to minimize your variation in your process . Is it not ? If you take a look at a DMAIC Six Sigma project for example, during the analyze phase, you would look at the potential factors that is creating the variation for your problem. Take the  equation, y=f(x). You would like to know what are the 'X's , that would address the 'Y' . Not many times you may be able to provide the causes/root causes, with conventional analytical techniques, which could be due to size of data, data gathering is complex,due to cost of data gathering,....(typical scenario in a six sigma project) . So you make an assumption(hypothesis statement) and then find out the influential factors(cause or causes depending upon the assumption) . Accordingly, the factor(s) is/are deemed as root causes for the given problem on hand.

So those factors(X) are addressed to improve Y. 

 

Conclusion: 
For every problem or effect that is happening or happened, there would be a reason/cause or reason(causes) because of which the problem would have occurred in the first place. Making use of proven and relevant techniques can help in nailing down the problem, at hand. Root Cause Analysis(RCA) of a problem helps in addressing the problem by specifically focussing/working on the root cause(s) identified and ensure that time is spent only on the actual issue and make sure that part is addressed. Ultimate Objective for anyone/team for doing the RCA is to fix the root cause(s) for a problem and ensure that there is minimal variation in the process(if the problem is part of a process) or ensure that a particular event or thing does not happen (if the problem is a standalone feature or entity)  . 

 

 

 

 

Root causes are the causes beyond which we cant go. Root cause would be terminated only when we get change in system, process, technology, training, policy. Hence in that case Root cause would refer to cause in those cases like

a. technology is missing, '

b. policy doesn't say anything at present,

c. training process has not been initiated for something,

d. changes/tweak in system are made.

Few examples where causes refer to root causes:

1. (changes/tweak in system are made) We could consider causes as root causes when we are performing controlled experiments where we have experimental group and control group with only experimental group being treated with factor of interest to observe its impact. If any changes seen in the experimental group then it could be directly inferred that causes of the changes is the root cause that is the change in the factor of interest. Some of the fields it is used is chemical processing, pharmacology,aeronautics.

 

While solving problems, root cause analysis is considered as an obvious step. When is it that one should refer to a “cause” as the “root cause”? (or a set of “causes” as “root causes”) 

The most comprehensive answer wins. Do try to consider varying situations. If answers are similar in detail, those with examples will get preference over others.

Each occurrence of a problem will have a "RootCause". However, another instance of the same problem may have a different "Rootcause".

Most often these Rootcauses can be bucketed into : People/ Product/ Process related.

When can I call the cause "RootCause"? When you don't get an answer to this question : " Why did this Cause Occur?? " Keep asking this question till there is NO Answer. That could be the "RootCause".

In Hotels for example : The Guest Slipped in the Bathroom may have the following Potential Causes : 1) The HK associate forgot to clean up the water used to wash the bathroom(i.e he missed Dry Mop) 2) There was a leakage in the pipeline to the Wash sink 3) The WC got choked and the water overflow occurred 4) Due to changing weather conditions outside, the AC Condensation occurred resulting is water drops falling from ceiling.
 

Therefore, whenever a Defect occurs, do a RCA. Solve the problem with an effective solution. Keep collecting the RCAs over a period of time to develop a perspective around the problem and the appropriate long term solutions. This is an ongoing activity. 

When addressed well, the Rootcause will not REPEAT !!

 

As a Problem solver, when we are making an attempt to investigate and understand the root cause of the problem, There are several tried and tested method that are experienced across industries. One of the best technique is Fish-bone or Ishikawa analysis where we brainstorm and map various probable causes from different dimensions, experiences, horizons, facts and perspectives. 

While identifying the root cause, we validate each and every probable causes through several validation techniques, most successful of which is GENCHI GENBUTSU. This involves making the Gemba round for each of the probable causes, authenticate the probable causes by obtaining facts, correlating parameters, performing challenge test etc. While performing the validations, what is considered to be paramount is the fact that , the parameters (CAUSES) which we are validating should have a correlation with the problem (IMPACT), we are dealing with. Continuing this process helps us to narrow down to one or few potential cause(s). This gives us the confidence to carry out further deep down analysis through techniques such as 5 WHY etc. to narrow down to the Root cause of the problem. This process renders the confidence to have attained the root cause, as the probability of all other probable causes gets null and void based on validation with facts, data and challenge test.

 

One of the interesting example I often refer in the training newbies is the columbia spacecraft disaster in 2003. WHY DID THIS HAPPEN ? N number of probable causes were at stake which might have resulted into one of the worst spacecraft disaster. When all the probable causes after listing down were validated and ruled out based on facts and challenge test, what was most promising and obvious in nature was related to Material, specifically the shuttle's external tank, from which a large piece of foam fell and damaged the spacecraft wing.

Therefore we can say it was the ROOT CAUSE, considering the thorough analysis of remaining potential causes.

 

Lets take another hypothetical example from the service industry. Say on a particular day, the XYZ Courier company delivered the material with 25 Minutes delay. As a team, we need to fix this problem and understand the root cause before submitting the solution. We can list multiple factors with respect to the processing time, logistics, transaction, weather condition, vehicle condition of transporter, personal mood, Service level agreement etc, etc, etc,... However to reach the root cause of the problem that is ''25 minutes delay in delivery time'', we need to validate each and every such probable cause(s) with the factual scenario which was prevalent on that particular day. Once we do that we will find, most of the causes will get eliminated based on the evident data. What we will be able to attain at the end of this exercise is very limited (No ideal number) Cause(s){Though in most cases,we get only one root cause}.

 

Whats paramount in this entire process is to sustain the perseverance and structured approach while we are determining the root cause. We need to remember once we get the root cause, that means we have identified the demon & we need to kill it with relevant CAPA. It shouldn't and wouldn't reoccur ever in the future.

Thanks!!!

The problem resolution happens when we attack the root cause completely. The sustenance of the solution and problem not appearing again can be achieved only when the root cause can be known using tools like

• Affinity Diagram - Kawakita Jiro
• Fishbone or Ishikawa Diagram
• Cause & Effect Matrix (C&E Matrix)
• 5-Why Analysis
• Fault Tree Analysis

A cause is the most direct reason that something failed. For an example if an employee loses an unsecured laptop filled with confidential data, the cause may be labeled as human error.

A root cause required analysis that looks at fundamental reasons that a failure occurred. This consider deeper issues such as processes, systems, design and chain events.

 

In the above example root cause may be that laptop wasn't encrypted properly.

 

When a identified cause breaks the chain of asking why and mitigate the risk then a cause is termed as root cause 

On 5/3/2019 at 5:03 PM, Vishwadeep Khatri said:

Q. 157   While solving problems, root cause analysis is considered as an obvious step. When is it that one should refer to a “cause” as the “root cause”? (or a set of “causes” as “root causes”) 

The most comprehensive answer wins. Do try to consider varying situations. If answers are similar in detail, those with examples will get preference over others. 

 

Please remember, your answer will not be visible immediately on responding. It will be made visible at about 5 PM IST on 10th May 2019, Friday to all 53000+ members. It is okay to research various online sources to learn and formulate your answer but when you submit your answer, make sure that it does not have content that is copied from elsewhere. Plagiarized answers will not be approved. (and therefore will not be displayed) 

 

All Questions so far can be seen here - https://www.benchmarksixsigma.com/forum/lean-six-sigma-business-excellence-questions/

 

All rewards are mentioned here - https://www.benchmarksixsigma.com/forum/excellence-rewards/

 

Cause(s) are the conditions that create the failure mode or problem. 

Based on the identified causes, there could be one or more potential causes identified for the problem/failure mode. These potential causes can be identified by various techniques such as

Cause and effect diagram (Ishikawa technique).

Further these can be narrowed down by 5 Why's, VA/NVA analysis to get the most probable cause(s) responsible for the problem/failure mode. These probable causes are the root causes which can be rectified and controlled so as to avoid the problem reoccurrence.

 

For eg.

 

For a batch of tablets not passing the specifications of physical dimensions such as thickness at the Q.C. lab.

The various causes could be 

1. Men- Not operating the process at defined parameters in the batch records.

2. Machine- Some instrument malfunctioning

3. Methods- Using a wrong method for analysis

4. Material-  a different grade of material/ different vendor used

5. Measure- different measurement technique

6. Miscellaneous- other factors such as mixture from other product or any environment deviations.

 

Based on the current quality systems at manufacturing location, it was identified that men( human error) is the most probable cause for the occurrence of the problem.

 

Now the team has to work upon how to correct the root cause and provide a corrective and preventive action so that the chances of occurrence of such type of root cause never happen again.

 

 

A Contributing cause  provides you an answer but leaves you asking why?. Controlling this cause reduces the likelihood of the error. Asking  why’s? successively to the contributing causes will eventually lead you to the root cause. A Root cause is the real reason for the error happening and fixing the root cause should prevent the error from happening again.

List all the potential causes through tools like Fishbone diagram, Brainstorming, etc.,

Verify and Prioritize all the potential causes through Hypothesis testing, PARETO ANALYSIS, FMEA and other tools.

Once Statistically significant difference is proved for Critical Causes, Check whether it is Practically significant(Since sample size affects the result. Always Check the outliers for proper result as that may be affecting results) 

Root cause should be both Statistically and Practically significant.

 

Root cause is the event which was deviated from the standard practice or should be practice which lead to the occurence of the final failure/defect through a chain of causes.

For Example.

Less moisture contain in cookies produced.

Why less moisture - because dough moisture containt was low.

Why low moisture in dough- because less water pumped while dough preparation.

Why less water pumped -because pump sensor not working correctly.

Why sensor not working correctly- because while maintenance it was missed to check

Why it was missed  - No checklist for verification after maintenance .

 

Answer of last why is the root cause for the less moisture contain in cookies and answers of other Whys are causes.

When one can simulate the same problem on application of the cause.

While doing the Root Cause Analysis, one must do a deep dive of the problem. Now while doing the deep dive there might be scenarios wherein there are more than one of the causes, and might or might not be interlinked. In those kind of specific cases we as a process excellent consultants need to focus on multiple things at the same time. So, in those kind of scenarios CAUSE becomes the focus of an RCA. 

Benchmark Six Sigma Expert View by Venugopal R

 

I am sure that most of the Excellence Ambassadors will have good answers for this question based on their experiences. My discussion would be to focus on a allied topic while RCA is performed.

 

One of the simple and popular methods used to drill down to the ‘root cause’ is the ‘5 Why’ analysis. The underlying belief is that when we ask the first ‘Why’, we may not be sure whether we have got the answer that is the fundamental cause or it is just a symptom. We need to drill down until we identify a cause, for which we can directly find a solution. 

 

For example, when we ask a question “Why the car did not start?”, the immediate answer could be that the starter motor did not work. “Why the starter motor did not work?” The answer could be that no power was being delivered to the motor. “Why power is not delivered to the motor? The answer could be that the battery had drained and had no power left. “Why the battery got drained?” The answer could be “The driver left the parking lights ‘on’ and hence the battery got drained overnight”.

 

Now, should we stop here and decide that the root cause is because the driver forgot to switch off the light? So, we go and question the driver why he did not switch off the parking lights. He replies that “The warning beep, when we keep the lights ‘on’ with the engine not running, was not working”. Now, should we hold the driver responsible for his neglect or conclude that the root cause was that the warning beep wasn’t working?

 

In the above example, there had been two incidents that led to the failure. The warning beep not working and the driver forgetting to switch off the parking lights. Even if one of those incidents had not occurred, the failure wouldn’t have happened. Those of you who are familiar with the FMEA concepts, will recall that that while analyzing a failure mode, we look at something known as “Occurrence” and “Current Controls”. The ‘current controls’ usually refer to a detection system or a ‘mistake proofing’ system.

 

In the above example, the cause is certainly the driver neglecting to put off the lights; However, there was a ‘current control’ system in the form of a warning beep that had not worked. Hence, isn’t it important that when the root cause is being finalized for this failure, we need to consider both the error by the driver and the break-down of the control system? Similar approach would be applicable to many situations where we ask “What was the root cause that led to the failure?” and “What happened to the control system?”.  A few examples:

1.      A fire broke out

          a.      Cause – Poor quality of cables leading to short circuit

          b.      Control system failure – The automatic sprinkler system failed

2.      Amount credited to wrong bank account

         a.      Cause – Human error in entering account number

         b.      Control system failure – Automated validations of account number with       other details did not function

3.      Vehicle skidded

         a.      Cause – Driver applied sudden brake on slippery road

         b.      Control system failure – the ABS did not function

 

In case one is not able to identify the existence of a relevant ‘current control system’, the absence of any 'current control' needs to be recorded as part of the root cause analysis.

 

Hope the above discussion helped to illustrate that many times, failures occur not just because of the ‘cause’ but when it is combined along with the failure of one or more control systems. The root cause investigation must identify the factor that caused the condition for failure and the ineffectiveness or absence of a ‘current control’ system.

 

Ideally one shouldn’t wait for a failure to realize that the ‘current control’ did not work. There have to be pro-active assessments to ensure the effectiveness of such controls.

 

One last point.... Even when such controls existed and prevented failures, those incidents need to be investigated to act upon the fundamental cause that caused a condition for failure, though it was averted by the ‘current control’

Root cause analysis is an action that helps to filter out the vital few factors from trivial many that are responsible for the product nonconformance. The basic rule that needs to be followed is that, cause needs to be Actionable. One cannot conclude that Man/ Mother earth is the root cause. The factor that is identified as the root cause needs to be eliminated/controlled  from the process as part of continuous process improvement. The different techniques that are useful in root cause analysis are the 5 why's technique, Affinity diagram and The Fish bone analysis. The basic ideology for the root cause analysis is the identification of the source, so that the a proper control strategy can be designed. Sometimes, Various statistical methods like Hypothesis testing, ANOVA may also be used in root cause analysis.

As Pareto principle states, 80% of the effects come from 20% of the causes.

Out of those 20% causes, the one Cause which has many dependencies/dependents which has the major significance of that 80% will be considered as root cause. 

 

That one cause which is impacting a vehicle's mileage (y) might be due to several 'x' factors. y=f(x1,x2,x3,...xn).

For example, x1 can be low tyre pressure, x2 can be poor fuel quality, x3 can be driving style, etc.,

 

All these X factors are causes of low mileage. But X2 seems to be the root cause which can have a significant impact on the engine which can further result or induce more effects (issues) similar to low mileage.  So we consider that to be a root cause. 

 

In a set of various causes to a non conformance, the one cause if resolved will not recur again or move to the other process is called the "Primary Root Cause".  For example while analyzing why a person is late to work, the root cause could be as simple as forgetting to replace the battery of an alarm clock.  It is that cause beyond which you cannot ask the "Why" and this cause will lead to recommendation of solution.  Also I could reflect to one root cause that my quality assurance team conducted on the associate entering the bill data and the supporting as multiple bills in the system.  The root cause here was the associate did not bother to look at "Bill to" on the bills and supporting. The quality assurance team further educated the Accounts payable team to read the details on the bill payable and introduced a pop up for every mandatory field to be entered in the system which was an error proofing solution.