For consultants fixing a problem that keeps coming back
Root Cause Analysis Template With Fishbone
Trace a recurring problem to a root cause you can prove, with a fishbone table, 5 whys, countermeasures and a check that the fix held.
Building the fishbone
The six fishbone categories, and what to ask under each
A fishbone diagram sorts the possible causes of one problem into branches. ASQ says Kaoru Ishikawa introduced the 6Ms as generic labels for the main branches, and encouraged renaming them so the people using the diagram understand them4. The template uses plain names. Under each, ask why the problem might happen, and write every idea as a cause, never a fix.
| Category | What it covers | Questions to ask |
|---|---|---|
| Methods | Procedures, rules, schedules and handoffs between teams | Is there a written way to do this, and is it what people actually do? Did a rule, schedule or handoff change? |
| Machines | Equipment, systems and software | Did a system, setting or tool change? Does the problem follow one machine, system or screen? |
| Materials | Supplies, stock and the information that comes in | Did a supplier, input or data feed change? Does what arrives match what the records say? |
| Measurement | Data, targets and how results are counted | Is the number counted the way everyone assumes? Could the count have changed rather than the work? |
| People | Skills, training, staffing and workload | Who does this work now who didn't before? Do they have the time, instructions and tools? Ask why the process let a mistake through, not who made it. |
| Environment | Demand, the workplace and outside conditions | Did volume, timing or customer behavior change around the start date? Does the problem follow the calendar, the weather or one location? |
People and environment stand in for Ishikawa's manpower and Mother Nature, and ASQ also lists a less common seventh M, money. A cause that fits more than one category can go on each of those branches. When ideas run dry, focus on the branches with the fewest ideas4.
How it works
What is root cause analysis, and what goes in the template?
Root cause analysis is a structured way to find out why a problem keeps happening, so the fix removes the cause instead of the symptom. ASQ, the American Society for Quality, defines a root cause as a factor that caused a nonconformance and should be permanently eliminated through process improvement1. A good analysis moves in one order: state the problem, gather evidence, list possible causes, prove which are real, fix those and check that the fix held. The template's eight sections follow that order.
Write the problem first, with no cause in it: what is going wrong, where, since when and how big, against a target. Say where it doesn't happen too, because the difference often points to the cause. Then ask what changed just before it started: change analysis, as ASQ describes it, explores changes in people, equipment, information and more1. Build the fishbone with the people who do the work, and mark each cause verified, suspected or ruled out against the evidence. Follow the strongest causes down a 5 whys chain.
Three tests verify a cause. It is present where the problem happens and absent where it doesn't, it started before the problem, and removing it would stop the problem. NASA's rules for mishap investigations build the last two tests into their definition: a root cause existed before the failure and, if eliminated or modified, would have prevented it2. Fix each verified cause with a change to the process, not a reminder. Give each fix a date and one owner rather than a committee3, as the National Patient Safety Foundation's RCA2 guide advises.
How it works
How to do a root cause analysis, step by step
Download it or open it in River
Download both Word documents free, or paste the problem and what you know, and River drafts a first pass to check.
State the problem with numbers
Put the gap against a target in numbers, note where the problem doesn't happen, and protect customers while you look.
Find and test the causes
Log each fact with its source, sort possible causes on the fishbone, and run 5 whys on the best-supported ones.
Fix it and check it held
Change the process behind each verified cause, name who owns each fix, then track the problem's number until the target holds.
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.
What lands in your doc
What's inside the root cause analysis template
- Root Cause Analysis Template
The fill-in Word document: eight numbered sections, from the problem statement to a list of facts to confirm. - Problem statement and evidence log
The problem in numbers, a stopgap that protects customers meanwhile, and each fact with its source and date. - Fishbone diagram as a 6M table
Possible causes under six categories, each marked verified, suspected or ruled out against the evidence. - 5 whys and root causes
Why chains for the top causes, then each root cause with its evidence or the test that would confirm it. - Countermeasures and the check
A fix, owner and due date for each verified cause, then the measure, target and check date. - Root Cause Analysis Example
A separate document: late deliveries at an invented distributor, every section filled in, with notes on why it works.
Questions consultants ask
Common questions
What is root cause analysis?
Root cause analysis traces a problem back to what causes it, so fixing that cause stops it coming back. ASQ calls it a collective term for a wide range of approaches, tools and techniques1 used to uncover causes. In this template's worked example, late deliveries trace back to an order cutoff moved to 5 p.m. without checking the 1:30 p.m. picking schedule.
What is a fishbone diagram, and what are the 6Ms?
A fishbone diagram, also called an Ishikawa or cause-and-effect diagram, puts the problem at the head of a fish and sorts its possible causes into categories along the ribs. ASQ lists Ishikawa's 6Ms as materials, machinery, methods, measurement, manpower and Mother Nature4. This template calls the last two people and environment, and lays the diagram out as a table for Word.
Should I use a fishbone diagram, 5 whys or an issue tree?
Usually a fishbone first, then 5 whys. The fishbone widens the search beyond the first idea in the room, and the 5 whys follow the strongest causes down to one the client controls. Start with an issue tree for a broad question, such as why margin fell, or a SIPOC diagram if nobody has mapped the process.
How do you know a root cause is verified?
When evidence, not opinion, ties it to the problem: it shows up only where the problem does, it came first, and taking it away stops the problem. Useful tests are data from before and after the start date, a comparison with an unaffected site, or a small trial that removes the cause. Until then, keep it marked suspected.
What happens after the root causes are fixed?
Check that the fix held, then make it standard. RCA2, a patient safety guide, advises two kinds of measure: process measures confirm the action was taken, while outcome measures show whether it worked3. In the Lean Enterprise Institute's guide to the PDCA cycle, a team that reaches a measurable gain5 updates its standard work, and one that doesn't starts the cycle again.
Is this root cause analysis template free?
Yes. Download the template and the worked example as two Word documents, free and with no account. Edit with AI opens both in a free River workspace. Fill them in yourself there, or paste the problem and what you know in the box at the top of this page, and River drafts a first pass.
What does Edit with AI do?
It opens the template and the worked example in River. If you pasted the problem, River drafts every section from your notes and adds other likely causes to the fishbone. Each cause stays suspected until evidence settles it, and facts your notes lack are left in brackets, on a list to confirm. Under River's privacy policy, your content isn't used to train AI models.
Your next step