Root cause techniques
Problem management needs methods that fit the evidence you have — not a single template for every investigation. These techniques are common industry practice. Use them to structure thinking; they are not official ITIL procedure text.
How to choose a technique
Match method to the shape of the problem. A single failure chain with clear steps suits 5 Whys or a timeline. Many possible contributing factors suit a fishbone. A large volume of similar incidents suits Pareto. Mixed symptoms across teams often need a short situation appraisal before deeper analysis.
Good analysis stops when further digging will not change the action you take. Document assumptions, residual risk, and what would reopen the investigation. Hand lasting fixes to change; keep workarounds visible as known errors when cause is understood but removal will take time.
Five Whys
Ask “why” repeatedly from the observed failure until you reach a cause you can act on — usually a controllable process, design, capacity, or configuration issue rather than a vague statement such as “human error”.
When to use it. Linear cause chains, post-incident reviews, and first-pass analysis when the failure path looks short and well observed.
What good looks like. Each “why” is backed by evidence (logs, timestamps, config, witness statements). You stop at a cause the organisation can change. You record whether other branches were considered and discarded.
Common pitfalls. Stopping at the first convenient answer; blaming an individual instead of the conditions that made the error likely; inventing causes without data; treating “five” as a mandatory count rather than a prompt to go deep enough.
Ishikawa (fishbone) diagram
Map contributing factors under categories (often people, process, technology, partners, information, and environment — adapt labels to your context). Brainstorm candidates, then test which ones evidence supports.
When to use it. Complex or multi-factor problems where several teams or dimensions may contribute, and where jumping straight to one “root cause” would miss dependencies.
What good looks like. Categories are filled with concrete candidates, not empty headings. Each retained factor has a verification step (reproduce, measure, review change history). The diagram leads to ranked actions, not a wall of sticky notes.
Common pitfalls. Exhaustive brainstorming with no validation; categories that duplicate each other; treating every branch as equally important; never updating the diagram as evidence rules factors in or out.
Pareto analysis
Rank incident or error types by frequency or impact and focus investigation on the vital few that drive most pain. Useful when the queue is noisy and you need to choose where problem effort pays off.
When to use it. Recurring incident volumes, noisy alert classes, or backlog triage across many similar failures. Works best with clean categorisation and a defined time window.
What good looks like. Categories are meaningful to operators (same failure mode, not just the same assignment group). You show both frequency and business impact. Actions target the top drivers and you re-measure after fixes land.
Common pitfalls. Bad taxonomy that hides the real pattern; chasing volume while ignoring rare but severe events; freezing the chart once and never refreshing it after changes.
Chronological analysis (timeline)
Build a single timeline of events, changes, alerts, and user impact. Align clocks, note gaps, and separate what is known from what is inferred. Often the fastest way to see whether a deploy, capacity cliff, or external dependency started the failure.
When to use it. Intermittent faults, major incidents after restoration, and any problem where “what happened when” is disputed or incomplete.
What good looks like. One shared timeline with sources cited. Time zones and clock skew are corrected. Hypotheses are tested against the sequence (“could this cause have preceded the first symptom?”).
Common pitfalls. Mixing local times without normalisation; treating correlation as causation because two events are close; omitting unsuccessful recovery attempts that actually worsened impact.
Situation appraisal (Kepner-Tregoe style)
Before diving into deep RCA, clarify what is wrong, what is not wrong, where and when the issue appears, and what changed. Compare “is” versus “is not” to narrow the search space. This is a practical problem-solving habit used widely in IT operations; use it as a scoping aid, not as a branded ceremony.
When to use it. Messy problems with conflicting reports, several possible services involved, or pressure to “fix everything” before the fault is bounded.
What good looks like. A short written appraisal everyone can challenge: affected vs unaffected CIs, first/last seen, recent changes, and the sharpest current hypothesis. Only then pick 5 Whys, fishbone, or deeper technical tests.
Common pitfalls. Skipping appraisal and jumping to a favourite cause; writing the template without interviewing people who saw the failure; never revisiting the appraisal when new evidence arrives.
Practical takeaway
Technique choice should be visible on the problem record: what method you used, what evidence you trusted, and what action you will take. Combine methods when needed — for example Pareto to pick the theme, timeline to reconstruct an episode, then 5 Whys or fishbone to pin the controllable cause.
This page is Workflow Professionals’ operational reading of common RCA methods in an ITIL problem practice context. Until revised practice guides say otherwise, treat technique choice as organisational design, not as a Version 5 mandate.