5 Whys Root Cause Analysis Template and Step-by-Step Guide

A 5 Whys root cause analysis asks "why" repeatedly, starting from a specific problem, until you reach a cause you can fix in a process, policy, or decision. The template below gives you a problem statement, a chain of evidence-backed answers, and an action list. Run it with a small group, keep every answer tied to facts, and stop when the fix would prevent a repeat rather than just treat the symptom.

Why most 5 Whys sessions fail

The technique looks trivial, which is why it gets abused. Most sessions I have seen fail in one of three ways.

• They stop at a symptom. The group reaches "the developer pushed a bad change" and calls it done.
• They stop at a person. The fifth why lands on "Sam didn't follow the process," and the action item is a reminder email.
• They turn into speculation. Every answer starts with "probably" and nobody checks anything.

All three produce an action list that feels productive and changes nothing. The problem comes back in two months, and the team concludes that root cause analysis does not work. It works fine. The session just did not reach a cause.

The fix is structure: a tight problem statement, evidence for every answer, and a clear rule for when to stop. That is what the template enforces.

When to use it (and when not to)

The 5 Whys fits problems that have a clear failure, a short causal chain, and people in the room who know what happened. Late shipments, a churn spike in one segment, a missed launch date, a billing error, a campaign that underperformed against a specific benchmark.

It fits poorly in two situations:

• Complex failures with many interacting causes. An outage involving three systems and two teams needs a wider tool first, such as a timeline review or a fishbone diagram. Use the 5 Whys afterward on each branch.
• Vague dissatisfaction. "Morale is low" or "growth feels slow" is not a problem statement. If you cannot say what happened, to whom, and how much, you are not ready for a session. A gap analysis is a better first step because it forces you to define the gap between current and target performance.

Before the session: prep in 20 minutes

Good sessions are won before anyone sits down.

1. Write the problem statement. One sentence, with a number and a time frame. "Customers are unhappy" fails. "Late deliveries rose from 3% to 11% of orders between March 1 and April 15" works.
2. Pull the evidence. Bring the data that shows the problem: reports, tickets, logs, order exports. People will want to argue from memory. Give them something better.
3. Pick 3 to 6 participants. Include the people who do the work, not only the people who manage it. One person from an adjacent team helps, because they ask the naive questions that insiders skip.
4. Name a facilitator who is not the owner of the problem. The person whose area failed will defend it without meaning to. Someone neutral keeps the chain honest.
5. Set the ground rules. Say them out loud: we are looking for how the system allowed this, not who caused it. If your team is guarded about admitting mistakes, read how to build psychological safety in your team before you run this, because a blame-heavy room produces polite, useless answers.

Template

Copy this outline into a doc or onto a whiteboard. Print it if your team works better on paper.

5 WHYS ROOT CAUSE ANALYSIS

Date:
Facilitator:
Participants:

PROBLEM STATEMENT (what, how much, when, where)
______________________________________________

EVIDENCE WE HAVE (data, reports, logs)
______________________________________________

WHY CHAIN
Why 1: Why did [problem] happen?
  Answer:
  Evidence:
Why 2: Why did [answer 1] happen?
  Answer:
  Evidence:
Why 3: Why did [answer 2] happen?
  Answer:
  Evidence:
Why 4: Why did [answer 3] happen?
  Answer:
  Evidence:
Why 5: Why did [answer 4] happen?
  Answer:
  Evidence:

ROOT CAUSE (a process, policy, or decision we can change)
______________________________________________

STOP TEST
[ ] Would fixing this prevent the problem from recurring?
[ ] Is it within our control to change?
[ ] Is it a system, not a person?

ACTIONS (owner, due date, how we will measure success)
1.
2.
3.

FOLLOW-UP DATE (check whether the metric moved):

If you prefer a grid for the whiteboard, this layout works well:

The confidence column is the part most templates leave out, and it matters. A low-confidence answer is a task for after the session: go verify it before you build an action plan on top of it.

Step-by-step: running the session

Block 60 minutes. Here is the walkthrough I use.

Step 1: Agree on the problem statement (10 minutes)

Read the statement aloud and ask if anyone disagrees with the facts. Resolve disagreements now. If two people describe the problem differently, you have two problems, and you should run two chains.

Step 2: Ask the first why and demand evidence (5 minutes)

Write the question on the board: "Why did late deliveries rise from 3% to 11%?" Collect answers on sticky notes or in a shared doc. Then ask for the evidence behind each one. "I think" gets a low-confidence mark. "Here is the report" gets high.

Step 3: Choose the answer to follow (2 minutes per level)

Often one answer is clearly supported and the others are not. Follow that one. If two answers are both well supported, branch: record both and run them as separate chains, one after the other.

Step 4: Repeat until the stop test passes (20 minutes)

Each answer becomes the subject of the next question. Phrase it as "Why did [exact answer] happen?" and not as a loose paraphrase. Drift in wording is how chains wander off into side issues.

Stop when the answer passes the stop test from the template: it is a process, policy, or decision, you control it, and fixing it would prevent a repeat. If you hit the fifth why and the answer is still a symptom, keep going. If you hit the third why and the answer already passes, stop.

Step 5: Run the reverse check (5 minutes)

