16.5 How to Present Reestimation to Other Project Stakeholders

Estimators on poorly estimated projects allow themselves to be forced into providing a single-point estimate early on. They will then be held accountable for that estimate for the rest of the project. For example, suppose over the course of a project that you provide the set of estimates listed in Table 16-1.

Table 16-1: Example of Estimation History of a Project Estimated Using Single-Point Estimates
Point in Project	Estimate (Staff Months)
Initial concept	10
Approved product definition	10
Requirements complete	13
User interface design complete	14
First interim release	16
FINAL	17

With this set of estimates, the customer will consider the project to have slipped over budget and behind schedule the first time the estimate increases from 10 staff months to 13 staff months. Each time you reestimate the project after that, the project will seem to be slipping into ever more trouble. That's unfortunate, because what's really happening is that the first 10-month estimate was subject to a very high degree of inaccuracy. It's appropriate to reestimate several times after that. The final tally of 17 staff months might be the result of a well-run project, but the way the estimates were presented makes it seem otherwise.

Contrast that scenario with one in which you provide estimates in ranges that become narrower as the project progresses, as shown in Table 16-2.

Table 16-2: Example of Estimation History of a Project Estimated Using Estimate Ranges
Point in Project	Estimate (Staff Months)
Initial concept	3–40
Approved product definition	5–20
Requirements complete	9–20
User interface design complete	12–18
First interim release	15–18
FINAL	17

As you refine each estimate in this case, your customer will consider the project to be staying within expectations. Rather than losing the customer's confidence by taking one schedule slip after another, you build confidence by consistently meeting the customer's expectations and by tightening up the ranges as you go.

Another reason to use ranges rather than single-point estimates is that researchers have found that initial estimates tend to become "anchors" for future estimates, even when the original estimates are not well founded (Lim and O'Connor 1996, Jørgensen 2002). A poor, initial single-point estimate can thus contaminate the estimates for the whole project. Using ranges instead of single-point estimates helps avoid this problem.

Tip #75

Present your estimates in a way that allows you to tighten up your estimates as you move further into the project.

When to Present the Reestimates

There are no magic times to reestimate. Estimation accuracy improves continuously throughout the project. Projects commonly reestimate at major milestones, upon major releases, or when major project assumptions change, such as when a large influx of requirements changes are made.

Regardless of how many times you plan to reestimate, communicate your reestimation plan to other project stakeholders in advance. The Cone of Uncertainty frees you from making firm commitments in the early part of the project when you have a poor chance of ultimately meeting those commitments. But it obligates you to update project stakeholders regularly as your view of the project comes into focus.

Table 16-3 gives an example of an estimation schedule that you might publish on a sequentially run project.

Table 16-3: Example of an Estimation Schedule for a Sequential Project
After Milestone	Estimate Accuracy (for Remainder of Project)	Comments
Initial concept	-75%, +300%	For internal use only; do not publish outside of development group.
Approved product definition	-50%, +100%	Exploratory Estimate. For internal company use only; do not publish externally.
Requirements complete and user interface design complete (UIDC)	-20%, +25%	Budget Estimate. OK to publish the high end of the range externally. Do not publish the lower number or midpoint.
First interim release	-10%, +10%	Preliminary estimates fine-tuned with project data. Do not publish externally; these are just FYI. Available approximately UIDC + 45 days.
Second interim release	-10%, +10%	Preliminary Commitment Estimate. OK to publish the high end of the range externally. Do not publish the lower number.
Third interim release	-10%, +10%	Final Commitment Estimate. OK to publish the midpoint number externally.
Interim releases 4-X	-10%, +10%	Estimates updated only when new requirements are approved by the Change Board.
Code complete	-5%, +5%	Same as above.

Depending on the needs of your project stakeholders, you might need to provide reestimates more or less frequently than illustrated in the table. You should adjust the details of this table to fit your environment. Chapter 17 extends this example and suggests an additional approach that's well suited to iterative projects.

Tip #76

Communicate your plan to reestimate to other project stakeholders in advance.

What If Your Management Won't Let You Reestimate?

Is it really true that your management won't let you reestimate? I doubt it. Your management might not allow you to change your commitment, but that is different from prohibiting you from reestimating. You should always plan to reestimate periodically, if only for your own internal project planning and project-control purposes, regardless of whether your management or customer will accept the result of the reestimation.

Many organizations do plan ahead for reestimation. I'll discuss that more in Section 17.2, "Fitting Estimation into a Stage-Gate Process."