To complete a root cause analysis worksheet, write a measurable problem statement, list the verified facts, and ask "why" until you reach a process you can change. Then test that cause against your data and assign actions with an owner, a due date, and a success measure. The template below holds every field you need. Copy it into Word, Excel, or Google Docs and start filling it in.
Most blank forms fail the same way. Someone writes "operator error" in the cause box, assigns retraining, and closes the file. Three weeks later the same defect, delay, or incident returns, because the form recorded a symptom instead of a cause. A worksheet only works when each field forces a specific kind of thinking.
Lean Six Sigma Experts has helped businesses reduce waste and improve operations through an engineering-driven approach to Lean Six Sigma since 2011. You get a copy-ready worksheet, four steps for completing it, a worked manufacturing example, and a way to confirm the fix held.
What your worksheet needs before you start
A useful worksheet has five parts: a problem statement, evidence, a cause chain, a verified root cause, and tracked actions. Anything less leaves a gap where assumptions slip in. Use the template below as a base and adapt the labels to your industry.
The five parts of a working worksheet
Each part has one job, and each one blocks a common failure.
- Problem statement: pins down what happened, where, when, and how big, so the team investigates one thing.
- Facts and evidence: separates what you know from what people believe.
- Cause chain: shows how you got from symptom to cause, so others can check your logic.
- Root cause statement: names one cause you can change, with proof.
- Actions and effectiveness check: assigns owners and dates, then measures whether the problem stopped.
A worksheet that skips verification and follow-up is only a record of what you assumed.
Copy-ready worksheet template
Paste this into any document. In Word, keep it as is and add a table where you see "|". In Excel, make each label a column header and give each "why" its own row. For a PDF, paste it into Word and save as PDF. In healthcare or other regulated settings, add the event classification and reporting fields your organization requires.
ROOT CAUSE ANALYSIS WORKSHEET
Incident ID: Date/time of event:
Process/location: Prepared by:
Team members: Date opened:
1. PROBLEM STATEMENT (what, where, when, how big; no causes, no blame)
2. CONTAINMENT (what was done right now to limit damage)
3. FACTS AND EVIDENCE
Fact | Source | Verified by
4. CAUSE ANALYSIS
Why 1:
Why 2:
Why 3:
Why 4:
Why 5:
Other contributing factors (people, method, machine, material,
measurement, environment):
5. ROOT CAUSE STATEMENT
Because ____, ____ happened, which led to ____.
Evidence that confirms it:
6. ACTIONS
Action | Type (corrective/preventive) | Owner | Due date | Status
7. EFFECTIVENESS CHECK
Metric: Baseline: Target:
Check date: Result: Closed by:
Step 1. Define the problem and gather facts
Start with a one-sentence problem statement that someone outside your team could verify, then collect evidence before anyone proposes a cause. Skipping this step is the main reason teams solve the wrong problem.
Write a measurable problem statement
Use four elements: what, where, when, and how much. A weak statement reads "Line 3 has quality issues." A strong one reads "Between Oct 1 and Oct 14, 6.2% of housings from Line 3 failed the bore diameter check, against a baseline of 1.1%." That sentence names the defect, the place, the period, and the size of the gap.
Leave causes and names out of it. "Because the night shift skipped calibration" is a theory, not a problem statement, and it will bias every later field.
Collect facts before you ask why
Fill in the facts table next. Pull inspection records, maintenance logs, timestamps, and photos, and interview the people closest to the work. Record the source of each fact, because a fact without a source is an opinion.
Separate observations from interpretations. "The tool was replaced 9 days late" is a fact if the log shows it. "The tool was probably worn" is a guess to test later. Also log what you did to contain the problem, such as quarantining parts or pausing the line.
Evidence comes first, because a team that starts with theories will find evidence to match them.
Step 2. Trace causes with the 5 Whys and a fishbone
Ask "why" about each answer, one link at a time, until you reach a process or system you can change. Five is a guide, not a rule. Stop when the next answer is outside your control or when fixing the current one would prevent the problem.
Run the 5 Whys on one branch at a time
Here is the Line 3 example, written the way it belongs in the worksheet.
| Why | Answer | Evidence |
|---|---|---|
| 1. Why were housings out of tolerance? | The bore was cut undersized | Gauge data, Oct 1 to 14 |
| 2. Why was the bore undersized? | The cutting tool was worn past its limit | Tool inspection |
| 3. Why was it worn past its limit? | It was replaced 9 days late | Maintenance log |
| 4. Why was it replaced late? | The schedule counts calendar days, not parts cut | Maintenance plan |
| 5. Why was it never adjusted? | Nobody reviews the interval when volume changes | Change records |
Do not stop at "operator error" or "human mistake." Ask why the process allowed the mistake. A person is rarely the root cause. The system around them usually is.
Use a fishbone when several causes fit
If your first "why" has more than one plausible answer, sketch a fishbone diagram. Label the branches people, method, machine, material, measurement, and environment. List candidate causes on each branch, then run a separate 5 Whys on each branch that the evidence supports. Record the extra branches under "Other contributing factors" so they are not lost.
Follow each branch with evidence, and the cause chain will show you where to stop.
Step 3. Verify the root cause and assign actions
Confirm that your cause actually explains the problem, then write actions that change the process. A cause you have not tested is only a hypothesis, and an action without an owner does not happen.
Test the cause before you accept it
Apply two checks. First, does the cause explain every fact in your table, including the timing? Second, if this cause had been absent, would the problem have been prevented? In the example, compare the defect dates with tool-change dates. If defects began only after the tool passed its limit, the cause holds. If they started earlier, keep digging.
Then write the root cause statement: "Because the tool-change interval is set in calendar days rather than parts cut, tools ran past their wear limit when volume rose, producing undersized bores."
Write actions with an owner and a date
Each action needs a type, an owner, a due date, and a status. Prefer actions that remove or error-proof the cause over those that rely on memory.
| Action | Type | Strength |
|---|---|---|
| Quarantine and re-inspect Line 3 stock | Containment | Short term |
| Change tool replacement to a parts-cut counter | Corrective | Strong |
| Add a rule to review intervals when volume shifts 15% | Preventive | Intermediate |
| Remind operators to check tool wear | Corrective | Weak |
Retraining and reminders are the weakest fixes, so never let them be the only action.
A strong action changes the process so the problem cannot recur, whether or not people remember.
Step 4. Confirm the fix worked and close the worksheet
Close the worksheet only after data shows the problem stayed away. Closing on the day you finish the actions is the most common way teams end up repeating the same investigation.
Set the effectiveness check up front
Fill in section 7 before the actions start. Name the metric, the baseline, the target, and a check date. For the example: defect rate on bore diameter, baseline 6.2%, target at or below 1.1%, checked four weeks after the new counter goes live. If the result misses the target, reopen the worksheet and return to the cause chain.
Keep the record and look for patterns
File the finished worksheet where others can find it. Review a batch of them every quarter, and a Pareto chart of root cause categories will show where your biggest recurring losses sit. If one process keeps generating worksheets, it needs a full DMAIC project rather than another patch. Our Six Sigma Online Training covers DMAIC and Pareto analysis for teams that want to build this skill in-house.
One finished worksheet fixes a problem, but a pile of them shows you where the system is weak.
Put the worksheet to work
A root cause analysis worksheet is only as good as the thinking behind each field. Define the problem with numbers, gather facts, trace the cause chain, verify it, assign strong actions, and check the result with data. Copy the template above and use it on your next incident, even a small one, so the habit forms before you need it on a serious one.
If your problems keep returning despite your worksheets, or you want help running investigations across several sites, contact Lean Six Sigma Experts. We offer a free 30-minute assessment with no obligation.