We value your privacy

We use cookies to enhance your browsing experience, serve personalised ads or content, and analyse our traffic. By clicking "Accept All", you consent to our use of cookies.

Powered by
    TeamAssurance

    What are the 5 whys?

    Short answer

    The 5 whys is a root cause analysis technique in which a team asks "why?" repeatedly, typically about five times, to move from a problem's visible symptom to its underlying cause. Each answer becomes the subject of the next question. Popularised by Toyota, it works best for straightforward problems and when answers are checked against facts at the process.

    Last updated · TeamAssurance

    How the 5 whys works

    Start with a clear, factual problem statement. Ask why it happened and write down the answer. Then ask why that answer is true. Keep going until you reach a cause that, if fixed, would stop the problem recurring and that is within the team's control. "Five" is a guide, not a rule; some problems need three whys, others seven.

    Steps

    1. Write a specific problem statement: what, where, when, how much.
    2. Go to the process with the people who do the work.
    3. Ask why the problem occurred and confirm the answer with evidence.
    4. Repeat for each answer, keeping one clear chain of cause and effect.
    5. Stop when you reach a systemic cause you can act on.
    6. Check the logic backwards using "therefore" from the root cause to the problem.
    7. Put a countermeasure in place and verify it works.

    Worked example

    Problem: Line 3 stopped for 40 minutes on the night shift because the main motor tripped.

    • Why did the motor trip? It overheated under load.
    • Why did it overheat? The bearing was running dry.
    • Why was the bearing dry? The automatic lubricator was empty.
    • Why was the lubricator empty? Nobody refilled it at the last scheduled check.
    • Why wasn't it refilled? The lubricator is not on the autonomous maintenance checklist, so refilling depends on one technician remembering.

    Countermeasure: add the lubricator level check to the autonomous maintenance checklist with a visual indicator, then confirm over the following weeks that the checks happen and the trips stop.

    Read backwards: the lubricator is not on the checklist, therefore it was not refilled, therefore it ran empty, and so on. The logic holds.

    Common mistakes

    • Stopping at blame: "the operator forgot" is not a root cause.
    • Following guesses rather than facts verified at gemba.
    • Forcing a single chain when the problem has several contributing causes. A fishbone diagram is better there.
    • Ending on a cause outside the team's control, such as "the supplier is unreliable", without asking why the process is vulnerable to it.

    How TeamAssurance helps

    TeamAssurance includes 5 Whys Analysis as a built-in method: define the problem, ask why it occurred, repeat for each answer, identify the root cause and develop a countermeasure. Each analysis and its countermeasures are tracked via tiered daily management, so actions are followed up in the team's regular meetings.

    Explore Continuous Improvement Request a demo

    Frequently asked questions

    Do you always have to ask why five times?

    No. Five is a rule of thumb. Stop when you reach a cause that would prevent recurrence if fixed and that the team can act on.

    What is the difference between the 5 whys and a fishbone diagram?

    The 5 whys follows one chain of cause and effect in depth. A fishbone diagram maps many possible causes across categories, and is often used first to find the most likely cause before drilling down with the 5 whys.

    What are the limitations of the 5 whys?

    It can oversimplify problems with multiple causes and depends heavily on the knowledge of the people involved. Verifying each answer with data at the process reduces both risks.

    ← Back to the glossary