5 Whys Template: Worksheet + 2 Worked Examples
A 5 whys template is a worksheet that structures root cause analysis into a problem statement, five rows of “why” questions with answer and evidence columns, a root cause, a corrective action, and a verification step. It forces teams to trace a symptom back through cause-and-effect links instead of stopping at the first plausible explanation.
What Is a 5 Whys Template?
The 5 Whys method, developed at Toyota as part of the Toyota Production System, asks “why” repeatedly against a problem until the questioning reaches a process-level root cause rather than a surface symptom. A template turns that method into a repeatable document: same fields every time, so any team member can run one and a reviewer can audit it later.
The template matters more than it sounds. Without one, teams write informal notes, skip the evidence step, and stop after two whys because the third answer feels uncomfortable (“the operator was in a hurry”). A structured 5 whys worksheet keeps every session honest by requiring proof, not opinion, at each step.
The Copy-Paste 5 Whys Worksheet
Copy this table into a document, spreadsheet, or your quality system of record. Fill in every evidence cell before moving to the next why — an answer without evidence is a guess.
| Field | Entry |
|---|---|
| Problem statement | (one sentence: what happened, where, when, impact) |
| Team | (names and roles) |
| Date | (analysis date) |
| Step | Why did this happen? (Answer) | Evidence |
|---|---|---|
| Why 1 | ||
| Why 2 | ||
| Why 3 | ||
| Why 4 | ||
| Why 5 |
| Field | Entry |
|---|---|
| Root cause | (the process or system gap, not a person) |
| Corrective action | (what changes, who owns it, due date) |
| Verification | (how and when you’ll confirm the fix worked, e.g. “0 recurrences in 60 days”) |
If you’d rather not build this by hand each time, QualityManager.AI’s free 5 Whys tool asks the probing follow-up questions for you at each step and exports the finished analysis to Word or Excel.
How Do You Fill Out a 5 Whys Worksheet?
- Write the problem statement first, narrowly. “CNC spindle overheated on line 3, 2nd shift, July 8” is usable; “quality problems on line 3” is not.
- Ask why the problem occurred, then require evidence. A sensor log, a maintenance record, or an operator interview note — not “I think.”
- Use the answer to Why 1 as the subject of Why 2. Each why targets the answer just given, not the original problem restated.
- Stop when the answer points to a process, system, or decision your team can act on. If the next why would need someone outside the room to answer, you’ve likely reached the root cause.
- Write a corrective action that changes the process, not one that just retrains or disciplines an individual.
- Set a verification date and metric before closing the analysis, so the fix gets checked rather than assumed.
Worked Example 1: CNC Spindle Overheating (Machine Downtime)
Problem statement: CNC spindle on Line 3 shut down on thermal overload three times in one week, costing roughly 6 hours of downtime.
| Step | Answer | Evidence |
|---|---|---|
| Why 1 | The spindle overheated past its thermal cutoff | Machine error log shows three thermal-limit faults, temps 15°C above threshold |
| Why 2 | Coolant flow to the spindle bearing was reduced | Flow meter reading was 40% of spec during teardown inspection |
| Why 3 | The coolant filter was clogged with metal fines | Filter inspection showed heavy sediment buildup |
| Why 4 | The filter hadn’t been replaced on schedule | Preventive maintenance log shows the filter-change task was skipped for 2 consecutive cycles |
| Why 5 | The PM schedule task was marked complete without the filter actually being replaced | Interview with maintenance tech confirmed the checklist item was signed off as a formality when the tech was behind on other jobs |
Root cause: The preventive maintenance process allows checklist sign-off without a verification step, so a backlogged technician can mark a task done without doing it.
Corrective action: Add a photo-verification requirement to the PM checklist for filter changes; supervisor spot-checks 20% of completed PM tasks weekly. Owner: Maintenance Supervisor. Due: 2 weeks.
Verification: Zero thermal-overload faults on Line 3 for 60 days, confirmed via machine error log review.
Worked Example 2: Late Supplier Delivery (Purchasing Process Gap)
Problem statement: A key raw-material shipment from Supplier B arrived 9 days late, delaying production start on a customer order.
| Step | Answer | Evidence |
|---|---|---|
| Why 1 | The supplier didn’t ship on the agreed date | Supplier’s shipping confirmation email is dated 9 days after the PO due date |
| Why 2 | The supplier hadn’t confirmed the order until after the due date had nearly passed | Email thread shows order confirmation request went unanswered for 12 days |
| Why 3 | The purchase order was sent without a required order-confirmation follow-up | Purchasing log shows no follow-up task was created after PO issuance |
| Why 4 | The purchasing system has no automatic reminder for unconfirmed POs | Review of the purchasing workflow confirms follow-up is manual and undocumented |
| Why 5 | The purchasing process was never updated to require confirmation tracking when the team switched ERP systems | Process documentation predates the ERP migration and was never revised |
Root cause: The purchasing process lacks a mandatory order-confirmation checkpoint, a gap introduced when the ERP system changed and the procedure wasn’t updated.
Corrective action: Add a confirmation-tracking field to the PO workflow with an automatic 3-day follow-up alert; update the purchasing SOP. Owner: Purchasing Manager. Due: 3 weeks.
Verification: Audit next 20 POs to Supplier B (and two other key suppliers) for on-time confirmation; target zero missed confirmations.
Common Pitfalls When Using the 5 Whys Method
- Stopping at symptoms. “The spindle overheated” is a symptom, not a root cause. If your last why still describes a physical failure rather than a process or decision gap, keep going.
- Blaming individuals instead of the process. “The operator forgot” is rarely the root cause — ask why the process let that forgetting cause a failure. A good root cause is something you can fix by changing a system, not by disciplining a person.
- Following a single causal chain when there are several. Many real problems branch: a late delivery might stem from both a purchasing gap and a supplier capacity issue. Running only one why chain hides the second cause. Branch the worksheet and run parallel chains when the team identifies more than one plausible path at any step.
- Accepting whys without evidence. An unsupported answer (“probably a rush job”) turns the exercise into speculation. Require a log, record, or documented interview at every step before moving on.
5 Whys vs Fishbone Diagram: Which Should You Use?
| 5 Whys | Fishbone Diagram | |
|---|---|---|
| Best for | A single, well-defined problem with one main cause path | Problems that could stem from several categories at once |
| Speed | Fast — 10-20 minutes | Slower — needs a facilitated brainstorm |
| Output | A linear chain to one root cause | A branching map of candidate causes across categories |
| Risk | Missing a second causal chain if not branched | Can generate causes without narrowing to a verified root cause |
| Pairs well with | Fishbone (to catch multiple causes), then 5 Whys per branch | 5 Whys, run on each branch identified |
For a broader comparison of RCA methods, see the root cause analysis tools overview, or start from the general root cause analysis template if you haven’t picked a technique yet. If your problem looks like it has more than one contributing category, build a fishbone diagram first, then run a 5 Whys chain on each branch.
Frequently asked questions
Do you always need exactly five whys?
No. Five is a guideline, not a rule. Some problems reach a process-level root cause after three whys; others need seven. Stop asking why when the next answer would require an action outside your team's control, or when the answer repeats an earlier one — that signals you've hit the real root cause.
When does the 5 Whys method fail?
It fails on problems with multiple independent causes, on complex systems where cause and effect aren't linear, and when the team accepts opinions instead of evidence at each step. It also fails when used alone on high-severity or recurring failures that need statistical or cross-functional analysis, like a fishbone diagram or FMEA.
How do you handle a problem with multiple causal chains?
Run a separate why chain for each distinct contributing factor instead of forcing one line of questioning. Branch the worksheet at the point where two plausible causes diverge, document evidence for each branch, and address every root cause with its own corrective action rather than picking just one.
5 Whys vs fishbone diagram: which should I use?
Use 5 Whys for a single, well-defined problem with one primary cause path — it's fast and needs no special training. Use a fishbone diagram when a problem could stem from several categories at once (machine, method, material, people) and you need to brainstorm broadly before narrowing down.
What's the difference between a 5 Whys template and a root cause analysis template?
A 5 Whys template is one specific RCA technique focused on sequential why questions. A root cause analysis template is broader and may incorporate 5 Whys, fishbone diagrams, or Pareto analysis depending on the problem. Use the 5 Whys template when you already know the technique fits.