Fishbone Diagram

The Fishbone diagram was developed by Dr. Kaoru Ishikawa, a Japanese quality control statistician in the 1960s, with an aim to aid employees avoid solutions that merely address the symptoms of a much larger problem.

In our day-to-day lives as well as professional careers and businesses, no matter what line we are in, sometimes things get wrong, and we are faced with problems and challenges. Sometimes, the issues are easy to identify and resolve, but more often problems are complex and require detailed analysis. The Fishbone diagram is an important tool for this kind of analysis because it focuses on identifying the root cause or causes of a problem instead of encouraging teams to jump straight to immediate solutions that may later prove incorrect. It is an important tool used to find the root cause or causes for a problem rather than directly jumping onto the immediate solution which might later be incorrect. In this way, the problem can be resolved permanently and in the first go itself. The Fishbone diagram serves the following purposes:

1. Identify root causes of a problem
2. Product development to fulfill the requirements in the current market
3. Identify bottlenecks and areas of improvement in processes and operations

The model

The Fishbone diagram is one of the seven quality control tools and is used in the analyze phase of the DMAIC (Define, measure, analyze, improve and control) approach. It takes its name from the fact that it resembles the shape of a fish skeleton: the head of the diagram represents the problem statement under investigation, while the backbone connects to spines that represent primary causes. These primary causes branch into secondary causes and, if needed, tertiary causes. The most effective way to build a Fishbone diagram is through collective brainstorming in cross-functional teams that include people from diverse fields, ensuring broad coverage of potential causes. Primary cause categories help focus the discussion on specific groups of factors rather than considering all possible factors at once. The Fishbone diagram is also known as the cause-and-effect diagram, Ishikawa diagram, or Herringbone diagram. Over time, several generalized models have emerged, providing standard sets of primary causes that can be tailored to the industry or domain in which the problem lies. It gets its name from its resemblance to a fish.

6M's (Manufacturing)

The 6M model is used generally when dealing with a problem in the manufacturing industry. The 6M's include:

1. Man
2. Machine
3. Material
4. Mother Nature
5. Method, And
6. Measurement

"Man" refers to human-related factors such as skills, training, motivation, and communication. "Machine" covers equipment and technology, including maintenance, configuration, and reliability. "Material" addresses the quality, availability, and handling of inputs and supplies. "Method" focuses on the processes and procedures by which work is carried out, including standard operating procedures and workflow design. "Measurement" concerns how performance and conditions are measured and monitored, including data quality and metrics. "Mother Nature" (or environment) captures external and environmental influences such as physical conditions, organizational culture, and regulatory factors. These six categories provide a structured lens for identifying and organizing potential root causes in manufacturing or manufacturing-like settings.

8P's (Marketing)

The primary causes in this model are:

1. Product
2. Place
3. Price
4. Promotion
5. People
6. Process
7. Physical Evidence, And
8. Performance

"Product" describes the core offering and its features, functionality, and quality. "Place" refers to how and where the product or service is delivered, including distribution channels and logistics. "Price" focuses on pricing models, cost structures, and perceived value. "Promotion" encompasses all forms of communication and branding that shape customer awareness and perception. "People" includes everyone involved in delivering the service or interacting with customers, their skills, behavior, and attitudes. "Process" covers the end-to-end flow customers experience and the internal processes that support it. "Physical Evidence" represents tangible cues—such as facilities, equipment, and documents—that signal quality and reliability in otherwise intangible services. "Performance" captures actual outcomes and results, including operational, financial, and customer-related performance. These eight categories help marketing and service teams explore how different aspects of their offering and operations collectively influence a problem.

4S (Service industry)

This includes four categories of primary causes:

1. Surroundings
2. Suppliers
3. Systems, and
4. Skill

"Surroundings" refer to the environment in which the service is delivered, including physical layout, organizational climate, and external conditions. "Suppliers" include all external providers who contribute to the service, such as vendors, contractors, and partners, along with the quality of relationships and reliability of supply. "Systems" cover the formal and informal systems that govern how work is done, including IT systems, management processes, and standard procedures. "Skill" refers to the capabilities and competence of people at different levels, including technical, managerial, and interpersonal skills. By structuring analysis around these four dimensions, service organizations can systematically examine how environmental conditions, external partners, internal systems, and human capabilities contribute to a given problem.

5 Whys

In order to trace back to the root cause(s), we use a technique called 5 Whys. It is basically a technique wherein we interrogate iteratively by asking for each primary cause, why did it occur, five times subsequently. Thereafter, we try to find the corrective actions for each level so as to ensure that the problem doesn't occur again. It was originally developed by Sakichi Toyoda in the 1930s to revive the Toyota Production System (TPS). Let us understand it using an example. Suppose our company's website is down and we need to get the site up and running ASAP. We would try to get to the root cause using 5 Whys in the following way:

