- Description
- Une digue de béton qui avance dans la mer pour briser les vagues et les surcotes de tempête, avec deux pêcheurs sur les rochers.
- Source
- Lucky Ambago Purok Otso · original page
- Licence
- CC0 Public domain
Risk Management (RSK)
A risk is an uncertain event whose occurrence degrades the project. The difference between a risk and an issue is about timing: risk is handled at low cost beforehand, the issue…
Level: 🟢→🔴 · Code: RSK · Matrix: PI
Why this theme#
A risk is an uncertain event whose occurrence degrades the project. The difference between a risk and an issue is about timing: risk is handled at low cost beforehand, the issue is paid at full price afterward. Teams that do not discuss them experience their unexpected events as surprises, even though most were predictable (departure of a key person, unstable data source, delayed external dependency). The cost of ignoring this: recurring crises, exhausted heroes, timelines with no real buffer.
What this theme measures#
- Axis: from reacting to crises to integrating risks into decisions.
- Key indicator: share of issues that occurred which had been identified as risks (anticipation rate); total residual exposure.
- Unit: % of anticipated issues; exposure in days or euros; number of risks handled before occurrence.
The five levels#
| Level | Short name | Promise | Typical indicator (orders of magnitude) |
|---|---|---|---|
| 1 | Firefighters | Issues are handled as they erupt, by whoever is available. | Anticipated: < 10% |
| 2 | Risk list | Known risks are written down at kickoff; we know what worries us. | Anticipated: 20 to 30% |
| 3 | Living register | Each risk has an owner, a probability, an impact, a response, and a review date; the register is reviewed every week or at each iteration. | Anticipated: 40 to 60%; weekly review |
| 4 | Tracked exposure | Overall exposure is quantified and tracked over time; each realized risk is analyzed, and responses are effective. | Anticipated: 60 to 80%; response effectiveness measured |
| 5 | Risk in decision-making | Risks weigh on choices (scope, schedule, architecture); quantified reserves exist, and risks are shared across projects. | Sized reserves; anticipated > 80% |
Milestones by level#
| ID | Milestone | Verifiable evidence |
|---|---|---|
| PI-RSK-1.1 | Incidents are recorded when they occur. | Project incident log. |
| PI-RSK-1.2 | A person is designated when a crisis erupts. | Name of the crisis owner for the last 3 crises. |
| PI-RSK-1.3 | Past crises are recounted to the team. | Records of crisis reports. |
| PI-RSK-2.1 | A risk list exists at kickoff, with at least 5 entries for a medium project. | Document dated at kickoff. |
| PI-RSK-2.2 | Each risk is stated as “cause → event → consequence.” | Review 5 risks: complete form. |
| PI-RSK-2.3 | The list is reviewed at least once halfway through. | Two successive versions. |
| PI-RSK-3.1 | Each risk has a named owner. | “Owner” column filled 100%. |
| PI-RSK-3.2 | Probability and impact are rated using a common scale. | Written scale; rating for each risk. |
| PI-RSK-3.3 | A response is chosen for each major risk (avoid, reduce, transfer, accept) with a dated action. | Actions tracked in the ticketing tool. |
| PI-RSK-3.4 | The register is reviewed on a fixed cadence (at least every two weeks). | Version history and review dates. |
| PI-RSK-3.5 | Triggers (triggers) are defined for major risks. | Written observable thresholds. |
| PI-RSK-4.1 | Exposure (probability × impact) is aggregated and tracked by period. | Exposure curve over ≥ 6 months. |
| PI-RSK-4.2 | Each realized risk leads to an analysis (had it been identified? did the response work?). | Analysis sheets for realized risks. |
| PI-RSK-4.3 | The anticipation rate is calculated (issues that occurred already in the register). | Indicator over at least 10 issues. |
| PI-RSK-4.4 | Data-specific risks (drifting source, volume, quality, compliance) are in the register. | Specific entries present. |
| PI-RSK-5.1 | A schedule or budget reserve is sized from the register. | Documented reserve calculation. |
| PI-RSK-5.2 | Risks influence decisions: a choice is modified to reduce exposure. | Tracked decision example. |
| PI-RSK-5.3 | Risks are consolidated across projects (shared dependencies, shared resources). | Portfolio view of risks. |
| PI-RSK-5.4 | Simulations (pre-mortem, scenarios) regularly feed the register. | Pre-mortem report with new entries. |
Detailed reading by level#
Level 1. Signs: “we'll see” ; the latest crisis rewrites the schedule. Benefit: no administration cost. Does not guarantee: avoiding repetition of the same crises. Difficulty: 1/5. Effort: 1/5.
Level 2. Signs: a risk table written at kickoff, rarely reopened. Benefit: awareness. Does not guarantee action is taken. Difficulty: 1/5. Effort: 1/5.
Level 3. Signs: the topic is on the weekly agenda; reduction actions exist. Benefit: real reduction in crises. Does not guarantee: exhaustiveness (the “unknown unknowns”). Difficulty: 3/5. Effort: 2/5.
Level 4. Signs: exposure curve, analysis sheets, known anticipation rate. Benefit: measured improvement in collective judgment. Does not guarantee the rating scale is calibrated. Difficulty: 4/5. Effort: 3/5.
Level 5. Signs: quantified reserves, influenced decisions, pre-mortems, portfolio view. Benefit: shock tolerance. Does not guarantee the absence of systemic risk outside the project scope. Difficulty: 5/5. Effort: 4/5.
Partial achievement and rating#
Common rule: see README.
- 0.5: the register exists but is updated only before committees; owners named without dated actions.
- 1: each major risk has a dated action and an owner who can discuss it without notes.
- A partial 5: measured anticipation rate (≈ 70%), schedule reserve derived from the register, annual pre-mortem; no portfolio view. Score ≈ 4.5.
Risk: “the sales force application API is limited in number of calls per hour; if volume doubles, daily extraction exceeds the overnight window, and morning reports are outdated.” Owner: datamart manager. Trigger: extraction duration > 70% of the window. Response: incremental extraction, prototype before the 15th of the month. The risk has a measurable trigger: that is what separates it from a concern.
Alibi register. Symptom: 60 lines rated “medium,” never addressed. Cause: the register is a deliverable rather than a tool. Remedy: limit to 10–15 active risks, require a dated action, close what no longer makes sense.
Goodhart: if the number of “red” risks is a target, they get rerated as yellow. Audit ratings on samples; compare rating and occurrence (4.3).
The pre-mortem (“let's imagine the project failed in six months: why?”) helps, in one short session (on the order of 45 minutes), bring out risks that classic identification misses, because it allows everyone to say what they sense.
Move to the next level#
Possible means (optional)
- 1 → 2: 30-minute kickoff workshop, shared list.
- 2 → 3: register with rating scale, owner, action, and trigger; 10-minute weekly check-in; see Project Management Fundamentals and Predictive Methods (waterfall, V-model, spiral, RUP, PMBOK, PRINCE2, Merise, CMMI).
- 3 → 4: exposure tracking; feedback on each realized risk; indicators in Project Metrics and Reporting.
- 4 → 5: management reserves, periodic pre-mortem, portfolio consolidation.
Useful for suggesting common risks for the project type and reviewing a register for omissions; limit: it does not have the memory of your incidents, and a “perfect” generated register gives an illusion of coverage. See AI for Project Management (General Then Data).
See also#
- Related themes: 02 Governance · 03 Planning · 06 Team · 09 Delivery · 10 Continuous Improvement.
- Other matrices: Security (DL) · Observability and Reliability (DL) · Security, Privacy, Compliance (data) · Data Sources and Contracts (data).
- Practice: Pitfalls and Good Practices in Project Management (Cross-Functional Synthesis) · Predictive Methods (waterfall, V-model, spiral, RUP, PMBOK, PRINCE2, Merise, CMMI) · Glossary.
✻ Written by Claude Sonnet 5.5
