What is a risk mitigation strategy?
Mitigating a risk essentially means deliberately doing something to reduce risk exposure - to burn down the amount of risk associated with a project.
By mitigating risk, we reduce either risk impact or risk probability, or both. There are many ways to mitigate risk, and identifying good (or great) mitigations is the key to a successful project.
Recall from previous posts that risk exposure consists of two independent terms – impact and probability.
Risk Exposure = Risk Impact * Probability of risk materializing
Arriving at great mitigation plan is enabled by clearly defining Risk Drivers (aka Knowledge Gaps) and Impacted Objects during the risk analysis phase.
Risk mitigation planning
Effective risk mitigation has many facets, all of which we will cover in the next few posts. For example, we’ll discuss the various types of mitigations available to choose from, and mitigation strategies that we find the most effective and valuable among the teams we have worked with. In the process, we will cover:
There are several types of mitigations including:- Risk Avoidance
- Architectural Changes
- Contingency Plans
- Knowledge generating mitigations
Making the trade-off between scope, schedule, and cost, and making decisions that maximize the top-level goal of making a profit is at the heart of risk planning.
Sometimes we should forego a difficult feature or performance requirement. Sometimes we should accept a longer schedule or increased costs in order to meet that requirement. Choosing the best option is risk planning.
Let's first review the four types of risk mitigation strategies.
Risk Avoidance
Let’s start with risk avoidance as a possible mitigation strategy.
Recall from the introductory post in this series that risks only exist when there are project objectives that may be impacted. The primary project objective is usually making a profit, which is directly related to the economic objects of sales volumes, sales price, cost of goods, and project expense objectives.
Economic objectives are high-level project requirements, which are directly related to the lower level product requirements such as features, performance specifications, quality and reliability goals — to name a few. i.e. Product requirements are a subset of project requirements.
Risks only exist when there are project requirements which may be difficult to achieve. One way to reduce risks is to not try to meet the requirement which produces the risk in the first place. This is known as risk avoidance.
For example, let's use the same scenario we’ve used in previous posts about the cellphone which may get too hot to hold. Avoiding the risk might mean we revert to an image sensor and/or circuitry with a lower resolution, or a slower refresh rate, or some other reduced performance factor which would result in a less desirable product.
Of course, avoiding risk by forgoing a product performance requirement generally results in a less innovative product that doesn’t sell as well. On the other hand, everything is possible given enough time and money, and we could choose to avoid the risk to schedule and cost by relaxing the schedule and cost requirements on the project.
Modeling the cost of risk avoidance
A project economic model is an important tool in making the decision to eliminate a requirement, or extend the schedule a little in order to take time to mitigate the associated risks. Differentiating the value of each requirement (e.g. identifying each requirement as a ’must’, ’should’, or ’could’) is also important, as it provides the basis on which to make the best decisions. A good project plan is also an important tool that enables good risk planning decisions.
These tools show that the avoidance of risk by foregoing a performance goal or feature is generally a good choice when the requirement is of relatively low value. ’Nice-to-have’ or ’could’ requirements generally should be avoided if the requirement adds much work, cost, or potential delay to the project (the risk is medium or high). Often even low risk requirements are worth avoiding if they provide only a little reward.
Forgoing, or at least deferring requirements like this is a big part of the Lean Startup movement where we define and implement a ’minumum viable product’, which basically strips out all of those nice-to-have requirements that present any work at all. As a result, we find and resolve earlier the problems in our implementation of the more valuable requirements, and/or we sell the product earlier by not slowing development with low-value requirements. Deferring lower-value, higher-risk requirements until after initial release’ is a big part of Agile software development as well.
By avoiding the risk entirely, we are essentially reducing the risk probability to zero. Most mitigations also reduce probability. Before we get to those, however, let’s look at a couple of options that reduce impact...
Modularizing product architecture to mitigate risk
As discussed in the post about risk analysis and capturing the objects impacted by a design risk, one way to mitigate risk is to modularize the product architecture to isolate the risky areas (the areas/parts we’ll have to change several times as we test, learn, and work out the unknowns and issues.) By isolating the areas we have to change more times, we can change them more quickly. This has the direct effect of reducing the impact that each learning iteration will have on the duration of the project.
Contingency plans
Contingency plans are those other mitigations which, by definition, do not change the probability of the risk occurring, but only change the impact. One example of a contingency in the heat-risk example might be to develop and procure an alternate design using a more expensive material which would dissipate the heat better, but result in higher cost of goods.
If the less costly design is too hot, rather than delaying the product launch for months while evaluating the alternate material, we could have it ’in our back pocket’ ready to build into units with minimal delay to the project. A few weeks of delay could easily cost the business more profit than a little higher COGS, and by implementing this contingency plan, we can reduce the impact to profits if the initial design doesn’t work out well.
In another example, perhaps we see a risk that a prototype supplier won’t be able to meet our production volume and quality requirements. A common contingency plan for this risk is to find and qualify a second supplier. If the prototype supplier doesn’t meet our needs, we can switch to the new supplier with minimal impact to product deliveries and company profits.
In the next post we’ll start looking at the more common (and usually more profitable) types of mitigations known as ’risk prevention’. These mitigations typically reduce risk probability through knowledge generation. Fast knowledge generation is the key to mitigating risks posed by high-value requirements that would cost a lot to avoid. We’ll then delve into some of the more effective techniques available for generating knowledge quickly. Stay tuned...
Download our free risk management template to get started.
Related Posts
What is Risk Management?
Risk Management and Project Objectives
8 Types of Risk
ROI of Risk Management
Risk Management Process
Risk Identification and Capture
Risk Drivers and 5 Whys
Risk Mitigation Strategy (part 1)
Objects Impacted and Modular Architecture
Calculating Risk Exposure and Free Risk Exposure Spreadsheet
Risk Mitigation strategy (part 2)