1^st Why: Why did the site go down? Reason: It ran out of memory Corrective action: Get the site up and running again

2^nd Why: Why did it run out of memory? Reason: Because it was incorrectly configured Corrective action: Create an SOP to verify configuration before every update

3^rd Why: Why did that happen? Reason: Because the site administrator made a mistake Corrective action: Make sure the site admin knows how to run the new verification

4^th Why: Why did he make a mistake? Reason: Because the development team hadn't provided adequate instructions Corrective action: Train the development team to provide sufficient instructions

5^th Why: Why did they do so? Reason: Because they assumed it was obvious Corrective action: Have a word with the development team manager

In the above example, what first looked like a technical problem turned out to be a human problem i.e., the development team made a mistake.

Case study: St James hospital

Inefficient supply chain management at St James hospital jeopardized its reputation. The hospital was facing issues as the supply chain was being coordinated by too many people which often led to overstocking, stock-outs and directionless employees. As a result, the hospital was struggling to maintain its reputation in the market.

Step 1: Draw the fishbone diagram with the problem as the fish's head

The first step in addressing this issue would be to draw a Fishbone diagram with the central problem—inefficient supply chain management jeopardizing reputation—at the fish's head.

Step 2: List the six primary causes as the spines of the fish skeleton

The second step would be to list six primary causes as the main spines:

1. Misdirected People
2. Faulty Process
3. Inefficient Management
4. Lack of proper Equipment
5. Materials managed poorly
6. Improper Environment

Step 3: For each primary cause, use the 5 Whys technique to reach the root causes

• Misdirected People: Employees are known to be involved in power wars and don't trust one another. They are not much aware of their job specifications and are underperforming
• Faulty Process: The reason is poor inventory management that is causing overstocking and stock-outs. This is mainly because of high costs, lack of specifications and faulty ordering systems apart from too many suppliers and longer lead times
• Inefficient Management: The reasons for this are hidden costs, short budget, lack of innovation, lack of employee orientation, absence of material manager and lack of relationship with suppliers
• Lack of proper Equipment: High costs of equipment, under-utilization, lack of adequate IT facility to support equipments are some of the reasons why the hospital is not able to compete in the market
• Materials managed poorly: The secondary causes include high costs of supplies, lack of proper storage capacity and unavailability of required materials at required times
• Improper Environment: Factors like protectionism, resistance to change, unsound set-up, rivalry among employees, etc. are thwarting the working environment in the hospital from being conducive for business growth

Step 4: List down the corrective actions for the root causes

• Misdirected people: Conduct training sessions regularly to motivate employees. Also conduct knowledge transfer to specify about their individual responsibilities
• Faulty process: Adopt an electronic ordering system to track orders and automate the process that will resolve the issues of overstocking or stock-outs
• Inefficient management: Hire a material manager to bring in innovations and accelerate the supply chain tasks. Involve employees in the decision-making process
• Lack of proper equipment: Undertake a comprehensive program to include a centralized information system for regular tracking of equipment and ensure higher utilization and zero wastage. Hire IT experts to seek guidance
• Material managed poorly: Adopt centralized ordering system, maintain strong supplier relationships and rent additional warehouses to increase storage capacity
• Improper environment: Involve employees in creating and maintaining work schedule and working standards so as to prevent them from rivalry, protectionism, resistance to change etc.

Manufacturing – high defect rate on a packaging line (6Ms)

Problem statement (head of the fish)

Printed date codes on cartons are smearing on Line 3, causing a 5% rejection rate over the last two weeks

Man (People)

• Operators on the night shift have not been trained on the new ink's longer drying time, so they are stacking cartons too quickly after printing.
• A new temporary operator rotates through Line 3 and follows habits from another line with a different printer setup, leading to inconsistent handling.

Machine (Equipment)

• The print head height has drifted because the adjustment screws are worn, increasing the distance variation between print head and carton.
• Cleaning of the print head is done ad hoc; inspection shows dried ink buildup on the nozzles, which leads to uneven ink laydown.
• Conveyor speed was increased last month to meet a rush order, but printer settings were never recalibrated for the higher line speed.

Method (Process)

• There is no written standard for optimum print‑head‑to‑carton distance or cleaning frequency; operators rely on what looks right
• Work instructions do not specify how long cartons should remain on the conveyor before stacking, so practices differ across shifts.
• Changeovers between inks are not governed by a checklist; flushing and priming steps are sometimes skipped under time pressure.

Material (Inputs)

• A new ink supplier was introduced two weeks ago; the ink formulation has a longer drying time than the previous one.
• Carton stock was switched to a glossier finish to save costs, but this surface is less absorbent, so ink sits longer on the surface.

Measurement (Data and Checks)

• There is no intermediate quality check on ink curing; inspection only happens at the end of the line when defects are already baked in.
• The visual inspection criteria for smearing are not defined; different inspectors apply different thresholds, making trend detection harder.

