# Risk Management Walkthrough — Learn by Doing

## Before We Begin

**Diagnostic:** What's the difference between a *risk* and an *issue*? When something has already gone wrong, is it still a risk—or something else? How would you treat each differently?

**Checkpoint:** You can explain that a risk is *potential* (it might happen); an issue is *actual* (it has happened). Your response to each is different.

---

## Step 1: Run a Pre-Mortem

**Task:** Pick a project (real or hypothetical). Imagine it has failed. Write 5–7 plausible reasons it failed. Don't filter—just list. Then pick the top 2 that feel most likely.

**Question:** Why does imagining failure surface risks more effectively than asking "what could go wrong?" What assumptions did you uncover?

**Checkpoint:** At least 5 failure modes listed; top 2 selected with brief rationale.

---

## Step 2: Build a Risk Matrix

**Task:** Take your top 2 risks and 2 more (e.g., "key person unavailable," "third-party API delay"). For each, assign probability (L/M/H) and impact (L/M/H). Plot them on a 3×3 risk matrix. Which one would you address first?

**Question:** What makes "high probability + high impact" different from "low probability + high impact"? How might stakeholders disagree with your ratings?

**Checkpoint:** All 4 risks are plotted; priority order is justified.

---

## Step 3: Choose Response Strategies

**Task:** For each of your 4 risks, assign a response: Avoid, Mitigate, Transfer, or Accept. For at least 2, write one concrete action (e.g., "Mitigate: run load tests in CI before each release").

**Question:** When is "Accept" the right choice? When would you avoid vs mitigate?

**Checkpoint:** Each risk has a strategy; at least 2 have specific actions.

---

## Step 4: Create a Risk Register

**Task:** Turn your 4 risks into a risk register. Include: ID, description, probability, impact, response, and owner. Add one more risk (e.g., technical: "integration test gaps") and fill it in.

**Question:** Who should "own" a risk? What does ownership mean—tracking, reporting, or executing the response?

**Checkpoint:** Register has 5 risks; format is consistent; owners assigned.

---

## Step 5: Map Dependencies

**Task:** Draw a simple dependency map for your project: your system in the center, with 4–5 things it depends on (people, systems, vendors). For each dependency, note: What happens if it fails? Who owns it?

**Question:** Which dependency would hurt most if it failed? Is that reflected in your risk register?

**Checkpoint:** Map is drawn; each dependency has a failure implication.

---

## Step 6: Draft Risk Communication

**Task:** Pick your highest-priority risk. Write a 3–4 sentence status update for a stakeholder. Lead with context, include the risk and your response, and avoid alarmism.

**Question:** What would make you sound like the "doom person"? What would make you sound like you're on top of it?

**Checkpoint:** Update is calm, includes response, and is stakeholder-appropriate.