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 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 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 Figure.

Figure: Example of an Estimate With Risk Quantification

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 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 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 Figure.

Figure: Example of a Confidence-Factor Estimate

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 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.

Image from book
Figure: 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. Figure shows an example of case-based estimates.

Figure: 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 provides an example of how you might present similar information visually.

Image from book
Figure: 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. Figure shows an example of how you might present a case-based estimate for features.

Figure: Example of Case-Based Estimates 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.



 Python   SQL   Java   php   Perl 
 game development   web development   internet   *nix   graphics   hardware 
 telecommunications   C++ 
 Flash   Active Directory   Windows