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 which is the topic of this post…
There are four primary types of mitigations to choose from when developing the best mitigation plan. We’ll cover three of them in this post, starting with one type of mitigation that provides an introduction to the primary objective of risk planning – the objective of finding the best plan possible.
Note that in the previous post, we established that a mitigation is any deliberate action taken to reduce risk exposure, by either reducing risk probability, risk impact or both.
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, lets use the same scenario we’ve used in previous posts about the handheld camera 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.
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 ’inital 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...
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 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...
If you haven't read our previous posts on project risk managment the links to the series are below.
We also have a free risk management template available.
In Part 1, we defined project risk.
In Part 2, we looked at the key piece of project risk management – the project’s objectives and how effective risk management must start with defining project objectives.
In Part 3, we considered the uncertain events and conditions that are the cause of a risk.
In Part 4, we looked at the return on investment of risk management and how to calculate risk exposure.
In Part 5, explored the risk managementlearning management) process.
In Part 6, covers project risk identification and capture.
In Part 7we reviewed risk drivers and the 5 Whys techniquea simple and powerful technique for discovering the root of the problem (the root of the risk)!
In Part 8, we used a real life example to demonstrate how to define risk drivers and prioritize them.
InPart 9, we discussed the importance of capturing the objects impacted by a risk in order to understand risk exposure.
In Part 10, we demonstrated how to calculate risk exposure both qualitatively and quantitatively
In Part 11, we begin to explore risk mitigation.