Probability and Impact Matrix

Goal

The probability and impact matrix ranks the individual risks of a project by priority. It answers a project control question: which risks does the team spend its time and budget on first? IEC 31010 treats it as a screening tool for a register that holds many risks. The matrix names the risks that need deeper analysis, the risks the team treats first and the risks that the team escalates to management.

The technique produces scales that define each level of probability and impact. It produces a grid that ties a zone to each cell and a decision rule to each zone. The risk register receives the rating, the score and the zone of each risk.

The matrix is the rating instrument of risk analysis and management, which describes the whole process. The Perform Risk Analysis process of the PMBOK Guide assesses each risk by its probability and impact throughout the project. It adds a quantitative analysis when the project calls for one. The Manage risks task of HERMES 2022 asks for the same assessment: the probability of occurrence of each risk and the extent of the damage it would cause. The team records the result in the project status report.

Usage

When to use it

• A register of several dozen risks: sort the risks by what they need: a response, a quantified analysis or monitoring.
• A steering committee to brief: show on one page which risks fall in the high zone.
• End of a phase or release: re-rate the open risks before the next stage is released and see which ones changed zone.
• Threats and opportunities in the same register: rank them on a common probability scale.
• Scales already set by the organisation: the project adopts them and rates from the first workshop.
• A line manager in the room: silent individual rating comes before the discussion and keeps diverging views visible.
• A distributed team: everyone rates remotely in a shared spreadsheet. The session deals only with the gaps.

When not to use it

• A decision that depends on total exposure: scores do not add up. To size a reserve or to check that a date will hold, move to Monte Carlo simulation.
• The amount to commit to a response: the matrix sets an order and puts no figure on it. Decision trees compare the value in francs of several responses whose outcome is uncertain. Cost-benefit analysis compares the cost of a response with the expected loss it avoids.

Description

The elements of the matrix

The probability scale divides the chance that a risk occurs into levels. Each level carries bounds in per cent. The impact scale divides the effect of the risk on each project objective into levels. The grid plots one scale against the other. Each cell carries a score and a zone. Each zone carries a prioritisation rule: what the team does with a risk placed there.

The PMBOK Guide allows named levels (from very low to very high) or numeric values. With numeric values, the product of probability and impact gives the score. According to the PMBOK Guide, the organisation can set the prioritisation rules in advance in its organisational process assets. The project can also tailor them to its context. Steps 1 to 5 build the matrix for a project that receives nothing from the organisation. A project that inherits scales and zones starts at step 4. It first checks that its sponsor's thresholds match them.

1. Translate risk appetite into thresholds

The PMBOK Guide starts from the risk appetite of the stakeholders. The risk management plan expresses it for each project objective as measurable thresholds. These thresholds set the acceptable exposure. The definitions of probability and impact rest on them. The analyst obtains them from the sponsor before the first rating workshop. The analyst asks one question per objective: what delay, what cost overrun, what loss of quality will you tolerate?

A threshold becomes a scale bound. On a CHF 1.2 million project, the sponsor tolerates a two-week delay and a CHF 50'000 overrun. These two values form the upper bound of the Low level on the impact scale. A risk that exceeds them enters the Medium level. A scale built without these thresholds is argued over at every session because nobody knows what "medium" means.

2. Build the scales

According to the PMBOK Guide, a simple process usually has three levels and a detailed analysis most often has five. IEC 31010 cites three, four or five points as the most common. Three levels are enough for a team that rates for the first time. Five levels separate the risks better in a register of several dozen rows.

The impact scale carries one column per objective. Table 4-2 of the PMBOK Guide gives three: schedule, cost and quality. The guide notes that an ethical risk, a reputational risk or a risk to team morale may fit none of these columns. The team and the sponsor then define an impact column for the objective that the risk threatens. Failing that, the team enters the risk in the register outside the grid and notes why. A risk receives a rating on each objective it affects. The register keeps all these ratings. The team places the risk in the grid by the highest one. Otherwise a risk with a small delay and a large cost ranks on its low schedule rating. Its high cost rating goes unnoticed.

According to IEC 31010, the definition of each level must be as unambiguous as possible. A numeric definition carries its unit. "Likely" means 60% to one person and 90% to another. "More than 60 to 85% over the project's duration" means the same to everyone. The impact scale runs from the most severe credible consequence down to the smallest one that deserves attention. The lowest probability must remain acceptable for the highest impact. Otherwise any activity whose worst consequence is severe becomes intolerable, whatever its probability.

