Root Cause Analysis
Root cause analysis (RCA) is a methodology for finding and correcting the most important reasons for performance problems. The purpose of RCA is not to fix a specific product failure, but to support improvement by identifying the gap in the system that allowed issues to happen.
"If you want your problems to go away, your best option is to kill them at the root.”
-- Bill Wilson
RCA seeks out unnecessary constraints as well as inadequate controls.
In safety and risk management, it looks for unrecognized hazards and inadequate or missing barriers.
It helps target CAPA (corrective action and preventive action) efforts at the points of most leverage.
RCA is an essential ingredient in pointing change efforts in the right direction.
RCA is probably the only way to find the core issues contributing to your toughest problems.
“If I only had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.”
THE GOAL of any good root cause analysis is to get past the immediate blame and justification, find the gap in the system tools, information, resources, or structure, and close the gap effectively.
A good root cause states the cause in one sentence and clearly points to the ‘needed change to prevent recurrence’ (ISO calls this a corrective action). Conversely, you will know if the root cause analysis was weak, if the corrective action is implemented and the issue recurs!
To make this a useful part of a culture of improvement remember to have fun! Brainstorm with those involved, to get past the obvious.
Recognize and celebrate those who contribute thought or effort to the process.
5 simple RCA tools/ideas to support your improvement process regardless of company size.
Download our free white paper for more in-depth details on these steps.
Cross-functional teams increase likelihood of creating an effective solution compared to a single-department ‘silo’ approach, or using external resources only. Have each team member bring data that they believe contributed to the issue.
The Ishikawa Fishbone tool broadens focus from the incident person or department, to all contributing activities. (For example, try describing in detail the processes involved to have flowers delivered.)
Evaluate if anything within each of the 6 major inputs had any contributing impact on the issue:
Manpower (staff, training, competence evaluation, culture, language, responsibility, authority).
Method (process inputs/outputs defined, instruction clarity, order of activities, communication).
Material (process inputs whether information or physical material, supply chain control).
Machine (equipment selection, capability, maintenance, fitness for purpose, capacity, scheduling).
Measurement (test, inspection, monitoring validation, and the tools to do it).
Environment (Physical: space, temp, humidity, noise, technology. Social: cooperative, teamwork, communication, isolation. Psychological: supportive, collaborative, stressful, hostile).
The team identifies contributing factors in each of these areas, selects those with the highest risk of recurrence or impact, and investigates the root cause for each, using one of the tools below.
If you find the team struggling with the fishbone, try this, and keep asking What else?
Who (see Manpower above).
What (see Material, Machine, and Measurement above).
Where (see Environment above).
When (consider timing or time pressures, lighting, shift changes).
How (see Method above)
4. The 5 Why's
Remember to keep the focus on the system, not the person. This tool works to investigate one cause at a time, not 5 unrelated causes. For each identified cause, ask “Why is that?” of the previous answer (at least five times):
Why 1: Define the suspected immediate cause.
Why 2: Define why the immediate cause happened.
Why 3: Define why the contributing cause happened.
Why 4: Define why the supporting cause happened.
Why 5: Define why the hidden cause happened.
5. The 3 X 5 Whys:
When there are multiple contributing causes, pick three of them and use the 5 Whys tool for each input. The steps are the same as above, diving past the obvious to find the system weakness.