23.2 Political Influences on Estimates

Several nontechnical factors influence management's response to software estimates.

External Constraints

In many cases management is concerned with significant external influences that require the delivery of the software by a specific date or at a certain cost. There might be an external, immovable deadline (such as the Christmas shopping season, a regulatory compliance date, or a trade show). Similarly, the cost of a project might be influenced by a competitive bidding environment in which management believes that your company won't get the work if it submits a bid high enough to cover your estimate.

The fact that an external requirement exists does not necessarily mean it's possible to meet that requirement. It does mean that you need to make it perfectly clear to the executives you're dealing with that you understand the requirement and that you take it seriously.

Tip #111

Be aware of external influences on the target. Communicate that you understand the business requirements and their importance.

Budgeting and Dates

A consideration for many businesses is that delivery dates tend to be influenced by quarter boundaries. Companies report expenses and revenues based on quarters. Sometimes it's easier to get a later date accepted than an earlier date because of the pressure to force the earlier date into the previous quarter. If you suggest a delivery date of July 15, you might well encounter pressure to deliver on June 30 instead—that is, in second quarter rather than third quarter. If you suggest a delivery date of September 15, a date deep into the third quarter, you might actually find that it's easier to get that delivery date approved than it would be to get the July 15 date accepted because there will be less pressure to push the delivery back into the previous quarter. This stickiness will tend to be even stronger for dates that cross fiscal year boundaries.

Negotiating an Estimate vs. Negotiating a Commitment

In some circumstances, negotiation is appropriate, and in others, it isn't. We don't negotiate questions of fact, such as the surface temperature of the Sun or the total volume of the Great Lakes. We look them up. Similarly, a software estimate is the result of an analytical activity, and it isn't rational to negotiate the estimate. It is rational to negotiate the commitment that is related to the estimate. Such a discussion might go something like this:

TECHNICAL LEAD: Our estimate for this project is that it will take 5 to 7 months. We're still pretty early in the Cone of Uncertainty, so we can tighten that up as we go.

EXECUTIVE: Five to 7 months is too wide a range. How about if we just use an estimate of 5 months?

TECHNICAL LEAD: We've found it really useful to distinguish between estimates and commitments. I can't change the estimate, because that's a result of a lot of computations. But I could possibly have my team commit to a delivery schedule of 5 months if we all agree that we want to take on that level of risk.

EXECUTIVE: That seems like semantics to me. What's the difference?

TECHNICAL LEAD: Our range of 5 to 7 months includes one standard deviation of variation on each side of our 50/50 estimate of 6 months. That means we have about an 84% chance that we'll deliver within 7 months. Our estimates suggest that we have only 16% chance of actually meeting a 5-month commitment.

EXECUTIVE: We need more than 50% confidence in the date we commit to, but 84% is more conservative than we need. What would the 75% confident date be?

TECHNICAL LEAD: According to the probabilities we estimated, that would be about 6.5 months.

EXECUTIVE: Let's commit to that then.

TECHNICAL LEAD: That sounds good.

Many technical personnel view the kind of dialogue described here as a career-limiting move. In my experience, exactly the opposite is true. If you are willing to endure some uncomfortable dialogues—and if you always keep the best interests of your organization in mind—you are engaging in a career-enhancing move. The real career-limiting move is to sign up for unsupported, unrealistic commitments and then fail to deliver.

Tip #112

You can negotiate the commitment, but don't negotiate the estimate.

What to Do if Your Estimate Doesn't Get Accepted

Developers and managers sometimes worry that presenting an estimate that's too high will cause the project to be rejected. That's OK. Executive management has both the responsibility and the right to decide that a project is not cost-justified. When technical staff low-balls a project estimate, it denies the executives important information they need to make effective decisions, effectively undermining the executive's decision-making authority. This results in diverting company resources from projects that are cost-justified to projects that aren't cost-justified. Good projects aren't supported adequately, and bad projects are supported excessively. The whole scenario is incredibly unhealthy for the business, and it tends to end unpleasantly for the people involved in the projects that should not have been approved in the first place.

Responsibility of Technical Staff to Educate Nontechnical Stakeholders

If you want to ensure the success of your software projects, educate your nontechnical project stakeholders about the costs associated with arbitrarily cutting cost and schedule estimates without making corresponding cuts in the work that needs to be done. Educate them about the Cone of Uncertainty, and about the differences between estimates, targets, and commitments. In my experience, nontechnical stake-holders tend to be very receptive to these ideas when they're presented in the context of trying to do what's best for the organization.

Tip #113

Educate nontechnical stakeholders about effective software estimation practices.

In addition to educating nontechnical stakeholders about software, educating yourself about your business's objectives, priorities, and sensitivities will help support the most constructive estimation discussions possible.