1.1 Estimates, Targets, and Commitments

Strictly speaking, the dictionary definition of estimate is correct: an estimate is a prediction of how long a project will take or how much it will cost. But estimation on software projects interplays with business targets, commitments, and control.

A target is a statement of a desirable business objective. Examples include the following:

"We need to have Version 2.1 ready to demonstrate at a trade show in May."
"We need to have this release stabilized in time for the holiday sales cycle."
"These functions need to be completed by July 1 so that we'll be in compliance with government regulations."
"We must limit the cost of the next release to $2 million, because that's the maximum budget we have for that release."

Businesses have important reasons to establish targets independent of software estimates. But the fact that a target is desirable or even mandatory does not necessarily mean that it is achievable.

While a target is a description of a desirable business objective, a commitment is a promise to deliver defined functionality at a specific level of quality by a certain date. A commitment can be the same as the estimate, or it can be more aggressive or more conservative than the estimate. In other words, do not assume that the commitment has to be the same as the estimate; it doesn't.

Tip #1

Distinguish between estimates, targets, and commitments.

1.2 Relationship Between Estimates and Plans

Estimation and planning are related topics, but estimation is not planning, and planning is not estimation. Estimation should be treated as an unbiased , analytical process; planning should be treated as a biased , goal-seeking process. With estimation, it's hazardous to want the estimate to come out to any particular answer. The goal is accuracy; the goal is not to seek a particular result. But the goal of planning is to seek a particular result. We deliberately (and appropriately) bias our plans to achieve specific outcomes . We plan specific means to reach a specific end.

Estimates form the foundation for the plans, but the plans don't have to be the same as the estimates. If the estimates are dramatically different from the targets, the project plans will need to recognize that gap and account for a high level of risk. If the estimates are close to the targets, then the plans can assume less risk.

Both estimation and planning are important, but the fundamental differences between the two activities mean that combining the two tends to lead to poor estimates and poor plans. The presence of a strong planning target can lead to substitution of the target for an analytically derived estimate; project members might even refer to the target as an "estimate," giving it a halo of objectivity that it doesn't deserve.

Here are examples of planning considerations that depend in part on accurate estimates:

Creating a detailed schedule
Identifying a project's critical path
Creating a complete work breakdown structure
Prioritizing functionality for delivery
Breaking a project into iterations

Accurate estimates support better work in each of these areas (and Chapter 21, "Estimating Planning Parameters," goes into more detail on these topics).

1.3 Communicating about Estimates, Targets, and Commitments

One implication of the close and sometimes confusing relationship between estimation and planning is that project stakeholders sometimes miscommunicate about these activities. Here's an example of a typical miscommunication :

EXECUTIVE: How long do you think this project will take? We need to have this software ready in 3 months for a trade show. I can't give you any more team members , so you'll have to do the work with your current staff. Here's a list of the features we'll need.

PROJECT LEAD: OK, let me crunch some numbers , and get back to you.

Later …

PROJECT LEAD: We've estimated the project will take 5 months.

EXECUTIVE: Five months!? Didn't you hear me? I said we needed to have this software ready in 3 months for a trade show!

In this interaction, the project lead will probably walk away thinking that the executive is irrational, because he is asking for the team to deliver 5 months' worth of functionality in 3 months. The executive will walk away thinking that the project lead doesn't "get" the business reality, because he doesn't understand how important it is to be ready for the trade show in 3 months.

Note in this example that the executive was not really asking for an estimate; he was asking the project lead to come up with a plan to hit a target . Most executives don't have the technical background that would allow them to make fine distinctions between estimates, targets, commitments, and plans. So it becomes the technical leader's responsibility to translate the executive's request into more specific technical terms.

Here's a more productive way that the interaction could go:

EXECUTIVE: How long do you think this project will take? We need to have this software ready in 3 months for a trade show. I can't give you any more team members, so you'll have to do the work with your current staff. Here's a list of the features we'll need.

PROJECT LEAD: Let me make sure I understand what you're asking for. Is it more important for us to deliver 100% of these features, or is it more important to have something ready for the trade show?

EXECUTIVE: We have to have something ready for the trade show. We'd like to have 100% of those features if possible.

PROJECT LEAD: I want to be sure I follow through on your priorities as best I can. If it turns out that we can't deliver 100% of the features by the trade show, should we be ready to ship what we've got at trade show time, or should we plan to slip the ship date beyond the trade show?

EXECUTIVE: We have to have something for the trade show, so if push comes to shove, we have to ship something, even if it isn't 100% of what we want.

PROJECT LEAD: OK, I'll come up with a plan for delivering as many features as we can in the next 3 months.