Root Cause Analyzer

Purpose

Move beyond symptomatic fixes to identify true root causes of recurring problems, using proven analytical methods and producing actionable corrective actions.

When to use

• a problem has occurred more than once despite previous fixes
• a production incident needs thorough investigation
• quality defects are increasing and the cause is unclear
• customer complaints cluster around a specific area
• post-mortem or incident review

When not to use

• the cause is obvious and the fix is straightforward
• strategic planning (use strategy tools)
• risk identification for future events (use risk-register)

Inputs

• problem statement (what happened, when, how bad)
• impact data (who was affected, financial cost, customer impact)
• timeline of events leading to the problem
• previous fix attempts and their outcomes
• relevant process or system documentation
• available data or metrics related to the problem

Procedure

1. Define the problem precisely:
   • What is happening vs. what should be happening?
   • When did it start? How often does it occur?
   • What is the quantified impact?
   • Template: "[Thing] is [problem] resulting in [impact] since [when]"
2. Choose analysis method based on problem type:
   • 5 Whys: for linear causation chains (simple to moderate)
   • Ishikawa / Fishbone: for complex problems with multiple potential causes
     • 6M categories: Man, Machine, Method, Material, Measurement, Mother Nature (Environment)
   • Pareto Analysis: when multiple causes contribute and you need to prioritize
     • 80/20 rule: find the 20% of causes responsible for 80% of the impact
3. Execute analysis:
   • For 5 Whys: ask "why?" iteratively until you reach a systemic cause (typically 3–7 levels). Stop when the answer points to a process, policy, or system — not a person.
   • For Ishikawa: brainstorm causes in each 6M category, then validate with data.
   • For Pareto: list all contributing causes, quantify frequency or impact, sort descending, calculate cumulative %.
4. Validate root cause — confirm it is:
   • Actionable (you can do something about it)
   • Preventable (fixing it prevents recurrence)
   • Systemic (not blaming an individual)
5. Define corrective actions (CAPA framework):
   • Containment: immediate actions already taken
   • Corrective Action: fix the root cause
   • Preventive Action: prevent recurrence in similar processes
   • Each action: What | Who | When | Verification method
6. Define recurrence metrics — how will you know it's fixed?

Output

• problem statement (one clear sentence with impact data)
• analysis output (5 Whys ladder, Fishbone diagram, or Pareto chart)
• validated root cause with supporting evidence
• CAPA table: Containment | Corrective | Preventive actions with owners and dates
• recurrence monitoring plan

Definition of done

• root cause is systemic, not individual blame
• root cause is validated with evidence or data
• corrective and preventive actions are defined with owners and due dates
• recurrence metrics are established

Examples

• "Our deployment failed 3 times this month. Run a 5 Whys analysis."
• "Customer complaints about delayed invoices are increasing. Do a Fishbone analysis."
• "We have 12 different bug types from last quarter. Use Pareto to prioritize which to fix first."

Quality Criteria

• Steps are executable in sequence without external context
• Decision points have clear if/then branching
• Rollback or abort procedures are documented for risky steps
• Expected duration or time-per-step is estimated

Verification (4C)

Check	Question
Correctness	Do the steps execute correctly in the order specified?
Completeness	Are decision points, error handling, and escalation paths all documented?
Context-fit	Could someone with the right access but no prior context complete this runbook?
Consequence	If Step N fails and the operator skips to Step N+1, what breaks?

Edge Cases

• Steps require access the operator doesn't have — Document exact access requirements upfront. Include escalation contact for emergency access.
• Environment differs from documented state — Add a pre-flight check as Step 0 to verify prerequisites before starting.
• Runbook is triggered during off-hours — Document who to contact and which steps can be safely deferred to business hours.

Changelog

• v1.0.0 — Initial release