What Is a Fishbone Diagram?

A Fishbone Diagram is a visual problem-solving tool used to organize and investigate the possible causes of a problem. Its structure resembles a fish skeleton: the problem we want to investigate is placed at the head, while different groups of possible causes are distributed along the bones.

The tool is also widely known as the Ishikawa Diagram, after Kaoru Ishikawa, and as a Cause and Effect Diagram because its purpose is to connect an observed effect — the problem — with the factors that may be contributing to it.

One of its greatest advantages, in my opinion, is that it forces us to look at the problem from a more systemic perspective. Instead of quickly choosing the explanation that seems most obvious, we open several lines of investigation and start asking which processes, people, tools, information, methods, or environmental conditions may be influencing the result.

This is particularly useful in projects because an important problem rarely has only one isolated cause. A delay may be related to inaccurate estimates, lack of experience, external dependencies, poorly written tasks, excessive work in progress, missing automation, or several of these factors at the same time.

What Is a Fishbone Diagram Used For?

A Fishbone Diagram can be used whenever we need to understand why a particular result is occurring. In project environments, it can help investigate delivery delays, cost overruns, quality issues, rework, recurring bugs, low productivity, conflicts between teams, process failures, and many other situations in which the actual outcome differs from what we expected.

No matter how much we plan a project, something that was not mapped in advance will eventually appear. When these issues are not properly understood, they can lead to delayed deliveries, postponed product launches, problems with stakeholders, teams under pressure, higher costs, and, in more serious situations, decisions that directly affect people and budgets.

The important point is that fixing the effect does not necessarily fix the cause. If tasks are delayed because the team cannot estimate them properly, putting more pressure on developers does not solve the underlying problem. If the issue comes from poorly managed dependencies, adding another person to the team may not solve anything either. A Fishbone Diagram helps us explore these possibilities before deciding what action to take.

Fishbone Diagram, Ishikawa Diagram, or Cause and Effect Diagram?

These three names generally refer to the same tool. Fishbone Diagram describes its visual shape, Ishikawa Diagram refers to the technique’s creator, and Cause and Effect Diagram describes what the tool is designed to analyze.

Regardless of the name, the logic remains the same: we begin with an effect that needs to be understood and organize possible causes into categories. This helps us stop treating the problem as one single block and instead view it as a system influenced by multiple factors.

What Are the 6Ms of a Fishbone Diagram?

One of the best-known ways to organize causes inside a Fishbone Diagram is through the 6Ms. These categories give us a structure for looking at the same problem from different perspectives instead of concentrating the entire analysis on one area.

• Machine: equipment, tools, systems, infrastructure, and technologies being used.
• Method: processes, procedures, rules, practices, and instructions used to perform the work.
• Material: raw materials, components, documentation, information, requirements, or other inputs needed for the work.
• Mother Nature / Environment: physical environment, organizational environment, culture, or external conditions affecting the work.
• Measurement: metrics, inspections, monitoring systems, indicators, and controls used to evaluate results.
• Manpower: people, skills, experience, capacity, training, and availability.

The 6Ms originated in a context strongly connected to quality and manufacturing, but the logic can be adapted very well to technology projects. “Machine,” for example, may represent infrastructure, development environments, CI/CD pipelines, or tools. “Material” may represent documentation, requirements, APIs, reusable components, or any information needed to perform the work.

We also do not need to fill every category. If there is no relevant cause related to Measurement, for example, we should not invent one just to complete the diagram. The purpose of the tool is to improve our investigation, not to fill in a template.

How to Create a Fishbone Diagram Step by Step

The first step is to define clearly which problem we want to investigate. This may sound obvious, but many root cause analyses start badly because the original problem was described too broadly.

“The project is going badly” is not specific enough. “User stories delivered by Team X have an average delay rate of approximately 20%” already gives us a much better starting point.

Once the problem is defined, we place it at the head of the fish. Then we create the categories we want to use — the 6Ms or another classification that better fits our context — and begin adding possible causes to each one.

At this stage, I try not to jump to a solution too quickly. First, I want to broaden the investigation. I can talk to the team, analyze historical data, review processes, investigate dependencies, and formulate hypotheses. Only after that do we start eliminating explanations that are not supported by evidence and investigate the most likely causes in greater depth.

Fishbone Diagram Example for a Project

