Skip to main content
    QHSEtech
    Updated
    All glossary terms
    Content date: · No individual check logged· AI use

    5 Whys

    Also known as: Five Whys

    Definition

    A technique that asks “why” repeatedly, often about five times, to move from a symptom towards a cause the team can act on and check.

    Editorial definition: The QHSE Standard, updated 3 October 2026 · https://qhsetech.com/glossary/5-whys

    Scope: Five is a rule of thumb, and each answer is a hypothesis until evidence supports it.

    What the ADB note and OSHA say about asking why

    The Asian Development Bank's note on the technique, issued in February 2009 in its Knowledge Solutions series, describes the Five Whys as a simple technique of asking questions to explore cause and effect behind a problem. It credits Sakichi Toyoda with developing the technique for Toyota Industries Corporation and treats five as a good rule of thumb: one may need to ask fewer times or more. It describes the exercise as better done by a team. The team agrees the problem statement, asks the first why and records every sensible answer, repeats the question for each answer, looks among the last answers for systemic causes, and then agrees corrective actions. The root cause has been reached, the note says, when further whys produce nothing more of use.

    The same note records the criticisms. Investigators may stop at symptoms, may not look beyond the information they already hold, may lack facilitation, and different teams have been known to reach different causes for the same problem. Its safeguard is to verify each answer on the spot before the next why is asked. OSHA's incident investigation page asks for the same habit in safety work. It says it is far too easy to treat carelessness, or a procedure not being followed, as the whole explanation, and its examples ask why a procedure was ignored, whether production pressure was allowed to compromise safety, and why a known shortcoming had gone unaddressed.

    A quality-improvement article in the US National Library of Medicine's PMC archive notes that fishbone diagrams are often paired with the five whys when teams look for the root cause. None of the three sources sets the technique out as a legal requirement. This page is general information. If a customer, certification body or your own investigation procedure names a method, follow what it says.

    Sources opened :

    What a 5 whys record holds in software

    • The problem statement the team agreed, written from observed facts, with date, place and the people present.
    • Each answer in the chain, in order, with the evidence checked before the next why was asked and the name of whoever checked it.
    • Branches: where one why had several plausible answers, all of them, including those set aside and the reason.
    • Where the chain stopped and why, for example a cause the organisation can act on, or no further useful information.
    • The causes the team accepted, marked as specific to this event or systemic.
    • Links to the corrective actions raised from each accepted cause and the later check on whether they worked.

    5 whys, fishbone diagram and root cause analysis

    A 5 whys exercise follows one line of questions downwards at a time. A fishbone diagram lays out many possible causes by category at once. Root cause analysis is the wider activity that either can serve. A five-box template in a software tool records the shape of the technique and nothing about the quality of the answers, so the useful test is whether each answer carries evidence and whether the chain ends at something that can be changed.

    A hypothetical example: labels shipped with the wrong date

    This case is invented to show how a chain of answers is recorded and describes no real business. A small print shop finds that a batch of labels was dispatched with last week's date. The first answer is that the operator keyed the old date. The second is that the date was typed by hand because the label template did not take it from the order. The third is that the template was copied from an old job when the order system changed. The fourth is that nobody was named as owner of templates after that change. The team checks each answer before moving on: the print log, the template file, the order record and the operator's own account.

    At the third answer a second branch appears. The packing check did not catch the error because its checklist asks only whether a label is present. The team records both branches and stops when each reaches something it can change. The actions are to name a template owner, to take the date from the order automatically and to add a date check to the packing list. A review six weeks later counts date errors found at packing. The record keeps the answers the team set aside, with the reason for each.

    Common misunderstandings about the 5 whys

    • Five is a rule of thumb, not a requirement. The ADB note says one may need fewer questions or more, and the stopping point is a cause that can be acted on or an answer that adds nothing.
    • One chain is not the whole picture. The note expects several sensible answers to the first why and says to follow up all plausible ones, so a single straight line can hide contributors.
    • A person is rarely a satisfying last answer. A chain that ends at an operator not paying attention has ended where OSHA's page says the questions should begin: why was the rule not followed.
    • An answer is not a fact until it is checked. Different teams can reach different causes for the same problem, which is why the note asks for verification at each step.
    • Finding a cause does not choose the action. The cause still needs an owner, a date and a later check that the change worked.

    How the 5 whys relates to other glossary terms

    The technique sits inside investigations and feeds actions, so its neighbours are the wider analysis and the follow-through.

    • Root cause analysis: the wider activity of which a why chain is one tool.
    • Fishbone diagram: a category-by-category map of possible causes, often used alongside a why chain.
    • Incident investigation: the process in which the questions are asked and the evidence gathered.
    • CAPA: turns the accepted causes into owned actions with an effectiveness check.

    Records and evidence that usually exist for a 5 whys analysis

    • The investigation record naming the team and the date.
    • The agreed problem statement.
    • The chain of answers with the evidence behind each one.
    • Notes on branches followed and branches set aside.
    • The accepted causes and the reason the questioning stopped.
    • The corrective actions, owners and dates, and the later effectiveness check.

    What a software tool needs to capture for the 5 whys

    • An ordered chain with an evidence field on every step, not one free-text box.
    • Branching, so several answers to one question sit side by side.
    • A status on each answer (verified, assumed or unknown) and who set it.
    • A field for why the questioning stopped.
    • A link from each accepted cause to its actions, with a flag when a cause has none.
    • Attachments for photographs, logs and measurements.
    • Version history, so a revised chain keeps the earlier one visible.

    Catalog profiles documenting root cause analysis

    These profiles describe a root-cause capability in their records. Whether any of them supports a why chain, or checks the answers given in it, is a question for a demonstration.

    Same rule for every product: tagged “Root Cause & Investigation”, “Incident Management”, “Incident Reporting”, “CAPA Management”, “Quality Management”, “Safety Management”, “EHS Management”, “Occupational Health”, “Risk Assessment”, “Risk Management”, “Food Safety”, “Audits & Inspections” or “Barrier Management”, with a sourced root cause analysis capability in its record, or one the vendor stated to us, labelled as vendor-stated. Documented and conditional capabilities qualify; check the linked scope before treating a module as included.

    Tekmon pays for a sponsored placement (above); its place in this list follows the same rule as every entry. How lists are ordered

    All 48 matching profiles are shown. Documentation review, not hands-on testing or a claim of compliance.

    Related software

    Frequently asked questions

    Do I have to ask why exactly five times?

    No. The ADB note calls five a rule of thumb and says fewer or more questions may be needed. Stop when the answer is a cause you can act on, or when asking again adds nothing.

    Is a 5 whys chain enough for a serious incident?

    The ADB note itself lists criticisms, such as stopping at symptoms and different teams reaching different causes. Use your investigation procedure to set the depth and methods, and treat a why chain as one tool among several.

    Who should take part in the exercise?

    The ADB note says it works better with a team. OSHA advises involving both managers and employees in an investigation, because they know different parts of the work.

    More quality terms

    Related guides