Read the chain backward, from root cause up to the problem, using "therefore." If each link holds, the logic is sound. If one link sounds like a stretch, that is where the chain is weak, and you need more evidence.

Step 6: Assign actions (10 minutes)

Every action needs an owner, a due date, and a measure. "Improve communication" is not an action. "Ops manager adds a receiving scan step by May 10, measured by dock-to-system time under 24 hours" is.

Worked example: late shipments at a 14-person online store

An online home-goods store does about $2.4 million a year, roughly 2,850 orders a month at a $70 average order value. Between March 1 and April 15, orders arriving after the promised date climbed from 3% to 11%. That is roughly 230 extra late orders a month. The store paid about $28 per late order in refunds and discount credits, so the problem cost around $6,400 a month and was pushing up one-star reviews.

Problem statement: Late deliveries rose from 3% to 11% of orders between March 1 and April 15.

Why 1: Why were orders late? Orders sat in the pick queue a median of 2.5 days instead of 0.5 days. Evidence: timestamps from the order system.

Why 2: Why did orders sit in the pick queue longer? Two of the four warehouse staff spent their mornings resolving "item not found" errors instead of picking. Evidence: pick-error log showed 60 to 80 errors per week, up from about 10.

Why 3: Why were there so many "item not found" errors? Stock counts in the storefront did not match what was on the shelves. Evidence: a spot check of 40 SKUs found 14 with wrong counts.

Why 4: Why were stock counts wrong? Supplier deliveries were entered into the system 3 to 4 days after arrival, so the storefront sold items that were not yet counted and, in other cases, stock sat unrecorded. Evidence: receiving dates versus entry dates on 25 recent deliveries.

Why 5: Why were deliveries entered late? Receiving entry belonged to one person, the operations manager, who had also been covering customer support since the support hire left on February 20. Nobody else knew the receiving process, and it was not written down. Evidence: the ops manager's calendar and a direct conversation.

Root cause: Receiving data entry depended on one person with no backup and no documented process, and no one owned coverage when that person's workload changed.

Notice what the group did not conclude. The first draft of the fifth answer was "the ops manager is overloaded," which is a person-shaped answer. The facilitator pushed: why was one person the only path for a task that affects every order? That question moved the root cause from a person to a system.

Actions:

1. Document the receiving process in one page by April 25 (ops manager).
2. Train a second person on receiving entry by May 2 (warehouse lead).
3. Add a dock scan step so stock is recorded on arrival, target under 24 hours from delivery to system (ops manager, live by May 10).
4. Add a rule: when anyone leaves, the owner of their tasks is named within one week (owner/founder).

Five weeks later, late deliveries were back to 4%, and pick errors dropped to about 12 a week. The team never "tried harder." They removed the single point of failure.

Common mistakes and how to avoid them

Mistake 1: Stopping at a person

"Human error" is almost never a root cause. People make mistakes under conditions the system created: no checklist, no backup, unclear ownership, or a deadline that made shortcuts rational. When an answer names a person, ask "what allowed this to happen?" and keep going. This pairs with a known trap: we love explanations that assign blame because they feel final. The cognitive biases that hurt business decisions article covers this and a few others that sneak into root cause sessions, such as confirmation bias when the group only looks for evidence that supports its first guess.

Mistake 2: Answering without evidence

A chain built from guesses is a story, not an analysis. Require one piece of evidence per answer. If none exists, mark confidence low and assign someone to verify before you act. Sometimes the best output of a session is not the fix but a list of three things to check by Friday.

Mistake 3: Treating "5" as a rule

Five is a prompt, not a quota. Forcing a fifth why on a problem that was solved at three leads to invented abstractions like "poor culture." Forcing a stop at five when you are still at a symptom leaves the real cause untouched. Use the stop test, not the count.

Mistake 4: Following only one branch

Real problems often have two or three contributing causes. If the group finds two well-supported answers at the same level, follow both. Then rank the fixes by impact and effort before committing. For ranking, the Eisenhower Matrix is a quick way to separate urgent patches from important structural fixes.

Mistake 5: Ending with no follow-up

The session ends, the actions get assigned, and nobody checks whether the metric moved. Put a follow-up date in the template and look at the same number you used in the problem statement. If late deliveries did not drop, your root cause was wrong, and that is useful information too.

Turning the output into action

A root cause is only valuable if it changes something. Keep the action list short: three to five items, each with an owner and a date. Anything more and the list becomes a wish list. If the fixes need coordination across several people, put them into a simple plan using the approach in how to build an execution plan that teams actually follow.

Also save the filled-in template. After a few sessions, patterns show up. If three different problems all trace back to "no owner for a recurring task," you have found something bigger than any one incident, and that is a conversation for your next planning meeting.

Key takeaways

• Start with a specific problem statement that includes a number and a time frame, or the chain will drift.
• Require evidence for every answer and mark confidence, so guesses get verified instead of acted on.
• Stop when the cause is a process, policy, or decision you control and fixing it would prevent a repeat, not when you hit five.
• If an answer names a person, ask what in the system allowed it, and keep going.
• Branch when two answers are both supported, then fix the branch with the largest impact first.
• Finish with owners, due dates, and a follow-up check on the original metric, or the session is just a discussion.