3.6: Milestone 5 – Diagnosing Root Causes- Fishbone Diagram

Milestone 5 – Diagnosing Root Causes: Uncovering What’s Beneath the Risk

Tool Applied: Cause Tracer Diagram (Fishbone/Ishikawa) and 5 Whys
Final Output: Root Cause Analysis Diagram and Root Cause Rationale Summary

1. Scenario Briefing

MEMO
To: SMDC Risk Strategy Team
From: Kira L. Joshi, Chief Operating Officer, SMDC
Date: Week 6 – Risk Remediation Planning
Subject: Request for Root Cause Analysis on Persisting High-Impact Risk Area

Team,

After reviewing the control checklists you delivered last week, one concern has come up repeatedly: we seem to be treating symptoms rather than underlying conditions. I’ve heard feedback from Engineering, Clinical, and Product that our dashboards, alerts, and processes still show signs of tension, even where controls exist. In several sprint retrospectives, we’ve captured issues that sound like this:

“Too many alerts are misfiring.”
“Data syncs inconsistently across devices.”
“Users aren’t responding to critical insights.”
“We’re fixing the same bugs repeatedly.”

These are not isolated failures. These are signs that we haven’t reached the root.

I need your help to trace one high-impact risk theme all the way down—to find the underlying causes, assumptions, or systemic breakdowns that keep fueling it. Use both visual and narrative cause analysis tools to show the difference between a surface symptom and a structural problem.

We’ll use your output to decide:

• Where to invest redesign
• Where to escalate
• Where to slow down, re-architect, or re-scope
• Where to accept failure as inherent and design around it

You have permission to go deep. The more uncomfortable and unspoken the root cause, the more valuable your analysis.

Let’s move from observation to transformation.

Kira

2. Action Strategy

Purpose of This Milestone

This milestone introduces you to root cause analysis—the practice of tracing risk events back to their origin points, behavioral patterns, or systemic design flaws.

Most risk plans fail not because risks were invisible—but because teams only addressed surface symptoms. Without root cause work, risk plans get stuck in cycles of band-aids and rework.

You will use two integrated tools:

• A Cause Tracer Diagram (also called a Fishbone or Ishikawa Diagram) to visually map potential root causes across categories
• A 5 Whys Analysis to interrogate one specific event or failure chain in depth

You’ll learn how to:

• Distinguish symptoms from sources
• Identify systemic patterns hidden beneath isolated incidents
• Trace feedback loops and unspoken assumptions
• Create visual models of complex risk interactions
• Communicate technical or human root causes without blame

Your final product is a structured diagnostic that prepares your team for deep, cross-functional redesign or escalation.

Step-by-Step Guide

Step 1: Choose a Risk Theme or Event to Diagnose

Start by reviewing your previous milestones. Choose one high-priority risk theme or event that remains unresolved or difficult to control. Examples include:

• Patient Alert Confusion
• API Integration Delays
• Glucose Data Gaps
• Incomplete Clinician Onboarding
• Unusable Features for Non-English Speakers
• Frequent Regression Bugs Post-Release

Choose a theme that:

• Crosses multiple functions or domains
• Has reappeared in more than one milestone
• Reflects both technical and human elements
• Has ambiguous ownership or unclear resolution paths

Write a short paragraph summarizing:

• The risk
• Where it originated (Milestone 1–4)
• Why it is worth deeper diagnosis

• What breakdown or failure it represents

Step 2: Build the Cause Tracer Diagram

Use the Fishbone/Ishikawa structure to visually organize potential root causes under thematic branches. Use at least four of the following cause categories:

• People (e.g., skill gaps, unspoken norms, conflict avoidance)
• Process (e.g., poor documentation, unclear handoffs, role confusion)
• Technology (e.g., unstable APIs, poor test coverage, tool incompatibility)
• Environment (e.g., startup pressure, limited feedback time, funding stress)
• Measurement (e.g., no alert tracking, poor data interpretation, misaligned KPIs)
• Policy (e.g., HIPAA ambiguity, unclear regulatory boundaries)

