Project risk management is the discipline of identifying, ahead of time, the events that could derail scope, schedule, budget or quality, ranking them by probability and impact, and deciding what to do about them before they happen. It is not a form filled in at kick-off and forgotten: it is a loop run at every review. This guide covers the 5-step process, a probability × impact risk matrix, a sample risk register, the four response strategies, risk examples by family, the structure of a risk management plan and how to track risks in a steering committee.
Project risk management: risk or issue?
A risk is an uncertain future event that, if it occurs, would affect at least one project objective. It has two dimensions: a probability of occurring and an impact if it does. An issue (or problem) is an event that has already happened: the probability is 100% and it now calls for an action, not a response plan. The distinction matters: a risk register filled with issues is an action log in disguise, and nobody anticipates anything any more. A risk can also be positive — an opportunity such as an earlier delivery or a reusable component — and it is handled with the same tools.
A well-written risk names three things: the cause (the fact you can observe today), the event (what could happen) and the effect on the project. “Delay” is not a risk. “Because the business expert is on leave in August (cause), acceptance testing could be pushed back three weeks (event), delaying go-live past the fiscal year-end (effect)” is one.
The risk management process in 5 steps
The process is the same whatever the method — PMBOK, PRINCE2, ISO 31000 — only the vocabulary changes. It is run in full at launch, then rerun at each review for new risks.
- Identify: list the risks with the team, using the plan, the deliverables, past projects’ registers, checklists by family (schedule, resources, technical, budget, suppliers, organisation) and interviews with stakeholders. Write each risk as cause – event – effect.
- Analyse: rate each risk’s probability and impact on a shared scale (1 to 4 or 1 to 5), then compute criticality = probability × impact. Add the trigger: the observable signal that the risk is materialising.
- Evaluate and prioritise: place the risks on the risk matrix, keep the 8 to 15 most critical for active treatment, and put the others under simple watch.
- Treat: choose a response strategy for each priority risk (avoid, reduce, transfer, accept), turn it into dated actions with an owner, and write a contingency plan for critical risks.
- Monitor: review the register every two weeks, update probability and impact, close risks that have passed, add new ones, and escalate those that cross the thresholds set in the risk management plan.
The risk matrix: probability × impact
The risk matrix (or probability and impact matrix) turns two ratings into a single criticality score, so risks can be compared and the ones worth an action singled out. A 4 × 4 grid avoids the “everything in the middle” effect of odd-sized scales. Criticality thresholds: 1–3 low, 4–6 moderate, 8–9 high, 12–16 critical.
| Probability \ Impact | Minor (1) | Moderate (2) | Major (3) | Critical (4) |
|---|---|---|---|---|
| Very likely (4) – more than 70% | 4 – moderate | 8 – high | 12 – critical | 16 – critical |
| Likely (3) – 40 to 70% | 3 – low | 6 – moderate | 9 – high | 12 – critical |
| Unlikely (2) – 10 to 40% | 2 – low | 4 – moderate | 6 – moderate | 8 – high |
| Rare (1) – less than 10% | 1 – low | 2 – low | 3 – low | 4 – moderate |
The scales must be defined in writing before rating starts, or every contributor uses their own. Example of an impact scale for a six-month, €400k project: minor = less than a week of delay or under €10k; moderate = 1 to 3 weeks or €10k to €40k; major = 1 to 2 months or €40k to €100k; critical = a missed contractual milestone, more than €100k, or a regulatory breach. Probability is rated as a range, never as a decimal nobody can defend.
Sample risk register
The risk register is the living document of the process: one row per risk, updated at every review. Example for a CRM deployment project, rated on the 4 × 4 matrix above:
| Risk | Probability | Impact | Criticality | Response | Owner | Status |
|---|---|---|---|---|---|---|
| Customer data to migrate is poor quality (duplicates, empty fields) | 4 | 3 | 12 – critical | Reduce: data audit and cleansing before migration, dry-run migration | Julie T. (data lead) | In progress |
| Integrator delivers the ERP connector late | 3 | 4 | 12 – critical | Transfer: late-delivery penalties in the contract, intermediate delivery milestone | Marc D. (procurement) | Open |
| Business expert unavailable during acceptance testing (summer leave) | 3 | 3 | 9 – high | Reduce: book two weeks of testing before 15 July, name a deputy | Claire M. (project manager) | In progress |
| Sales teams reject the tool (habit change) | 3 | 3 | 9 – high | Reduce: one ambassador per team, training before cut-over | Sophie L. (change lead) | Open |
| Data loss during cut-over | 1 | 4 | 4 – moderate | Avoid: full backup and tested rollback plan before go-live | Karim B. (IT) | Open |
| Licence budget overrun (user count underestimated) | 2 | 2 | 4 – moderate | Reduce: user census validated by each department | Claire M. (project manager) | Closed |
| Personal-data regulation changes mid-project | 1 | 3 | 3 – low | Accept: watch, 5-day contingency reserve | Karim B. (IT) | Watch |
Beyond these seven columns, a useful register also carries the trigger, the date of the last review, the residual criticality after treatment and a link to the actions. The two critical risks are the only ones discussed in steering committee; the others are handled by the project manager. The closed risk stays in the register: it documents that the question was asked and answered.
The 4 risk response strategies
Each priority risk gets one strategy — sometimes two combined. The choice depends on criticality, on the levers available and on the cost of the response compared with the expected loss (probability × financial impact).
| Strategy | When to use it | Example |
|---|---|---|
| Avoid | The impact is unacceptable and the cause can be removed by changing the plan | Replace an unproven technology with a mastered one; take a high-risk feature out of scope; move a milestone off the year-end freeze |
| Reduce (mitigate) | The general case: high criticality and levers to lower probability or impact | Build a prototype before committing; test early; train users before cut-over; pair a key person with a deputy |
| Transfer | The impact is mainly financial and a third party is better placed to bear it | Insurance; contractual penalties; fixed price instead of time and materials; supplier warranty |
| Accept | Low criticality, or the response would cost more than the expected loss | Watch the trigger; set aside a contingency reserve (time or budget); write a contingency plan to activate if the risk occurs |
Acceptance is a decision, not an omission. It is recorded, with the reserve set aside and the contingency plan attached. For opportunities the mirror strategies apply: exploit, enhance, share, accept.
Project risk examples by family
Checklists by family speed up identification and reduce blind spots. Common examples, to adapt to your context:
- Schedule: optimistic estimates without contingency; dependency on a deliverable from another project; critical path with no float; milestone set in the summer holidays or the year-end freeze.
- Resources: key person available only part-time; departure of an expert mid-project; skill not present in-house; team over-allocated across three projects at the same time.
- Technical: unproven technology; integration with a legacy system that is poorly documented; performance not tested at full volume; poor quality of data to migrate.
- Budget: exchange rate or price increase on a purchase; user count underestimated on licences; hidden costs (training, support, run); no contingency reserve.
- Suppliers and contracts: late delivery by an integrator; supplier financial failure; vague contractual scope; deliverable acceptance criteria not defined.
- Organisation and stakeholders: sponsor changes; scope creep from a department; user resistance to change; conflicting priorities between two business units; late decisions from the steering committee.
The risk management plan: what it contains
The risk management plan is the short document — two to four pages — that sets the rules of the game before the first risk is rated. It is written at launch, approved with the project charter and rarely changes. Typical structure:
- Objectives and scope: what is covered (the project, its dependencies, its suppliers) and the risk tolerance set by the sponsor.
- Roles: who identifies (the whole team), who owns each risk (one named owner, never “the team”), who arbitrates (project committee, steering committee).
- Probability and impact scales, with the written definition of each level, and the matrix with its criticality thresholds.
- Risk families used for identification and reporting.
- Escalation thresholds: at which criticality a risk goes to the steering committee, and within what timeframe.
- Review cadence: frequency of the risk review and its place in existing rituals.
- Contingency reserve: the time and budget set aside for accepted risks, and who can release them.
- Register format and tooling, and how risks are reported in the status report.
Tracking risks in committee: review and escalation thresholds
A register that is not reviewed decays within a month. The review is part of the project’s existing rituals rather than a separate meeting: fifteen minutes every two weeks with the workstream leads, and a dedicated item at each steering committee. At each review: has a trigger fired? Have probability or impact changed? Are the actions on time? Which risks are closed, which are new?
Escalation thresholds, written in the risk management plan, decide who handles what:
- Criticality 12 to 16 (critical): presented at every steering committee with its response plan and its contingency plan; a new critical risk is reported to the sponsor within 48 hours.
- Criticality 8 to 9 (high): handled in the project committee; a reduction action with a due date is mandatory.
- Criticality 6 or less: managed by the project manager and the risk owner; watched, mentioned in the status report only if it changes.
- Any risk whose trigger has fired becomes an issue: it leaves the register for the action log and its contingency plan is activated.
Common project risk management mistakes
- The register written once: filled in at kick-off to satisfy the method, never reopened. Symptom: probabilities that have not changed in four months.
- Risks without an owner, or with “the team” as owner: nobody watches the trigger, nobody runs the action.
- Confusing risk and issue: the register fills up with events that have already happened, and the anticipation work stops.
- No contingency plan for critical risks: when the risk occurs, the response is improvised under pressure.
- Vague risks (“delay”, “budget”) that cannot be rated or treated; write cause – event – effect.
- Fifty risks all rated “moderate”: the matrix no longer discriminates; keep 8 to 15 under active treatment.
- Responses without a due date or a check: the action is decided, then nobody verifies that it lowered the criticality.
- Risks assessed project by project only: the same resource at 140% load on three projects is invisible in each individual register.
Project risk management in FoxPlan
In FoxPlan, risks are attached to the project with a probability, an impact, an owner and a status, alongside the decisions and actions that follow from them — so a response plan becomes dated actions tracked to closure. The Committees module puts the risk review on the agenda of each steering committee session, and the project status report (project weather) carries the state of the risks alongside schedule, effort and budget. At portfolio level, dashboards consolidate the risks of all projects for the PMO and management.
See how to do it in the FoxPlan documentation ↗
Frequently asked questions
What is project risk management?
Project risk management is the process of identifying the uncertain events that could affect a project’s scope, schedule, budget or quality, rating them by probability and impact, choosing a response (avoid, reduce, transfer, accept) and tracking them until the project closes. It relies on a risk register, a probability × impact matrix and a review at each project ritual.
How do you build a risk matrix?
Define a probability scale and an impact scale (1 to 4 each) with a written definition of every level, then rate each risk and multiply the two scores. Place the risks on the 4 × 4 grid: 1 to 3 is low, 4 to 6 moderate, 8 to 9 high, 12 to 16 critical. Critical risks get a response plan and a contingency plan; low ones are simply watched.
What is the difference between a risk and an issue?
A risk is a future event that may or may not occur; it has a probability and an impact, and it calls for a response plan. An issue has already happened: its probability is 100% and it calls for an action now. When a risk’s trigger fires, it leaves the risk register and enters the action log, and its contingency plan is activated.
What is a risk register?
A risk register is the table that lists a project’s risks with, for each one, its description (cause, event, effect), probability, impact, criticality, response strategy, owner, status and trigger. It is created at launch and updated at every review, typically every two weeks. Closed risks stay in it as a record.
How do you calculate the criticality of a risk?
Criticality = probability × impact, each rated on the same scale (1 to 4 or 1 to 5). A risk rated 3 in probability and 4 in impact has a criticality of 12, which is critical on a 4 × 4 matrix. Some teams add a third factor, detectability, to obtain a risk priority number as in FMEA.
What are the four risk response strategies?
Avoid (change the plan to remove the cause), reduce or mitigate (lower probability or impact through actions), transfer (pass the financial impact to a third party through insurance or contract) and accept (watch, set aside a reserve and prepare a contingency plan). For opportunities the mirror strategies are exploit, enhance, share and accept.
