11.3 Perform Qualitative Risk Analysis
Rank the logged risks by how likely and how serious each one is.
Planning / Risk · ← PMBOK reference · See it on the map
Why it matters
Treating every risk on the register as equally urgent spreads limited attention too thin to matter, and the genuinely dangerous ones get lost in the noise.
What done looks like
Every logged risk has a likelihood and impact rating and is ranked by priority.
First time tip
Re-rank the whole register on a fixed schedule, not just when a new risk appears. A risk's priority can shift even when nothing new has happened.
What you need (Inputs)
- Risk Management Plan
- Scope Baseline
How Scrum/Kanban projects satisfy this — counted from: committed backlog items and definition-of-done items (models/agile.py) — a committed backlog (status ready/in_progress/done) plus a written definition of done is what an agile team baselines scope against - Assumption Log
- Risk Register
- Stakeholder Register
- Enterprise Environmental Factors
How you do it (Tools & Techniques)
- Expert Judgment
- Data Gathering
- Risk Probability and Impact Assessment
- Risk Categorization
- Data Representation
- Meetings
What you get (Outputs)
Worked example
Using the scale agreed up front, the committee rates what it logged. A thunderstorm is both likely enough and damaging enough to land high on each, the headline act cancelling is unlikely but severe, and the toilets arriving late is likely but easy to absorb. The register is reordered so the storm and the cancellation sit at the top.
Common pitfalls
- Rating everything medium to avoid an argument, which leaves the register in no useful order at all.
- Scoring once at kickoff and never rescoring as the forecast and the bookings firm up.
- Mistaking how loudly someone raised a risk for how serious it actually is.
How driftless helps
- Risk Probability and Impact Assessment can be run here.
- Meetings can be run here.
- Risk Register can be created in the wizard.
- Assumption Log can be created in the wizard.