Established model
The Ishikawa diagram
Kaoru Ishikawa · 1968
Also known as Fishbone diagram, Cause-and-effect diagram
Work backwards from an observed problem through the categories of cause that could produce it.
Its place in the frameworkData Core›Performance Analysis
What it does
Branches for the standard families — people, method, machine, material, measurement, environment — each expanded until the causes are specific enough to test. Its value is coverage under pressure: a group looking for a cause converges on the first plausible one within minutes, and the categories force the other five to be considered.
- Reach for it when
- When performance has moved and the explanation was agreed on before anyone looked.
- Where it stops
- It generates candidate causes; it does not weigh them. Every branch is a hypothesis and the diagram gives no way to tell which one is true.
Kaoru Ishikawa, Guide to Quality Control, JUSE, 1968.
Why it sits at Performance Analysis
Turning numbers into understanding: starting from a question, choosing a method that can answer it, reading the result honestly, and doing something.
A model is only useful when you reach for it at the right moment. This one answers a question that arises here — so it is filed here, and nowhere else. These are the working areas it serves:
- The questionDecision-analysis practice on defining the decision before the data, and on the value of information as the test of whether analysis is worth doing.
- MethodThe distinction between observational and experimental design, and the conditions under which observational data supports a causal claim.
- Reading the resultWork on confounding, selection effects and the base-rate problems that make plausible business findings wrong.
- Acting on itEvidence-based management on the gap between findings and practice, and the closure of the loop from analysis to measured outcome.
What it touches elsewhere
Nothing in a business is decided on its own. A conclusion reached with this model at Performance Analysis lands in these other cores, whether or not anyone follows it there.
- KPI managementAnalysis usually starts because a measure moved, and the definition of that measure constrains what can be concluded.
- ReportingReporting says what happened; analysis says why, and the two are frequently confused.
- Goal CoreThe decision an analysis informs is usually about whether a goal is achievable or has been achieved.
- Market CoreAttribution and incrementality are analysis problems, and they are where causal claims most often exceed the evidence.
Filed at the same place
These answer questions that arise at Performance Analysis too. Where they disagree with this one, the disagreement is the useful part.
- A/B testing and controlled experimentsRandomised assignment is the only method that separates what your change caused from what would have happened anyway.
- Cohort analysisGroup people by when they arrived, then follow each group separately instead of averaging them together.
Elsewhere in Data Core
These are other people’s models, named here so you can go to the source and use them properly. The Omnigoal is not affiliated with their authors and is not endorsed by them; nothing of theirs is reproduced here — no canvas, no diagram, no wording. Each is described in our own words, with the originator credited, because the framework is a place to put thinking, not a replacement for the people who did it. Model names and trademarks belong to their respective owners and are used here only to refer to the work itself.
All 125 models