Let’s imagine a very common problem: “All our tasks are delayed.” If I immediately conclude that the cause is low team productivity, I have already jumped from the problem to a conclusion. The Fishbone Diagram forces me to open the investigation instead.

Using the 6Ms, we can start with several hypotheses. Under Machine, we might identify a lack of DevOps automation for deployments to staging and production. Under Method, refinements may not be considering the developers’ actual experience. Under Material, our components might not be reusable. Under Manpower, there may be too many junior developers or no dedicated DevOps professional.

Notice that we do not need to identify something under every M. The same cause may also appear in more than one category. Lack of team experience, for example, may belong under Manpower but also affect Method. The absence of a DevOps professional may appear under both Manpower and Machine because it also affects infrastructure and automation.

When the same cause appears repeatedly in different parts of the analysis, I usually pay special attention to it. This does not automatically prove that we have identified the root cause, but it is often a strong signal that this area deserves deeper investigation.

How to Find the Root Cause of a Problem

The Fishbone Diagram helps us organize possible causes, but a proper root cause analysis should not end when the diagram is complete. The next step is to validate which hypotheses actually explain the problem.

If we believe that tasks are delayed because the team lacks experience, we need evidence. Are junior professionals really taking longer to complete tasks? Which types of activities show the greatest difference between estimated and actual duration? Are delays concentrated in a specific area? Is there a relationship with bugs, rework, or poorly defined activities?

If our hypothesis is that refinement quality is poor, we can look at how many tasks begin without estimates, how many are re-estimated after work has started, how many have insufficient descriptions, and how much rework appears during execution.

This is where we move from having an opinion to building an analysis supported by facts.

How to Use the 5 Whys for Root Cause Analysis

The 5 Whys technique is one of the simplest ways to investigate a cause that appears during a Fishbone Analysis. The idea is to continue asking “why?” until we reach a more fundamental explanation for what is happening.

Despite the name, there is no rule requiring exactly five questions. We may reach the root cause on the third question or need seven. The goal is not to reach a specific number but to continue while the answers are still describing symptoms or consequences.

Consider this example:

- Why don’t we have access to the production machines?
- Because the security team did not provide access.
- Why did the security team not provide access?
- Because only the security team is allowed to access production.
- Why is only the security team allowed to access production?

And here we may arrive at the answer everyone knows but nobody wants to say:

Because the CTO required it.

This example also highlights one limitation of any root cause analysis technique: we need transparency. If people avoid certain answers because the problem involves internal politics, hierarchy, or fear, we can build a perfect Fishbone Diagram and still reach the wrong conclusion.

How to Do the 5 Whys Exercise

One practice I find particularly useful is to build each new question directly from the previous answer. This creates traceability and helps prevent the investigation from jumping between unrelated hypotheses.

We might start by asking: “Why are the tasks delayed?” The answer could be: “Because the developers are estimating them incorrectly.” The next question should then use that answer directly: “Why are the developers estimating the tasks incorrectly?”

We may discover a lack of experience, poor refinement, incomplete requirements, or an inappropriate estimation technique. Each answer produces the next question until we reach a point where we can identify an action capable of addressing the underlying problem.

The Fishbone Diagram and 5 Whys work particularly well together. The Fishbone Diagram expands the investigation and organizes possibilities. The 5 Whys allows us to go deeper into one of those possibilities.

Fishbone Diagram vs. 5 Whys: When Should You Use Each?

I do not consider these techniques competitors. They solve different parts of the same investigation. When we still do not know where a problem may be coming from, the Fishbone Diagram is especially useful because it broadens our view and organizes different families of causes.

When we already have a likely cause and want to understand what exists behind it, the 5 Whys may be more efficient. I often start with a Fishbone Diagram and then apply the 5 Whys to one or more causes that appear especially relevant.

In our delayed-task example, we might identify “inaccurate estimates” in the Fishbone Diagram and then use the 5 Whys to understand why estimates are inaccurate. We could do the same with “lack of automation,” “lack of experience,” or any other potential cause.

Root Cause Analysis Tools: Hypotheses and Scenario Analysis

Before we confirm a cause, we are usually working with hypotheses. To formulate useful hypotheses, we need to understand the problem, its context, the people involved, the related processes, and the difference between the expected result and what actually happened.

