How to Create a Fishbone Diagram: Step-by-Step Guide (2026)

Q: How long does it take to create a fishbone diagram?

A complete fishbone session typically takes 45 to 90 minutes with a team. This includes problem definition (10 min), category selection (5 min), brainstorming (20 40 min), voting on root causes (10 min), and planning corrective actions (10 15 min). Simpler problems or smaller teams can finish in 30 minutes.

Q: How many people should participate in a fishbone diagram session?

The ideal group is 4 to 8 people. Fewer than 4 limits perspective diversity. More than 8 makes it hard for everyone to contribute effectively. Include people from different roles and departments who have direct knowledge of the problem.

Q: What is the difference between a cause and a sub-cause?

A main cause sits directly on a primary bone (branch) of the diagram. A sub-cause explains why that main cause exists and branches off the main bone. For example, "Machine downtime" is a main cause. "Preventive maintenance not followed" is a sub-cause. "No automated maintenance reminders" is a sub-sub-cause.

Q: Can I create a fishbone diagram by myself?

Yes. A solo fishbone still helps you think more systematically about causes. However, a cross-functional team reveals causes that one person would miss. If working alone, try to represent multiple viewpoints by considering what someone from operations, quality, engineering, and management would say.

Q: What should I do after completing a fishbone diagram?

Validate the top candidates with data. Run a 5 Whys analysis on the top 2 3 causes to drill deeper. Create a corrective action plan with owners, deadlines, and success metrics. Schedule a follow-up review in 2 4 weeks to verify the problem is resolved.

A fishbone diagram (also called an Ishikawa or cause-and-effect diagram) is one of the most effective tools for structured brainstorming during root cause analysis. This guide walks you through seven steps to create one from scratch — with tips, common mistakes, and examples at each stage.

By the end, you will have a completed fishbone diagram that maps all potential causes of your problem and highlights the most likely root causes for further investigation. Whether you are working on a whiteboard, a spreadsheet, or a digital tool, the process is the same.

The 7 steps at a glance

Define the problem or effect clearly
Draw the spine and effect box
Choose your category framework (6M, 6P, or custom)
Brainstorm causes for each category
Add sub-causes for deeper analysis
Identify the most likely root causes
Plan corrective actions

Total time: 45–90 minutes with a team of 4–8 people. Let us walk through each step in detail.

Step 1: Define the problem or effect clearly

1 Write a specific, measurable problem statement

The problem statement becomes the "head" of your fish. It must be specific enough that everyone on the team agrees on what you are analyzing. Include what is happening, where, when, and how much it deviates from the target.

Good problem statements:

"Assembly line defect rate increased from 1.2% to 4.8% over 8 weeks"
"Customer onboarding takes 32 days (target: 14 days)"
"Monthly churn rate rose to 5.1% vs. 2.8% industry average"

Poor problem statements:

"Quality is bad" — too vague
"John keeps making mistakes" — blames a person
"Everything is slow" — not measurable

Tip: Use the format "[Metric] is [current value] vs. [target/expected value] since [time period]." This forces specificity and gives the team a shared understanding of the gap.

Common mistake: Including a presumed cause in the problem statement. "Defect rate is high because of bad materials" already assumes the answer. State the effect only, not the cause.

Step 2: Draw the spine and effect box

2 Create the backbone of your diagram

Draw a horizontal arrow pointing right. At the right end, draw a box containing your problem statement. This arrow is the "spine" of the fish, and the box is its "head."

┌─────────────────────┐ ════════════════════════════════════════════════> │ Defect rate 4.8% │ │ (target < 1.5%) │ └─────────────────────┘

On a whiteboard, use the full width of the board. In a digital tool, make sure there is plenty of space above and below the spine for branches. The diagram will grow significantly as you add causes.

Tip: If working on a physical whiteboard, use sticky notes for causes instead of writing directly. This makes it easy to move causes between categories as the brainstorming evolves.

Step 3: Choose your category framework

3 Select 4–6 categories for your main branches

The categories are the main "bones" angling off the spine. They represent broad areas where causes might originate. Your choice of framework determines which perspectives the team will explore.

Framework	Categories	Best for
6M	Man, Machine, Method, Material, Measurement, Mother Nature	Manufacturing, production, quality
6P	People, Process, Policy, Place, Procedure, Technology	Services, IT, healthcare
Custom	You define 4–6 categories	Business outcomes, cross-functional issues

For detailed guidance on choosing the right framework, see our fishbone diagram template guide, which includes a decision flowchart and examples for each framework.

Man Machine Method | / | / | / ═════════*════════════════════════════> [Defect rate 4.8%] / | / | / | Material Measurement Mother Nature

Common mistake: Using categories that overlap. If your team keeps debating whether a cause belongs under "Process" or "Procedure," merge them into one category. Overlapping categories waste time and create confusion.

Step 4: Brainstorm causes for each category

4 Generate 3–5 potential causes per branch

This is the core of the exercise. Go category by category and ask the team: "What factors in [this category] could contribute to [the problem]?" Write every idea on the diagram without filtering or judging.

Brainstorming techniques that work well:

Round-robin: Go around the room. Each person states one cause per turn. Skip if you have nothing. Ensures equal participation.
Silent brainstorming: Everyone writes causes on sticky notes for 5 minutes before sharing. Prevents groupthink and anchoring bias.
Data-driven prompts: Before the session, gather relevant data (error logs, customer complaints, metrics trends) and use them to prompt discussion.
Category rotation: Assign each person to start with a different category. After 3 minutes, rotate. Fresh eyes on each branch spark new ideas.

