Duration: 30--40 minutes

## Definition

A **risk** is an uncertain event or condition that could affect the
project's outcome, schedule, scope, quality, cost, or operations. An
**issue** is a problem that is already happening.

## Simple Mental Model

> **Risk = might happen. Issue = is happening.**

Good project management tries to identify important uncertainty before
it becomes a surprise.

## How It Works

Use a lightweight four-step process:

1.  **Identify** what could prevent the outcome or next milestone.
2.  **Assess** probability and impact.
3.  **Respond** by avoiding, mitigating, transferring/sharing, or
    accepting the risk.
4.  **Monitor** the important risks as the project changes.

You do not need fake numerical precision. Low / Medium / High is often
enough.

Example:

  --------------------------------------------------------------------------
  Risk           Probability    Impact         Response       Owner
  -------------- -------------- -------------- -------------- --------------
  DevOps         Medium         High           Confirm        Project owner
  unavailable                                  commitment     
  before QA                                    early          

  --------------------------------------------------------------------------

A dependency is something you know the project needs. A risk is
uncertainty around what might happen.

## Example

Your project is on schedule, but Security has not reviewed an
architecture required for production. The deadline has not slipped yet,
but the unresolved review is a material risk. The project may already
deserve Yellow health.

## How It Fits Into the Bigger Picture

Dependencies tell you what the project needs. Estimation exposes
assumptions. Risk management asks what could make those assumptions
fail. [[Project Health]] then reflects important risks before
deadlines are actually missed.

## My Company / Real-World Context

Likely project risks in your environment include vendor delivery, DevOps
availability, Security approval, Product requirement changes,
operational interruptions, QA availability, data quality, and key-person
dependencies.

Focus on the few risks capable of materially changing delivery rather
than maintaining a huge register nobody reads.

## CTO Perspective

A project should not remain Green merely because nothing bad has
happened yet. Leadership status must be forward-looking.

### Questions to Ask

-   What could prevent the next milestone?
-   What assumptions are we relying on?
-   Which risk has the highest impact?
-   Who owns the response?
-   What can we do now?
-   What signal tells us the risk is becoming an issue?
-   Does this risk change project health?

## Meeting Scenario

**Situation:** Security has not reviewed a required architecture and
production is approaching.

**Possible response:**

> The milestone hasn't slipped yet, but the unresolved Security review
> is now a material delivery risk. Let's get a committed review date and
> escalate if that date threatens production.

## Key Takeaways

-   Risks are uncertain future events; issues are current problems.
-   Identify risks before they become blockers.
-   Focus on material risks.
-   Assess probability and impact.
-   Significant risks need an owner and response.
-   Health should reflect major risks before a deadline is missed.

## Related Concepts

-   [[Dependencies]]
-   [[Project Health]]
-   [[Estimation and Forecasting]]
-   [[Capacity and WIP]]
-   [[RAID]]