Why risk management isn't optional
Many projects treat risk management as an administrative formality done once at the start, filled in to check a box, then never revisited. This approach misses the point: risks evolve along with the project. A risk flagged as minor at kickoff can become critical three months later if the context changes — a new supplier, a regulatory constraint, a key person leaving.
Conversely, active risk management, regularly updated, lets you anticipate problems before they become costly to fix, and make informed decisions rather than reactive ones.
Identify the risks
Risk identification should draw on several sources: experience from similar projects, feedback from the project team, discussions with stakeholders, and an analysis of the external context (market, regulation, technical dependencies). An identification workshop at the start of the project, complemented by regular check-ins, produces better results than one person's isolated thinking.
- Technical risks: complexity, dependencies, technical debt
- Organizational risks: resource availability, turnover
- External risks: suppliers, regulation, market
- Scope-related risks: ambiguous needs, scope creep
Assess and prioritize: probability and impact
Every identified risk should be assessed on two combined criteria: its probability of occurring, and the impact it would have on the project if it did (schedule, cost, quality). A probability/impact matrix, even a simple one (low/medium/high on each axis), lets you quickly visualize which risks deserve priority attention.
A risk that's both likely and high-impact should be treated first. An unlikely but catastrophic risk still deserves a contingency plan, even without immediate action. A frequent but minor risk can often be accepted without specific treatment.
A 3x3 matrix (low/medium/high probability × low/medium/high impact) is enough for the vast majority of projects — finer granularity complicates the exercise without necessarily improving decision quality.
The four risk treatment strategies
Once a risk is assessed, four treatment strategies are possible. Avoid: change the project plan to eliminate the risk at the source. Reduce: act to lower probability or impact without eliminating it entirely. Transfer: shift the consequence of the risk onto a third party, for example through insurance or a contract clause. Accept: do nothing specific, knowingly, generally for low-impact risks.
- Avoid — remove the cause of the risk
- Reduce — lower the probability or impact
- Transfer — shift the consequence onto a third party
- Accept — take on the risk knowingly
Continuous tracking through a risk register
A risk register centralizes all identified risks, their assessment, the chosen strategy, and who's responsible for tracking them. This register should be reviewed at every major project milestone — not just when it's created — to add new risks, reassess existing ones, and close out those no longer relevant.
A risk register that's never updated after its creation quickly loses all usefulness: it becomes an administrative artifact rather than a real steering tool.
Risk, issue, and the vocabulary that ties them together
Getting the vocabulary precise matters here: a risk register that mixes up risks (uncertain, future) with issues (confirmed, already happening) tends to lose credibility with a steering committee, since the two call for different kinds of action — anticipation for risks, resolution for issues.
Go further
Frequently asked questions
How often should the risk register be reviewed?
At minimum at every major project milestone, and ideally at every steering committee. A high-stakes project or one operating in an unstable context may justify more frequent reviews.
Who should be responsible for tracking a risk?
Every risk in the register should have a named owner, responsible for tracking its evolution and triggering the treatment plan if needed. Without a clear owner, a risk tends to be tracked diffusely, meaning poorly.
How do you tell a risk apart from a problem?
A risk is an uncertain event that might occur in the future. A problem is an event that has already occurred and has a confirmed impact on the project. An untreated risk that materializes becomes a problem.
Should every risk be documented, even minor ones?
Not necessarily in detail. Minor, low-impact risks can be noted briefly, without an elaborate treatment plan, so as not to unnecessarily burden the register at the expense of tracking priority risks.
Does risk management differ in an agile context?
The principle stays the same, but the rhythm changes: in agile, risks are often reassessed every sprint rather than at more spaced-out milestones, which allows faster detection of emerging risks.
What's the most commonly underestimated risk in projects?
Scope creep is frequently underestimated: each change request seems minor in isolation, but their cumulative effect can significantly affect schedule and budget without any formal alert ever being triggered.
Should a budget contingency reserve be planned for risks?
It's a common and recommended practice: a financial or schedule reserve, sized according to the project's overall risk exposure, absorbs the consequences of risks that materialize without systematically requiring a renegotiation of the overall budget.
Who should attend the risk identification workshop?
Ideally a mix of the project team, key stakeholders and, where relevant, people who worked on similar past projects — a group broad enough to surface blind spots, but small enough to keep the discussion focused and productive.
← How to Become a Product Owner
Next article: How to Prepare PMP or PRINCE2 with Flashcards →