A good hypothesis should be something we can investigate. Saying that “the team is not committed” is too abstract. Saying that “the increase in concurrent tasks is increasing average delivery time” creates a hypothesis that can actually be tested.

Scenario analysis can also help us understand how certain causes may evolve. Imagine that a tech leader is overloaded and asks for a salary increase. The issue may simply be compensation, but it may also involve excessive responsibility, knowledge concentration, or the absence of other people capable of taking over those responsibilities.

If that person leaves the company, we may lose knowledge, redistribute work unexpectedly, create dissatisfaction among other team members, and generate new delays. Building different scenarios helps us understand not only the current problem but also the risk of doing nothing.

When this investigation involves people with significant power or influence over the project, stakeholder analysis can also become important. I discuss this in: Stakeholder Mapping: How to Identify, Analyze, and Manage Project Stakeholders .

Define the Problem Before Looking for the Root Cause

There is one mistake that can compromise the entire investigation: trying to find the root cause of a problem that was never clearly defined. If our initial definition is wrong, we can spend hours investigating the causes of something that does not actually represent the real problem.

This is where I like to use a problem statement. A problem statement is a clear declaration of what we are trying to solve. It describes what is happening, who is affected, why the problem matters, how large the impact is, and what result we want to achieve.

The more we can quantify it, the better. Instead of saying “our deliveries are frequently delayed,” we can write something like:

“The delay rate for user story deliveries in Team X is approximately 20%, generating around one month of delay every six months, US$100,000 in additional costs per semester, and dissatisfaction among the end customer, CTO, CEO, and finance team. The main causes identified are lack of team experience and inaccurate estimates. How can we reduce these delays to 5% within three months?”

Now we have a much more concrete problem. We know how to measure improvement, understand who is being affected, and can connect potential solutions with the causes identified during the investigation.

How to Use Project Data to Validate Root Causes

There is an important difference between a possible cause and a cause supported by evidence. Technology projects generate a huge amount of data while work is being performed. Jira, Azure DevOps, Asana, Monday.com, and ClickUp already record tasks, estimates, assignees, statuses, sprints, dates, work types, and many other signals that can support root cause analysis.

This is exactly where Saint Jude Project Intelligence can support the investigation. Instead of relying only on the manager’s perception, we can analyze patterns in delays, inaccurate estimates, team performance, costs, task quality, bugs, sprint deviations, and risks.

Returning to our example — “all tasks are delayed” — we can break the analysis down by area, seniority, role, task type, tag, cost, planned hours, consumed hours, or sprint performance. We may discover that the problem does not affect the entire team but only a particular type of work. We may also find that delays are concentrated in tasks without estimates or within a specific seniority level.

This does not replace the Fishbone Diagram, the 5 Whys, or the manager’s analysis. On the contrary: data makes these root cause analysis tools stronger because it helps us confirm or reject our hypotheses.

The same logic applies to productivity. If our investigation suggests that capacity or team performance may be part of the problem, I also recommend: Productivity Metrics for Software Teams: KPIs to Measure and Improve Developer Performance .

And when delays seem to be related to dependencies and to the impact of specific activities on the final delivery date, it may also be useful to read: Critical Path in Project Management: How to Identify Dependencies That Can Delay Your Project .

Finding the Root Cause Is Only the Beginning

The Fishbone Diagram helps us organize possible causes. The 6Ms provide a structure for exploring the problem from different perspectives. The 5 Whys helps us go deeper into a specific line of investigation. Hypothesis formulation and scenario analysis expand our understanding, while a good problem statement turns what we discovered into something clear and measurable.

But none of these tools should be used just to create a nice diagram or complete a worksheet. The objective is to move away from a discussion based on symptoms and arrive at an explanation strong enough to support a decision.

If my tasks are delayed, I do not want to know only how many are delayed. I want to understand why they are delayed. If my costs increased, I do not want to simply cut expenses; I want to discover what is consuming more money than expected. If productivity dropped, I want to understand what changed in the system before concluding that people are simply working less.

Once we understand the root cause, we can finally move on to solutions. I discuss that next step in: How to Find the Right Solutions for Your Product Problems .

In the end, perhaps this is the most important contribution of a Fishbone Diagram: it forces us to stop asking only “How do we solve this?” and start with a much more important question:

“Why is this happening?”

See you soon!

Erik Scaranello