Analyse Phase: Creating Effective Fishbone Diagrams for Root Cause Analysis

In the world of process improvement and quality management, identifying the root causes of problems is essential for developing lasting solutions. The Fishbone Diagram, also known as the Ishikawa Diagram or Cause and Effect Diagram, stands as one of the most powerful tools in the Lean Six Sigma methodology’s Analyse phase. This comprehensive guide will walk you through everything you need to know about creating and utilizing effective Fishbone Diagrams to drive meaningful improvements in your organization.

Understanding the Fishbone Diagram

The Fishbone Diagram was developed by Dr. Kaoru Ishikawa, a Japanese quality control expert, in the 1960s. The diagram earned its name from its visual resemblance to a fish skeleton, with the problem statement forming the “head” and the potential causes branching off like “bones.” This structured visual approach helps teams systematically explore all possible causes contributing to a specific effect or problem. You might also enjoy reading about Lean Six Sigma Analyze Phase: The Complete Guide for 2025.

The beauty of this tool lies in its simplicity and versatility. Whether you are dealing with manufacturing defects, service delivery issues, healthcare complications, or administrative bottlenecks, the Fishbone Diagram provides a framework for comprehensive root cause analysis. It encourages teams to think broadly about potential causes while organizing thoughts in a logical, visual manner that facilitates discussion and understanding. You might also enjoy reading about Analyze Phase Documentation: What to Record and How to Present Findings in Lean Six Sigma Projects.

The Critical Role in the Analyse Phase

Within the DMAIC (Define, Measure, Analyse, Improve, Control) framework of Lean Six Sigma, the Analyse phase serves as the bridge between understanding what the problem is and determining how to fix it. After defining the problem and measuring its extent in the previous phases, the Analyse phase focuses on identifying root causes rather than merely addressing symptoms. You might also enjoy reading about How to Formulate Null and Alternative Hypotheses for Your Six Sigma Project.

The Fishbone Diagram proves particularly valuable during this phase because it:

  • Facilitates structured brainstorming sessions that capture diverse perspectives from cross-functional teams
  • Organizes potential causes into logical categories, making complex problems more manageable
  • Provides a visual representation that enhances communication among stakeholders
  • Helps teams avoid jumping to conclusions by systematically exploring all possibilities
  • Documents the thinking process for future reference and organizational learning
  • Identifies areas where additional data collection may be necessary

The Six Major Categories of Causes

Traditional Fishbone Diagrams organize potential causes into six primary categories, often referred to as the 6Ms. These categories provide a comprehensive framework for exploring all aspects of a process or system:

Man (People)

This category examines human factors contributing to the problem. Considerations include employee training levels, experience, knowledge, skill sets, fatigue, motivation, communication effectiveness, and adherence to procedures. Human error often plays a significant role in process failures, but it is crucial to approach this category without blame, focusing instead on systemic factors that enable or prevent errors.

Method (Process)

The Method category investigates the procedures, protocols, and processes used to complete work. This includes standard operating procedures, work instructions, process design, decision-making criteria, and the logic behind how tasks are performed. Inefficient or poorly designed methods frequently contribute to quality problems and operational inefficiencies.

Machine (Equipment)

This category focuses on the tools, technology, and equipment used in the process. Relevant factors include equipment age, maintenance schedules, calibration status, capacity limitations, technology obsolescence, software issues, and equipment suitability for the intended purpose. Machine-related causes are particularly common in manufacturing environments but remain relevant in service industries relying on technology.

Material (Raw Materials)

Material causes relate to the inputs used in a process, including raw materials, components, consumables, and information. Quality variations in materials, supplier reliability, material specifications, storage conditions, and material handling procedures all fall within this category. Even in service industries, “materials” might represent data inputs, forms, or other informational resources.

Measurement (Inspection)

The Measurement category examines how performance is monitored and evaluated. This includes measurement system accuracy, inspection procedures, data collection methods, calibration practices, and the appropriateness of metrics used. Measurement problems can mask true process performance or create the illusion of problems where none exist.

Mother Nature (Environment)

Environmental factors encompass conditions in the work environment that might influence outcomes. Temperature, humidity, lighting, noise levels, cleanliness, workspace layout, and external regulatory requirements all belong in this category. Environmental causes are sometimes overlooked but can significantly impact process performance.

Step-by-Step Guide to Creating an Effective Fishbone Diagram

Step 1: Define the Problem Statement Clearly

