The Ishikawa Diagram is a visual problem-solving tool. It is named after Kaoru Ishikawa and is also known as a fishbone diagram because the finished diagram looks like a fish skeleton.
- The problem (or effect) is written at the head of the fish.
- The main branches show broad cause categories.
- Smaller branches show specific possible causes.
This structure helps a team move from a general complaint, such as “reports are often late”, to clearer areas to investigate, such as unclear deadlines, missing data, system access, workload or training.
The main value of the tool is that it slows decision-making down. In the workplace, people often jump from problem to solution. For example, if a dashboard contains incorrect figures, the first reaction might be to blame the person who entered the data. A fishbone diagram encourages the team to look wider:
- Was the process clear?
- Was the system difficult to use?
- Were checks missing?
- Was the deadline unrealistic?
- Were people trained properly?
Wong, Woo and Woo (2016) describe the Ishikawa Diagram as a structured way to identify and organise potential causes. For learners, the important point is simple: better decisions usually come from exploring the problem before choosing the fix.
A common starting point is the 6Ms: Methods, Machines, Materials, People, Measurement and Environment (ASQ, n.d.). These categories can be changed to fit the workplace. In an office or service setting, a team might use people, process, technology, information, customers and environment. In a digital and data-driven setting, the categories might include data source, system, user behaviour, process, reporting rules and quality checks. The categories are not the answer; they are prompts to help people think more fully.
The diagram supports decision-making because it separates symptoms from possible root causes. A symptom is what people can see, such as repeated customer complaints. A root cause is the deeper reason that allows the issue to keep happening. Ilie and Ciocoiu (2010) explain that the fishbone diagram can be used to group the causes of different organisational problems, not only quality problems. This makes it useful for risk, service improvement and process review. However, a listed cause should not be treated as true until it has been checked. The team should use evidence such as data, observations, customer feedback, audit findings, system reports or examples from real work.
This evidence-based approach is important when decisions affect people, performance or customers. Carvalho et al. (2021) used an Ishikawa Diagram to organise root causes affecting hospital administrative data quality. Their work shows how the tool can help teams connect data problems to wider issues such as process design, staff knowledge and systems. In another case, Oo and Sukhotu (2023) used a fishbone diagram with observation and warehouse data to identify causes of delays in order picking. These examples show that the tool is strongest when it is used with real evidence, not just opinions.
Once the team has mapped possible causes, the next step is prioritisation. A fishbone diagram can create a long list, but not every cause will have the same impact. Teams should agree which causes are most likely, most serious or easiest to test. They might use simple scoring, the 5 Whys, a Pareto chart or further data analysis. Improvement Cymru Academy (n.d.) advises teams to agree which causes need further investigation and to use data to understand the problem. This prevents the diagram from becoming a one-off brainstorming activity.
The Ishikawa Diagram also improves collaboration. It gives people a shared view of the problem and encourages contributions from colleagues who understand different parts of the work. For example, an administrator, team leader, data analyst and customer adviser may all see different causes of the same issue. Bringing those views together can reduce blame and improve ownership. The facilitator should keep the discussion focused, ask for evidence and make sure quieter voices are included.
The tool does have limitations. It does not prove cause and effect by itself. It can become messy if the problem is too broad. It can also reflect bias if only one person or one team contributes. For this reason, the problem statement should be specific and measurable, such as “15% of weekly reports were submitted after the deadline in May”, rather than “reporting is poor”. The diagram should then be reviewed as new information is collected.
Used well, the Ishikawa Diagram helps learners make more thoughtful decisions. It turns a problem into categories, categories into possible causes, and possible causes into evidence-based actions. In a digital and data-driven world, this matters because decisions should not rely only on instinct or opinion. They should be based on clear problem definition, shared insight, reliable data and practical action.
Action Point
Choose one current workplace issue, such as delays, errors, missing data, or repeated queries. Write a clear problem statement, create a simple fishbone diagram and list possible causes under relevant categories. Then choose two causes to check with evidence before suggesting an action. Do not move straight to a solution until you have tested the likely causes.