3.2: Milestone 1 – Structuring Risk- Risk Breakdown Structure (RBS)

Milestone 1 – Structuring Risk: Risk Breakdown Structure (RBS)

Tool Applied: Planning Meeting and Analysis
Final Output: Structured, Team-Aligned RBS for SMDC Project Leadership

Welcome to Your First Mission

You’re stepping into your first real role as a risk strategist. And like any good strategist, your job isn’t to panic—it’s to see clearly before the chaos begins.

Your mission? Help SMDC’s leadership team build a Risk Breakdown Structure (RBS) that exposes the hidden risks, blind spots, and invisible cracks in their plan to build a diabetes dashboard for people whose lives literally depend on it.

Sound intimidating? Good. That means it matters.
But don’t worry—we’ll walk you through every step.

Scenario Briefing

INTERNAL MEMO
To: Embedded Risk Analyst(s) – Risk Management Team
From: Kira L. Joshi, Chief Operating Officer, SMDC
Date: Week 2 – Initiation and Planning Phase
Subject: Request for Structured Risk Visibility Using Risk Breakdown Structure (RBS)

Team,

We are officially entering the build phase of our SMDC Data Dashboard initiative—a first-generation digital platform designed to support self-managed diabetic care through personalized, integrated data visualization and alerts.

This is a high-stakes project. We are balancing:

• Multi-device data integration
• Real-time clinical relevance
• Regulatory exposure
• And the needs of a highly diverse patient population

Your job is to surface and structure risks using a clear, visual RBS. We need to see:

• Where risk clusters
• What we haven’t named yet
• What might hurt us if ignored

Please go deep. Ask the hard questions. Help us prepare, not just react."

Our users are managing diabetes minute to minute. If our dashboard fails, distracts, or delays action, it won’t just be a design flaw—it may create clinical risk, erode trust, or deepen health disparities.

As a leadership team, we are asking for your expertise to help us see the risk landscape clearly and early.

Please initiate a Planning Meeting and Analysis using a Risk Breakdown Structure (RBS). This RBS should visually categorize the major risk domains across our organization, timeline, infrastructure, and stakeholders.

Specifically, identify risks related to:

• Scope clarity and MVP overreach
• Development velocity vs. clinical safety
• Budget fragility and investor pressure
• HIPAA compliance, SaMD thresholds, and FDA signaling
• Stakeholder misalignment across UX, clinical, product, and legal
• Team burnout, blind spots, and cultural carryovers from past projects
• Equity failures—where our product may unintentionally exclude, confuse, or harm vulnerable populations

Your RBS should not be just a diagram. It should be a decision-support artifact. We will use it to prioritize early-stage resourcing, shape investor briefings, and guide technical tradeoffs across the next three sprints.

You have full permission to ask hard questions and surface uncomfortable truths.

Help us see what we haven’t named yet.

With trust,
Kira

Action Strategy

Purpose of This Milestone

In the world of early-stage startups, most projects fail not because they lacked good ideas—but because risks were allowed to stay invisible. Your mission is to deliver a professional-grade Risk Breakdown Structure that creates visibility across SMDC’s operational ecosystem.

This milestone trains you to think structurally and speak clearly about risk before project chaos sets in.

You are not solving risks yet—you are identifying where they live, how they cluster, and how to create a shared language to track them.

Step-by-Step Guide

Step 1: Prime Yourself with Context (Read and Annotate)

Review these core readings before starting:

• Managing Diabetes in a Data-Driven World – to understand the user’s daily reality, endocrinology, and complexity
• Building SMDC – to examine startup constraints, regulatory exposure, and cultural dynamics

Create a notes doc or mind map to jot:

• Key failure points
• Behavioral or equity gaps
• Technical or organizational weak spots

Step 2: Review the Planning Inputs

Use the following six inputs as your starting categories:

Input Area	What to Consider
Scope	What’s being built? What features might expand late? What assumptions are unclear?
Cost	Where is the budget fragile? Where are resource mismatches likely?
Schedule	What timelines are fixed vs. flexible? What dependencies exist (e.g., APIs, device partners)?
Communication	Where might silos form? What information may not flow?
EEFs	What external rules, pressures, or markets shape our project (e.g., HIPAA, FDA, supply chain, digital equity)?
OPAs	What internal norms, tools, or habits might help—or hurt—our ability to manage risk?

For each category, brainstorm at least 5–8 specific risks using post-its, digital whiteboards, or a shared doc.

Encourage boldness:

“What’s the thing we’re pretending won’t happen?”

Step 3: Facilitate a Risk Mapping Workshop (Team or Solo)

If in a team:

• Appoint a Risk Facilitator
• Assign categories across teammates
• Use color-coded cards or Miro/Mural boards
• Use phrases like:
  • “Where do we think we’re strongest?”
  • “Where’s the most invisible risk?”
  • “What’s an edge case we’re not ready for?”

If working independently:

• Build a table with six columns and start populating risks
• Use guiding categories like:
  • Regulatory
  • Technical
  • Clinical
  • User Experience
  • Operational
  • Team Health

Use specific risk phrases, e.g.:

• “Clinicians reject dashboard due to cluttered alerts”
• “Bluetooth sync fails on Android 11 devices”
• “Pilot launch delayed due to EHR vendor incompatibility”

Aim for 30–40 raw risks before clustering.

Step 4: Build Your RBS Tree

Now cluster your risks into a 3-Level Risk Breakdown Structure:

Level	Function	Example
Level 1	Major domain	Clinical
Level 2	Functional subdomain	Clinician Interpretation
Level 3	Risk example	“Alert fatigue causes clinicians to ignore trend notifications”

Use a digital diagramming tool (Slides, Lucidchart, Canva, etc.) or a well-organized table. Choose a clean layout:

• Vertical hierarchy
• Swimlane format by stakeholder
• Color-coded tree by urgency or ownership

Make the RBS a living structure, not just a one-time document.

Step 5: Annotate and Strategize

Add optional but powerful annotations:

• Icons for high-risk/high-uncertainty nodes
• Color bands for “patient harm,” “reputational,” or “technical failure” risks
• Arrows for interdependencies (e.g., device failure → data delay → alert mistrust)

Use this version in team discussions or milestone reviews.

Your Deliverable

Part 1: Risk Breakdown Structure Diagram

• Title: RBS – SMDC Risk Mapping – [Your Name/Team]
• Format: Clean visual with 5–7 top categories
• Detail: At least 15–25 specific risk examples
• Language: Clear, precise, no jargon
• Optional: Color codes, icons, arrows for bonus clarity

Tips for Impact:

• If Kira reviewed this, would she find it readable in under 3 minutes?
• If the CEO had to defend this at a board meeting, would it hold up?

 Part 2: Framing Narrative (1–2 paragraphs)

Include:

• Where risk was most concentrated
• What surprised you during your mapping
• How this will help the team avoid false confidence or “invisible icebergs”

Toolkits and Templates

• Mini Guide: Planning Meeting and Analysis (Appendix A)
• Sample RBS from a Healthcare App
• Editable RBS Template (Google Slides)
• “Managing Diabetes” Article
• “Building SMDC” Risk Article
• SMDC MVP Brief Sheet – Constraints and stakeholders

Critical Reflection (Required)

Respond in 150–250 words:

• Where did you feel most uncertain in categorizing risk?
• What’s a “taboo” or overlooked risk that felt hard to say out loud?
• What would you want to tell a future team leader reviewing this RBS?
• What did this teach you about silence, structure, or responsibility?

Quality Control Review

• 5–7 top-level categories labeled
• At least 15–25 specific risks detailed
• Clean structure, legible labels, no duplication
• Title, name(s), and version clearly listed
• Narrative and reflection attached or embedded
• Diagram file saved in accepted format (PDF/Slide/Image)
• Shared folder or LMS upload complete

Final Wrap-Up and Submission

Turn in your final milestone to the LMS, team folder, or instructor collection point. Your instructor may use this for:

• Team feedback
• In-class case discussion
• Risk maturity assessment
• Peer reviews or cross-team critique