The two scales can grow in different steps. In the example of Figure 5-14 of the PMBOK Guide, probability rises from 0.10 to 0.90 in equal steps. Impact doubles at each level: 0.05, 0.10, 0.20, 0.40, 0.80. This choice gives impact more weight than probability. A near-certain risk with a very low impact scores 0.90 × 0.05 = 0.045 there. A very unlikely risk with a very high impact scores 0.10 × 0.80 = 0.08 and ranks ahead. On two scales from 1 to 5, both would score 5. IEC 31010 leaves the weighting of the grid open: more weight on the consequence, more weight on the probability or equal weight. The team decides before the rating and records its choice in the risk management plan.

3. Set the zones and their rules

The product of the weights gives twenty-five scores. As in Figure 5-14, they are rounded to two decimals. The PMBOK Guide shades its grid in three colours and publishes no threshold between them. Like the prioritisation rules, the thresholds belong to the organisation or the project. The project sets the high zone at 0.20 and above. It sets the low zone at 0.05 and below. The scores in between form the medium zone.

A zone without a rule colours the grid and decides nothing. IEC 31010 links each level of risk to a decision rule: the attention of management, the time allowed for a response. The project records its own rules in the risk management plan. The thresholds of step 1 bound the scales. The zone rules decide who treats the risk. The sponsor steps in for the high zone.

Before approving the zones, the analyst applies the IEC 31010 rule on the lowest probability: does a very high impact remain acceptable at the Very low level? In the project grid, a risk with a chance of 15% or less of a cost overrun above CHF 250'000 falls in the medium zone (0.08). If the sponsor judges this risk unacceptable, the bound of the Very low level is too high. The project lowers it or adds a level below it.

4. Rate the risks in a session

The team rates the risks in interviews or meetings. The participants are team members and subject-matter experts from outside the project. They know the types of risk in the register. For each risk, they estimate the probability and the impact on each objective with the definitions of the risk management plan. They record the assumptions behind each level. According to the PMBOK Guide, differences between participants are to be expected and examined.

A gap of two levels often signals information that one person holds and the other does not. The developer rates "high" because he knows about the vendor's delay on another contract. The project manager rates "low" because he has read the contract. The facilitator has everyone rate in silence before the discussion. A rating given first and out loud by the most senior participant anchors all the ratings that follow.

According to IEC 31010, the team rates the probability of the consequence it chooses. The payroll server fails twice a year. A failure that stops the month's salaries from being paid is rarer. If the team chooses that consequence, it rates the probability that the salaries go unpaid. The team chooses between the most frequent consequence and the most severe credible one. When both matter, it enters them as two rows of the register.

5. Rank and review the ranking

Within a zone, the score orders the risks: the PMBOK Guide gives this role to the product of the two values. The register keeps the probability-impact pair next to the score. Two risks with the same score can call for different responses. For one, the response reduces the probability. For the other, it limits the impact.

The PMBOK Guide cites other criteria for qualitative analysis: when the impact would occur, how much control the team has over the risk, its links with other risks, common causes or effects. The grid shows none of them. The team reads them in the register. It can raise a risk above its zone and record why.

The PMBOK Guide puts risks of low probability and low impact on a watch list in the register. The analysis repeats throughout the project. At each review, the team re-rates the open risks. The review looks for the risks that change cell.

Threats and opportunities on the same grid

The PMBOK Guide sets the Risk performance domain a dual aim: increase the probability and impact of positive risks and decrease the probability and impact of negative risks. The guide places both on one matrix. A negative impact definition rates the threat. A positive definition rates the opportunity. Figure 5-14 draws the grid as a mirror: threats on the left, opportunities on the right, the same probability scale on both sides.

The same scale reads in both directions. For a threat, the Medium level means more than two to four weeks of delay or more than CHF 50'000 to 100'000 of overrun. For an opportunity, it means more than two to four weeks gained or more than CHF 50'000 to 100'000 saved. An opportunity in the high zone calls for a response just as a threat does. The responses specific to opportunities belong to opportunity analysis.

HERMES 2022 defines risks as potential events that cause damage. A team that keeps to this definition rates only threats and leaves the right half of the grid empty.

What the grid does not show

Cox (2008) identifies the flaws of risk matrices. One cell receives very different risks. A smaller risk can receive a higher rating than a larger one. The grid gives no basis for allocating resources between responses.

With the project's scales, a risk A of 16% on CHF 55'000 and a risk B of 38% on CHF 95'000 fall in the same cell (0.30 × 0.20 = 0.06). Their expected losses are CHF 8'800 and CHF 36'100: a ratio of four.

A risk C of 62% on CHF 22'000 falls in the medium zone (0.70 × 0.10 = 0.07). A risk D of 14% on CHF 240'000 falls in the low zone (0.10 × 0.40 = 0.04). Yet D carries an expected loss of CHF 33'600. C carries CHF 13'640. The grid reverses the order of the two.

