Introduction
Root cause analysis (RCA) attempts to find the underlying (root) cause of a problem or non-conformance, rather than simply dealing with the symptoms. This is done in the hope of implementing a solution that, in the future, eliminates the causal chain of events that led to the problem.
RCA may be a step in more general problem-solving approaches, such as: Six Sigma’s DMAIC methodology, Shewhart/Deming’s PDCA cycle, 8D, CAPA / NC process, etc.
Problem Definition
One of the first steps in RCA is to correctly define the problem. This is not as trivial as it sounds; in fact, experience tells us initially what will be relayed is most likely to be a perceived solution instead of the problem:
“We need to replace the proximity sensor on line 1”
“Could you buy a new chiller for Cell2?”
“We can’t keep doing it this way, can we get that new software?”
Defining the problem is in fact the most critical part of RCA. Even if we do everything right after problem definition, if we’re stuck with an incorrect problem we’ll wind up with an incorrect solution. The adage “garbage in, garbage out” rings true here as well.
A good way of defining the problem in medical devices is to ask: What about the [process, product, service] makes it non-conforming?
A good way of defining the problem in medical devices is to ask: What about the [process, product, service] makes it non-conforming?
The non-conformance could be with regards to:
An explicit specification in a document (SOP, drawing, etc.)
An implicit (non-stated) lack of meeting expectations
In the latter case, the specifications need to be improved with additional details.
Brainstorm Causes
Once the problem has been defined, the next step is to brainstorm possible causes. At this stage it is important to form a well-rounded multi-disciplinary team, consisting of both subject matter experts (SMEs) and those new to the topic. This is to ensure:
We consider as many points of view as possible
Have the expertise and experience needed
Promote out-of-the-box thinking.
Why include people new to the topic on the team? Because, in the words of Shunryu Suzuki: "In the beginner’s mind there are many possibilities, but in the expert’s there are few."
"In the beginner’s mind there are many possibilities, but in the expert’s there are few."
3 RCA Methods:
- 5 Whys Method -
In this method we start with the problem and ask consecutively why the previous symptom or issue arose. The premise is that by asking Why five times, we’ll get to the root cause and not stop at intermediate causes.
We can stop prior to asking all five of the Whys; however, this will make it more likely the method will identify a symptom rather than the root cause.
Pros:
• Simple to understand and perform
• Best tool when the causal chain is evident or strongly suspected
• Often, good choice for service problems
Cons:
• Only one causal chain is explored (additional 5 Whys may be needed)
• Complicated if there’s more than one cause per Why (branching)
• If not careful, may arrive at a cause that’s too broad or too narrow
• Can lead to confirmation bias (i.e., finding what we wanted to find)
- Cause and Effect Diagram -
Also referred to as an Ishikawa or Fishbone diagram, it is a graphical method where the potential causes are grouped into one of 5 or 6 categories:
Man (personnel) causes
Machine (equipment) causes
Materials causes
Measurement causes
Methods causes
Environment (a.k.a., ‘Mother nature’ to make 6 M’s)
These are referred to as the 5M's, 5M's+1E, or 6 M's.
Finally, a very brief statement of the problem is then placed at the head of the diagram.
Pros:
• Categories aid in brainstorming possible causes
• Good technique when dealing with many possible causes
• Great choice when possible causes will be further investigated via natural experiments, DoEs, prototype / pilot runs, etc.
Cons:
• Can seem overwhelming or confusing
• May lead to identifying too many causes or no root-cause
• Often necessitates other RCA or investigative techniques to narrow down to the actual root-cause
WARNING: Although the Cause and Effect diagram is very popular, equally as popular is its wrong application. Frequently, it is misused as a convenient way to list all possible causes and implement solutions to each one. This defeats the whole point of RCA in general and the diagram in particular.
- Is / Is Not Diagram -
Super-powerful when applied to the right problems, this method employs questions to systematically explore What, Where, When and How big a problem is. This can greatly reduce the number of possible causes. The Is / Is Not diagram can also be used in problem definition and, especially in medical devices, in containment activities.
Of all 3 methods outlined here, it is the least common but especially effective during troubleshooting of machine malfunctions.
Pros:
• Easy method to understand and apply
• Can serve as a guide in problem definition
• Useful in containment activities
• Especially powerful in machine troubleshooting and product issues
Cons:
• Applied to the wrong problems, may not narrow down the list of possible causes
• May need other RCA or investigative techniques to finally get to the root-cause
Verification: Correlation vs. Causation
Once the root-cause has been preliminarily identified, it is advisable to verify it is indeed a causal factor. In other words, just because a certain variable, condition or situation seems associated (correlated) with a given problem it does not necessarily follow it causes it.
One way to verify this is to experiment by removing the presumptive root cause and making sure the problem disappears; re-introducing it should then make the problem re-appear. Having the problem appear and disappear at will by introducing or removing the presumptive root-cause, ensures we've discovered a causal relationship and not just an association.
Another verification method is to eliminate the presumptive root cause and making sure no more instances of the non-conformance occur. This is a negative observation, meaning we’re expecting the problem to not re-appear, so time is required to verify the solution has been effective. It's most often used for service processes, since it is frequently not practical to perform an experiment as outlined above.