109 lines
3.4 KiB
Markdown
109 lines
3.4 KiB
Markdown
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]]
|