Most root cause analyses stop one "why" too early. The template structure is fine. Problem statement, timeline, findings, corrective actions. You can download that from any government website. The part where investigations fail is picking the wrong method for the problem type and stopping the causal chain before reaching something you can actually fix.
A fishbone diagram template applied to a single-point failure wastes everyone's time. A 5 whys template used on a complex systems problem produces one linear chain when the real cause sits at the intersection of three. The method has to match the problem. That decision is where most root cause analysis templates give you nothing.
Here are the templates that work, when to use each one, and how to write findings that lead to corrective actions instead of filing cabinets. If you are figuring out how to do a root cause analysis for the first time, start with the method selection table below. Every root cause analysis template free to use, works in ChatGPT, Claude, Gemini, or any AI tool you already have.
What a Root Cause Analysis Actually Includes
A root cause analysis is a structured investigation that traces a problem from its symptoms to the underlying cause, then defines corrective actions to prevent recurrence. Not a blame exercise. Not a form you fill out because compliance asked for it. An investigation.
Every root cause analysis template needs six components. Skip one and the RCA gets challenged the first time someone asks "but did you actually check that?"
Problem statement. What happened, when, where, who was affected, and the measured impact. "Production line stopped" is not a problem statement. "Line 3 stopped for 4.5 hours on March 2, delaying 340 units and costing $28,000 in overtime" is a problem statement.
Timeline. A sequence of events, decisions, and conditions before, during, and after the incident. The timeline is where you find the things nobody thought to mention in the initial report.
Method selection. Which root cause analysis method you used and why. More on this below because picking the wrong method is the second most common RCA mistake after vague problem statements.
Findings. The identified root causes with evidence chains, confidence levels, and a clear distinction between confirmed causes and probable causes needing verification.
Corrective action plan. Immediate containment actions that stop the bleeding, long-term corrective actions that fix the root cause, and preventive actions that change the system. Each action gets an owner, a deadline, and a success metric.
Verification schedule. How you will confirm the fix worked. 30, 60, and 90 day checkpoints with specific metrics. Without this, the corrective action plan is a wish list.
If your rca template is missing any of these, you are building a document that creates the appearance of investigation without the substance of one.
Which Method Fits Your Problem
Not every problem needs the same root cause analysis method. Using the wrong method wastes investigation time and produces findings that look thorough but miss the actual cause.
| Problem Type | Right Method | Best Template | Why |
|---|---|---|---|
| Single failure with a clear chain of events | 5 Whys | 5 Whys Template | Linear questioning works when the causal chain is straightforward |
| Multiple potential causes across categories | Fishbone Diagram | Fishbone Diagram Template | Categorized brainstorming catches causes that 5 Whys misses |
| Complex system failure with interacting causes | Fault Tree Analysis | Root Cause Analysis Template | Logic gates (AND/OR) model how combinations of failures create the incident |
| Recurring problem where 80% of impact comes from 20% of causes | Pareto Analysis | Root Cause Analysis Template | Ranks contributing factors by frequency or impact to focus resources |
| Critical incident requiring team-based structured response | 8D Method | Root Cause Analysis Template | Eight-discipline process with team formation through lessons learned |
Best for: Operations, quality, and safety teams running formal investigations. Skip if: The problem is a one-time human error with an obvious fix. You do not need a full RCA for someone accidentally deleting a file. A corrective action note covers it.
The biggest mistake is reaching for a fishbone diagram template when the problem has one clear causal path. You end up with six categories of brainstormed causes, most of them speculative, when three rounds of "why" would have reached the root in 20 minutes. The reverse is equally wasteful. Applying 5 whys root cause analysis to a problem with multiple interacting causes produces one chain and misses the other three.
The 5 Root Cause Analysis Steps
Regardless of which method you pick, every root cause analysis follows the same five steps. The method changes how you execute step 3. Everything else stays the same.
Step 1: Define the Problem
Write a problem statement with numbers. Date, time, location, who was affected, measured impact. The problem statement sets the scope for the entire investigation. A vague statement produces a vague investigation.
Weak: "Customer complaints increased." Strong: "Tier 1 support tickets rose from 45/week to 112/week between February 10 and March 1. 78% of new tickets cite delayed order fulfillment. Average resolution time increased from 2.1 hours to 6.4 hours."
The strong version gives the investigation team something to trace. The weak version gives them nothing.
Step 2: Build the Timeline
Map every event, decision, and condition in sequence. Start 2-4 weeks before the incident. Include process changes, staffing shifts, system updates, supplier changes. Flag gaps where you do not have data. Those gaps are often where the root cause hides.
Step 3: Apply Your Method
This is where the templates diverge. See the 5 Whys and Fishbone examples below.
Step 4: Write the Corrective Action Plan
Every root cause gets three layers of action. Containment (stop the bleeding within 48 hours). Corrective action (fix the root cause within 2-4 weeks). Preventive action (change the system so this class of problem cannot recur). Each action needs an owner, a target date, and a metric that proves it worked.
Step 5: Verify and Monitor
Set checkpoints at 30, 60, and 90 days. Define success criteria before you start. If the metric is not improving by day 30, the corrective action is wrong. Reopen the investigation.
5 Whys: A Real Example
The 5 whys template works best for problems with a single causal chain. Start with the problem, ask why it happened, then ask why that answer happened. Keep going until you reach a systemic cause you can actually fix.
Here is a 5 whys example from a fulfillment operation. Each level includes the evidence source so the chain is defensible.
Problem: 23% of orders shipped late in the last 2 weeks (up from 4% baseline).
Why 1: Warehouse picking took 3x longer than normal. (Evidence: WMS time stamps show average pick time rose from 8 min to 24 min.)
Why 2: Pickers could not locate inventory in assigned bin locations. (Evidence: 67 of 89 late orders had at least one bin mismatch logged.)
Why 3: A new inventory management system went live on February 8 and bin location data migrated incorrectly. (Evidence: IT migration log shows 1,400 SKUs mapped to wrong zones.)
Why 4: The data migration was tested against a 200-SKU sample instead of the full 12,000-SKU catalog. (Evidence: QA test plan document, approved February 5.)
Why 5: No migration testing standard exists. QA scope was left to the project lead's judgment. (Evidence: No SOP for system migration testing in the quality manual.)
Root cause: Missing standard operating procedure for system migration testing, resulting in inadequate QA coverage.
Notice the pattern. Each "why" includes the evidence that connects it to the previous answer. Without evidence, a 5 Whys chain is just speculation formatted as questions. The 5 Whys Template generates branching causal chains automatically, including evidence prompts at each level and a corrective action plan with 30-60-90 day verification.
Common 5 Whys mistakes: Stopping at "human error" (always ask why the system allowed the error). Asking leading questions that confirm what you already believe. Running only one chain when the problem has two contributing paths. The template handles the branching for you, but you still need discipline on evidence.
Fishbone Diagram: When to Use It
A fishbone diagram template organizes potential causes into categories, which is why it works for problems where the source could be people, process, equipment, or materials. Also called an ishikawa diagram or cause and effect diagram after Kaoru Ishikawa, who created the method for quality control at Kawasaki shipyards in the 1960s.
The standard framework uses six categories, called 6M:
| Category | What to Investigate | Example Causes |
|---|---|---|
| People (Man) | Training, staffing, fatigue, communication | New hire without certification, understaffing on night shift |
| Machine | Equipment age, maintenance, calibration, capacity | Sensor out of calibration since January, no backup pump |
| Method | SOPs, workflow design, handoffs, approvals | No SOP for the new process, approval bottleneck at QA |
| Material | Raw material quality, supplier consistency, specs | Supplier changed resin formula without notification |
| Measurement | Data collection, inspection criteria, sampling | QC checks reduced from 100% to 10% sampling |
| Mother Nature | Temperature, humidity, seasonal factors, external | Humidity spike in warehouse during rainy season |
Best for: Quality defects, process failures, customer complaint patterns, recurring issues where multiple factors might contribute. Skip if: You already know the general area of the problem and need to drill into one specific chain. Use 5 Whys instead.
The Fishbone Diagram Template supports three category frameworks. The standard 6M for manufacturing and operations. The 4S framework (Surroundings, Suppliers, Systems, Skills) for service industries. The 5P framework (Product, Price, Place, Promotion, People) for marketing problems. Pick the framework that matches your industry. Using manufacturing categories for a marketing problem produces six empty branches and one overloaded one.
After brainstorming causes under each category, the template generates a prioritization matrix. Each cause gets a likelihood score (1-5) and an impact score (1-5). Multiply them. The top five causes by priority score go into the verification plan. This prevents the classic fishbone mistake: brainstorming 40 causes and investigating none of them.
Writing the Root Cause Analysis Report
The root cause analysis report is where investigations either create change or collect dust. A report that reads like a form produces no action. A report that tells the story of the investigation and makes the corrective actions unavoidable produces results.
Structure that works:
Executive summary (3-4 sentences). Problem, root cause, recommended action, expected outcome. This is for the person who will not read the full report. Make it specific enough that they can approve the corrective action from the summary alone.
Problem description and timeline. Detailed narrative with dates, data points, and the sequence of events. Include what was happening normally before the problem appeared. Contrast highlights the deviation.
Investigation method and team. Which method you used (and why), who participated, what data sources you accessed. This establishes credibility for the findings.
Findings. Each root cause with its evidence chain, confidence level (high/medium/low), and classification (process, people, equipment, materials, management, environmental). Separate confirmed causes from probable causes needing verification.
Corrective action plan. Table format. Columns: root cause, action type (containment/corrective/preventive), description, owner, deadline, success metric. No action without an owner. No owner without a deadline. No deadline without a metric.
Verification schedule. 30, 60, 90 day review dates with specific metrics to check at each interval. Define what "closed" looks like before you start the corrective actions.
The Root Cause Analysis Template generates this full report structure from a problem description. It supports all five major root cause analysis methods (5 Whys, Fishbone, Fault Tree, Pareto, 8D) and includes the corrective action table, verification schedule, and prevention plan automatically.
Common RCA Mistakes That Kill Investigations
Five patterns that turn an RCA into a paperwork exercise:
1. Stopping at "human error." Someone made a mistake is never the root cause. The root cause is why the system allowed the mistake, did not catch it, or did not have a safeguard. If your 5 Whys chain ends at "the operator pressed the wrong button," ask one more why. What about the interface, the training, or the process design made that error possible?
2. Choosing the method after the investigation. If you run a fishbone brainstorming session and then write up the findings as a 5 Whys, the structure does not match the process. Pick the method first. It shapes what data you collect and how you analyze it.
3. No evidence at causal links. Every "because" in your chain needs evidence. "The sensor failed because it was not calibrated" is only valid if you can show the calibration log. Without evidence, you are documenting assumptions.
4. Brainstorming without prioritizing. A fishbone diagram with 35 potential causes and no prioritization matrix is a brainstorm dump. Score each cause on likelihood and impact. Investigate the top 5-10. Dismiss the rest unless new evidence surfaces.
5. Writing corrective actions without owners. "Improve the training program" is not a corrective action. "L&D Manager updates Module 4 to include hands-on calibration practice by April 15, measured by post-training assessment scores above 85%" is a corrective action. If you cannot name the person, the deadline, and the metric, the action will not happen.
Healthcare Root Cause Analysis
Root cause analysis healthcare investigations follow the same steps but operate under regulatory requirements that add documentation layers. Joint Commission mandates root cause analysis for sentinel events. CMS requires it for certain adverse events. The investigation process is identical. The documentation standards are higher.
The key difference: healthcare root cause analysis uses contributing factor categories specific to clinical environments. Instead of the 6M manufacturing categories, healthcare RCAs typically examine human factors, communication, leadership, physical environment, equipment, and information management.
The Root Cause Analysis Template includes healthcare as an industry option. When you select healthcare, the output adjusts the investigation categories and includes patient safety impact assessment sections. For problems specific to a single clinical workflow, the 5 Whys Template often works better because clinical incidents usually have identifiable causal chains rather than diffuse contributing factors.
Building RCA Reports with AI
Static Word and Excel templates give you the structure. They do not help you write the analysis. You still stare at "describe the problem" and wonder how specific is specific enough.
That is where AI-generated RCA reports close the gap. Instead of searching for a root cause analysis example that matches your industry, describe the incident in plain language and the output includes the problem statement with quantified impact, a timeline template, the appropriate analysis method applied with evidence prompts at each step, a corrective action table with owner and deadline columns, and a verification schedule with 30-60-90 day checkpoints.
The Root Cause Analysis Template works in ChatGPT, Claude, Gemini, or the Dock Editor. Select your industry, describe the problem, choose your severity level and analysis method, and the output is a complete root cause analysis report ready for review.
For the specific methods:
- 5 Whys Template for linear causal chains with branching support
- Fishbone Diagram Template for categorized cause brainstorming with prioritization
All three are free to use. Open any of them in the Dock Editor to generate a customized RCA document in under a minute.
FAQ
How do you write a root cause analysis?
Start with a specific problem statement that includes dates, impact numbers, and who was affected. Build a timeline of events leading to the incident. Apply your chosen method (5 Whys for linear problems, fishbone for multi-category problems). Document each root cause with supporting evidence. Write a corrective action plan with owners, deadlines, and success metrics. Set 30, 60, and 90 day verification checkpoints.
What are the 5 steps of root cause analysis?
Define the problem with measurable terms. Build a timeline of events and conditions. Apply the investigation method (5 Whys, fishbone, fault tree, Pareto, or 8D). Write corrective actions at three levels: containment, correction, and prevention. Verify effectiveness at 30, 60, and 90 days with documented metrics.
What is the difference between 5 Whys and a fishbone diagram?
The 5 Whys follows one causal chain by asking "why" repeatedly until reaching a systemic root cause. It works best for single-path problems. A fishbone diagram (also called an ishikawa diagram) organizes potential causes into categories like people, process, and equipment. It works best when the cause could come from multiple areas. Use 5 Whys when you know roughly where the problem is. Use a fishbone when you do not.
What makes a good root cause analysis?
A good RCA has a specific problem statement with numbers, evidence at every causal link, root causes that are systemic (not "human error"), corrective actions with named owners and deadlines, and a verification schedule. The test: if someone reads only the root cause and the corrective action, can they understand exactly what broke and exactly what will change?
Can an employee refuse to participate in an RCA?
Participation depends on your organization's policies and any union agreements. Effective RCAs are non-punitive investigations focused on systems, not individuals. Frame participation as process improvement, not blame assignment. If your RCA culture is punitive, people will hide information and your investigations will consistently miss root causes.
What are the 3 R's of root cause analysis?
Recognize the problem, Rectify the immediate situation, and Resolve the underlying cause. Recognition means detecting and defining the problem with data. Rectification is the containment action that stops ongoing damage. Resolution is the corrective action that prevents recurrence. Most teams get the first two right and skip the third.
How long should a root cause analysis take?
Simple problems with a clear causal chain (5 Whys) take 2-4 hours including documentation. Complex problems requiring fishbone analysis or fault tree modeling take 1-3 days for investigation plus a day for report writing. Critical incidents using the 8D method can take 2-4 weeks with a dedicated team. The timeline should match the severity. Rushing a serious investigation is worse than taking the time to get it right.