April 17, 2011, 9:14 a.m.
posted by concurre
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.
PlusorMinus Qualifiers
An estimate with a plusorminus qualifier is an estimate such as "6 months, ±2 months" or "$600,000, +$200,000, $100,000." The plusorminus 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 plusorminus 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 onestandarddeviation range, use qualifiers that account for more than one standard deviation of variability. (See Figure, "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 plusorminus 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 singlepoint numbers. If you use this technique, be sure you can live with the singlepoint number that's left after the estimate gets converted to a simplified form.
Risk Quantification
Risk quantification is a combination of plusorminus qualifiers and communication of the estimate's assumptions. With risk quantification, you attach specific impacts to specific risks, as shown in Figure.
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 
Graphicsformatting 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 fullfledged 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 rolledup, largegrained 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 Figure 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 Conerelated 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 confidencefactor approach, you can answer that question by providing an estimate that looks like the one in Figure.
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 Figure, "Estimation Error by SoftwareDevelopment 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.
Figure: Example of presenting percentageconfident 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. 
CaseBased Estimates
Casebased estimates are a variation on confidencefactor 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. Figure shows an example of casebased 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 provides an example of how you might present similar information visually.
Depending on whether you're managing more to a schedule or to a feature set, the casebased estimate can be expressed in terms of feature delivery instead of dates. Figure shows an example of how you might present a casebased 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 bottomup estimates based on effort for individual tasks, you can probably switch to months or weeks and eventually to days.