22.2 Expressing Uncertainty
22.2 Expressing Uncertainty
The key issue in estimate presentation is documenting the estimate's uncertainty in a way that communicates the uncertainty clearly and that also maximizes the chances that the estimate will be used constructively and appropriately. This section describes several ways to communicate uncertainty.
Plus-or-Minus Qualifiers
An estimate with a plus-or-minus qualifier is an estimate such as "6 months, ±2 months" or "$600,000, +$200,000, -$100,000." The plus-or-minus style indicates both the amount and the direction of uncertainty in the estimate. An estimate of 6 months, +1/2 month, -1/2 month says that the estimate is quite accurate and that there's a good chance of meeting the estimate. An estimate of 6 months, +4 months, -1 month says that the estimate isn't very accurate and that there is less chance of meeting the estimate.
When you express an estimate with plus-or-minus qualifiers, consider how large the qualifiers are and what they represent. A typical practice is to make the qualifiers large enough to include one standard deviation on each side of the core estimate. With this approach, you'll still have a 16% chance that the actual result will come in above the top of your estimate and a 16% chance that it will come in below the bottom. If you need to account for more than the 68% probability in the middle of the one-standard-deviation range, use qualifiers that account for more than one standard deviation of variability. (See Table 10-6, "Percentage Confident Based on Use of Standard Deviation," on page 121, for a list of standard deviations and associated probabilities.)
Be sure to consider whether the minus qualifier should be the same as the plus qualifier. If you're dealing with effort or schedule, typically the minus side will be smaller than the plus side for the reasons discussed in Section 1.4, "Estimates as Probability Statements."
A weakness of the plus-or-minus style is that, as the estimate is passed through the organization, it tends to get stripped down to just the core estimate. Occasionally, managers simplify such an estimate out of a desire to ignore the variability implied by the estimate. More often, they simplify the estimate because their manager or their corporate budgeting system can handle only estimates that are expressed as single-point numbers. If you use this technique, be sure you can live with the single-point number that's left after the estimate gets converted to a simplified form.
Risk Quantification
Risk quantification is a combination of plus-or-minus qualifiers and communication of the estimate's assumptions. With risk quantification, you attach specific impacts to specific risks, as shown in Table 22-1.
| Estimate: 6 months, +5 months, -1 month | |
|---|---|
| Impact | Description of Risk |
| +1.5 months | This version needs more than 20% new features compared to Version 2.0 |
| +1 month | Graphics-formatting subsystem delivered later than planned |
| +1 month | New development tools don't work as well as planned |
| +1 month | Can't reuse 80% of the database code from the previous version |
| +0.5 month | Average staff sickness during the summer months instead of less sickness |
| -0.5 month | All developers assigned 100% by April 1 |
| -0.5 month | New development tools work better than planned |
This is a comparatively simple example that focuses only on schedule risks. A more full-fledged example might enumerate major risks to effort and features as well as risks to the schedule. Keep in mind that this technique is an estimate presentation technique. The purpose of the technique is to communicate to nontechnical stakeholders that the project presents risks. The point is not to deluge nontechnical stakeholders with detailed risk information. Thus, you should try to focus on rolled-up, large-grained risks.
When you document the sources of uncertainty this way, you provide your project stakeholders with information they can use to reduce the risks to the project, and you lay the groundwork for explaining estimate changes in case any of the risks materialize.
If you're far enough into the project to have made a commitment, the risks listed in Table 22-1 might be risks to meeting the commitment rather than risks to the estimate.
This example does not present the generic uncertainty in the project that arises from the Cone of Uncertainty. If you haven't yet made a commitment, you might need to present the Cone-related uncertainty, too.
| Tip #105 | Be sure you understand whether you're presenting uncertainty in an estimate or uncertainty that affects your ability to meet a commitment. |
Confidence Factors
One of the questions that people often ask about a schedule is, "What chance do we have of making this date?" If you use the confidence-factor approach, you can answer that question by providing an estimate that looks like the one in Table 22-2.
| Delivery Date | Probability of Delivering on or Before the Scheduled Date |
|---|---|
| January 15 | 20% |
| March 1 | 50% |
| November 1 | 80% |
You can approximate these confidence intervals by using your "most likely" estimate and the multipliers from Table 4-1, "Estimation Error by Software-Development Activity," on page 39, for the appropriate phase of your project.
As discussed in Chapter 2, "How Good an Estimator Are You?" and throughout the book, avoid presenting highly confident percentages like "90% confident" unless you have a quantitatively derived basis for such a high percentage.
Also, consider whether you really need to present low probability estimates. The fact that a result is remotely possible doesn't mean that you have to put it on the table. I doubt that you're currently presenting the options that are 1% likely or 0.0001% likely. Presenting only those options that are at least 50% likely is a legitimate estimation strategy.
| Tip #106 | Don't present project outcomes to other project stakeholders that are only remotely possible. |
Some people more easily understand data presented in a visual form than in a table form, so you might also consider a more visual presentation, such as the one shown in Figure 22-2.
Figure 22-2: Example of presenting percentage-confident estimates in a form that's more visually appealing than a table.
| Tip #107 | Consider graphic presentation of your estimate as an alternative to text presentation. |
Case-Based Estimates
Case-based estimates are a variation on confidence-factor estimates. Present your estimates for best case, worst case, and current case combined with your commitment, or planned case. You can use the gaps between the planned case and the best and worst cases to communicate the degree of variability in the project and the degree of optimism in the plan. If the planned case is much closer to the best case, that implies an optimistic plan. Table 22-3 shows an example of case-based estimates.
| Case | Estimate/Commitment |
|---|---|
| Best case (estimate) | January 15 |
| Planned case (commitment) | March 1 |
| Current case (estimate) | April 1 |
| Worst case (estimate) | November 1 |
The relationships between these different dates will be interesting. If the planned case and the best case are the same, and the current case and the worst case are the same, your project is in trouble!
If you use this technique, be prepared to explain to your project's stakeholders what would have to occur for you to achieve the best case or fall into the worst case. They will want to know about both possibilities.
Figure 22-3 provides an example of how you might present similar information visually.
Figure 22-3: Example of presenting case-based estimates in a visual form.
Depending on whether you're managing more to a schedule or to a feature set, the case-based estimate can be expressed in terms of feature delivery instead of dates. Table 22-4 shows an example of how you might present a case-based estimate for features.
| Case | Estimate/Commitment |
|---|---|
| Best case (estimate) | 100% of Level 1 features 100% of Level 2 features 100% of Level 3 features |
| Planned case (commitment) | 100% of Level 1 features 100% of Level 2 features 50% of Level 3 features |
| Current case (estimate) | 100% of Level 1 features 80% of Level 2 features 0% of Level 3 features |
| Worst case (estimate) | 100% of Level 1 features 20% of Level 2 features 0% of Level 3 features |
Coarse Dates and Time Periods
Try to present your estimate in units that are consistent with the estimate's underlying accuracy. If your estimates are rough, use obviously coarse numbers, such as "We can deliver this in second quarter" or "This project will require 10 staff years," rather than misleadingly precise numbers, such as "We'll deliver this May 21" or "This project will require 15,388 staff hours." Consider using the following:
-
Years
-
Quarters
-
Months
-
Weeks
In addition to expressing the message that the estimate is an approximation, the advantage of coarse numbers is that you don't lose information when the estimate is simplified. An estimate of "6 months, +3 months, -1 month" can be simplified to "6 months." An estimate such as "second quarter" is immune to such simplification.
As you work your way into the Cone of Uncertainty, you should be able to tighten up your time units. Early in the Cone you might present your estimate in quarters. Later, when you're creating bottom-up estimates based on effort for individual tasks, you can probably switch to months or weeks and eventually to days.
EAN: 2147483647
Pages: 212