After you've identified the schedule risks to your project, the next step is to analyze each risk to determine its impact. You can use risk analysis to help choose among several development options, or you can use it to manage the risks associated with an option you've already chosen. With risks in general, this can be a tricky business, but when you're primarily concerned with schedule risks, assessment is simpler.
A useful risk-analysis practice is to determine the "risk exposure" of each of the risks you've identified. Risk exposure is often abbreviated as "RE." (Sometimes it's called "risk impact.") One definition of risk is "unexpected loss." Risk exposure is equal to the probability of the unexpected loss multiplied by the size of the loss. For example, if you think there's about a 25-percent chance that it will take 4 weeks longer than expected to get your project approved, the risk exposure would be 25 percent multiplied by 4 weeks—which equals 1 week.
Because you're concerned only with schedule risks, you can express all the losses in weeks or months or some other unit of time that makes them easy to compare.
Table 5-4 is an example of a risk assessment table you could create using the risk, the probability of loss, the size of the loss, and the risk exposure.
Table 5-4. Example of a Risk-Assessment Table
Risk | Probability of Loss | Size of Loss (weeks) | Risk Exposure (weeks) |
|---|---|---|---|
Overly optimistic schedule | 50% | 5 | 2.5 |
Addition of requirement to fully support automated updates from the mainframe | 5% | 20 | 1.0 |
Additional features added by marketing (specific features unknown) | 35% | 8 | 2.8 |
Unstable graphics-formatting subsystem interface | 25% | 4 | 1.0 |
Inadequate design—redesign required | 15% | 15 | 2.25 |
Project approval takes longer than expected | 25% | 4 | 1.0 |
Facilities not ready on time | 10% | 2 | 0.2 |
Management-level progress reporting takes more developer time than expected | 10% | 1 | 0.1 |
Late delivery of graphics-formatting subsystem by contractor | 10–20% | 4 | 0.4–0.8 |
New programming tools do not produce the promised savings | 30% | 5 |
In the sample risk-assessment table shown in Table 5-4, a theoretical project has identified several risks that range in potential severity from 1 week to 20 weeks. The probabilities that the risks will occur range from 5 percent to 50 percent. On a real project, you might identify many more risks than I've shown in this table.
How do you come up with the probability and size of the loss? You have to estimate both numbers, so you can't expect either to be exact.
The size of the loss is often easier to pin down than the probability. In the example above, you might have a precise estimate of 20 months for the time it would take to fully support automated updates from the mainframe. Or you might know that the project will be approved either February 1 or March 1, depending on which month the executive committee reviews the proposal for the project. If you assumed that it would be approved February 1, the size of the risk that the project approval will take longer than expected would be exactly 1 month.
In cases in which the size of the loss is not easy to estimate directly, sometimes you can break down the loss into smaller losses, estimate those, and then combine the individual estimates into an aggregate estimate. For example, if you're using three new programming tools, you could estimate the loss resulting from each tool not producing its expected productivity gain. You could then add the losses together, which might be easier than estimating the combined loss.
Estimating the probability of the loss is usually more subjective than estimating the size of the loss, and there are many practices available to improve the accuracy of this subjective estimate. Here are a few ideas:
Have the person most familiar with the system estimate the probability of each risk, and then hold a risk-estimate review.
Use Delphi or group-consensus practices. In the Delphi approach, you have each person estimate each risk individually, and then discuss (verbally or in writing) the rationale behind each estimate, especially the very high and low ones. Continue the process in successive rounds until the estimates converge.
Use betting analogies with personally significant amounts of money: "Would you take this bet? If the facilities will be ready on time, you win $125. If they're not ready on time, I win $100." Refine the bet until you'd be just as happy being on either side of it. The risk probability is the dollar amount on the downside divided by the total dollar amount at stake. In the example, the probability of the facilities not being ready on time would be $100 / ($100 + $125) = 44 percent.
Use "adjective calibration." First have each person choose the risk level from a verbal scale of phrases like highly likely, very good chance, probable, likely, improbable, unlikely, and highly unlikely. Then convert the verbal assessments to quantitative assessments (Boehm 1989).
An interesting side effect of computing risk-exposure numbers as illustrated in Table 5-4 arises from the fact that in statistical terms these risk exposures are "expected values." The risk of an inadequate design would cost you 15 weeks if it actually occurred. Since it's not 100 percent likely to occur, you don't actually expect to lose 15 weeks. But it's not 0 percent likely either, so you don't expect to lose 0 weeks. In a statistical sense, the amount you expect to lose is the probability times the size, or 15 percent times 15 weeks. In this example, you "expect" to lose 2.25 weeks. Since we're talking only about schedule risks, you can add up all the risk exposures to get the total expected overrun for your project. The expected overrun for this project is 12.8 to 13.2 weeks. That's the overrun before doing any risk management.
The size of the expected overrun provides insight into the overall risk level of your project. If the project in the example is a 25-week project, an expected overrun of 12.8 to 13.2 weeks clearly calls for active risk management.
CROSS-REFERENCE
For more on plus-or-minus schedule qualifiers, see Estimate Presentation Styles in Size Estimation.
Should you change your schedule to reflect the expected overrun? Yes, I think so. Recompute the total risk exposure after you've done your risk-management plan, and then add it to your schedule as a buffer. That will give you a more meaningful buffer than the rule-of-thumb buffers that people sometimes use to pad their schedules. Alternatively, you can simply publish a schedule with plus-or-minus qualifiers for each risk and adjust the schedule whenever a risk materializes.