The Beginner's Guide to Root Cause Analysis (with 5 Whys Examples)

What root cause analysis actually is

Root cause analysis (RCA) is the umbrella term for any structured method of tracing a problem back past its visible symptoms to the actual condition, action, or system failure that caused it. The key word is structured — RCA isn't just "thinking harder about why something went wrong," it's a repeatable process that forces a team to keep digging past the first plausible-sounding explanation, which is usually where untrained problem-solving stops.

There are several formal RCA techniques — Fishbone (Ishikawa) diagrams, Fault Tree Analysis, Failure Mode and Effects Analysis (FMEA), Pareto analysis — but the one most people meet first, and the one this guide focuses on, is the 5 Whys.

Why "root cause" matters more than it sounds

Every problem has a chain of causes behind it, and most visible problems sit at the very end of that chain — they're symptoms, not causes. A machine jamming, a customer complaint, a late shipment: these are all downstream effects. If you fix at the symptom level, you're treating the last domino, not the one that started the chain falling. The domino you stopped falls over again next time, in a slightly different way, because the actual trigger further up the chain was never addressed.

This matters financially as much as operationally. Recurring problems cost more than one-off ones, because they consume investigation time, rework, and goodwill repeatedly instead of once. A defect that keeps recurring because the true cause was never fixed isn't really "fixed" at all — it's postponed, with interest.

The 5 Whys technique, step by step

The 5 Whys is credited to Sakichi Toyoda and became a core part of the Toyota Production System's problem-solving culture^[1]. The method is disarmingly simple: state the problem, ask "why did this happen?", write down the answer, then ask "why" again about that answer. Repeat roughly five times, though the actual number of iterations is a guideline, not a rule — you stop when you reach a cause that is within your control to fix and that, if fixed, would prevent recurrence.

Step 1: Write a precise problem statement

Vague problem statements produce vague root causes. "Customers are unhappy" isn't a starting point; "14% of orders shipped last week arrived more than two days late" is. Precision at this stage saves an enormous amount of wasted effort later, because it stops the team drifting into discussing a different, related problem halfway through the exercise.

Step 2: Assemble the right people

5 Whys works best as a group exercise involving the people who actually do the work connected to the problem, not just managers theorising about it from a spreadsheet. A machine operator, a warehouse picker, or a customer service rep will often surface a "why" that nobody in a management meeting would think to ask.

Step 3: Ask "why" and resist the first answer

The most common failure in a 5 Whys session is treating the first or second "why" as the finish line, because it already sounds plausible. Plausible is not the same as true, and true is not the same as root. Keep going until the answer describes something systemic — a missing standard, a training gap, a design flaw, an unclear responsibility — rather than a one-off human error, which is very rarely the actual root cause even when it's the easiest thing to blame.

Step 4: Stop at a cause you can act on

You know you've gone deep enough when the answer to "why" is something your team has the authority and the means to fix. If the chain leads somewhere genuinely outside your control (e.g. "because steel prices rose globally"), that's useful context but not a stopping point for action — back up one level to the last cause that is within your control.

Step 5: Verify before you commit

Before implementing a fix, briefly test whether removing the identified root cause would plausibly have prevented the original problem. This doesn't need to be a formal experiment for small issues, but for anything costly to fix, a short pilot or a check against historical data (does the pattern match other instances of this failure?) avoids acting on a root cause that was only partially correct.

Worked example 1: A late delivery

Problem: A customer's order shipped three days later than promised.

1. Why was the order late? Because it wasn't picked from the warehouse until Thursday, one day before the promised ship date.
2. Why wasn't it picked until Thursday? Because it was stuck in the "awaiting stock check" queue since Monday.
3. Why was it stuck in that queue for three days? Because stock checks are only reviewed once a day, at 4pm, and this order was flagged at 4:15pm on Monday — missing that day's review window.
4. Why is the stock check review only run once a day? Because it's a manual process run by one person as their last task of the day, and it was never designed to handle orders flagged after the cut-off.
5. Why was a once-daily manual check ever used for something time-sensitive? Because order volumes were low enough historically that a daily manual pass was sufficient — but volumes have roughly doubled in the last year and the process was never revisited.

Root cause: A manual, once-daily stock verification process that was appropriate at the old order volume has become a bottleneck at the new volume, and orders flagged just after the daily cut-off silently wait almost 24 extra hours.

Notice what this example demonstrates: the "obvious" fix at Why #1 would have been "tell the picking team to prioritise this order" — which would have solved this one late shipment and done nothing for the next hundred orders flagged just after 4pm. The actual fix (moving to a more frequent or triggered stock check, or reassigning volume-based capacity to the process) addresses the systemic issue.

Worked example 2: A recurring quality defect

Problem: 8% of units on Line 2 are failing final inspection for a hairline crack near a weld point, up from a historical baseline of 2%.

1. Why are units failing at the weld point? Because the weld is cracking under normal handling stress after assembly.
2. Why is the weld cracking under normal stress? Because the weld penetration depth is inconsistent — some welds are noticeably shallower than the specification.
3. Why is weld penetration depth inconsistent? Because the welding current setting has been drifting between shifts.
4. Why has the current setting been drifting? Because it's adjusted manually by each shift's lead operator based on visual judgement, rather than a fixed, calibrated setting.
5. Why is it set manually rather than calibrated and locked? Because the welding machine was installed before the current SOP was written, and the SOP was never updated to include a locked, calibrated current setting for this specific weld point.

Root cause: An outdated SOP allows manual, judgement-based adjustment of a weld parameter that should be fixed and calibrated, and the increase in defect rate coincides with newer, less experienced shift leads whose "visual judgement" differs from the original operators'.

