For consultants fixing a problem that keeps coming back
Root Cause Analysis Template With Fishbone
The full analysis in one doc: problem statement, evidence, a fishbone table under the 6Ms, 5 whys, countermeasures and a check that it worked.
Late deliveries, Eastfield warehouse (example)
Root cause analysis · countermeasures in place
- Problem
- 13% of orders late since July, against a 5% limit
- Fishbone
- Seven possible causes under the 6Ms, three ruled out
- Verified cause
- Orders taken until 5 p.m.; last picking wave at 1:30
- Countermeasure
- A 5:30 p.m. picking wave · warehouse manager · 6 Oct
- Check
- 5% late or less for six weeks, by 1 Dec
What you'll get
Problem statement, fishbone table, 5 whys, countermeasures and a check
- A problem statement, an evidence log and a fishbone table under the 6Ms
- 5 whys chains, with verified and suspected causes kept apart
- Countermeasures with owners and dates, and a check that the fix worked
Before and after
Your notes in. A first fishbone out.
Next-day deliveries from Eastfield have been late since early July, about 13% of orders. We used to be around 4%. Warehouse says orders come in too late in the day. Sales thinks the stock records are wrong. Trucks are leaving on time.
Problem statement: Since early July, about 13% of next-day orders from Eastfield have arrived late, against about 4% before. Target: [target]. Fishbone, by category. Methods: Orders arrive after the last picking wave (the warehouse's view, per your notes). Suspected. Materials: Stock records don't match the shelf (the sales team's view, per your notes). Suspected. Methods: Trucks leave late. Ruled out: your notes say trucks are leaving on time. To confirm with the client: entry times of late orders, the picking schedule, and short picks before and after July.
Every cause stays suspected until evidence verifies it, and the data that would settle it goes on your to-confirm list.
Why it works
What is root cause analysis, and what goes in the template?
A root cause analysis template takes one problem from what you can see to the causes you can prove, then to a fix and a check that it worked. ASQ defines a root cause as a factor that caused a nonconformance and should be permanently eliminated through process improvement. This template is the full document in eight sections: the problem, the evidence, possible causes, 5 whys, verified causes, countermeasures, the check, and what to confirm.
The possible causes go in a fishbone diagram laid out as a table. Kaoru Ishikawa's 6 Ms, as ASQ sets them out, become six plain categories: methods, machines, materials, measurement, people and environment. Each cause gets the evidence for or against it and a status: verified, suspected or ruled out. Keeping those apart is the point. A suspected cause gets a test, not a fix, and ruled-out causes stay on the page so nobody reopens them. The strongest causes then go through a 5 whys chain.
The second doc is a fully worked example: late deliveries at an invented supplies distributor, from a 13% late rate to countermeasures with owners, dates and a check. Paste the problem and what you know so far, and River drafts the problem statement and a first fishbone, with every cause suspected until the evidence says otherwise. If the problem sits in a process nobody has mapped, start with a SIPOC diagram. When the facts are in interview notes, interview synthesis pulls them out with every quote sourced.
What lands in your doc
What's inside the root cause analysis template
- Problem statement
What, where, since when and how big, where it doesn't happen, and containment while you look. - Evidence log
Each fact with its source and date, plus what changed just before the problem started. - Fishbone diagram as a table
Possible causes under the 6Ms, each marked verified, suspected or ruled out against the evidence. - 5 whys for the top causes
A why chain for each strong cause, with a how-do-we-know column and a rule for when to stop. - Countermeasures and the check
A fix for each verified cause with an owner and a date, then the measure, target and check date. - A worked example
Late deliveries at an invented distributor, every section filled, with a note on why each one works.
How it works
How to do a root cause analysis, step by step
State the problem
Write what is going wrong, where, since when and how big, against a target. Name no cause yet, and note where the problem doesn't happen.
Gather the evidence
Pull the data, record each source and ask what changed just before it started. Optional: paste what you know, and River drafts a first pass.
Build the fishbone, then ask why
With the people who do the work, list causes under the six categories and mark each against the evidence. Run 5 whys on the strongest until you reach one the client controls.
Fix it and check
Give each verified cause a countermeasure, an owner and a date, and test suspected causes first. Then track the problem's own measure until the target holds.
Questions consultants ask
Common questions
What is root cause analysis?
Root cause analysis is a structured way to find why a problem happens, so you fix the cause instead of the symptom. ASQ calls it a collective term for many approaches and tools. Most follow one path: state the problem, gather evidence, list possible causes, test them, fix the verified ones and check that the fix held.
What is a fishbone diagram, and what are the 6Ms?
A fishbone diagram sorts the possible causes of one problem into categories drawn like the bones of a fish, with the problem at the head. Ishikawa's 6Ms are materials, machinery, methods, measurement, manpower and Mother Nature. This template calls the last two people and environment, and lays the diagram out as a table that fits in a Word document.
Should I use a fishbone diagram or 5 whys?
Usually both, in that order. The fishbone widens the search, so the team considers causes beyond the first idea in the room. The 5 whys then go deep, following the strongest causes down to one the client can act on. For a small problem with one obvious chain, 5 whys alone can be enough.
How do you know a root cause is verified?
It passes three tests. The evidence shows the cause where the problem happens and not where it doesn't. It began before the problem did. And removing it would stop the problem. A cause that passes only the first test stays suspected, with a test to settle it, such as comparing data from before and after a change.
How is root cause analysis different from an issue tree?
An issue tree breaks a broad business question, such as why margin fell, into branches to analyze. Root cause analysis starts from one specific, measurable problem in a process and proves what causes it. Consultants often use both: the issue tree shows where the problem sits, and the root cause analysis explains it.
What happens after the root causes are fixed?
Track the problem statement's own measure until the target holds, usually for several weeks. Then make the change standard: update the procedure, train new starters and name who keeps watching. If the client wants a bigger change in how the process works, a gap analysis sets out the current state, the target and the steps between.
Will River make up causes or facts?
No. River drafts only from what you paste. Causes your notes suggest are marked suspected, with whose view each one is. Numbers, dates and owners your notes don't give stay in brackets, and the evidence still needed goes on a list to confirm with the client. What you paste stays in your River space unless you share it.
Your next step
More for your project
Fix the cause, not the symptom
Open the template with a worked example beside it, or paste the problem and what you know for a first pass.