Software Estimation: Demystifying the Black Art (Best Practices (Microsoft))

16.6 A View of a Well-Estimated Project

It's difficult to know mid-stream how good your estimates are. The accuracy of a project's estimates is assessable only in hindsight. In hindsight, however, you can tell the difference between a well-estimated project and a poorly estimated one.

Once the project has been completed, review the project's estimation history to determine whether the project's estimates anticipated the project's eventual outcome. Figure 16-5 shows an example of a project that was well estimated.

Figure 16-5: A well-estimated project. The single-point estimates miss the mark, but the ranges all include the eventual outcome.

The vertical bars in the figure represent the estimation ranges. The shaded blue dots represent the single-point Expected Case estimates. The solid blue dot represents the actual project outcome. In this project, the single-point estimates were different from the final outcome until the end of the project. But each of the ranges presented throughout the project included the eventual outcome, so I would consider this project to have been well estimated.

Figure 16-6 shows an example of a project that was systematically underestimated.

Figure 16-6: A poorly estimated project. The project is uniformly underestimated, and the estimation ranges are too narrow to encompass the eventual outcome.

In essence, this project has fallen prey to the same issue we discussed in Chapter 2 ("How Good an Estimator Are You?") with regard to unrealistically narrow ranges and "90% confident" claims. The project used estimation ranges, which is good, but the ranges were too narrow to include the project's eventual outcome, which is bad.