This project is read-only.

Chapter 6 - Risk Model

Risk Model

Every project inherent risks whether or not we recognize them. Determining what those risks are can be a challenge. Project risks of producing software-intensive systems relate to whether the product development team understands what the Product Owner wants built and how to build it and inability to construct and delploy the product as intended, in a timely manner, and cost-effectively . Opeational risks relate to the product not functioning as excepted or failing during operation. A risk model can help us understand all the risks and come up with risk mitigation plans to reduce their likelihood or impact.

What Could Possibly Go Wrong? Risk Assessment

One way to define risk is by asking what keeps us awake at night? More specifically, what might happen and what would be the consequences if it did happen?
We can make the discussion of risk more meaningful by translating nebulous concerns into concrete events that could happen and talking about the likelihood that it might happen and the consequences if it does happen.
For example, suppose we ordered some critical hardware which we require to conduct certain types of acceptance testing without which we are not prepared to make the acceptance decision. What could possibly go wrong? The following are some examples:
  • The hardware could be destroyed in transit.
  • The wrong hardware could be shipped either through an ordering error or a fulfillment error.
  • The hardware could be defective.
For each of the preceding events we can estimate the likelihood that it will occur and assess the impact on our project if it did occur. Performing these two calculations separately helps us to better understand the risk as shown in the risk matrix in Figure 1. As the probability of an event increases, the risk increases. As the consequences of an event increases, the risk increases.
Figure 1
Figure 1 Risk Matrix
In Figure 1 – Risk Matrix, the two areas on either side of the diagonal and the diagonal itself represent three degrees of risk. The bottom left (green) risk regime represents low risk, the top right (red) risk regime represents high risk, and the top-left to bottom-right diagonal (yellow) risk regime represents moderate risk. In general, risks that fall in the same risk regime are equally important to mitigate.

Unquantifiable Risks

It is important to recognize that it is not the known and quantifaiable risks that cause the biggest problems, but the completely unexpected things that do so. In his treatment of the issue, Pete McBreen emphasizes that flexibility is the key to surviving the unexpected [McBreenOnRiskManagement].

Who Should Identify the Risks

Everyone on the project has a different and valuable perspective on the possible risks involved in building and delivering a product whether it is for sale to customers or for use by internal users. Risk identification should not be a monopoly of the project managers but should include product designers, product developers, testers and all stakeholders including the Product Owner. Ultimately, it is the Product Owner who needs to understand the risks and decide which ones they can accept as-is and which ones they want to spend money to reduce therefore the Product Owner must be intimately familiar with at least the risks in the red (top right) and yellow (diagonal) regions of the risk matrix. Ultimately, as Tom Gilb stated in his Asking Principle: “If you don’t ask for risk information, you are asking for trouble” [GilbOnSEManagement].

Should We Do Something About It? Risk Management

After we understand the risks of our project, what can we do about them? There are three possible courses of action:
  • We can accept the probability and consequence that a particular event might happen.
  • We can perform activities to reduce the likelihood of it happening.
  • We can perform activities to reduce the consequence if it does happen.
The course we choose depends on a number of factors, including the following:
  • The factors we have control over, such as the following:
  • If there are no courses of action that could reduce the likelihood of something happening we may be forced to focus on trying to reduce the consequence. For example, the only way to avoid an extreme weather event might be to move to a different area, which may simply exchange one set of extreme weather events for a different set. But we can prepare for the occurance of the extreme weather by choosing appropriate facilities or other preparations.
  • If there is no way to reduce the consequence of an event, we need to focus on reducing the likelihood of it occurring. For example, most people would agree that it is better (and economically more feasible) to try to reduce the likelihood of a heart attack by exercising and eating well than to try to improve the probability of surviving it by hiring a heart specialist to be at your side at all times.
  • The relative cost of the options available to use. If it is much cheaper to reduce the likelihood than the consequence, we should first focus on lowering the likelihood and vice versa. Note that the cost is typically non-linear and gets more expensive the closer to zero we try to drive the likelihood or consequence. Therefore it may be more appropriate to try to partially reduce both likelihood and consequence rather than reduce just one to a larger degree.
  • The cost of risk reduction relative to the cost we would incur if the risk occurred. For example, if a parking ticket costs twice as much as paying for the parking and there is only a 20 percent chance of getting caught and ticketed, we may choose to take the chance by not paying for parking.

How Can Testing Help? Risk Mitigation Strategies

If we decide to mitigate a risk, how we go about it depends on the nature of the risk. Risks that relate to the possibility of delivering a defective product are amenable to risk mitigation through some form of testing. Risks that relate to discovering something too late for a timely fix can be mitigated by activities that move the discovery earlier in the project.

Doing Something Earlier

Many risks on projects are related to time. Will something happen in time? If it happens too late, will we have time to react without affecting the project timeline?
A good example of this is the late discovery of missed or misunderstood requirements. When this discovery occurs during the acceptance testing phase of a project shortly before the product is expected to be turned over to users, the impact (of the discovery) may be a significant delay in achieving the business benefits expected from the system. In this case, we can reduce the impact of the discovery by doing the acceptance testing activities earlier in the project.
The incremental acceptance testing practice used on many agile projects is one way to move discovery of problems such as misunderstood requirements earlier in the project so there is plenty of time to address them. Sequential projects can also reap the benefits of incremental acceptance testing by moving to an incremental delivery model where the product is built in functional modules that can be acceptance tested as they become available.

Doing Something Different

An extreme form of "too late" discovery is when we do not discover it at all and a problem occurs when the product is being used. If the problem is severe enough to have serious repercussions, the consequences can be disastrous. The high-profile losses or theft of customers' private information is just one example of something discovered "too late." These types of risk may require additional activities to reduce the likelihood of their occurrence. The solution often lies in doing additional kinds of testing to improve the likelihood that a certain class of defect, if it exists, is found in time. Many test authoring practices are focused on ways to define additional tests that improve the test coverage (from a risk coverage instead of a code coverage perspective).


A risk management model and a way to track risks and risk mitigation is important on all types of projects. Making risks explicit allows us to devise ways to choose the right risks to take and to mitigate the risks either by reducing the probability or the consequence. For risks related to misunderstanding of the requirements, earlier testing through incremental acceptance can reduce the consequence by giving us more time to rework any issues. Prioritizing acceptance testing activities should be part of the risk model to ensure that highly-critical features are thoroughly addressed during software acceptance. The Product Owner needs to be involved in identifying and understanding risks and in determining which risks need to be addressed.

What’s Next?

A significant risk on most projects is late discovery that the product is much farther from done than thought. The next chapter introduces a model for thinking about the degree to which the product is ”done”.


[McBreenOnRiskManagement] Pete McBreen, “The Myth of Risk Management”, Better Software Magazine: 30-34, June, 2008.
[GilbOnSEManagement] Tom Gilb, Principles of Software Engineering Management, Addison Wesley, 1988.

Last edited Nov 5, 2009 at 8:38 PM by rburte, version 2


No comments yet.