Tip: Set a timer. Spend no more than 5–7 minutes per category. If a category generates fewer than 2 causes, that is a signal it may not be the right category for this problem. If it generates more than 7, consider splitting it into two branches.

Common mistake: Filtering ideas during brainstorming. Comments like "that's not a real cause" or "we already checked that" shut down participation. Capture everything first. Filter later.

Skip the drawing — use our free online tool

Our fishbone diagram tool guides you through each step with pre-built category frameworks and real-time collaboration.

Start Free Fishbone Diagram →

Step 5: Add sub-causes for deeper analysis

5 Ask "why?" for each main cause

For each cause on the diagram, ask: "Why does this happen?" The answers become sub-cause branches. This second level of detail is where the real root causes often hide.

Example: Under the "Machine" category, a main cause is "CNC press calibration drift." Ask why:

Why? — Preventive maintenance was skipped last month
Why? — Maintenance technician was reassigned to cover a vacancy
Why? — No backup technician was trained

Notice how this sub-cause drilling is essentially a mini 5 Whys analysis on one branch of the fishbone. This is exactly how the two methods complement each other.

Tip: You do not need sub-causes for every single cause. Focus on the ones the team considers most likely or most impactful. Going two levels deep on 5–8 key causes is more valuable than going one level deep on 30 causes.

Step 6: Identify the most likely root causes

6 Narrow down from brainstormed list to top candidates

With all causes mapped, the team needs to identify which ones are most likely to be the actual root causes. This is where you shift from divergent thinking (brainstorming) to convergent thinking (prioritizing).

Prioritization techniques:

Dot voting: Give each team member 3–5 adhesive dots. They place dots next to the causes they believe are most likely. The causes with the most dots become your top candidates.
Impact/likelihood matrix: Rate each cause on two scales: how likely it is to be a contributor, and how large its impact would be. Focus on high-likelihood, high-impact causes first.
Data validation: Check existing data (logs, metrics, records) against the brainstormed causes. Which causes have evidence supporting them?

Aim to identify 2–3 top candidates. More than that dilutes investigation effort. Fewer than two risks missing the real cause.

Common mistake: Stopping at the fishbone without validating. The diagram identifies possible causes, not confirmed ones. You still need to verify your top candidates with data, experiments, or a deeper 5 Whys analysis.

Step 7: Plan corrective actions

7 Turn root causes into actionable fixes

For each confirmed root cause, define a corrective action. Every action needs four elements: what will be done, who owns it, when it must be completed, and how you will measure success.

Root Cause	Corrective Action	Owner	Deadline	Success Metric
Work instructions not updated after ECO	Link ECO system to document control; auto-flag outdated SOPs	Quality Mgr	Apr 15	100% SOPs updated within 48h of ECO
Go/no-go gauge tolerance too wide	Recalibrate to new spec; add to weekly calibration check	Metrology Lead	Apr 1	Defect rate < 1.5%

Schedule a verification review 2–4 weeks after implementing corrective actions. Check whether the problem has improved. If it has not, revisit the fishbone diagram and investigate other branches.

Tip: Corrective actions should target processes and systems, not people. Instead of "retrain John," define "update training program to include spec rev. 4.2 and add competency verification test." Systems fixes last; people fixes fade.

Putting it all together: complete example

Let us walk through a complete fishbone diagram for an IT incident.

Problem: API response times exceeded 2 seconds for 35% of requests last week (SLA: 99% under 500ms).

Categories chosen: People, Process, Technology, Environment, Measurement (custom 5-category framework)

Category	Causes	Sub-causes
People	New engineer deployed without review	No pair programming policy; reviewer on PTO
Process	No load testing before deploy	Load test environment decommissioned 2 months ago; no one noticed
Technology	Database query missing index	ORM auto-generated query bypassed indexing; no slow-query monitoring
Environment	Traffic spike from marketing campaign	Marketing did not notify engineering; no capacity planning for campaigns
Measurement	Alerting threshold set to 5s, not 500ms	Threshold never updated after SLA change; alert config not in version control

Top candidates after voting: (1) Database query missing index, (2) No load testing before deploy

Verified root cause: The ORM auto-generated a query that performed a full table scan on a 12-million-row table. Without load testing and with the alerting threshold at 5s, the problem went undetected for 3 days.

Corrective actions: Added the missing index (immediate fix). Implemented mandatory slow-query log review in CI pipeline. Restored the load test environment and added it to the deploy checklist. Updated alerting thresholds to match SLA. Added alert configuration to version control.

Frequently asked questions

How long does it take to create a fishbone diagram?

A complete fishbone session typically takes 45 to 90 minutes with a team. This includes problem definition (10 min), category selection (5 min), brainstorming (20–40 min), voting on root causes (10 min), and planning corrective actions (10–15 min). Simpler problems or smaller teams can finish in 30 minutes.

How many people should participate in a fishbone diagram session?

The ideal group is 4 to 8 people. Fewer than 4 limits perspective diversity. More than 8 makes it hard for everyone to contribute effectively. Include people from different roles and departments who have direct knowledge of the problem.

What is the difference between a cause and a sub-cause?

A main cause sits directly on a primary bone (branch) of the diagram. A sub-cause explains why that main cause exists and branches off the main bone. For example, "Machine downtime" is a main cause. "Preventive maintenance not followed" is a sub-cause. "No automated maintenance reminders" is a sub-sub-cause.

Can I create a fishbone diagram by myself?