Root cause analysis example: 6 worked samples and a template

A good root cause analysis example shows a clear problem and a chain of causes backed by evidence. It ends with a root cause statement and a countermeasure that prevents recurrence. This guide gives six root cause analysis samples, each using a different technique.

All six are illustrative examples written to show the method. They are not real company cases, and the numbers are invented for teaching.

Key takeaways

A root cause is a process condition you can change that, if fixed, stops the problem coming back.

Different problems suit different root cause analysis techniques: 5 Whys, fishbone, is/is-not, fault tree, Pareto and 8D.

Each example here follows the same order: problem, method, chain of causes, root cause statement, countermeasure.

A strong root cause statement describes a cause in the system, never a person's failing.

Verify each cause with evidence before acting on it.

What does a good root cause analysis look like?

A good root cause analysis defines the problem precisely and tests each cause against evidence. It stops at a cause the team can control and ends with a countermeasure and a check. The write-up is short enough to read in a few minutes.

The types of root cause analysis differ in how they find causes. Sequential methods such as 5 Whys follow one chain. Diagram methods such as fishbone and fault trees map many possible causes. Data methods such as Pareto charts show which problem to attack first.

Many teams record the result on an A3 report. See the guide to A3 problem solving, and the root cause analysis page for the full overview.

Example 1: machine stoppage with 5 Whys

Problem: a packing machine stops about three times a shift because the sealing jaw jams. Method: 5 Whys, asked at the machine.

Chain: the jaw jams because film is out of position. The film shifts because the feed roller slips. The roller slips because its surface is worn and glazed. The surface is worn because replacement is not on any schedule. There is no schedule because the roller was never listed as a wear part.

Root cause statement: the roller has no planned replacement because it is missing from the preventive maintenance list. Countermeasure: add the roller to the list with a replacement interval, then check stoppages weekly for a month.

Example 2: late deliveries in an office with a fishbone

Problem: a back-office team sends about one in five customer quotes after the promised date. Method: a fishbone diagram, with the team listing causes under people, method, tools, information and environment.

Chain: the group tests each branch against ten late quotes. Seven of them waited for pricing approval, and the approval request had no owner or due date. Approvers received it by general email and checked it only once a day.

Root cause statement: quotes are late because pricing approval requests have no named approver or time limit. Countermeasure: route requests to a named person with a four-hour response standard and a visible queue.

Example 3: software outage with a fault tree

Problem: an online booking service went down for 45 minutes. Method: a fault tree, which starts at the failure and branches downward into the combinations of events that could cause it.

Chain: the service failed because both database connections were unavailable. The first failed on a certificate expiry. The second failed because the backup used the same certificate, so one expiry removed both paths.

Root cause statement: the backup connection shared the certificate of the main one, and no alert warned of its expiry. Countermeasure: use separate certificates and add an expiry alert 30 days ahead. Bell Labs developed fault tree analysis in the early 1960s for missile safety work.

Example 4: clinic waiting times with a Pareto chart

Problem: patients at a small clinic wait too long before seeing a nurse. Method: a Pareto chart, which counts causes and ranks them so the biggest few are tackled first.

Chain: staff log the reason for each of 100 long waits. Missing registration details account for 46, nurse room not ready for 25, late arrival of patients for 15, and other reasons for 14. The registration problem comes from paper forms left incomplete at the front desk.

Root cause statement: registrations are incomplete because the form allows submission with required fields blank. Countermeasure: make required fields mandatory at check-in, then re-run the count after two weeks.

Example 5: label complaint with is/is-not analysis

Problem: a customer reports that product labels peel off. Method: is/is-not analysis, popularized by Kepner and Tregoe. It compares where and when the fault occurs with where and when it could occur but does not.

Chain: the peeling is found on one batch, one filling line and cartons stored near the loading door. It is not found on other lines or other batches. The difference is a new adhesive roll loaded on that line, and cold, damp storage.

Root cause statement: labels peel because the adhesive roll used on line 2 was not rated for cold, damp storage. Countermeasure: specify the adhesive grade on the material standard and add a storage check at goods-in.

Example 6: warehouse picking errors with 8D

Problem: a warehouse ships the wrong item on about two orders in a hundred. Method: 8D, an eight-discipline team method that Ford documented in the late 1980s, covering containment, root cause, corrective action and prevention.

Chain: as containment, the team adds a scan check at packing. Analysis shows most errors involve two products stored in adjacent bins with similar packaging. Pickers rely on a visual match, because the bin label shows only a short code.

Root cause statement: picking errors occur because look-alike items sit in adjacent bins with no scan confirmation at pick. Countermeasure: separate the items, require a scan at the bin and review error counts weekly. See also poka-yoke.

How to write a root cause statement

Write a root cause analysis statement as a cause-and-effect sentence about a process condition: this problem occurs because this condition exists. Use a simple template and keep it to one sentence.

Template: [Problem] happens because [process condition], which allows [mechanism] to occur. For example: late quotes happen because approval requests have no named owner, which allows them to sit unseen.

Test the statement three ways. Can you verify it with evidence? Would fixing it stop the problem? Is it a condition, not a person? The root cause analysis software and CAPA software categories include tools that store such statements and actions.

Common root cause analysis mistakes

The most common mistake is blaming a person, such as operator error, which ends the analysis before the system is examined. Ask why the process let the error happen or go unnoticed.

Another mistake is stopping at a symptom. A jammed machine, a late quote and a wrong pick are effects, so ask why again until you reach a cause you can change.

Teams also act on guesses without evidence, pick a single cause when several combine and skip the check that confirms the fix worked. Going to the real place helps, as the gemba walk checklist shows.

Frequently asked questions