These calculations assume an estimate in francs that the grid does not use. When the team has this estimate, it keeps it in the register. It checks the ranking of the risks close to a zone boundary.

According to IEC 31010, risks do not add up: no number of low risks equals a medium risk. The grid therefore gives no overall exposure. The rating is subjective. Two assessors often rate the same risk at different levels. Risks of different categories compare poorly. Two distinct consequences of one cause remain two rows of the register. The flaw comes from a consequence split into ever finer scenarios: each row receives a lower probability. The grid then underestimates the total risk. The team sets the split before the rating.

Krisper (2021) lists twenty-four problems of matrices with ordinal scales, where each level follows the previous one without a measured gap between them. He argues for fully quantitative methods. In practice, the matrix sorts some thirty risks in one committee session and names the risks that deserve a calculation. The quantitative analysis of the Perform Risk Analysis process does that calculation: the overall exposure, the contingency reserve, the probability of meeting a date. Monte Carlo simulation is its usual tool. Decision trees compare the value in francs of several responses whose outcome is uncertain. Cost-benefit analysis decides whether a response is justified: it compares the cost of the response with the expected loss it avoids.

AI considerations

A language model writes a first draft of the scale definitions from the thresholds in the risk management plan. The analyst checks that each bound matches one of the sponsor's thresholds. The model also reviews the register. It flags risks with no written consequence, ratings that contradict the assumption noted beside them and risks split into neighbouring scenarios. A spreadsheet or a script calculates the scores and draws the grid. The model spots the risks close to a zone boundary for the team to review in the session.

The rating belongs to the group. It rests on what the participants know about the vendor, the team and the context. The model does not know these things. If the facilitator shows a model's rating before the silent rating, it anchors all the others. The facilitator shows it after the rating. There it counts as the view of one more participant. The thresholds commit the sponsor: only the sponsor sets them.

The register of a project names suppliers, contracts and sometimes employees. Personal data falls under the Federal Act on Data Protection (FADP). The analyst removes it before submitting the register to a model hosted outside the organisation.

Examples

The CHF 1.2 million project replaces the payroll software of a municipality. Its register applies its scales and zones to five risks.

T1 also affects cost at the Low level (0.10). The register keeps this rating. The grid places T1 by its schedule rating, which is the higher one.

T1 is the most probable threat in the register. T2 ranks ahead of it because the impact scale doubles from one level to the next. A tax configuration missed on 1 January reaches the very high level. On two scales from 1 to 5, T1 would score 16 and rank ahead of T2 at 15.

Visualisations

The scales, the zones and the register fit into rows and columns: they are HTML tables. The grid needs a diagram. The position of a risk in the grid shows its probability, its impact and its zone at a glance. Threats sit on the left and opportunities on the right. A second diagram places risks A, B, C and D in their cells with their expected loss. It shows where the order of the cells and the order of the losses diverge.

Cost

Tools

A spreadsheet is enough for most projects. A formula calculates the score. Conditional formatting colours the zone. A pivot table places the risk references in the cells. In the room, a grid drawn on a whiteboard takes one sticky note per risk. The team sees the risks move from cell to cell during the discussion. For a distributed team, a digital whiteboard such as Miro or Mural carries the same grid. An online form collects the individual ratings before the session.

Project management software and governance, risk and compliance (GRC) modules draw the grid from the register and keep it current. They keep the history of the ratings from one review to the next. For quantitative analysis, tools such as @RISK or Oracle Primavera Risk Analysis take over from the grid.

Sources

• Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK Guide), 8th ed., PMI: the dual aim of the Risk performance domain (§2.7); the Perform Risk Analysis process and its assessment criteria (§2.7.2.3, Figure 2-50); risk appetite, the definitions of probability and impact, the number of levels and the scale per objective (Section 4, Table 4-2); the grid shared by threats and opportunities, the score and its numeric example (Section 5, Figure 5-14); rating in a group, differences between participants and the watch list (Section 5).
• IEC 31010:2019, Risk management, Risk assessment techniques, IEC/ISO: the matrix as a screening tool, the requirements on the scales, the weighting of the grid, the decision rules per level, the choice of the consequence rated and the limits of the technique.
• Federal Chancellery, HERMES 2022, Project Management Reference Manual, task 5.4.3.41 Manage risks: the assessment of the probability of occurrence and the extent of damage and its recording in the project status report.
• Cox, L. A. Jr., "What's Wrong with Risk Matrices?", Risk Analysis 28(2), 2008, pp. 497-512: the low resolution of the cells, ranking errors and the lack of a basis for allocating resources.
• Krisper, M., "Problems with Risk Matrices Using Ordinal Scales", arXiv:2103.05440, 2021: an inventory of the problems of matrices with ordinal scales. The author argues for quantitative methods.