Root cause analysis
A root cause analysis template that walks each incident through a structured 5 whys investigation, ending in a corrective action with an owner.
About this template
A root cause investigation that stops at "human error" hasn't found the root cause. This template forces the "why" question at least five times, so the corrective action addresses the process gap that let the problem happen — not just the immediate trigger.
Each card holds a specific, measurable problem statement, the chain of whys, the root cause, and two separate actions: a containment action that stops the immediate problem right away, and a corrective action, owned and dated, that fixes the root cause so it doesn't come back. Group related incidents by category to spot the same root cause showing up across different symptoms.
An RCA isn't done when the corrective action is assigned — it's done once you've verified the problem hasn't recurred. Move the card to Verified only after that check, not the moment the fix ships.
Pairs well with a lessons learned template if you also want to capture the softer, process-level takeaways alongside the formal investigation.
What’s inside
Columns included
Task types
Custom fields
Key features
- Structured 5 whys field to force past the surface symptom
- Containment and corrective action tracked separately, so a quick workaround doesn't get mistaken for the fix
- Verification step to confirm the root cause is actually gone before closing
- Category tagging to spot recurring root causes
- Contributing factors field for causes beyond the primary one
- Works for incidents, defects, and customer complaints alike
Who is this template for?
- Engineering teams running incident postmortems
- QA teams investigating recurring defects
- Support teams tracking customer-impacting failures
- Operations teams auditing process breakdowns
- Manufacturing and ops teams doing formal RCA
How to use this template
Use this board to move an incident from report to a documented, owned corrective action — and confirm it actually worked.
Step 1
Write a specific, measurable problem statement
Name what happened with numbers, not a vague summary — "checkout errors rose from 1% to 8% starting March 3" instead of "checkout is broken." Don't jump to a cause yet.
Step 2
Ask why, at least five times
Chain the whys until you reach a process-level cause rather than a person or a one-off event.
Step 3
Contain, then fix the root cause
Log a containment action to stop the bleeding now, and a separate corrective action — with an owner and due date — that addresses the root cause so it doesn't resurface.
Step 4
Verify before closing
Only move the card to Verified once you've checked the problem hasn't recurred. Resolved means the fix shipped; Verified means it worked.
Frequently asked questions
Related templates
Risk register
A risk register template that scores likelihood and impact, assigns an owner to every risk, and keeps mitigation plans visible until they're closed.
Project charter
A project charter template that locks down scope, sponsor, budget, and success criteria before work starts, and tracks approval status for teams running several projects at once.
Communication plan
A communication plan template that maps each stakeholder audience to a channel, frequency, and owner, so updates go out on schedule instead of by memory.