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 is root cause analysis?

    Short answer

    Root cause analysis (RCA) is a structured method for finding the underlying reason a problem occurred, rather than treating its symptoms. Teams define the problem, gather facts, identify possible causes, verify the true cause with evidence and put countermeasures in place so the problem does not recur. Common RCA tools include the 5 whys and fishbone diagrams.

    Last updated · TeamAssurance

    How root cause analysis works

    Most operational problems are first handled with containment: sort the suspect stock, restart the machine, retrain the operator. Containment protects the customer today, but the problem comes back unless someone asks why it happened. Root cause analysis is that discipline. It separates the symptom (what you saw) from the point of cause (where it happened) and the root cause (the system condition that allowed it).

    The core steps

    1. Define the problem clearly. State what happened, where, when and how big the gap is against standard. Avoid building a cause into the problem statement.
    2. Contain it. Protect people, product and customers while the investigation runs.
    3. Go to gemba and gather facts. Look at the process, the parts and the data. Talk to the people who do the work.
    4. Identify possible causes. Use a fishbone diagram to brainstorm broadly, then narrow down.
    5. Verify the root cause. Test it with data or by switching the cause on and off. An unverified cause is still a guess.
    6. Implement countermeasures. Change the process, standard or design, not just the person.
    7. Check effectiveness and standardise. Confirm the problem has not returned, then update standard work and share the learning.

    Common RCA tools

    • 5 whys for straightforward, single-path problems.
    • Fishbone (Ishikawa) diagram for problems with many possible contributors.
    • Fault tree analysis for complex or safety-critical failures.
    • A3 report to document the whole investigation on one page.

    Common mistakes

    • Stopping at "human error" or "operator didn't follow the procedure". Ask why the system made the error possible.
    • Jumping to a solution before the cause is verified.
    • Running RCA in an office without visiting the process.
    • Closing the action once implemented, without checking it actually worked.

    Example

    A filling line keeps rejecting under-weight packs. Containment adds a 100% check-weigh. Investigation at the line shows the rejects cluster after product changeovers. Data confirms the filler is not being re-zeroed because the changeover standard does not include that step. The countermeasure adds re-zeroing to the changeover standard and a verification check, and rejects are monitored for several weeks before closing.

    How TeamAssurance helps

    TeamAssurance supports root cause analysis with built-in methods including 5 whys, fishbone diagrams and A3 problem solving, and every investigation can be tracked through tiered daily management. AI agents can draft a first fishbone of potential causes, help the team challenge causes and add evidence, and turn an agreed root cause into a draft action plan for the team to review and assign.

    Explore Continuous Improvement Request a demo

    Frequently asked questions

    What is the difference between a root cause and a contributing cause?

    A root cause is the underlying condition that, if removed, would prevent the problem recurring. Contributing causes make the problem more likely or worse but would not prevent it on their own if fixed.

    When should you do a root cause analysis?

    Use RCA for problems that recur, have a significant safety, quality or customer impact, or where the cause is not obvious. Simple one-off issues with a clear cause can usually be fixed directly.

    Is human error ever a root cause?

    Rarely. Human error is usually a symptom of a system that made the mistake easy to make, such as an unclear standard, poor design or missing error-proofing, so keep asking why.

    ← Back to the glossary