4. Today’s Forecast -- Quantitative Risk Analysis
The “Quantitative Risk Analysis” process attempts to quantify (put some numbers against) the risks under consideration. It is a way to help understand the magnitude of individual risks and then, viewed together, the overall project risk profile. Before we start quantifying risks, let’s talk about the dangers of applying math to estimates and speculations.

As Albert Einstein said, “Not everything that can be counted counts and not everything that counts can be counted”. In other words, some of the things we can quantify are not that useful, and some of the things we would like to quantify cannot easily be measured. Also, some research claims that quantitative risk approaches divert attention from precautionary or preventative measures [1] .

However, as long as we are aware that trying to quantify risks may be problematic, we can still gain some valuable insights into their likely importance that can help us with prioritization. The usual way of quantifying risks is to express the Impact of the risk occurring in monetary terms and the probability of it occurring as a percentage. We can then calculate the Expected Monetary Value of our risks.

For example, in a software project we may have a risk that our in-house reporting engine may not be up to the performance needs of the project. If the cost of swapping it out was $80,000 and we thought it 50 percent likely we need a replacement reporting engine, then we could calculate the Expected Monetary Value of the risk as:

Expected Monetary Value = Impact ($80,000) x Probability (50%) = $40,000

Calculating the Expected Monetary Values of our risks then allows us to prioritize them. The general idea is that, much like an agile project’s prioritized backlog of features, we want to tackle them (find ways to avoid the risk or make it smaller) in that order to minimize risks to the project as soon as possible.

The team games we use in this step are more to socialize the risk management concepts with the team to better illustrate why backlog items may shift, than taking action. That comes in the next step (risk response planning), which is all about deciding what to do about the risks and putting work in our project backlog of things to do. For now, we are just concerned with quantifying the risks.

Dragons’ Den
Agile has the concept of the “next-best dollar spent” that reminds us to always be looking where we can add the most value next. This may be in developing a new feature from the backlog that will generate an increment of Return On Investment (ROI) once it is released to the business; or it may be to invest some time in avoiding or reducing a risk that threatens to negatively impact the project through expensive rework, delays or additional costs.

The popular TV show “Dragons’ Den”, in which entrepreneurs pitch investment proposals to investors, can be a useful metaphor for modeling the next-best dollar spent. By comparing features from the backlog with risks to mitigate, we can get the team more comfortable with the seemingly shifting priorities that may come from the product owner or business representative when they consider the next-best dollar spent and prioritize the backlog accordingly.

Other techniques used in quantitative risk analysis are:

• Decision Tree Analysis-- applying EVM to decision options to determine the most cost-effective decisions
• Monte Carlo Simulation-- running simulations of risk scenarios based on their probabilities of occurrence and looking at the frequency of specific outcomes on cost and schedule to determine the most likely project completion date or cost, or the likelihood of hitting pre-specified schedule dates and costs.

5. Backlog Injector -- Plan Risk Responses

• Junction Function -- choose the risk response path
• Dollar Balance -- Risk/Opportunity EVM to ROI comparison
• Report Card -- Customer/Product owner engagement
• Inoculator -- inject risk avoidance/mitigation and opportunity stories into backlog

Junction Function
The Risk Response Planning step is where we decide what to do about the risks we have identified, ranked and measured. The options generally available to us are:

1. Avoidance – eliminate the cause of the risk
2. Mitigation – reduce probability of the occurrence
3. Transference – insurance, outsource, etc.
4. Acceptance – accept and communicate to stakeholders

A fifth “Denial” option is widely practiced risk response approach, but is not a valid option. Generally it is best to avoid risks by finding ways to eliminate the root cause of the risk. Failing that, make them smaller or pass them to a party who is better able to handle them (for instance, outsource that work to a specialist in that field). Finally, the least preferable option is to accept the risk. For example, perhaps we just need to wait for service pack 2 from the vendor to fix the issue and until then we are accepting the risk of performance slowdowns.

We need to explain these options to the team and make sure they understand the order of preference and how the risk response options impact the residual risk to the project.

Residual risk is the remaining risk to the project even after we taken the best risk response option we are able to. Perhaps in our reporting performance example, we chose to run the reporting engine on a high-performance server. This helps somewhat, but we still have the residual risk that the higher spec machine is not sufficient.

Secondary risks are new risks occurring as a result of our risk-response strategy. Maybe we decided to do the report processing on the company’s new scalable cloud platform. This may sound like a good idea, but if the company cloud platform is new and untested, then maybe this secondary risk is more significant that the original one we were trying to avoid or reduce. So we need to quantify secondary risks to ensure they are indeed smaller than the risk we are responding to.

