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