BoardSnap is an iOS app that converts whiteboard photos into clean summaries and action items in about ten seconds. This root cause analysis template structures a five whys or fishbone diagram session on a whiteboard — then BoardSnap reads it and produces the RCA finding with corrective action items.
Use root cause analysis whenever a problem recurs, when an incident postmortem surfaces a systemic issue, or when the first fix didn't stick and the problem came back. RCA is also valuable for quality failures, process breakdowns, and unexpected customer churn spikes — any situation where 'fix the symptom' isn't producing durable results.
Budget 60 minutes. Bring the people closest to the problem — not the most senior people, the most informed ones.
Write the specific, observable problem at the top of the board. Not 'our deployment process is bad' — 'deployment to production failed three times in the last two weeks, causing a combined 90 minutes of downtime.' Specificity prevents the RCA from wandering into generalized complaints.
Write Why 1 below the problem statement. Below that, write Why 2 (why is Why 1 true?). Continue to Why 5. The chain should lead from the observable symptom to a systemic condition — a missing process, an architectural decision, or an absent safeguard. If Why 5 is still blaming a person, go to Why 6.
If you're running a fishbone diagram instead of five whys: draw the spine, write the problem at the head, and draw six arms labeled People, Process, Technology, Environment, Materials, and Measurement. Under each arm, write the factors in that category that contributed to the problem. This is especially useful for complex problems with multiple causes.
Write the root cause in one sentence at the bottom of the five whys chain or the body of the fishbone. It should be a systemic condition — 'We have no automated test for X' or 'The deployment process has no rollback verification step.' If it's a person's name, rewrite it.
Two to four specific changes that address the root cause. Each action has: a description of the change, the owner, and the deadline. Corrective actions that address symptoms, not the root cause, will produce the same problem six months later.
The most common RCA failure is starting with a vague problem. Spend five minutes writing a precise problem statement before starting the five whys. A specific problem produces a specific root cause. A vague problem produces a vague finding.
Read the problem statement aloud. Ask 'why did this happen?' Write every answer you hear. If there are multiple answers, you may have multiple causal chains — follow each one separately. Merge them at the root cause.
The test for a good root cause: if you fixed it, would this problem happen again? If the answer is 'probably yes,' you haven't gone deep enough. Keep asking why. A root cause that points to a person ('human error') is not a systemic root cause — go one level deeper.
Five whys is best for linear causal chains. Fishbone is best for complex problems with multiple simultaneous contributing factors. Use five whys first. If the problem doesn't fit a single chain, switch to fishbone.
When the chain reaches a systemic condition, write it clearly in a box on the board. Read it aloud. Ask: 'If this condition didn't exist, would the original problem have occurred?' If the answer is 'probably no,' you have the root cause.
For each corrective action: write the change, the owner, and the date. Then ask: 'Does this change address the root cause, or does it address a symptom?' If it's a symptom fix, add it but note that it's a short-term measure — then write the real corrective action that addresses the root cause.
BoardSnap reads the problem statement, five whys chain, root cause statement, and corrective actions. The output is a structured RCA finding — root cause in bold, corrective actions as dated action items.
RCA sessions that happen in a Confluence doc feel like writing, not thinking. RCA sessions at a whiteboard feel like detection — because drawing the causal chain visually, with everyone watching it build, makes it much easier to spot when the chain is still at the symptom level.
BoardSnap captures the full causal chain — from the problem statement to the root cause — and produces a document that's more readable than a doc full of nested bullets.
Five whys is a root cause analysis method where you repeatedly ask 'why did this happen?' about each successive answer until you reach a systemic root cause — typically after five iterations. Developed by Sakichi Toyoda for Toyota's quality control system, it's now used in incident postmortems, process improvement, and quality management across every industry.
A fishbone diagram (also called an Ishikawa diagram or cause-and-effect diagram) maps contributing factors to a problem across six categories: People, Process, Technology, Environment, Materials, and Measurement. The problem is the 'head' of the fish; the categories are the 'bones.' It's useful when a problem has multiple simultaneous causes rather than a single causal chain.
Five whys works well for problems that have a clear causal sequence — one thing led to another. Fishbone works better for complex problems where multiple factors from different categories combined to produce the outcome. If you start a five whys and find multiple answers at each level, switch to fishbone.
The free tier includes one project and 30 boards. Pro is $9.99/month or $69.99/year for unlimited boards and AI chat on every board you snap.
The broader incident review that often generates RCA as a deliverable.
Triage the symptoms; use RCA to address the root cause for recurring bugs.
After a systemic RCA, review the architecture to find structural vulnerabilities.
No exporting, no transcription. Snap the board, get the action plan.