Risk Management in PM²: anticipating uncertainty before it becomes a problem
Eighteenth article in the “Learning PM² Through a Project” series
A risk is not a problem that has already happened. It is an uncertain event or condition that, if it occurs, may affect the project’s objectives, schedule, cost, quality, scope or benefits.
Risk Management in PM² does not promise to eliminate all uncertainty. It makes uncertainty visible, assesses it and manages it with reasonable actions before it becomes an issue.
Risk and issue: the essential boundary
| Term | State | Example |
|---|---|---|
| Risk | Possible, not yet happened | The push provider may change its policies before go-live. |
| Issue | Real, current or already happened | The provider has changed its policy and notifications are no longer sent. |
When a risk materialises, it does not remain merely a “red risk”: it becomes an issue and must be managed as such. The Risk Log still preserves history and learning.
The risk-management cycle
flowchart LR
A[Identify] --> B[Analyse]
B --> C[Evaluate and prioritise]
C --> D[Plan response]
D --> E[Assign owner and actions]
E --> F[Monitor residual risk]
F --> A
It is a cycle, not an initiation activity. New dependencies, priority changes, test results, suppliers and stakeholders can create risks or change the profile of known ones.
Identifying a risk well
A useful formulation links cause, event and effect:
Because of [cause], there may be [event], resulting in [effect on the project].
Example:
Because of dependency on an external provider, push-notification policy may change, resulting in delayed go-live or reduced planned functionality.
Writing “notification risk” does not help decision-making or response design.
Analysis: probability and impact
PM² uses probability and impact analysis to focus project attention. Impact may concern one or more areas: objectives, schedule, cost, quality, scope, security, reputation or benefits.
| Probability / impact | Indicative approach |
|---|---|
| Low / low | Monitor lightly. |
| High / low | Reduce probability if the cost is reasonable. |
| Low / high | Prepare a response or contingency plan. |
| High / high | Immediate priority; escalate if it exceeds tolerances. |
A score helps compare risks but does not replace judgement. A rare risk with very high regulatory or security impact may require priority attention even if the “probability × impact” product is not the highest.
Response strategies
For threats, common responses are:
| Strategy | Meaning | Example |
|---|---|---|
| Avoid | Change the plan to eliminate the cause or risk. | Do not depend on a supplier’s beta feature. |
| Mitigate | Reduce probability or impact. | Create a prototype and test push integration early. |
| Transfer | Shift part of responsibility or impact to a third party, without removing oversight. | Contract with provider SLA and support. |
| Accept | Consciously decide not to act beyond monitoring, often with a contingency. | Accept a minor risk with a manual procedure ready. |
The mistake is choosing “accept” because there was no time to analyse. Acceptance must be conscious and proportionate to project authority and tolerances.
Opportunities can be managed in a corresponding way: exploit, enhance, share or accept them. Risk is not always negative, even though project practice often uses the term for threats.
Risk owner and actions: without them, the log is only an archive
Each material risk should have at least:
| Field | Purpose |
|---|---|
| Cause-event-effect description | Understand precisely what may happen. |
| Probability and impact | Prioritise. |
| Risk owner | Person accountable for monitoring and driving the response. |
| Actions and due dates | Make the response concrete. |
| Triggers / early indicators | Know when to activate contingency or escalation. |
| Residual risk | Understand what remains after actions. |
The risk owner is not necessarily the person who performs every action, and is not automatically the PM. The PM ensures the process works; the risk owner watches that specific risk and reports changes.
The Annotatio case: adoption risk
For Smart Bookings, the team sees that floor collaborators may continue handling bookings informally because they are used to WhatsApp and phone calls.
| Element | Definition |
|---|---|
| Cause | New process is perceived as slower and unfamiliar. |
| Event | Collaborators do not systematically use Annotatio at go-live. |
| Effect | Inconsistent data, double-booked places, reduced benefits and higher support cost. |
| Probability / impact | Medium / high. |
| Response | Mitigate: guided trial, short training, operating instructions and close support in the first week. |
| Trigger | During the pilot, more than 10% of bookings are still managed outside the system. |
| Owner | Business Manager or gym operational lead. |
This is a business-implementation risk, not a “technical-team problem”. Handling it early can protect benefits more than many code optimisations.
Risk appetite and tolerances
Organisations do not accept the same level of risk. Risk appetite indicates how much risk they are generally willing to accept; tolerances translate that attitude into practical project limits.
When a risk exceeds tolerances or requires a trade-off on budget, scope or date, the PM should escalate it to competent governance with analysis and recommendation. Waiting for absolute certainty can make the decision late and more costly.
Do not confuse these
| Statement | Correction |
|---|---|
| “A risk is a possible problem.” | It is an uncertain event; when it is present or has occurred, it becomes an issue. |
| “The Risk Log is completed at initiation.” | It must be updated throughout the project. |
| “Accepting a risk means ignoring it.” | It means consciously choosing a response, often with monitoring and contingency. |
| “The PM owns every risk.” | The PM manages the process; each risk should be assigned to the most suitable owner. |
Three questions to anchor it
- What cause, event and effect define this risk?
- Which early signal would tell you it is increasing?
- Which response genuinely reduces probability or impact, and who owns it?
Flashcards
Q: What is the difference between a risk and an issue?
A: A risk is uncertain and future; an issue is real, current or has already occurred.
Q: What should a well-managed risk contain?
A: Description, assessment, owner, response, actions, triggers and residual risk.
Q: What does accepting a risk mean?
A: Consciously deciding not to reduce it further, while retaining monitoring and, where appropriate, contingency.
Exam-style question
A supplier says delivery of a component may be delayed by three weeks. The PM immediately opens an issue and sets a new release date.
What is the correct approach?
Answer: as long as the delay has not occurred, it is a risk. The PM should assess probability and impact, define response and contingency, assign an owner and escalate if it exceeds tolerances. Changing the release baseline requires a governance decision, not an automatic change.
Source
Risk Management, the Risk Management Plan, Risk Log and probability/impact matrix are covered in the European Commission’s PM² Methodology Guide 3.1.
Next: Issue and Decision Management, for addressing real problems and documenting the decisions that change a project’s course.