Root Cause Analysis Series: Fixing Corporate Website Delays with the Fishbone Diagram

What the Fishbone Diagram is and where it came from

The Fishbone Diagram helps a team identify causes of a problem in a structured way. It shows the relationships between the factors that may have led to the issue through a layout that resembles a fish skeleton. The head represents the main problem, and the bones branch off into categories of contributing factors such as People, Process, Technology, Data, Environment, and Management.

The tool was created by Kaoru Ishikawa, a Japanese academic and engineer, around 1968. It originated in quality control at Kawasaki Steel and became a foundational tool of the Japanese quality management movement before spreading worldwide into project management, process improvement, and digital product delivery.

Building a corporate website typically requires coordination across many groups, including Marketing, Corporate Communications, Investor Relations, and IT. When that coordination is not managed deliberately, delays in providing information or feedback show up in every milestone and quietly drain the project's time and budget. That is exactly the shape of problem the Fishbone Diagram is built for.

How the Fishbone Diagram works (with a corporate website example)

Step 1: Define the problem

The problem is: "Corporate website delivery keeps slipping because information and feedback are not delivered on time."

Write this statement at the head of the fish. Make it observable and measurable, ideally with a number, like "delivery is six weeks behind the original timeline".

Step 2: Identify the main cause categories

The classic industrial 6M (Man, Machine, Method, Material, Measurement, Environment) was designed for factories and does not map cleanly onto a digital project. Adapting the categories is part of the work. For this case, the chosen categories are People, Process, Communication, and Management.

Step 3: Map sub-factors under each category

People: Subject-matter contributors do not have time to provide content because their primary roles take priority, and no team has a clearly named owner for the website effort.

Process: There is no shared master timeline that every team has acknowledged and committed to. Approval workflows are layered and redundant, so each review round adds days.

Communication: Information is spread across email, chat, and meetings with no single source of truth. There is no central place to see the status of every outstanding piece of feedback.

Management: There is no Project Owner with the authority to drive the work across teams, and progress check-ins happen irregularly rather than on a fixed cadence.

Step 4: Synthesize shared causes and identify roots

Looking at all categories together, two roots stand out. There is no centralized Project Ownership, and there is no structured communication and tracking system. These two roots feed each other, which is why the delays repeat at every milestone instead of being a one-off. This synthesis step is the heart of the Fishbone Diagram. Skip it and the team walks away with a tidy picture and no insight.

Step 5: Propose targeted fixes

Root: Lack of Project Ownership

Assign a Project Owner from a function with cross-team authority and the mandate to escalate when any team misses an agreed deadline.

Root: Lack of Structured Communication and Tracking

Designate a single communication channel for the project, schedule review checkpoints on the calendar from day one, and use a centralized feedback tracker that every team can see in one place.

Common pitfalls

Four mistakes show up again and again, and each one drains the value of the exercise.

Using the default 6M categories on a digital project. The Machine and Material bones rarely apply to software work, leaving entire bones empty while dimensions like Communication never get a slot. Adapt the categories to the shape of the problem before the team starts filling them in.

Listing symptoms instead of causes on the bones. Writing "delivery is late" on a bone just restates the head of the fish. The bones should hold the factors that produce that symptom. Quick test, if a bone could double as the head of a different fish, it belongs one layer deeper.

Stopping at the diagram. The Fishbone is a brainstorming structure, not the answer. Block fifteen minutes after the brainstorm specifically for synthesis, asking which roots multiple bones point toward together. Without that pass, the team walks away with a picture and no plan.

Letting one team avoid scrutiny. If a function is under political pressure, the team will quietly skip bones that point at it. The diagram looks balanced but the analysis is biased. Set the expectation upfront that Fishbone is about systems, not blame.

Compared to other tools in the RCA Series

In SUFFIX's RCA toolkit, Problem-Analysis (the 4-axis framework) is the gateway. It classifies the problem by clarity of symptom, scope, urgency, and ownership before you pick a tool. Fact-Based Thinking, drawn from McKinsey practice, sharpens the problem statement so the analysis starts on solid ground.

5 Whys drills deep into a single causal chain by repeatedly asking "why". Pick it when the team has a working hypothesis and wants disciplined depth. Fault Tree Analysis (FTA) uses AND/OR logic to show which factors must occur together and which act alone, useful when the relationships between causes determine where to intervene.

FMEA is the proactive option, scoring failure modes by Severity, Occurrence, and Detection and ranking them by Risk Priority Number. Change Analysis fits when there is a clear before-and-after moment. Barrier Analysis maps which defensive layers held and which broke. Parent Cause and Management Oversight zoom out to the organizational layer, where ownership models and reporting structures shape why problems repeat.

The Fishbone Diagram is the right call when you need broad coverage of every dimension at once, with multiple functions in the room. The category structure makes sure no angle gets missed, and gives every team an equal voice. That equal-voice property is why it works so well for cross-functional disagreements.

When NOT to use the Fishbone Diagram

Fishbone is the wrong shape in three situations.

When the problem has a single clear causal chain, Fishbone adds overhead without insight. You end up with several empty bones and one that does all the work. 5 Whys is faster and cleaner.

When the goal is to evaluate risks before they happen, Fishbone is reactive by design. It maps causes of an existing problem, not potential failure modes of a future one. FMEA is the right tool for proactive risk ranking.

When the analysis needs to make explicit which factors must combine and which act alone, the Fishbone's category structure obscures that logic. FTA's AND/OR gates show those relationships directly.

There is also a softer limit. Fishbone sessions are facilitator-heavy. Without someone keeping the group honest about symptoms versus causes and pushing the synthesis step, the output is brainstorming notes rather than analysis.

Use case for digital product teams

For digital product teams, Fishbone earns its keep on cross-functional delivery problems. Corporate website builds, product launches that touch Marketing, Product, Engineering, and Customer Support at once, CRM rollouts, and any initiative where the team disagrees about whose process is the bottleneck.

The SUFFIX way to run it is to pick categories that match the project, run a timeboxed brainstorm where every function fills its own bones, then come together for synthesis. The synthesis step asks which roots show up across multiple bones, since those shared roots are usually the ones worth fixing. From there, translate each root into a named owner, a concrete action, and a recheck date.

For executives, Fishbone is the right tool when the question is "everyone is blaming a different team, what is actually going on?" The category structure gives the conversation a neutral frame and pushes the discussion from blame to system.