Lean and quality teams use RCA after defects, breakdowns, safety incidents and customer complaints. It sits between containment, which protects the customer today, and the corrective action that protects them for good.
Where it comes from
RCA draws on several quality traditions: the five whys from Sakichi Toyoda and Toyota, the cause-and-effect diagram from Kaoru Ishikawa, and the problem-solving formats used in Six Sigma and the automotive 8D method.
At a glance
Below the waterline
Swipe sideways to see the whole diagram.
How to apply Root cause analysis
- 1
Define the problem
Write one clear problem statement: what happened, where, when and how big, compared with the standard. Avoid naming a cause in the statement.
- 2
Contain it
Protect the customer while you investigate. Quarantine suspect parts, add a temporary check or switch to a backup process.
- 3
Gather facts at the gemba
Go where it happened, look at the parts, the equipment and the records, and talk with the people involved. Collect data before forming theories.
- 4
List possible causes
Use a fishbone diagram to list causes across method, machine, material, measurement, environment and people. Keep the list broad at this stage.
- 5
Drill down and verify
Ask why for the most likely causes until you reach one you can act on. Then prove it with data or by turning the problem on and off.
- 6
Fix and prevent
Put in a corrective action that removes the root cause, ideally with mistake-proofing. Update standards and check other lines with the same risk.
- 7
Confirm it worked
Watch the results over enough time to be sure the problem is gone. Close the RCA only when the data shows it.
Worked example (illustrative)
A bottling line rejects 3 or 4 caps a week. The team contains the issue with a torque check on every case, then finds through a fishbone and five whys that one capper head wears faster because it is missing from the PM lubrication route. The team adds the head to the route and a wear gauge to the checklist. Rejects fall to 1 in the first week after the fix and none in the three weeks after that, so the RCA is closed and the plant adds the same check to its other capper.
Common mistakes
- Stopping at human error as the root cause, instead of asking why the process allowed the error.
- Picking a cause in the meeting room and never verifying it with data or at the gemba.
- Closing the RCA when the action is assigned, not when results show the problem has stopped.
When Root cause analysis is not the right tool
A full RCA takes time. For a one-off, low-risk issue with an obvious cause, a quick fix and a note may be enough.
RCA also needs facts. If nobody can see the process or the parts, start by collecting data rather than running a meeting.
Root cause analysis methods compared
The five whys suits simple problems with one chain of cause. The fishbone diagram helps when many causes are possible. Pareto analysis shows which problem to tackle first.
For a full investigation, teams wrap these tools in a format: an A3 in lean, DMAIC in Six Sigma, or 8D in automotive supply chains. The root cause examples guide walks through common cases.
Symptom, direct cause and root cause
Many RCA reports go wrong by stopping one layer too early. It helps to name three layers before choosing an action. Here is an illustrative case.
Layer 1: Symptom
A conveyor motor overheated and stopped the line.
Layer 2: Direct cause
The motor bearings were not getting enough lubrication.
Layer 3: Root cause
When the line's output went up, nobody added a lubrication check to the preventive maintenance schedule.
Restarting the motor fixes the symptom, and greasing it fixes the direct cause for a while. Only changing the PM schedule, with an owner and a check that the task gets done, stops the problem coming back.
RCA often runs alongside failure analysis, but the two answer different questions. Failure analysis explains how a part or system failed, such as a cracked shaft or a crashed service. RCA asks why the conditions for that failure existed and what to change so it does not happen again.
When to run a formal RCA
Not every problem needs a full investigation, and teams that run one for every small issue run out of time for the ones that matter. Agree the triggers in advance, so the decision is not made under pressure. Common triggers:
Repeat failures: the same breakdown, defect or outage comes back after it was fixed.
Safety events: injuries, near misses and environmental releases.
Escaped defects: a quality problem got past inspection or reached the customer.
Repeat complaints: customers report the same process failure more than once.
Long outages: downtime passes an agreed threshold, such as one hour on a critical line.
High-cost failures: scrap, rework, penalties or lost output above an agreed amount.
Compliance events: anything a regulator or a customer contract requires you to investigate.
Match the depth to the risk. A minor recurring nuisance may need only a short five whys on the team board. A safety incident or a major outage deserves a full investigation with a written report.
Strong and weak corrective actions
A corrective action changes something so the root cause is removed or controlled. Actions differ a lot in how well they hold. Weak actions rely on people remembering. Strong actions change the system around the work.
Weak: relies on memory
Strong: changes the system
Remind technicians to inspect belts
Add a belt tension check to the weekly PM checklist for line 3, with a photo as proof, and review failure counts after 60 days.
Retrain the operator
Add a fixture or sensor that stops the wrong part being loaded, a form of poka-yoke.
Send an email about the new rule
Change the form or the software field so the step cannot be skipped.
Add a final inspection
Move the check to the step where the defect is made, so it is caught at the source.
Each action also needs six fields: the specific change, one owner, a due date, the result you expect, how you will check that it worked and the date of that check. An action without an owner is only an intention.
Before you close an RCA: a checklist
Run through this list before marking an RCA closed. It works for a quick review of a small issue and for a formal investigation.
Ready to close?
- Problem statement. It describes what happened without naming a cause.
- Impact. Downtime, quality, safety, users affected or cost is stated where it applies.
- Evidence. Facts come from records, parts, logs and the gemba, not from memory alone.
- Timeline. It shows what happened before, during and after the event.
- Several causes considered. The team looked at more than one possible cause before choosing.
- Root cause verified. Data or a test supports it, not just agreement in the room.
- Actions fit the cause. They address the root cause, not only the symptom.
- Owners and dates. Every action has one owner and a due date.
- Check defined. The team knows how and when it will confirm the fix worked.
- Learning stored. The report is filed where the next team will find it.
Common RCA misconceptions
Myth“There is always one root cause”
In practiceMany incidents have several causes that combine. The aim is to find the ones that matter and can be controlled. The fault tree example shows causes combining.
Myth“The first cause we find is the root cause”
In practiceThe first answer is usually the symptom or the direct cause. Keep asking why until you reach a cause you can act on.
Myth“Corrective action means retraining”
In practiceTraining is easy to assign, but it rarely holds on its own. A changed design, check or standard usually works better.
Myth“Software can find the root cause for us”
In practiceTools that link alarms, logs and work orders speed up the search. Someone still has to check the evidence and confirm the cause.
| Method | Best for | Output |
|---|---|---|
| Five whys | One clear chain of cause | A cause you can act on |
| Fishbone diagram | Many possible causes | A grouped list of causes to test |
| Pareto chart | Choosing which problem to tackle | The few causes behind most defects |
| Fault tree analysis | Complex failures with combined causes | A logic tree of failure paths |
| 8D | Customer complaints in supply chains | A documented eight-step report |
| Change analysis | A problem that started after something changed | The change that set it off |
Guides on this topic
- Root cause analysis example: 6 worked samples and a templateA root cause analysis example for six settings, from a machine stoppage to warehouse picking errors, plus root cause statement wording and common mistakes.Read the guide
- Process improvement methodologies: 9 methods comparedProcess improvement methodologies compared: PDCA, lean, kaizen, Six Sigma, TQM, theory of constraints, BPR and retrospectives, with how to choose and combine.Read the guide
- Lean Six Sigma yellow belt: training, role and valueA lean six sigma yellow belt supports improvement projects with basic tools. See what yellow belt training covers and how it differs from green belt.Read the guide
- Six Sigma green belt: meaning, training and DMAIC toolsA six sigma green belt leads focused DMAIC projects. See what green belt training covers, the tools by phase, exam topics and whether it is worth it.Read the guide
Sources
Books and papers show their publication year. Web pages show the month we last checked them.
- 1.Kaoru Ishikawa, Introduction to Quality Control (3A Corporation, 1990)
- 2.Taiichi Ohno, Toyota Production System: Beyond Large-Scale Production (Productivity Press, 1988)
- 3.Durward K. Sobek II and Art Smalley, Understanding A3 Thinking: A Critical Component of Toyota's PDCA Management System (Productivity Press, 2008)