Five root cause methods, and when each one earns its keep

Choosing a root cause method is usually treated as a matter of taste. It is closer to a matter of proportion: the method should cost about as much effort as the incident warrants, and no more.

5 Whys

Fast, and genuinely useful for incidents with a single clear causal chain. Its weakness is that it produces one chain, so an incident with several contributing causes gets flattened into whichever one the facilitator followed. Good for a near miss on a Tuesday. Not good for anything with injuries.

Fishbone

Better when causes come from several directions at once, because the categories force you to look at people, equipment, method and environment separately rather than following the first thread. It organises thinking well but does not rank anything, so it can end in a diagram nobody acts on.

Fault Tree

Worth the effort when you need to be rigorous about combinations: this failed and that also failed, therefore the event became possible. It is the most demanding of the five and the most defensible when the finding will be challenged.

Bow-Tie

The one that looks forward rather than back. Threats on the left, consequences on the right, barriers between. Its real value is not explaining the incident, it is showing which barriers were missing or degraded, which turns directly into work to do.

TapRooT

A structured system with its own taxonomy, useful in organisations that want consistency across many investigators and sites. The consistency is the point: different people investigating similar events should arrive at comparable findings.

The choice matters less than the follow-through

An investigation that identifies a cause and produces no owned, dated action has not finished. The most common failure in practice is not picking the wrong method, it is a well-run analysis whose findings never became anybody's job.

What this looks like in HSE360

All five methods are available on an investigation, with multi-reviewer sign-off and an audit log of who changed what and when. Editing a critical field resets the approvals, so a signed-off conclusion always refers to the analysis that was actually approved.

Findings become corrective actions tagged by the hierarchy of controls, each with an owner, a due date and an effectiveness check, so the question is whether the fix held rather than whether the ticket closed.