Root-cause analysis: the fishbone diagram and 5 Whys

What root-cause analysis actually means

Root-cause analysis (RCA) is the disciplined search for the underlying reason a problem occurred — the cause that, if removed, stops the problem recurring — rather than the symptom you first see. A customer reports a leaking pump; the symptom is the leak, the immediate cause might be a failed seal, but the root cause could be a supplier who changed a rubber compound, a storage condition that hardened the seals, or an assembly torque spec that was never controlled. Treat the symptom and the pump gets a new seal and leaks again. Treat the root cause and the failure mode disappears.

RCA is the analytical heart of the investigate step in any complaint-handling lifecycle and of D4 in the 8D method. Two tools do most of the work and they are complementary: the fishbone diagram gives you breadth — it stops you fixating on the first plausible cause — and the 5 Whys gives you depth — it drives from a broad category down to the specific, actionable cause.

The fishbone (Ishikawa) diagram and the 6M

The fishbone diagram — also called the Ishikawa diagram after Kaoru Ishikawa, or the cause-and-effect diagram — organises the search for causes. The problem statement sits at the fish's head; a spine runs to it; and off the spine branch the major cause categories, each a "bone". The team brainstorms candidate causes onto the relevant bones, then tests the plausible ones against evidence. Its whole value is completeness: it forces the team to consider categories nobody wants to own, instead of anchoring on the first explanation offered.

In manufacturing the classic categories are the 6M:

The 6M is a manufacturing default, not a law. Service and transactional teams often use the 4S or 4P variants (Surroundings, Suppliers, Systems, Skills / People, Process, Policy, Plant). The categories are scaffolding to guarantee breadth — use whichever set fits your process, but pick one and use it consistently so your causes become analysable across cases.

How to build a fishbone in six steps

The 5 Whys — drilling from category to cause

The 5 Whys is deceptively simple: state the problem and ask "why?" repeatedly, each answer becoming the next question, until you reach a cause you can actually act on. "Five" is a rule of thumb — sometimes it is three, sometimes seven. Its discipline is refusing to stop at the first answer, which is almost always a symptom. The classic caution: 5 Whys can follow a single narrow chain and miss parallel causes, which is exactly why it works best inside a fishbone — the fishbone spreads the search wide, the 5 Whys drives the promising branches deep. And every "because" must be backed by evidence, or you have simply argued your way to a convenient conclusion.

A worked example, end to end

Complaint: a batch of machined housings shipped with burrs that fouled assembly at the customer. Fishbone brainstorming raises candidates across Machine (worn deburring tool), Method (no deburr check in the setup sheet) and Measurement (final inspection samples cosmetics, not burrs). The team drills the Method branch:

• Why did burred parts ship? Because the deburr step was skipped on the night shift.
• Why was it skipped? Because the deburr operation is not in the standard work instruction — it is "known" tribal knowledge.
• Why is it not in the instruction? Because the instruction was never updated when the part was revised.
• Why was it not updated? Because there is no trigger linking part revisions to work-instruction review.

The symptom was a burr; the immediate cause was a skipped step; the root cause is a missing change-control link between engineering revisions and shop-floor instructions. The corrective action is not "remind operators to deburr" — it is a controlled process that forces work-instruction review on every part revision, plus adding burr detection at inspection to close the escape point. That is a fix that spreads to every part, not just this one.

Fishbone vs 5 Whys — when to use each

They are partners, not rivals. Open with a fishbone to map the territory, then run 5 Whys down the branches that survive first contact with evidence — and always verify. See how this feeds the wider method in the 8D guide and becomes formal action in CAPA.

How Fast Complaint Software supports root cause

Fast Complaint Software gives the investigate step real analytical depth instead of a free-text "resolution" box. A complaint captured as a numbered ticket escalates into the 8D and CAPA tooling, where a fishbone diagram and structured cause categorisation (cause category versus specification) organise the search, and a Problem Solving Report holds the narrative. A Past Trouble Database is checked first, so a new complaint is matched against proven countermeasures before the team reinvents one — many "new" problems are old problems with a different part number. Confirmed fixes spread through Horizontal Deployment, overdue investigations are chased by SLA follow-up and escalation, and the customer's post-resolution rating rolls into the Customer Satisfaction Index. The result is a root cause that is recorded, reusable and traceable to the complaint that raised it.

Frequently asked questions