Within the world of risk management – a common aspect of improvement projects – there is a distinction between response and mitigation. A response is taken in reaction to risk, while mitigation is undertaken proactively. Thus, responses are implemented once risk materializes, and mitigation actions must be planned and implemented before a risk presents itself. The focus of this article is on mitigation actions and exploring both the limitations of a traditional risk analysis model and a method for overcoming these limitations.

Urgency and Importance

As with any aspect of business, risk mitigation planning, execution, and monitoring and control are constrained by cost, time, scope and quality. Typically, not all possible mitigation actions can be implemented; they must be prioritized so that the activities that will provide the biggest help to a project are implemented. Prioritization of any action is typically guided by two factors – urgency and importance.

The urgency of risk mitigation activities can be derived based on the time dependency of risk. Few risks are time dependent (i.e., they occur at a specific time in the project), while others may occur at any time throughout the project. That timing will inform the urgency of a particular mitigation action. For example, a mitigation action for a risk that may occur a year from now will be prioritized at a “low urgency” level compared to the mitigation action for another risk that may occur in the next month.

But how is the importance of risk mitigation determined? In the classic failure mode and effects analysis (FMEA) model, mitigation activities are prioritized based on the priority of the risk, that is, the calculated risk priority number (Table 1).

Table 1: Assessing Risk Priorities with FMEA Model
Process/Activity	Risk	Impact (I) (1 = low, 10 = high)	Control (C) (1 = low, 10 = high)	Occurrence (O) (1 = low, 10 = high)	Risk Priority Number (RPN = I * C * O)
P1	R1	8	6	5	240
P1	R2	6	6	7	252
P2	R3	2	8	8	128
P2	R4	8	9	1	72
P2	R5	3	3	4	36
P3	R6	7	5	9	315

Limitations of Prioritizing Mitigation Actions with FMEA

Using only the RPN evaluation to prioritize risk mitigation actions, however, has some limitations.

1. For example, as shown in Table 1, the mitigation activity associated with risk R6 – the risk with the highest RPN – is given highest priority. Assume that mitigation activity X will mitigate the highest priority risk, R6. Another mitigation activity, Y, will mitigate risks R2 and R4. But what if mitigation activity Y is less costly to implement than X? Does that cost benefit justify implementing Y before X? There is no way to calculate this with FMEA.

2. An FMEA assumes that each risk is an independent event. In real life, however, there are dependent as well as independent risks. For example, the risks in a particular project were identified and one risk is related to other risk as shown in Table 2.

Table 2: Sample Risks and Results
Risk Identifier	Risk	Result
A	Requirements not defined clearly	Solution does not meet the needs of the end user
B	High number of code redeployments	Environment instability and unavailability
C	Less-skilled development resources	Higher number of defects; increased effort required; schedule slippage

In this case, without clearly defined requirements available at the start of the project (Risk A), the requirements are sure to change at least once (and likely multiple times) over the course of the project. Design and development changes are likely to increase the number of code redeployments (Risk B). Similarly, less-skilled development resources (Risk C) will lead to a higher number of expected defects, and those defects will also require multiple code deployments.

The probability of Risk B is influenced by the probability of Risk A as well as Risk C. Further complicating matters, Risks A and C are mutually exclusive. Additionally, the probability of Risk B is not only dependent on the probability of Risks A and C, but is also a function of other independent (and uncertain) events.

FMEA does not distinguish between these relationships ? independent risks and dependent risks are treated in the same way.

3. Mitigation activities are planned as if one activity is independent of other. At times, however, one mitigation activity may mitigate more than one risk or a mitigation action may mitigate a risk partially.

Considering the same example shown in Table 2, prototyping as a mitigation action might help to achieve clear requirements (Risk A), which could result in fewer code redeployments, thereby also reducing or eliminating Risk B.

The classic FMEA model does not help users identify these dependencies.

Risk Mitigation Matrix

How can the limitations of FMEA be overcome? By supplementing FMEA with a risk mitigation matrix. A risk mitigation matrix is represented by a table with risks as the columns and mitigation actions as the rows. Each cell of the matrix is assigned a risk mitigation index (RMI) – either a one (1) or zero (0), where:

• One (1) means the risk is being mitigated by a given action and
• Zero (0) means the risk is not being mitigated by a given action

(For risks that are being partially affected, values between 0 and 1 can be used.)

The last column in the table is the risk mitigation number (RMN), which is the sum product of RPNs and their respective RMIs. For the sample data in Table 3, the RMN for mitigation action M1, for example, is calculated as:

RMN_M1 = (RPN_R1 * RMI_M1-R1) + (RPN_R2 * RMI_M1-R2) +(RPN_R3 * RMI_M1-R3) +
(RPN_R4 * RMI_M1-R4) + (RPN_R5 * RMI_M1-R5) +(RPN_R6 * RMI_M1-R6)

or

RMN_M1 = (252 * 1) + (128 * 1) = 380

Table 3: Risk Mitigation Matrix
Risks	Risk R1	Risk R2	Risk R3	Risk R4	Risk R5	Risk R6	Risk Mitigation Number (RMN)
RPN	240	252	128	72	36	315
Mitigation action M1	0	1	1	0	0	0	380
Mitigation action M2	0	0	0	0	0	1	315
Mitigation action M3	1	0	0	1	1	0	348
Mitigation action M4	0	1	1	1	0	0	452
Mitigation action M5	0	0	0	0	1	1	351
Mitigation action M6	1	0	0	0	0	0	240
Mitigation action M7	0	1	0	0	0	0	252
Mitigation action M8	0	0	0	0	1	0	36

If looking at the classic FMEA model, M2 or M5 would have been implemented first as they mitigate the highest RPN risk (risk 6 with an RPN of 315). Now, by using the RMM and looking at the RMN, it is clear that the first mitigation action that should be implemented is neither M2 nor M5. To achieve the greatest benefit, mitigation action M4 (RMN = 452) should be implemented first.

The revised action plan, in priority order of mitigation action to implement, is shown in Table 4.

Table 4: Reprioritized Mitigation Actions
Priority	Mitigation Action	RMN	Risks Affected
1	M4	452	R2, R3 and R4
2	M1	380	R2 and R3
3	M5	351	R5 and R6
4	M3	348	R1, R4 and R5
5	M2	315	R6
6	M7	252	R2
7	M6	240	R1
8	M8	36	R5

The mitigation actions can also be plotted on an urgency-importance matrix as shown below.

This visual representation can be extremely useful when working on small projects with minimal risks and mitigations. This visual display cannot replace exhaustive activity network diagramming or scheduling techniques. Risk mitigation actions, as identified during risk analysis, must be inputs into time management processes – further effects on resources (e.g., costs and schedules) must be evaluated.

Results at Fortune 500 Retailer

In one project at a Fortune 500 retail company, the top 10 mitigation actions – as identified by an FMEA supplemented with a risk mitigation matrix – were implemented. As a result, the company mitigated risks with a total RPN value of 1027. This compares to a total RPN value of 840 that would have been addressed if the classic FMEA model alone had been used to identify mitigation actions. With the same amount of effort, the retailer achieved a greater degree of risk management.