qa-aman/root-cause-analysis

Reference Files

• references/fishbone-categories.md - Six fishbone categories adapted for BA context (People, Process, Technology, Policy, Environment, Data) with example causes for each. Read this in Step 4 when building the Ishikawa diagram.

Overview

Based on Business Process Change by Paul Harmon - integrating Six Sigma DMAIC root cause methodology into business process improvement. Also draws on Lean Business Analysis by Mark Sherrington for the A3 Problem Solving technique - a one-page structured format that forces clarity by constraining the entire analysis to a single sheet. The key insight: most "root causes" identified in practice are actually symptoms. True root cause analysis requires asking "why" until you reach a systemic cause you can change - something in the process, policy, or system design, never an individual person.

Workflow

Step 1: Write the problem statement

Be specific and measurable. A good problem statement answers: what, where, when, and how much.

BAD:  "The system is slow."
GOOD: "Order processing takes 4.2 hours on average, exceeding the 2-hour SLA.
       This has occurred for 67% of orders in the past 30 days, primarily
       affecting [region/segment]. Impact: $[X] in late delivery penalties."

Step 2: Gather data

Before hypothesizing causes, collect evidence:

• Timeline of when the problem started and any changes that preceded it
• Frequency and pattern (constant, intermittent, time-based, load-based)
• Scope of impact (which users, processes, or systems are affected)
• Prior attempts to fix and their outcomes

Step 3: Run 5 Whys analysis

Start with the problem statement and ask "why" iteratively:

Problem: Order processing exceeds 2-hour SLA
Why 1?  Manual validation step takes 90 minutes
Why 2?  Validator must cross-reference 3 systems manually
Why 3?  Systems don't share a common order ID
Why 4?  Each system was built independently without integration design
Why 5?  No enterprise data architecture was defined when systems were procured
ROOT CAUSE: Absence of enterprise data architecture standards for procurement

Rules for 5 Whys:

• Branch when multiple causes exist at a level
• Stop when you reach a cause that is systemic and actionable
• If a "why" answer is a person's name, go deeper - root causes are systemic

Step 4: Build a Fishbone (Ishikawa) diagram

Use 6 BA-specific categories (see references/fishbone-categories.md):

• People: skills, capacity, roles, communication
• Process: steps, handoffs, bottlenecks, documentation
• Technology: systems, integrations, performance, functionality
• Policy: rules, approvals, compliance, SLAs
• Environment: organizational context, budget, competing priorities
• Data: quality, availability, accuracy, access

Place the problem at the head. Add potential causes along each bone. Circle the causes that appear across multiple categories - these are systemic.

Step 5: Apply Pareto analysis

Rank causes by frequency or impact. The 80/20 rule: typically 20% of causes drive 80% of the problem. Focus countermeasures on the vital few, not the trivial many.

Step 6: Validate the root cause

Before declaring a root cause, test it:

• Can you reproduce the problem by triggering this cause?
• Does removing this cause prevent recurrence?
• Does the causal chain from root to symptom hold under scrutiny?
• Is this cause actionable (you can change it)?

Step 7: Document using A3 format

| A3 Section | Content |
|------------|---------|
| Background | Why this problem matters |
| Current Condition | Problem statement with data |
| Goal | Target state after fix |
| Root Cause Analysis | 5 Whys + Fishbone summary |
| Countermeasures | Actions to address root cause |
| Implementation Plan | Who, what, when |
| Follow-up | How to verify the fix worked |
| Expected Results | Measurable improvement target |

Anti-Patterns

1. Stopping at symptoms Bad: "Users didn't follow the process." (Why didn't they? That's a symptom.) Good: "The process requires 12 steps across 3 systems with no integrated view, so users created workarounds."

2. Root cause is a person's name Bad: "John made an error." Good: "The process has no validation check at step 5, allowing data entry errors to propagate."

3. 5 Whys that go in circles Bad: Why? Because X. Why X? Because Y. Why Y? Because X again. Good: If you loop back, you've missed a branch. Split and explore both causal paths.

4. Fishbone with only technology causes Bad: All causes listed under "Technology" - ignoring process, people, and policy. Good: Populate at least 4 of the 6 categories before concluding.

5. No validation of the root cause Bad: "We think the root cause is X, so let's fix it." Good: Test the hypothesis - can you reproduce the problem? Does the fix address it?

Quality Checklist

• [ ] Problem statement is specific, measurable, and time-bounded
• [ ] Data gathered before hypothesizing (not after)
• [ ] 5 Whys reaches a systemic cause (not an individual)
• [ ] Fishbone covers at least 4 of 6 categories
• [ ] Pareto analysis identifies the vital few causes
• [ ] Root cause is validated (reproducible, removable, actionable)
• [ ] Countermeasures address root cause, not symptoms
• [ ] A3 document is complete with follow-up plan and expected results