This is Part 4 of our series on project risk management for hardware product development. In this part, we look at the return on investment of project risk management. The conclusion? It's high, and therefore worth the effort!...
As a reminder, in Part 1, we looked at the definition of risk management and discussed how the trick to effective risk management is to learn – both carefully and quickly – in the right balance.
The PMBOK definition of a Project Risk is “an uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives.”
In Part 2, we looked at risk management and project objectives.
In Part 3, we looked at another key piece of project risk – the uncertain events and conditions that are the cause of a risk.
In this part, Part 4, we look at the return on investment of risk management and how to calculate risk exposure.
In the last post, we left off with a picture of how risk management accelerates projects and enables teams to estimate completion dates with greater confidence. In this post we confirm that effective risk management has a high ROI.
Rather than accepting “the take-our-chances approach,” (figure 1) teams that choose to spend a little extra time (and money) deliberately diffusing risks will get to the finish line faster and more confidently (figure 2).
Even though taking the time to manage risk creates additional work up front (depicted by the green lines), it saves time and money in the end.
Figure 1: Project view without effective risk management
Figure 2: Project view with risk management
Why do teams avoid risk management?
Like buying insurance, a lack of clarity about the payback of risk management is a key reason why teams avoid risk management. It’s true, some risks never materialize. Uncertainty is inherent in risk. But if we let our optimism win out, and we ignore too many risks (in effect taking too many chances), it will certainly cost the project -- sometimes insurmountably.
Calculating risk exposure
So how do you determine how much time to spend on mitigating risk? By calculating risk exposure.
Let’s look at a single risk as if it is the only risk in our project, and determine how much time we should spend on mitigation.
Figure 3: Risk exposure
We’ll use a common example of a technical risk where we decide to use a component or design that may not withstand the rigors of customer or validation testing late in the project.
In this case, if the design fails, we estimate it would delay the project 8 weeks to make a late design change. We would need to identify a solution, release new drawings, procure new components, build them into new units, and re-run the validation test we failed.
The 8-week risk impact is largely a function of the lead time of our components, and how long it takes to release drawings and build units, and it isn’t difficult to estimate.
Let’s say, in this case, we estimate the probability of the design failing at 50%. This risk probability is more difficult to feel confident about and agree upon. We’ll address the difficulty of estimating probability in a future post. In the meantime, let’s just take it at a 50/50 chance you’ll need to change the design later if you don’t do something earlier to make sure it’s ok.
Risk Exposure = Risk Impact * Risk Probability
In this example, a 50/50 chance of an 8-week delay represents a risk exposure of 4 weeks. True, the actual cost will either be zero or 8 weeks, but when we are dealing with uncertainties, we have to use the probability modified cost. Fortunately, there are many risks on every project, so the law of averages makes this a valid approach.
To mitigate or not mitigate – that is the question
We could choose not to mitigate the risk, and run toward the finish line by getting drawings done and parts ordered, or whatever else we know we need to do. In one week of work, we’d be one week closer to the finish line, but the finish line is still out there, 4 weeks later than we were hoping for, as shown in the top of Figure 4.
Figure 4: Risk exposure, risk management
But if we can eliminate the risk in only 1 week of mitigation activities (like additional experimentation, carrying a ’back-pocket’ design with us, etc.), then we accelerate the project by 3 weeks. With a risk exposure of 4 weeks, we can spend up to 4 weeks to eliminate the risk before the mitigation costs more than it pays. Fortunately, most risks can be eliminated in much less time.
Risk mitigation up front is worth the risk!
On a real project there are enough risks running in parallel that each mitigation really costs, and pays back, a fraction of what it would for a single risk. Let me explain.
What if we had 10 risks we didn’t mitigate, so we’re likely to need another design iteration anyway? The week we spent eliminating one risk ends up delaying the project one week.
But if we take the time to mitigate the other risks, too, and do so in parallel with the original mitigation, then the other mitigations cost almost nothing. As shown in the red box in the picture above, we get all four mitigations for the delay cost of one. Each mitigation effectively costs a quarter of what it would cost if we only chose one mitigation.
These up-front, early, parallel green mitigations represent what occurs in many companies in the ’design feasibility’ or ’technical development’ phase. In this phase, teams will experiment for a few weeks to determine the best course forward with their design. By doing so, later iterations, which are longer iterations, can be eliminated. These late iterations become necessary when we make too many incorrect assumptions about the design.
There are additional mitigations which also have effectively zero delay cost, such as the one in the brown box. Mitigations which aren’t on the critical chain are, by definition, delay-free, which makes the ROI on those mitigations enormous.
For example, if there is wait time for some mechanical parts to arrive, the team could experiment on electrical parts they’ve already received with no impact on the length of the project. Alternatively, they could choose to not run any experiments, and potentially find out about an issue during a later test, when the issue would cause a significant delay to the project.
Determining the exact cost and payback of each mitigation can become very complex. Good tools (like PLAYBOOK, of course, as well as good economic models) can highlight the critical chain and more clearly show the true value and cost associated with risk mitigation.
But even without PLAYBOOK, it's possible to effectively manage risk by evaluating each risk independently. There are enough risks running in parallel that each mitigation really costs, and pays back, a fraction of what it would for a single risk. However, the ratio of payback to cost stays roughly the same. If we believe the individual risk mitigation pays more than it costs, it’s likely we are better off mitigating the risk than accepting it. And if we think mitigating the risk pays a lot more than it costs, we can be very confident about it.
When we can see the line between which risks to mitigate and which ones not to, and we agree on which risks to attack and which to accept, then we are poised to optimally manage risk. Quantifying all of the risks is absolutely not required, but when we do crunch some numbers, we often learn a lot about how to estimate them better.
I’ll discuss this a little more when I get to the ”planning” phase of the Risk Management Process, which we will start looking at in the next post. Stay tuned...
Interested in taking risk management a step further? Download your free risk management template.