Again, notice the layering: a shallow fix ("retrain the current shift leads") would help temporarily but would drift again with the next staff change, because it doesn't address the underlying issue that the process depends on individual judgement at all.

Common mistakes that make 5 Whys weaker than it should be

• Stopping at "human error." Almost every human error has a systemic condition behind it — unclear instructions, poor tooling, fatigue from understaffing, or a design that makes the error easy to make. "The operator made a mistake" is rarely a genuine root cause; it's usually Why #1 or #2.
• Branching into multiple chains without acknowledging it. Real problems often have more than one contributing cause. If your "whys" start splitting into two plausible directions, it's often better to run two separate 5 Whys chains (or switch to a Fishbone diagram) rather than forcing a single linear chain that oversimplifies a genuinely multi-causal problem.
• Doing it alone, from a desk. 5 Whys run by one person without input from the people closest to the work tends to reflect that person's existing assumptions rather than surface anything new.
• Skipping the verification step. Especially for expensive fixes, confirm the identified root cause against other historical instances of the same problem before committing resources.

When 5 Whys isn't the right tool

5 Whys works best on problems with a single, traceable cause chain. For problems with genuinely multiple, interacting causes (a defect that only appears when three separate conditions align, for example), a Fishbone diagram organised by category (Machine, Method, Material, Manpower, Measurement, Environment) is usually more effective, because it lets a team explore several branches in parallel rather than forcing one linear path. For safety-critical or highly regulated failures, a more formal Fault Tree Analysis or FMEA may be required to satisfy audit or compliance standards.

Worked example 3: A recurring IT support ticket

Problem: The same "unable to print" ticket has been logged by the finance team 11 times in the last quarter, each time resolved by an IT technician restarting the print spooler.

1. Why does printing fail? Because the print spooler service crashes intermittently on the finance department's shared print server.
2. Why does the spooler service crash? Because it runs out of available memory when a large batch of invoice PDFs is queued at month-end.
3. Why does memory run out during month-end batches? Because the print server was sized for the department's needs three years ago, before the finance team doubled the volume of invoices it processes monthly.
4. Why wasn't the server resized when volume increased? Because there's no process that flags growing print volume to IT — the only signal IT receives is a support ticket after something has already failed.
5. Why is there no proactive volume-monitoring process? Because print infrastructure was treated as "set and forget" after initial installation, with no periodic capacity review built into IT's standard operating procedure.

Root cause: Print server capacity was never included in IT's periodic capacity review process, so a genuine, predictable growth in print volume was only ever detected reactively, one failure at a time, instead of proactively.

This example is worth including because it illustrates a pattern common well outside manufacturing: eleven "fixes" (restarting the spooler) were applied to the same symptom over a quarter, and every one of them was technically correct in the moment and completely ineffective at stopping recurrence, because none of them addressed capacity planning. It also shows that 5 Whys applies just as well to office and IT processes as it does to a factory floor — the discipline of the technique doesn't depend on the industry.

5 Whys vs Fishbone: how to choose between them

Because these two tools are often taught together, it's worth being explicit about when to reach for which one. 5 Whys assumes a single, mostly linear chain of cause and effect — it works best when your instinct says "there's one thread here, I just need to follow it down." A Fishbone diagram (also called an Ishikawa diagram or cause-and-effect diagram) assumes the opposite: that several categories of cause might be contributing at once — typically grouped as Machine, Method, Material, Manpower, Measurement and Environment (the "6 Ms") — and it's built specifically to let a team brainstorm across all of those categories in parallel before narrowing down.

A practical way to decide: start with a quick 5 Whys. If you find the group genuinely disagreeing about which "why" to write down at any step — some people think it's a training issue, others think it's a machine issue — that disagreement is a signal you actually have a multi-cause problem, and switching to a Fishbone diagram to capture all the candidate causes before testing them will serve you better than forcing a single artificial chain.

How to know your root cause fix actually worked

Identifying a root cause is only half the job; confirming the fix worked closes the loop. This is where root cause analysis connects back to the broader DMAIC Control phase: after implementing a fix, keep watching the same metric that originally flagged the problem (the late-delivery rate, the weld defect rate, the ticket volume) for long enough to be confident the improvement is real and not a temporary dip. A good rule of thumb is to monitor for at least as long as the historical cycle that produced the original problem — if defects were previously reported monthly, watch for at least two to three months before declaring victory. Teams that skip this step sometimes discover, a quarter later, that they fixed a contributing factor rather than the true root cause, and the problem quietly returns.

Documenting what you find

A root cause investigation that lives only in a meeting's memory tends to get re-litigated the next time a similar problem appears, because nobody can point to what was actually concluded last time. Writing the 5 Whys chain down — problem statement, each why, the final root cause, and the fix implemented — on a single page takes a few minutes and pays for itself the first time someone asks "didn't we already look into this?" six months later. This is exactly the kind of lightweight documentation that separates a team that solves a problem once from a team that solves it repeatedly, forever.

Putting it into practice

The single biggest thing that separates a useful 5 Whys session from a wasted half hour is discipline: writing the problem statement down precisely, involving the right people, and genuinely resisting the urge to stop at the first comfortable-sounding answer. Done properly, it takes fifteen to thirty minutes and prevents the same problem from quietly resurfacing every few months.

To make this easier to run consistently, our free 5 Whys template gives you a structured worksheet to fill in live during the session, and our RCA worksheet extends this into a fuller root cause investigation for more complex, multi-cause problems.