Root cause analysis with the 5 Whys & fishbone diagram.

When you only fix what you can see, the same problem comes back: sometimes next week, sometimes on a different line, sometimes at a different customer. Root Cause Analysis (RCA) is how you stop that. This guide covers the two tools I reach for most, the 5 Whys and the fishbone (Ishikawa) diagram, with worked examples and the traps that send teams back to square one.

What is root cause analysis?

RCA is a structured way to answer one question: what's the real reason this happened, the one that, if we fix it, actually stops it from happening again? You don't need a dedicated investigator. You need a clear problem statement and the discipline to keep asking why.

Three ideas help you sort what you find:

• Symptom: what you can observe. It's real, but it's not the reason.
• Contributing cause: something that helped the problem happen but, fixed alone, wouldn't stop it. A worn seal, a missed inspection and a rushed shift can all stack up.
• Root cause: the underlying, verified cause you can act on. Removing it stops the problem from coming back. Complex problems can have more than one.

When to use RCA (and which tool)

Use RCA any time a problem has escaped to a customer, keeps coming back, or is serious enough that "we sorted the parts" isn't an acceptable answer. It's also the engine inside formal responses like a CAPA record or an 8D report.

• Use the 5 Whys when the problem has one clear thread to pull.
• Start with a fishbone when the cause could be hiding in several places.
• Many teams do both: a fishbone first to avoid tunnel vision, then the 5 Whys on the branch that looks most likely.

How to do a root cause analysis, step by step

1. Write the problem statement. Say what happened, not what caused it and not how to fix it. "Operator wasn't paying attention" is a guess at a cause, made too early. A real problem statement sounds like: "On March 4, Line 2 produced 40 brackets with weld penetration below the print minimum, discovered at final inspection." Get the team to agree on it word for word before anyone suggests a cause.
2. Contain the problem. Sort inventory, add temporary 100% inspection, or quarantine suspect stock. Containment stops the bleeding right now. It is not the finish line.
3. Map the possible causes. For a multi-direction problem, draw a fishbone with six categories: People, Machine, Method, Material, Measurement, Environment. List every reasonable possibility on its branch.
4. Ask "why" down the most likely thread. Start with the symptom, ask why it happened, then why that happened. Five is a guideline, not a rule. Stop when the answer is specific, backed by evidence, and within your control.
5. Verify with evidence. Every answer in a 5 Whys chain is a hypothesis until evidence backs it up. Say what you'd expect to see if the cause is right, and what you'd see if it's wrong. Then pull the record, run the test, or check the timeline.
6. Fix the verified root cause. The corrective action targets the root cause, so the problem stops happening, not just the symptom.
7. Plan the effectiveness check. Define what "worked" looks like before you implement: a metric, a time window, a sample size. "We haven't seen it again yet" isn't verification.
8. Update the related documents. If the fix changes a control, update the Control Plan and check whether a related FMEA needs the cause or control added.

Worked example 1: the 5 Whys on rusty brackets

Problem statement: brackets shipped to Customer B arrived with visible surface rust on the unpainted mounting face.

1. Why did the brackets rust? They sat exposed to humidity for several days.
2. Why? Finished-goods staging was over capacity, so the batch sat outside the climate-controlled area.
3. Why? Shipping volume for this customer went up, but the staging schedule wasn't adjusted.
4. Why? Nothing triggers a review of staging capacity when volume changes. The schedule only gets looked at once a year.

Evidence: shipping records and staging logs confirmed the overflow started right after the volume increase. Verified root cause: no process reviews staging capacity when shipping volume changes. Corrective action: a staging-capacity review triggered by shipping volume, not just the calendar.

Notice where the team could have stopped too soon. "Parts sat in humidity" is a symptom; fixing it fixes nothing. "Staging was over capacity" leads to adding more space, which works only until volume grows again.

Worked example 2: a fishbone (Ishikawa) diagram

A CNC machining cell suddenly scraps a lot of parts for bore diameter out of tolerance. The team builds a fishbone:

The root cause sat across two branches: the program change raised the feed rate, and nobody updated the tool-change interval to match. The fix: update the interval, and review tooling intervals whenever cutting parameters change. "New operator" sounded reasonable, but the evidence pointed somewhere else.

Common root cause analysis mistakes

• Stopping at "human error." If a person made a mistake, ask what allowed that mistake to happen and reach the next step uncaught. That system gap is usually the fixable root cause.
• Blaming the person instead of the process. Keep the discussion on the process, or people stop sharing what they know.
• A vague problem statement like "quality issue on Line 2" instead of what happened, how many, when, and how it was found.
• Stopping at containment. "We sorted the bad parts" is not a corrective action.
• Confusing correlation with cause. Two things changing at the same time doesn't mean one caused the other.
• Forcing a single root cause when the evidence shows more than one.
• Never verifying the fix, or changing a control without updating the Control Plan and FMEA.

Before you accept a root cause, make sure it's specific, backed by evidence, within your control, and that removing it would actually prevent the problem.

Root cause analysis questions people ask