Root cause analysis: investigate causes with evidence

What contributed to this problem—and what evidence supports that explanation?

Root cause analysis (RCA) helps investigate the conditions behind an event or recurring problem. There may be several interacting contributors, not one definitive “root cause”. A diagram organises possible explanations; it does not prove them.

Five practical investigation steps

  1. Define the problem. Establish what happened, where and when, and how it differed from what was expected. Build a timeline without assuming a cause.
  2. Gather evidence with the people involved. Review records, observe work and listen across team boundaries. Make it safe to explain what made sense at the time.
  3. Choose a useful tool. Use a fishbone to organise possible contributors, 5 Whys to explore a causal path, or specialist analysis where the risk and question justify it.
  4. Check explanations. Separate observations, assumptions and unanswered questions. Look for supporting and conflicting evidence. Branch when several contributors are plausible; pause when information is missing.

    Have we stopped at the obvious explanation? “Someone made a mistake” or “the procedure wasn’t followed” may describe what happened without explaining the conditions behind it. Would another person face the same difficulty? Explore Joiner’s levels of fix → Follow the evidence—not a prescribed level or a search for someone to blame. Remember to think about the systems conditions that might have been the deep root causes - See - What are system conditions? →

  5. Choose and test a change. Address a supported explanation. Agree responsibilities, expected effects, measures and a review date. Check implementation and possible harm, then adapt.

Respond according to risk—not a count of occurrences. Serious concerns may warrant action and investigation after one event. Three occurrences do not confirm common-cause variation.

Diagrams and templates

Open only what you need. Full-size views and SVG downloads are built into this page. The examples are illustrative hypotheses, not verified incident findings or clinical recommendations.

Blank fishbone template

Put a specific problem in the head box. Add possible contributors to the branches; adapt the categories to the work. Mark what is supported, assumed or unknown and assign evidence checks.

· Download SVG

Blank fishbone root cause analysis diagram template with six categories Problem (effect) write here People skills · training · fatigue Process method · steps · protocol Equipment tools · devices · systems Environment culture · place · workload Materials supplies · information Management policy · oversight causes
Six adaptable categories. Download to print or edit in a compatible vector editor; this is not an online fill-in form.
How a fishbone diagram works

Branches group possible contributors across people, processes, equipment, environment, management and materials. They are prompts—not a ranking of importance. A factor may belong in more than one category.

· Download SVG

PROBLEM STATEMENT Effect People Skills, staffing Process Steps, procedures Equipment Tools, technology Environment Workplace, culture Management Rules, resources Materials Supplies, data Start here Fishbone (Ishikawa) Diagram — Example Categories Each branch is a category of potential causes. Sub-bones are specific causes within that category. ▲ Top branches: above the spine    ▼ Bottom branches: below the spine    Each sub-bone is a specific hypothesis to investigate
Each sub-branch is a possible contributor to investigate, not an established cause.
Worked example: wrong-route medication event

· Download SVG

Completed fishbone diagram for wrong-route medication never event Wrong-route medication administered People Locum unfamiliar with ward Tired end of shift Process No independent check required Verbal handover only Equipment Similar connector design No NRFit connector fitted Environment High pressure, busy ward Poor lighting in bay Management NRFit rollout incomplete No mandatory double-check policy causes
Possible contributors span familiarity, checking, equipment, workload and oversight. No branch establishes a root cause.

Investigate: reconstruct the sequence using records and accounts. Check the actual equipment, safeguards, information and working conditions. Do not infer a policy failure from the event alone.

Test: use appropriate clinical and safety expertise to develop a safeguard for a supported vulnerability. Check reliable use, remaining risks and unintended effects.

Worked example: delayed discharge

· Download SVG

Completed fishbone diagram for delayed hospital discharge Discharge delayed beyond clinical date People Family not involved in planning No named coordinator Process No EDD set at admission Ward round after midday System boundary Social care package not arranged No Transfer of Care Hub Environment Beds needed, pressure to fill Red/Green system not in use Management No criteria-led discharge policy Discharge not owned at exec level causes
Possible contributors span the hospital and receiving services. The absence of a named organisational model does not establish the cause.

Investigate: build a timeline of readiness, decisions, medication, transport and support arrangements. Compare cases and involve receiving services; do not assume all delay is internal—or external.

Test: address a supported source of waiting. Check safety, readmissions, workload and effects on receiving services alongside discharge time.

A 5 Whys diagram: one possible path

· Download SVG

5 Whys diagram showing chain from problem to root cause Problem Wrong-route medication Why? Spinal and IV connectors look the same Why? NRFit connectors not fitted on this ward Why? Rollout programme not completed trust-wide Why? To check No executive accountable for NRFit completion
Check every arrow and branch for other contributors. Executive accountability is a hypothesis, not a conclusion.

Five is a prompt, not a guaranteed route to one root cause. Use the 5 Whys guide for a non-clinical example with evidence checks.

When another approach helps

A timeline or process map can establish the sequence. Feedback loops help explore how consequences sustain a pattern. For specialist safety investigations, follow the applicable framework and use trained support, such as the relevant PSIRF approach.

Optional: fault tree logic

Fault trees examine combinations of conditions behind a defined failure. An OR gate means any modelled condition can produce the event; an AND gate requires the specified conditions together. Check other pathways and dependencies. Do not assume the model is exhaustive or multiply probabilities without justifying the assumptions.

Test the response—not just the explanation

Agree what should change, by roughly how much and when. Check whether the intervention is being used and measure both the intended result and possible harm elsewhere.

A suitable chart or Bootstrap CUSUM analysis may identify a performance change. It does not, by itself, confirm the cause or prove the intervention worked. Consider implementation, data quality, timing and alternative explanations. No detected change is not automatically proof of no benefit.

Right intervention? →
Right measures? →

Complementary tools—not mandatory stages

Systems thinking examines parts and relationships; RCA investigates contributors with evidence; 5 Whys explores a particular causal path; feedback loops examine how consequences return to influence what happens next.

Return to Right problem? →

Full-size diagram

Scroll sideways or down to explore the diagram at a readable size.

Download this diagram as SVG