Begin by crafting a precise, specific problem statement. The problem should be written in the “head” of the fish, typically on the right side of the diagram. A vague problem statement like “poor quality” will lead to unfocused analysis, while a specific statement such as “15 percent increase in customer complaints about delayed deliveries in Q3” provides clear direction.

The problem statement should be measurable, observable, and agreed upon by all team members. Take time to ensure everyone understands exactly what issue you are addressing before proceeding with cause identification.

Step 2: Assemble the Right Team

Effective Fishbone Diagrams require input from people with diverse knowledge and perspectives. Assemble a cross-functional team that includes individuals who work directly with the process, those who receive the process outputs, subject matter experts, and fresh perspectives from people less familiar with day-to-day operations.

A team of five to eight members typically provides sufficient diversity without becoming unmanageable. Schedule adequate time for the exercise, typically 60 to 90 minutes for initial diagram creation.

Step 3: Draw the Basic Structure

Create a horizontal arrow pointing to the right, with the problem statement in a box at the arrow’s head. Draw six diagonal lines branching off the main arrow, three above and three below, creating the main “bones.” Label each bone with one of the six major categories (Man, Method, Machine, Material, Measurement, Mother Nature).

While you can create Fishbone Diagrams using specialized software, starting with a whiteboard or large paper often encourages more active participation and collaboration during brainstorming sessions.

Step 4: Brainstorm Potential Causes

Working through each category systematically, brainstorm potential causes that might contribute to the problem. Encourage team members to suggest all possibilities without immediate judgment or debate. The goal during this phase is quantity and diversity of ideas.

For each potential cause identified, ask “Why does this happen?” to drill deeper into contributing factors. These secondary and tertiary causes branch off the main category bones, creating the detailed structure that gives the diagram its fish-like appearance.

Step 5: Organize and Refine

After the initial brainstorming, review all identified causes for clarity and organization. Consolidate duplicate ideas, clarify ambiguous statements, and ensure causes are placed in the most appropriate categories. Some causes might legitimately fit in multiple categories, so use your judgment about the best placement or include them in both locations if necessary.

Step 6: Identify Most Likely Root Causes

Once the diagram is complete, work with the team to identify which causes are most likely contributing significantly to the problem. Use techniques like multi-voting, where team members receive a limited number of votes to allocate to the causes they believe are most significant. Circle or highlight the highest-priority causes for further investigation.

Step 7: Validate with Data

The Fishbone Diagram generates hypotheses about root causes, but these must be validated with data. For the priority causes identified, design data collection plans or experiments to confirm or refute their contribution to the problem. This data-driven validation distinguishes rigorous Lean Six Sigma analysis from mere speculation.

Real-World Example: Customer Service Call Center

Let us examine a practical example to illustrate how Fishbone Diagrams work in practice. Imagine a customer service call center experiencing a significant problem with average call handling time increasing from 8 minutes to 12 minutes over three months, resulting in longer customer wait times and decreased satisfaction scores.

Problem Statement

Average call handling time increased by 50 percent (from 8 to 12 minutes) between January and March 2024, resulting in customer satisfaction scores dropping from 4.2 to 3.6 out of 5.

Identified Causes by Category

Man (People):

  • High turnover rate leading to more inexperienced representatives (30 percent new staff in the last quarter)
  • Reduced training time for new hires (cut from 4 weeks to 2 weeks in December)
  • Increased stress levels among staff (employee survey scores down 25 percent)
  • Language barriers with some customer segments
  • Representatives lacking confidence to resolve issues without supervisor approval

Method (Process):

  • New product line launched without updated call scripts or procedures
  • Approval process requiring supervisor sign-off for refunds over 50 dollars causing delays
  • Multiple systems requiring separate logins and navigation
  • Knowledge base articles outdated and not reflecting recent policy changes
  • No standardized troubleshooting flowcharts for common issues

Machine (Equipment):

  • Customer relationship management system experiencing frequent slowdowns during peak hours
  • Outdated computers taking 3-4 minutes to boot up applications
  • Headset quality issues causing representatives to ask customers to repeat information
  • Phone system occasionally dropping calls, requiring callbacks
  • Search functionality in knowledge base slow and producing irrelevant results

Material (Information):

  • Product documentation incomplete for new product line
  • Customer data in system often outdated or incorrect
  • Policy manual last updated 18 months ago
  • Competing information in different knowledge base articles
  • No quick reference guides for complex procedures

Measurement (Metrics):

  • Call handling time metric not distinguishing between call types (simple inquiries versus complex problem resolution)
  • No measurement of first-call resolution rates
  • Quality monitoring only conducted on 2 percent of calls
  • Feedback from quality monitoring delayed by two weeks
  • No real-time performance dashboard for representatives to self-monitor

