How to Do Root Cause Analysis: A Practical Guide

Most problems get solved twice. The first time, someone patches the symptom — the deadline slips so the team adds a weekly status meeting, the product breaks in production so QA checks are doubled, the client churns so the account manager calls more often. The symptom quiets down. Six weeks later it is back. The second time, if anyone bothers, they trace the problem to its actual origin and change something structural. That second fix is root cause analysis.

Root cause analysis (RCA) is not one technique — it is a discipline that combines structured brainstorming (Ishikawa), iterative questioning (5-Why), and quantitative prioritisation (Pareto). Used together, the three methods prevent the most common failure in problem-solving: fixing the loudest cause rather than the largest one. What follows is a practical walkthrough of the full method, with a worked example you can replicate on any operational problem.

Step 1 — Define the Problem Precisely

Vague problem statements produce vague analysis. Before touching a fishbone diagram, write a problem statement that answers four questions: What happened? Where was it observed? When did it start? How big is the gap from expected performance?

Worked example: "Customer support ticket resolution time increased from an average of 6 hours to 14 hours between August and September 2026, affecting approximately 340 tickets per week and generating a 22-point drop in CSAT scores."

That statement is bounded enough to investigate. "Support is slow" is not.

Step 2 — Gather Evidence Before You Theorise

The temptation in any group problem-solving session is to jump straight to causes. Resist it. Collect data first: ticket logs, timestamps, agent workload records, product change history, staffing rosters. The evidence shapes the fishbone; the fishbone should not shape which evidence you look for.

Two sources matter most: process data (what actually happened, in sequence) and comparison data (what changed between the period when performance was acceptable and when it was not). A trend line with a clear inflection point is worth more than ten hypotheses.

Step 3 — Build the Ishikawa Diagram

The Ishikawa fishbone diagram maps potential causes into standard categories so nothing obvious is missed. The classic six for service and knowledge-work environments are: People, Process, Technology, Policy, Measurement, and Environment.

Draw the problem statement as the fish's head, then draw one bone per category. For each category, ask the team: what, in this category, could plausibly contribute to the problem? Write each candidate as a sub-bone. Quantity matters here — you want to surface at least fifteen to twenty candidate causes across the diagram before you start filtering. Early convergence is the enemy of good RCA.

In the support ticket example, the People bone might surface: two senior agents on leave, new-hire onboarding incomplete, shift handover gaps. The Technology bone might surface: a CRM upgrade rolled out on August 28, ticket routing logic changed, search degraded after migration.

Step 4 — Run 5-Why Chains on the Most Credible Causes

The fishbone gives you a candidate list. The 5-Why method drills down from each candidate to its underlying mechanism. Start with the cause and ask "why does this happen?" five times in succession (fewer if you reach a root, more if you need to).

Example chain for the CRM upgrade candidate:

• Why did resolution time increase? — Agents could not locate customer history quickly.
• Why could they not locate history? — The CRM search index was rebuilt post-upgrade and defaulted to partial-match only.
• Why did partial-match cause slowdowns? — Agents had to open three to five more tickets per query to find the right record.
• Why was this not caught in testing? — UAT was run on a data subset that did not include multi-channel tickets older than 90 days.
• Why was the subset incomplete? — The test data specification was not reviewed by support operations, only by IT.

The root here is not the CRM upgrade itself — it is a gap in cross-functional test governance. That is a structural fix, not a patch.

Step 5 — Pareto the Causes

Once you have completed 5-Why chains for your top candidates, you need to decide where to act first. Pareto analysis applies the 80/20 principle: rank causes by their estimated contribution to the problem and focus effort on the vital few that account for the majority of the effect.

The table below shows a simplified Pareto for the support ticket example, built from ticket log analysis:

Cause	Tickets / week	Avg delay (hrs)	Delay contribution (ticket-hrs/wk)	Cumulative %
CRM search degradation (partial-match default)	210	5.2	1,092	64%
Shift handover documentation gap	95	3.8	361	85%
Two senior agents on leave (no cover plan)	80	2.1	168	95%
Ticket routing misconfiguration	40	1.4	56	98%
All other causes	30	0.9	27	100%

The top two causes account for 85% of the total delay (multiply tickets by average delay, then rank). Fixing those three — and only those three — will recover the bulk of the performance gap. The remaining causes can be addressed in a second wave or absorbed into routine maintenance.

Step 6 — Validate Before You Countermeasure

Before committing resources to a fix, test the causal logic. Can you reproduce the problem by simulating the cause? Does the data pattern match the proposed mechanism? Would removing the cause (on paper or in a controlled test) eliminate or substantially reduce the effect?

Validation prevents countermeasure waste — the organisational equivalent of changing a car part that was not broken. In the CRM example, a quick test confirms that enabling full-match search in a test environment restores resolution time to baseline for multi-channel tickets. That is sufficient validation to justify the change request.

For each validated root cause, define a countermeasure with three elements: the specific action, the person accountable, and the date by which results will be re-measured. Without a measurement date, countermeasures become intentions.

Common Mistakes That Invalidate RCA

• Stopping at symptoms. "Agent performance dropped" is a symptom, not a cause. Keep asking why until you reach something that can be changed.
• Blame as a root cause. "The agent made an error" ends the inquiry too early. Why was the error possible? What system allowed it?
• Single-cause thinking. Most operational problems have three to five contributing causes. The Pareto step exists precisely because reality is multi-causal.
• Skipping validation. A plausible 5-Why chain is a hypothesis, not a finding. Evidence confirms it or it stays a theory.

Running This in Under Four Minutes

The method above, done rigorously by hand, takes a skilled team two to four hours. Treeng's Root Cause Analysis engine runs the same structured logic — Ishikawa categorisation, 5-Why chains, Pareto ranking — against a problem description or uploaded data file and returns a prioritised cause map in under four minutes. Every finding carries an evidence grade: solid (supported by uploaded data), indicative (strong inferential pattern), or needs data (plausible but unverified). That grading is what separates a structured diagnostic from a consultant's opinion dressed as analysis — and it is what tells you exactly where to look next before you spend anything on a fix.