Root Cause Analysis
Identify the underlying, originating cause of a problem rather than just its symptoms.
Definition
Root Cause Analysis identifies the underlying, originating cause of a problem rather than just its symptoms. Common techniques include the "5 Whys" (repeatedly asking why a problem occurs until the true cause is reached) and the Fishbone (Ishikawa) Diagram, which organizes potential causes into categories such as people, process, technology, and environment.
Inputs
- A clearly defined problem statement or observed symptom
- Access to people, data, or process knowledge needed to trace the issue backward
Outputs
- One or more identified root causes, distinct from surface-level symptoms
- A visual or structured artifact (fishbone diagram, why-tree) documenting the causal chain
When to Use
- A recurring problem keeps appearing despite repeated fixes to symptoms
- Before defining a solution, to ensure the right problem is being solved
- Post-incident or retrospective analysis, to prevent recurrence rather than just patch the immediate issue
When Not to Use
- The cause is already obvious and well-understood — formal analysis adds ceremony without value
- Time-critical situations requiring an immediate workaround before deeper analysis is feasible
See this technique in action with a free RequirementsHub workspace.
Start Free Workspace →