Mother Nature (Environment):

  • Call volume increased 40 percent following new product launch
  • Seasonal peak period coinciding with staffing challenges
  • New data privacy regulations requiring additional verification steps
  • Noisy open office environment making it difficult to hear customers
  • Uncomfortable workspace temperature affecting concentration

Priority Causes Identified

After team discussion and multi-voting, the following causes were identified as highest priority for data validation:

  • Reduced training time for new hires (potentially affecting 30 percent of staff)
  • New product line launched without updated procedures (affecting all calls related to new products)
  • CRM system slowdowns during peak hours (affecting all representatives during busiest times)
  • 40 percent increase in call volume without proportional staffing increase
  • Approval process requiring supervisor sign-off for refunds (creating bottlenecks)

Data Validation Approach

The team then designed specific data collection activities:

Comparing average handle time between representatives with full 4-week training versus those with reduced 2-week training revealed that newer representatives with shorter training averaged 14.5 minutes per call versus 9.8 minutes for fully trained staff. This data strongly supported training duration as a significant contributing factor.

Analysis of call logs showed that 45 percent of increased handling time occurred during calls related to the new product line, and representatives accessed the knowledge base an average of 4.2 times per call for new product inquiries versus 1.3 times for established products.

IT department logs confirmed CRM system response times increased from an average of 1.2 seconds to 4.7 seconds during peak hours, and representatives reported system issues on 67 percent of peak-hour shifts.

This data-driven validation allowed the team to move forward with targeted improvement initiatives addressing the confirmed root causes rather than implementing solutions based on assumptions.

Common Pitfalls to Avoid

Stopping at Symptoms Rather Than Root Causes

One of the most frequent mistakes is placing symptoms on the diagram rather than true causes. For example, “low employee morale” is often a symptom of deeper issues like inadequate recognition, poor working conditions, or ineffective leadership. Always ask “Why?” multiple times to drill down to underlying causes.

Allowing Blame Culture to Dominate

When discussing the “Man” category, teams sometimes slip into blaming individuals rather than examining systemic factors. Frame discussions around what enables or prevents people from performing well, not who is at fault. This approach leads to more honest analysis and sustainable solutions.

Creating Overly Complex Diagrams

While thoroughness is valuable, diagrams with hundreds of potential causes become unwieldy and difficult to act upon. Focus on quality over quantity. It is better to identify 20 well-considered causes than to list 100 possibilities that include many duplicates or irrelevant factors.

Working in Silos

Creating Fishbone Diagrams without diverse input results in incomplete analysis. Include perspectives from different departments, levels of the organization, and functional areas to ensure comprehensive coverage of potential causes.

Failing to Validate with Data

Perhaps the most critical mistake is treating the Fishbone Diagram as the endpoint rather than a starting point for data-driven investigation. The diagram generates hypotheses that must be tested and validated before implementing solutions.

Advanced Tips for Maximum Effectiveness

Customize Categories for Your Context

While the 6Ms provide an excellent starting framework, do not hesitate to adapt categories for your specific situation. Service industries might use the 4Ps (Policies, Procedures, People, Plant/Technology), while other organizations develop custom category sets aligned with their operational structure.

Use the 5 Whys Technique in Combination

For each cause identified on your Fishbone Diagram, apply the 5 Whys technique by repeatedly asking “Why does this happen?” This drives analysis deeper and helps distinguish symptoms from true root causes. Document this deeper analysis as sub-branches on your diagram.

Facilitate Rather Than Direct

If you are leading the Fishbone Diagram session, focus on facilitation rather than providing answers. Ask probing questions, encourage quieter team members to contribute, and ensure all ideas are captured without immediate judgment. The best insights often come from unexpected sources.

Document Assumptions and Unknowns

As you build the diagram, note which causes are based on data, which are assumptions, and where knowledge gaps exist. This documentation guides subsequent data collection efforts and prevents the team from treating unvalidated assumptions as facts.

Revisit and Refine

Treat your Fishbone Diagram as a living document. As you gather data and learn more about the problem, update the diagram to reflect new understanding. This iterative approach leads to increasingly accurate root cause identification.

Integrating Fishbone Diagrams with Other Lean Six Sigma Tools

The Fishbone Diagram rarely works in isolation. It integrates powerfully with other Lean Six Sigma tools throughout the DMAIC process:

Pareto Charts help prioritize which causes identified on the Fishbone Diagram deserve focused attention based on their relative impact

Related Posts