Once the team is familiar with the concepts of risk-response options, residual risks and secondary risks, we can engage them in the initial step of putting action items in the backlog. Backlog prioritization is a business/product owner role, but they will need help determining the priority of risk response actions. This is where steps to normalize the risks and feature values are required.

Dollar Balance
Not all risks can be avoided or reduced; we just reviewed how some risks might have to be accepted. When accepting a risk, there is no backlog action to create or balance against new functionality. However, if we can avoid a $50,000 risk then this risk avoidance action is worth $50,000 to the project and should be inserted in the backlog above features worth $49,000 to the business.

We need to compare the value of risk response actions to the value of prioritized features and insert them in the appropriate place. When doing so, we also have to be aware of residual and secondary risks. So the value of a risk response action =

Expected Monetary Value (EMV) of risk being avoided or reduced – EMV of Residual Risk – EMV of Secondary Risk.

For example, simply avoiding a risk with an EMV of $40,000 that has no residual risks or secondary risks is worth $40,000 -$0 - $0 = $40,000. Yet reducing the impact of a $60,000 risk by trying an alternative approach that only addresses half of the problem and in itself carries a $10,000 EMV is only worth $60,000 - $30,000 - $10,000 = $20,000.

So, we need to normalize all the risk responses to values to be net of residual and secondary risks before asking product owners to prioritize these actions in the backlog.

Report Card
The Report Card is a list of recommended risk responses, normalized by net EMV, for consideration by the business representative/product owner. It is prioritized by Net EMV.

With this information, the product owner can now discuss adding these risk response actions into the backlog.

Inoculator
“Inoculator” is the name given to the process of injecting risk avoidance / mitigation and opportunity stories into the backlog. It is done by the product owner, but with consultation and guidance of the development team. It is this ability and frequent opportunity (every iteration planning meeting) to be able to reduce remaining risks and capitalize on opportunities that set agile methods apart from other, slower review cadence approaches that inspect and adapt less frequently.

By avoiding and reducing risks closer to their identification, the horizon of risk the project is exposed to shortens. By making changes earlier in the lifecycle, the cost of changes are reduced. On the flip side, capitalizing on opportunities is like getting investments done early; they have longer to accumulate. These are the compounding benefits of early and rapid risk & opportunity management.

Getting the risk response actions into the backlog is how these tasks are scheduled and undertaken. We want to make sure that all our risk management work is not supplemental to the project plan, but baked right in. All too often, risk management is an activity done upfront or alongside the project, but never really integrated into the day to day activities of the project. By inserting these new stories into the backlog, we drive risk management actions from the analysis to action.

6. Risk Radar -- Monitoring and Controlling Risks
The last step in the process is monitoring and controlling the risk management process by making sure our strategies are effective, continually looking for new or escalating risks and ways to improve.

Risk Burn-Down Graphs
Risk burn-down graphs are a great way of showing the project’s cumulative risk position and trends over time. They are stacked area graphs of risk severity that I have documented previously.

Risk Retrospectives
Risk Retrospectives are periodic reviews of the risk and opportunity log and risk management processes being used on the project. Just as we review the evolving product and team processes throughout the project, so should we be evaluating the effectiveness of the risk management plan and processes being used by the team.

The types of questions we could/should be asking when we regularly review our risk management approach include:

1. Are we eliminating or reducing our risks?
2. How is our remaining Risk EMV burning down?
3. What is our Risk EMV Reduction Velocity per iteration?
4. When will our remaining Risk EMV be zero?
5. Do we have any new or escalating risks?
6. What are the root causes of our risks, and can we eliminate any of them?
7. Which risk avoidance or elimination strategies are working and which are not?
8. For risks that we chose to transfer, how are the third parties managing them? What can we learn from them, or would we be better bringing them back internally?
9. How are our team risk management capabilities developing?
10. Where do we still need mentoring and support?

Rinse and Repeat
Finally, reviewing is not enough; we need to update our risk management artifacts. Update our risk lists and EMV scores, and groom the backlog with new features and new risk responses; always be rebalancing the priorities. Update the risk information radiator graphs (like our risk burn-down graphs), and make sure people are not only looking at the impacts of new work in terms of estimates--but potential risks, too.

Conclusion
Risk management, like estimation, should not be just a project management activity. We can greatly raise a project team’s ability to manage risk--and therefore avoid project failures through socialization, collaboration and practice. If nothing else, these team activities make the basics of risk management more accessible to a larger pool of project stakeholders, and in doing so provide more eyes to find and avoid risks before they can impact the project—which, at the end of the day, is the heart of effective risk management.

Reference
[1]: Barry Commoner. “Comparing apples to oranges: Risk of cost/benefit analysis” from Contemporary moral controversies in technology, A. P. Iannone, ed., pp. 64–65.

(This post first appeared in Gantthead.com here)