Fishbone Diagram Template: The 6M Method Explained
A fishbone diagram template is a structured worksheet — usually a table with one column per cause category — that helps a team brainstorm every plausible cause of a problem before testing which one is real. It’s also called an Ishikawa or cause-and-effect diagram.
It organizes candidate causes under the 6M categories: Machine, Method, Material, Manpower, Measurement, and Mother Nature. Most teams don’t need a drawing tool to use one — a table works fine, and it’s what you can fill in during a meeting without anyone opening PowerPoint.
What is a fishbone diagram used for?
A fishbone diagram is used to brainstorm and organize possible causes of a defect, failure, or complaint before you commit to investigating one. The “head” of the fish is the problem statement; each “bone” is a category of cause; each item on a bone is a specific candidate cause someone on the team proposes.
The point isn’t the diagram itself — it’s forcing a team to look at all six categories instead of jumping straight to the first explanation someone raises. A maintenance tech will default to blaming the machine. An operator will default to blaming the procedure. The fishbone structure makes both groups look at material, measurement, and environment too, before anyone votes on what to investigate.
The tool traces back to Kaoru Ishikawa, a Japanese quality engineer who formalized it in the 1960s while working with quality circles at Kawasaki shipyards. It picked up the “fishbone” nickname because a filled-out diagram — a horizontal spine with angled category branches — looks like a fish skeleton. Both names describe the same worksheet; neither implies a different method.
The 6M fishbone diagram template
Copy this table into a document or your own tracker. Fill the “candidate causes” column during a team brainstorm — don’t filter yet, just capture everything plausible.
| Category | Prompt questions | Candidate causes |
|---|---|---|
| Machine | Has equipment changed, drifted, or been serviced recently? Is a tool, fixture, or setting out of spec? | (list here) |
| Method | Was the written procedure followed? Is the procedure itself ambiguous or outdated? Did a step get skipped under time pressure? | (list here) |
| Material | Did an incoming material lot change? Was material stored, handled, or aged differently than spec? Is a supplier certificate suspect? | (list here) |
| Manpower (People) | Was the operator trained and qualified on this exact step? Was there a shift change, fatigue, or unusual staffing that day? | (list here) |
| Measurement | Is the gauge or sensor calibrated? Is the sampling plan catching this failure mode at all, or only downstream? | (list here) |
| Mother Nature (Environment) | Did temperature, humidity, vibration, or contamination in the area change? Is the issue tied to time of day or season? | (list here) |
Service and office teams often relabel Machine as “Technology/Systems” and Material as “Inputs/Data,” and some add a seventh bone for Management or Milieu (culture). The structure — six-ish independent lenses on one problem — matters more than the exact labels.
Worked example: weld porosity on an aluminum assembly line
A line producing welded aluminum brackets starts failing X-ray inspection for porosity — small gas pockets trapped in the weld bead — at a rate of roughly 6% of parts, up from a baseline of under 1%. The team pulls together a quick fishbone session before deciding what to test.
| Category | Candidate causes raised by the team |
|---|---|
| Machine | Torch nozzle worn/damaged; wire feed speed drifting; new welding robot program parameters |
| Method | Travel speed increased to hit throughput target; joint fit-up tolerance not being checked before welding |
| Material | New aluminum coil lot from a second supplier; base metal not cleaned of oxide layer before welding |
| Manpower | Two new operators onboarded last month; reduced pre-weld inspection since headcount was cut |
| Measurement | X-ray inspection frequency unchanged, so detection isn’t the driver; gas flow meter on the welder overdue for calibration |
| Mother Nature | Line moved closer to a dock door two weeks ago; humidity in the shop up seasonally |
Six plausible causes, six categories, none obviously dominant from discussion alone. The team votes and ranks the top three: shielding gas flow/contamination, the new aluminum lot, and the dock-door draft.
They verify with data before touching anything else. Gas flow logs show flow rate is within spec, ruling that out on volume — but a technician traces the supply line and finds a loose fitting between the regulator and the torch, letting atmospheric nitrogen leak into the argon shielding gas intermittently. Porosity rate correlates almost exactly with shifts when that welder was in use. The new aluminum lot and the dock door are cleared: porosity is just as common on parts made from the old coil stock, and on days the dock door stayed closed.
Root cause: a contaminated shielding gas line from a loose regulator fitting, not the material change or the environment everyone initially suspected. The fix — replacing the fitting and adding a gas-line leak check to weekly PM — drops porosity back under 1% within a week.
This is the pattern a fishbone diagram is built for: several plausible causes across different categories, ambiguous until you check the data.
When does a fishbone diagram beat 5 Whys?
Both are cause tools, but they fit different shapes of problem.
| Situation | Better tool | Why |
|---|---|---|
| Multiple categories could plausibly be involved | Fishbone | Structures brainstorming across Machine/Method/Material/etc. so no category gets skipped |
| Team brainstorming session with several people | Fishbone | Gives everyone a lane (a bone) to contribute to, reducing groupthink around the loudest voice’s theory |
| One clear symptom with an apparent single thread | 5 Whys | Faster — a simple “why” chain gets to root cause without the overhead of a full diagram |
| Root cause already fairly obvious | 5 Whys | No need for a wide net when you’re confirming a known suspect |
| Cause is genuinely unknown and could be systemic | Fishbone, then possibly 5 Whys | Use fishbone to narrow the field, then 5 Whys to drill into the winning branch |
In practice, the two are often sequential rather than competing. Fishbone narrows six-plus candidates down to the two or three worth investigating; 5 Whys (or direct testing) confirms which one is the real root cause. If you want a walkthrough of the drill-down side, see our 5 Whys template.
How do you go from fishbone diagram to verified root cause?
A completed fishbone diagram is a list of hypotheses, not a conclusion. Three more steps turn it into an actual finding:
- Vote or rank. Have the team dot-vote or rank the candidate causes by how likely and how supported by initial evidence they seem. This narrows 15-20 raw ideas to the 2-4 worth spending investigation time on.
- Verify with data, not opinion. Pull the actual records — calibration logs, lot traceability, shift schedules, sensor data — for each top candidate. In the weld example, gas flow logs and lot-comparison data eliminated two of three finalists before anyone touched the equipment.
- Confirm by testing the fix. Once you land on a root cause, change only that variable and monitor the defect rate. If porosity doesn’t drop after fixing the gas line, you haven’t found the root cause yet — go back to the diagram.
Skipping straight from “the team likes this theory” to a corrective action is the most common failure mode with fishbone diagrams. The diagram organizes brainstorming; it doesn’t replace verification. For a structured way to track that verification step through to a documented finding, see our root cause analysis template.
If your defect data has a Pareto pattern — a handful of failure types driving most of the volume — running a Pareto chart first can help you pick which problem is worth a full fishbone session in the first place.
Filling out six categories by hand works, but it’s slow to keep organized across a long brainstorm. QualityManager.AI’s free AI-guided Fishbone tool builds the diagram interactively, suggests candidate causes per category based on your problem statement, and keeps the whole session in one place — try it at /signup before your next team RCA meeting.
What is the difference between a fishbone diagram and a cause and effect diagram?
None — “fishbone diagram,” “Ishikawa diagram,” and “cause and effect diagram” are three names for the identical tool: a problem statement at the head, with candidate causes branching off category bones. The 6M analysis (Machine, Method, Material, Manpower, Measurement, Mother Nature) is the most common way to structure those bones for manufacturing and physical-process problems.
Common mistakes when running a fishbone session
A few patterns show up repeatedly in teams new to the tool, and each one undercuts the diagram’s value.
- Stopping at the diagram. The most common mistake, covered above: treating a plausible-looking cause as confirmed just because it made it onto the chart and got votes. A fishbone diagram narrows candidates; it doesn’t verify them.
- One person filling it out alone. The tool is designed for a room of people with different vantage points — operators, maintenance, quality, and engineering each notice different candidate causes. A single person filling in all six bones from their own desk reproduces the same blind spot the tool exists to avoid.
- Overloading one bone. If Method has eleven items and every other bone has one, the team is anchoring on a favorite theory instead of brainstorming broadly. Rebalance by asking each category’s prompt questions explicitly before moving on.
- Treating every candidate cause equally. Not every item on the chart deserves the same investigation budget. Rank first, then spend verification effort on the top two or three — chasing all fifteen candidates with equal rigor is slower than it looks and rarely necessary.
Frequently asked questions
What are the 6 Ms in a fishbone diagram?
The 6 Ms are Machine, Method, Material, Manpower (People), Measurement, and Mother Nature (Environment). Each is a category of potential cause. Not every problem needs all six — service and office processes often drop Machine and Material and add Milieu or Management instead.
Fishbone diagram vs 5 Whys: which should I use?
Use 5 Whys for a single, fairly linear failure with one obvious starting point. Use a fishbone diagram when several categories of cause could plausibly be involved, or when you're brainstorming with a cross-functional team and need structure to avoid tunnel vision on one theory.
How many causes should go on each bone?
Three to six candidate causes per category is typical. Fewer than that and you probably haven't brainstormed hard enough; more than eight or ten per bone usually means causes are too granular or overlapping and should be grouped.
Is the fishbone diagram only for manufacturing?
No. It originated in manufacturing (Kaoru Ishikawa, Kawasaki shipyards) but works for any process with multiple contributing factors — software incident reviews, hospital patient-safety events, customer complaint patterns, and back-office errors all fit the same 6M structure with categories relabeled as needed.
What's the difference between a fishbone diagram and an Ishikawa diagram?
Nothing — they're the same tool. It's called a fishbone diagram because the finished chart looks like a fish skeleton, and an Ishikawa diagram after Kaoru Ishikawa, the Japanese quality engineer who formalized it in the 1960s.