For each branch, list at least two specific contributing factors. Push past the obvious.

Instead of “bad design,” ask:

• Why was it bad?
• Who designed it under what assumptions?
• What deadline or decision forced shortcuts?

This is a team learning artifact, not a blame diagram.

Step 3: Apply the 5 Whys Technique to a Single Symptom

Choose one concrete risk symptom from your theme—e.g., “Clinicians ignore trend alerts”—and apply the 5 Whys method to trace its logic downward.

Ask “Why did this happen?”
Then for each answer, ask “Why?” again, five levels deep.

Example:

1. Why did clinicians ignore trend alerts?
   → Because the alerts were too frequent.

2. Why were they too frequent?
   → Because thresholds were tuned for real-time data, not trend intervals.

3. Why were thresholds not differentiated?
   → Because the alert engine only had one configuration for both.

4. Why did the alert engine lack flexibility?
   → Because early technical decisions hardcoded alert logic to save time.

5. Why did that decision get made?
   → Because sprint velocity was prioritized over configurability due to funding pressure.

This method helps surface:

• Structural design decisions
• Time/budget tradeoffs
• Communication breakdowns
• Cultural or leadership blind spots

Record this 5 Whys sequence as part of your deliverable.

Step 4: Synthesize Findings into a Root Cause Summary

Write a narrative that explains:

• What your visual and narrative tools revealed
• Which root causes were most influential
• Whether root causes are:
  • Structural (design/architecture)
  • Behavioral (team habits or misalignments)
  • Temporal (made sense earlier, no longer valid)
  • Cultural (unspoken rules or tensions)

• What would need to change to prevent recurrence

• What risks remain even if a root cause is addressed

Use this summary to help leadership understand:

• Why symptoms persist
• What cannot be solved through surface fixes
• Where investments in process, training, or re-architecture are warranted

3. Your Deliverable

Part 1: Cause Tracer Diagram

Includes:

• Title of risk theme diagnosed
• At least four cause branches
• At least two specific contributors per branch
• Clear, legible labeling
• Cross-functional factors where applicable

Format: Table or diagram, typed or drawn clearly.

Part 2: 5 Whys Sequence

• One real symptom traced five levels deep
• Responses listed in narrative or bullet format
• Logical coherence between each level
• Clear articulation of the final root cause

Part 3: Root Cause Summary (1–2 pages)

• Theme overview and selection rationale
• Key contributors surfaced
• Types of root causes identified
• Recommendation summary (what should change, what must be re-examined)
• Optional: insights on trust, fear, or decision patterns

4. Toolkits and Learning Resources

• Root Cause Analysis Overview (Appendix)
• Sample Cause Tracer Diagram Template
• 5 Whys Example Walkthrough
• Milestone 4 Preventive Control (to cross-reference known gaps)
• Stakeholder Interview Prompts (if gathering quotes or context)

5. Critical Reflection

Write 200–300 words on:

• What changed when you stopped at the symptom and asked “Why?”
• Which causes were hardest to name or prove—and why?
• How might internal culture contribute to repeated risk symptoms?
• What’s the difference between accountability and blame in root cause work?
• What are the risks of skipping this kind of diagnosis in a fast-paced project?

6. Quality Control Review

Clear problem or risk theme defined
Fishbone-style cause diagram created with specificity
5 Whys sequence completed with logical depth
Summary includes explanation and insight—not just description
Reflection addresses team dynamics and system design
File is formatted for reuse in Milestone 6 or 7
All components clearly labeled and submitted together

7. Final Wrap-Up and Submission

Submit your full diagnosis bundle via your assigned LMS portal, team folder, or instructor pathway. You will reuse this root cause work in:

• Milestone 6 (Strategic Framing with SWOT/TOWS)
• Milestone 8 (Stakeholder Integration Plan)
• Milestone 11 (Contingency Planning)

This milestone teaches you how to go beyond the obvious—and help others see what needs to change.