Free 5 whys analysis template

• The MapTrack 5 whys analysis template has 4 columns and room for 6 entries. Columns: Level, Ask: why?, Answer / cause, Evidence that confirms it.
• The 5 Whys is a single-method root cause tool: ask why repeatedly, usually five times, until you reach a cause you can fix rather than a symptom.
• It suits one clear problem with a single causal chain; use a fishbone or full RCA when several independent causes are likely.
• Each answer must be evidence-based, not a guess. A weak link early in the chain leads the whole analysis to the wrong root cause.
• Every confirmed root cause needs a countermeasure with an owner and a due date, then verification that the problem has not recurred.

Learn more about maintenance and work orders in MapTrack.

• Fast to run: a small team can complete a focused 5 Whys in minutes, so it suits the daily problems that never justify a full investigation.
• Gets past symptoms: asking why repeatedly moves the team from the visible fault to the system condition that actually needs fixing.
• Reduces blame: the chain points at procedures, controls and design rather than the last person to touch the equipment, which keeps the analysis honest.
• Evidence discipline: recording how each answer was confirmed stops the chain becoming a string of assumptions that lead to the wrong root cause.
• Clear countermeasures: tying the root cause to a named owner and a due date turns the analysis into action rather than a filed form.
• Easy to read: a one-page linear chain is simple for a supervisor or auditor to follow and to challenge, unlike a dense narrative report.
• Feeds bigger tools: a completed 5 Whys plugs straight into a fishbone, an A3 or a formal RCA when the problem turns out to be more complex.

• Header details: reference number, problem title, date, facilitator, team members and the work order or incident this analysis relates to.
• Problem statement: a factual, quantified description of what happened, when, where and the impact (downtime hours, units rejected, cost).
• Why 1: the first answer to why the problem occurred, with the evidence that confirms it.
• Why 2: why that first cause occurred, again supported by evidence rather than opinion.
• Why 3: the next level down the causal chain, confirming the link to the level above.
• Why 4: the next answer, checking whether the chain has reached a system or process condition.
• Why 5: the final why, or earlier if a true root cause is reached sooner, or further if it is not.
• Root cause statement: a concise statement of the underlying cause the chain has reached, distinguished from contributing factors.
• Countermeasures: the actions that eliminate the root cause, each with a responsible person and a due date.
• Verification: how and when effectiveness will be checked, and confirmation the problem has not recurred.

1. Write a clear, factual problem statement before asking any why.

   Describe exactly what happened, where, when and the size of the impact, using numbers such as downtime hours or rejected units. A vague problem statement sends the whole chain in the wrong direction, so agree the wording with the team before you start.

2. Ask why the problem occurred and record the first answer with its evidence.

   Capture the most direct cause of the stated problem and note how you know it is true, for example a meter reading, a photograph or a maintenance record. Resist jumping straight to a favourite theory; the first why should be the immediate, verifiable cause.

3. Ask why of that answer, and keep going down the chain.

   Treat each answer as a new problem and ask why it happened, confirming each link with evidence. Continue for about five levels, but stop when you reach a cause you can actually control and go further if you have not, since five is a guide and not a rule.

4. Test the chain by reading it back from the root cause upward.

   Start at the deepest answer and say therefore at each step back up to the problem. If the logic holds in that direction, the chain is sound; if a step does not follow, you have a gap or a missing branch that needs more evidence before you continue.

5. State the root cause and write countermeasures that eliminate it.

   Phrase the root cause as a system or process condition, not as individual error, then define actions that remove it. Give each countermeasure a named owner and a due date so the analysis converts into work that someone is accountable for completing.

6. Verify effectiveness after a set period and close the analysis.

   Agree how you will confirm the fix worked, such as no recurrence over the next 30 to 90 days or a measurable drop in the failure, then review it on that date. Record the outcome and sign off, escalating to a fuller RCA if the problem returns.

Practical answers about the form, record keeping and using MapTrack.

This form is a starting point. Check the current requirements that apply to your equipment, work and location. The form alone does not establish compliance.

• ISO 9001, clause 10.2 - Nonconformity and corrective action (root cause analysis as part of corrective action)
• ISO 45001:2018, clause 10.2 - Incident, nonconformity and corrective action (investigation of underlying causes)
• WHS Act 2011, section 19 - Primary duty of care (investigating incidents to prevent recurrence)

• Model Work Health and Safety Act (Safe Work Australia)
• ISO 9001:2026, Quality management systems requirements (ISO catalogue)
• ISO 45001:2018, Occupational health and safety management systems (ISO catalogue)

MapTrack publishes this template. The linked authorities publish their own guidance; they haven't endorsed this form.

• Root cause analysis template
• Fishbone diagram template
• A3 problem solving template
• Corrective action form
• Maintenance management (MapTrack)
• Reporting and analytics
• Manufacturing