A fishbone diagram puts one problem at the head of a fish and sorts every possible cause onto bones by category, so your team stops arguing about one favorite theory and examines the whole system. Below are four worked examples (manufacturing, service, SaaS and warehouse), the category sets that fit each, the steps to run a session, and what to do after the diagram is on the wall.
The examples are illustrative scenarios we built to show the method. They are not client case results.
TL;DR
- A fishbone diagram shows possible causes of one specific problem, grouped by category. It does not prove which cause is real.
- Start with the classic 6M categories for production problems, then rename the bones to fit your business: 8P for services, or custom labels for software and sales.
- Gather data before the brainstorm, put people who touch the process in the room, and verify the top causes before you act.
- Pair the fishbone with Five Whys: the fishbone maps the branches, Five Whys drills down each one.
- A diagram without an owner and a deadline on each action is a poster. Assign both before the meeting ends.
Table of Contents
- What a fishbone diagram shows
- Choosing categories: 6M and its adaptations
- Example 1: Manufacturing, rising scrap on a machined part
- Example 2: Service business, late jobs and repeat visits
- Example 3: SaaS, rising customer churn
- Example 4: Warehouse, order-entry errors causing mis-picks
- How to build one: six steps
- Fishbone, Five Whys and other methods
- Where to find a template
- Common mistakes
- Our perspective: the diagram is the easy part
- When you want an outside diagnostic
- FAQ
- Sources
What a fishbone diagram shows
The diagram goes by three names: fishbone, Ishikawa and cause-and-effect diagram. The problem statement sits in a box at the head. A horizontal spine runs back from it, and angled bones carry the categories of cause, each with smaller twigs for sub-causes. ASQ describes it as a way to find possible causes of a problem by sorting ideas into useful categories.
Two points matter before you draw anything.
First, the diagram is a structure, not an idea machine. Kumah and colleagues (2024) stress that it does not generate ideas by itself. It gives a team a frame to analyze a problem in detail, narrow the investigation and build a shared understanding.
Second, everything on the diagram is a hypothesis. A cause only becomes a root cause once you have checked it against data or direct observation.
Choosing categories: 6M and its adaptations
The classic manufacturing set is the 6Ms: Materials, Machinery, Methods, Measurement, Manpower and Mother Nature (environment). ASQ lists these and, importantly, encourages teams to adapt the labels to the industry or problem in front of them.
Here is how that adaptation usually looks in practice:
| Context | Category set that tends to work | Why |
|---|---|---|
| Production, quality defects | Materials, Machinery, Methods, Measurement, Manpower, Environment | Physical inputs and equipment dominate |
| Service delivery | Policies, Procedures, People, Place, Plant/Technology, Price, Promotion, Product (8P) | Cause often sits in handoffs and customer-facing steps |
| Software incidents | Code, Infrastructure, Data, Third party, Process | Standard 6Ms map poorly to software |
| SaaS churn | People, Product, Process, Pricing, Competition, Measurement | Churn is cross-functional |
| Sales shortfall | Pipeline, Messaging, Pricing, Handoffs, Coaching, Data | Matches the revenue process |
The 8P set for services and the software and churn sets above are described in Deckary's walkthrough of worked fishbone models and monday.com's template guide. Treat them as starting points. If a category stays empty after ten minutes, replace it with one that fits your operation.
Example 1: Manufacturing, rising scrap on a machined part
Problem statement: "Scrap rate on the bracket line rose from the usual level to roughly double over the last six weeks." (Illustrative.)
A good statement is specific, measurable and tied to a place and a time. "Quality is bad" gives the team nothing to branch from.
The team draws the 6M bones and fills them:
- Materials: a new supplier lot, inconsistent hardness, missing certificates
- Machinery: worn drill bit, spindle vibration, deferred preventive maintenance
- Methods: outdated work instruction after a design revision, no first-piece check
- Measurement: gauge past its calibration date, different inspectors reading tolerance differently
- Manpower: two new operators on second shift, no certified trainer on nights
- Environment: temperature swings near the dock door
The diagram does not say which of these is the culprit. It gives the team a list to test. They pull scrap data by shift, lot and machine. If the defects cluster on second shift and on one supplier lot, two branches (Manpower and Materials) move to the top of the list, and the interaction between them may be the real story. Interactions like a hard blank meeting a worn tool are common, which is why one-cause thinking so often fails.
Example 2: Service business, late jobs and repeat visits
Problem statement: "Thirty percent of installs need a second visit." (Illustrative.)
Using 8P-style bones:
- Process: scoping notes not passed from sales to scheduling, no pre-visit checklist
- People: techs not trained on a newer product line
- Product: wrong part shipped, backorders
- Place: truck inventory not restocked
- Policies: dispatchers rewarded for volume, not first-time completion
- Technology: job tickets lack photo requirements
Here the pattern is typical of service firms: the cause is rarely the technician. It is a handoff. When you run this session, invite someone from sales, someone from scheduling and someone who rides in the truck. The Centers for Medicare & Medicaid Services guidance on fishbone sessions says to include team members with personal knowledge of the processes and systems involved. That advice carries over to any industry.
If you want to see how handoffs get documented, our guide to process mapping steps shows how to lay the sequence out before you brainstorm.
Example 3: SaaS, rising customer churn
Problem statement: "Annual logo churn in the 50 to 200 employee segment increased two quarters in a row." (Illustrative.)
Churn is a good fishbone problem because no single department owns it. Use these bones:
- People: customer success coverage ratio, turnover in the account team (see this look at data analysis for employee retention if staff turnover is a suspect)
- Product: missing integration, onboarding friction
- Process: no renewal playbook, health scores reviewed monthly rather than weekly
- Pricing: discount-heavy first year, large step up at renewal
- Competition: a competitor bundling a feature for free
- Measurement: churn reasons logged as "other" in the CRM
The Measurement bone is often the revealing one. If your exit data says "other" for 40 percent of departures, the first action is not a retention campaign. It is fixing how you capture the reason.
Example 4: Warehouse, order-entry errors causing mis-picks
Problem statement: "Mis-ships on the outbound dock reached a level that triggers customer credits every week." (Illustrative.)
- Methods: pick path changes not reflected in the slotting list, no scan verification at pack
- Machinery: handheld scanners dropping connection in one aisle
- Materials: look-alike SKUs shelved side by side, damaged labels
- Measurement: error tracked at weekly rather than shift level
- Manpower: seasonal temps without a buddy system
- Data: orders keyed by hand from emailed purchase orders
That last twig often deserves its own follow-up. Manual keying upstream creates errors the dock then inherits. Articles on reducing data entry errors cover that upstream piece. Once you find a cause like this, it may deserve a separate fishbone of its own: Kumah et al. note that when there is more than one root cause, a team may need to run a separate fishbone process for each.
How to build one: six steps
- Write a precise problem statement. Put numbers, place and timeframe in it. Agree on it before anyone draws a bone.
- Gather evidence first. NHS Scotland's improvement guidance advises bringing data and observations from the site of the problem into the room before brainstorming.
- Draw the fish. Problem box on the right, a spine pointing at it, and four to six category bones.
- Brainstorm causes and sub-causes. For each cause ask "why does that happen?" and add the answer as a twig. ASQ describes this repeated "why" questioning as the way to build out the branches.
- Balance the diagram. If the group runs dry, ASQ suggests focusing on the bones with the fewest causes listed so far.
- Pick causes to test. Vote, then verify with data, observation or a small trial before changing anything.
Keep the group small and cross-functional. NHS Scotland frames the diagram as a collaborative exercise that stops teams from jumping to conclusions or solutions before they have examined the underlying system.
Fishbone, Five Whys and other methods
A fishbone is one of several root cause analysis tools, and they work best in combination.
| Method | Best for | Limitation |
|---|---|---|
| Five Whys | A single, fairly simple chain of causes | Follows one path and can miss parallel causes |
| Fishbone | Mapping many possible causes across categories | Produces hypotheses, not proof |
| Data analysis (Pareto, run charts) | Showing which causes occur most | Needs usable data |
The PRISM risk control guide puts the difference plainly: Five Whys is an easy way to dig into causes, while a fishbone maps multiple lines of cause to one problem and gives a more comprehensive view. The same guide reminds teams to focus on factors they can control and not to confuse correlation with causation.
A practical sequence: build the fishbone, choose the two or three most probable branches using data, then run Five Whys down each of them. If your problem lives in a process, a value stream map will often show you where the delay or defect enters.
The tool is also not only for failures. The AHRQ's digital healthcare portal notes you can use it to investigate positive outcomes and learn which causes allowed success to occur. If one site hits its numbers every month, diagram why.
Where to find a template
You do not need special software. A whiteboard, a sheet of butcher paper or a slide works. If you want a file, ASQ lists a downloadable Excel fishbone template among its quality tools. For a Word or PowerPoint version, draw the spine and bones with shapes and lines, save it, and reuse it as your own template. Keep the category labels editable, since you will change them by problem.
Most teams get more from a physical wall and sticky notes for the first pass, then transcribe the result into a file for the record.
Common mistakes
- Vague problem statements. "Poor performance" produces a diagram of everything.
- Leaders only in the room. The people closest to the work know which causes are real.
- Stopping at the diagram. A fishbone is a means to an end. Without specific corrective actions, owners and deadlines, the analysis stays theoretical, as monday.com's guide also points out.
- Treating every twig as fact. Verify before you spend money.
- Blaming people. If a cause reads "operator error", ask what in the system made the error likely.
Our perspective: the diagram is the easy part
Most operations leaders we meet have already done a fishbone, or a version of it. They have a wall of sticky notes and a list of ten plausible causes. What they lack is the next step: someone owning each test, a weekly meeting where results are reviewed, and a scorecard that shows whether the fix held.
That gap is where strategy and floor-level execution part ways. We have run warehouse, home services, solar and consumer products operations, and the pattern repeats. A team finds a real cause, writes a good SOP, and six weeks later the shift has drifted back because nobody checks. The fishbone worked. The follow-through did not.
So we use the fishbone as an early step, not a deliverable. Build it with the people who do the work. Use data to pick the two or three branches that matter. Convert each into an action a floor manager can start on Monday, with a name and a date beside it. Then put a measure on it and review it weekly until the number moves and stays moved.
If your diagram has been on a wall for a month and nothing has changed, the problem is rarely the diagram. It is the cadence and accountability around it. Our piece on cross-functional alignment covers how to set that up.
— David
When you want an outside diagnostic
If you would rather not run this alone, our 90-Day Operations Audit is a fixed-price diagnostic at $3,500. It maps your people, processes and performance systems against your goals and turns the root causes into a prioritized action plan your team can execute. For a lighter start, a paid discovery call is $500. Details are on our main site.
FAQ
What is the difference between a fishbone diagram and an Ishikawa diagram?
Nothing. They are two names for the same tool, along with cause-and-effect diagram. It is named for Kaoru Ishikawa, and "fishbone" describes its shape.
How many categories should a fishbone diagram have?
Four to six is typical. The classic manufacturing set has six (the 6Ms), but ASQ encourages teams to rename or swap categories so they match the problem. Use fewer if the group is small or the problem is narrow.
Does a fishbone diagram find the root cause?
Not by itself. It organizes possible causes so you can test them. You still need data, observation or a trial to confirm which cause is real, and you may find more than one.
Should I use Five Whys or a fishbone?
Use a fishbone when the problem could have several unrelated causes, and Five Whys when you are following one chain. Together they work well: map first, then drill into the branches that data supports.
Sources
- ASQ: What is a Fishbone Diagram?
- ASQ: Quality Tools & Templates
- Kumah et al. (2024): Cause-and-Effect (Fishbone) Diagram, PMC
- CMS: How to Use the Fishbone Tool for Root Cause Analysis
- NHS Scotland Turas Learn: Cause and effect diagram
- AHRQ Digital Healthcare Research: Cause-and-Effect Diagram
- PRISM Risk Control: Root Cause Analysis
- Deckary: Fishbone Diagram Examples
- monday.com: Fishbone Diagram Template