Mother Nature (Environment)

• Plant humidity has increased since a recent HVAC repair; higher humidity slows ink evaporation and drying.
• The printer is placed near a draft from an open loading bay; temperature fluctuations affect ink viscosity and jetting consistency.

From causes to root cause and corrective actions

After building the fishbone and brainstorming, the team prioritizes causes using impact–likelihood scoring and then verifies them with data. They find that the combination of a new ink with longer drying time, glossier carton stock, and increased conveyor speed is the main driver, compounded by missing standards for print-head distance and stacking time.

They implement these corrective actions:

• Reduce conveyor speed on Line 3 to match the new ink's drying profile and document this as the default setting for this product.
• Update work instructions to define print‑head‑to‑carton distance, daily cleaning standards, and minimum time before stacking, and train all shifts.
• Run ink and carton compatibility tests before future supplier changes, including a controlled trial with defined acceptance criteria.
• Introduce an in‑process quality check (e.g., every 30 minutes) to detect smearing early and adjust parameters before large batches are affected.

Within a week, rejection rates drop from 5% to well under 1%, confirming that the prioritized causes were indeed root causes.

SaaS – frequent website outages (People–Process–Technology–Environment–Measurement)

Problem statement (head of the fish)

Customer‑facing web application experiences unplanned outages at least twice per month during peak traffic, causing user complaints and revenue loss

People (analogous to "Man" / Skill)

• On‑call rotation is unclear; engineers are not sure who owns incidents after hours, leading to delayed responses
• Junior engineers deploy configuration changes without peer review; several outages correlate with unreviewed changes
• Operations staff are unfamiliar with new autoscaling and monitoring tools, so they ignore early warning signals and rely on user reports

Process (analogous to Method / Systems)

• There is no formal change management process; teams deploy directly to production from feature branches without a standard pre‑deployment checklist
• Incident response runbooks are outdated or missing; during outages, teams improvise, leading to inconsistent and sometimes risky recovery steps
• Post‑incident reviews are sporadic and informal, so lessons learned are not captured systematically and the same patterns recur

Technology (analogous to Machine)

• Application servers are configured with fixed memory limits; under peak load, processes are killed due to memory exhaustion, triggering restarts and downtime
• Database connection pools are not tuned; under spikes, connection exhaustion causes cascading failures across services
• Monitoring covers only high‑level uptime checks; there is limited visibility into per‑service latency, error rates, and resource utilization

Environment (analogous to Mother Nature / Surroundings)

• Peak traffic occurs during promotional campaigns, but there is no capacity planning or load testing before major marketing launches
• The production environment shares infrastructure with staging; heavy test runs occasionally consume shared resources and impact live traffic
• Network routes between the application and a critical third‑party API are unstable during certain time windows, increasing error rates

Measurement (Measurement)

• Alert thresholds are poorly tuned; noisy alerts lead to "alert fatigue," so genuine issues are sometimes ignored
• There is no agreed SLA or SLO; metrics like uptime, mean time to detect (MTTD), and mean time to recover (MTTR) are neither defined nor tracked
• Logs are retained for a short period and not centralized, making it difficult to correlate events and analyze patterns across incidents

From causes to root cause and corrective actions

After building the fishbone with engineers from development, operations, and product, the team prioritizes causes based on impact and likelihood, then validates them with production logs, deployment history, and incident timelines. They find that most outages coincide with configuration changes deployed without review, under‑provisioned memory limits, and lack of capacity planning before campaigns, all amplified by weak monitoring and unclear on‑call ownership.

They implement these corrective actions:

• Introduce a standardized deployment pipeline with mandatory code review, automated tests, and a pre‑deployment checklist, including configuration validation
• Define clear on‑call rotations, publish escalation paths, and provide incident response training for all engineers
• Tune autoscaling and memory limits based on load testing; run regular performance tests before major marketing campaigns to validate capacity
• Expand monitoring to include service‑level metrics (latency, error rates, saturation) and set meaningful SLOs and alert thresholds
• Institutionalize blameless post‑incident reviews, documenting root causes and action items in a shared knowledge base, and revisiting these in future planning

After three months, the frequency of unplanned outages drops significantly, and when incidents do occur, detection and recovery times are much shorter, improving both customer experience and internal confidence.

Advantages

• Highlights problems visually to the stakeholders
• Expresses all causes simultaneously
• Immediately discerns whether the primary reason occurs several times in the exact cause
• Improves decision-making in project teams
• Helps identify methods for process improvement and take corrective action

Disadvantages

• Identifying connections between causes is a challenge
• For a realistic outcome, a skilled team of brainstorming is required
• It is difficult to express the interrelated nature of problems and causes in complex situations
• Sometimes it can be challenging to pinpoint the root cause of a problem due to team members' biases