Chapter 6 - 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
happen and talking about the likelihood
that it might
happen and the
if it does
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 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.
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
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
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.
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.