3.5 KiB
Risk Management
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:
- Identify what could prevent the outcome or next milestone.
- Assess probability and impact.
- Respond by avoiding, mitigating, transferring/sharing, or accepting the risk.
- 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