"How Long Will It Take?" Why a Software Estimate Is Not a Promise

An engineer is asked in a corridor how long a new feature will take. "About two weeks," she says. The project manager puts the Friday after next in the plan. The account manager mentions that Friday to the customer, and the customer announces a launch to their own users. Nobody lied. A guess became a date, the date became a promise, and the promise is now public.

When the feature lands three weeks later, the review asks why the estimate was wrong. That is the wrong question. The estimate was a reasonable guess. It was treated as something it never was.

What the question is for

"How long will it take?" is rarely curiosity. The person asking has a decision to make, and the number feeds it. The usual ones:

• Getting a budget approved. They need a ceiling they will not have to walk back.
• Picking a launch date. They need a date they can say in public, and to know what will be in it.
• Comparing vendors. They need numbers built on the same scope and the same assumptions.
• Deciding whether to do it at all. They need the order of magnitude: two weeks or two quarters, not Tuesday or Wednesday.

Each of those needs a different answer, at a different precision. For a go or no-go, "weeks, not months" may be all anyone needs. For a public date, the answer has to arrive with a scope and an honest level of confidence. This is the lesson of Beyond the Obvious applied to a calendar: the question asked is the apparent issue, and the decision behind it is the actual need. So before giving a number, ask what it will be used for. Steve McConnell makes the same observation in Software Estimation: Demystifying the Black Art (2006): "When executives ask for an 'estimate,' they're often asking for a commitment or for a plan to meet a target."

Three things that share one number

McConnell separates three ideas that teams routinely squeeze into a single figure:

Source: definitions quoted from Steve McConnell, Software Estimation: Demystifying the Black Art (2006), chapter 1. The last column is mine.

All three are legitimate. A business needs targets, and a launch with no date is not much of a plan. The trouble starts when one passes for another. In the corridor, "about two weeks" was an estimate. By the time it reached the customer it had become a commitment, and nobody had made it.

A target deserves a different reply from an estimate. If the business needs the feature by the end of the quarter, a new estimate does not help. A plan does: what fits by then, what does not, and which decisions have to be made this week to keep the date.

Why early numbers are wide

Barry Boehm charted how the accuracy of software cost estimates improves as a project moves through its phases, in Software Engineering Economics (1981). Steve McConnell's Cone of Uncertainty describes the same narrowing. At the initial concept, estimates made by skilled estimators can be wrong by a factor of four in either direction. The range narrows as the project proceeds, but not by itself: "The Cone narrows only as you make decisions that eliminate variability" (McConnell, 2010).

Two consequences follow. First, if the cone holds for a feature nobody has designed yet, "about two weeks" honestly means somewhere between half a week and two months. Nobody puts that in a launch announcement, which is rather the point. Second, a week of thinking harder does not narrow the range. Decisions do: what is in scope, what is out, which design, which integration. McConnell also calls the cone a best case, reached by skilled estimators on a well-run project. His summary (2010) is dry: "It isn't possible to be more accurate; it's only possible to be more lucky."

How to answer

I have worked on government-scale systems from pre-sale to handoff, and the habit I would teach first is simple: never let a number leave the room without its assumptions. In practice:

1. Ask what the number is for. A budget, a date, a vendor comparison, or a go or no-go.
2. Give a range, not a point. "Three to six weeks" is honest. "Four weeks" is a range with the edges cut off.
3. Name the assumptions. "Assuming the payment provider's test environment is ready, and the design is the one we reviewed on Tuesday."
4. Say what would narrow it. "I can tighten this after two days of investigation, or once you decide whether refunds are in scope."
5. Keep the commitment separate. If they need a date to announce, commit to the top of the range, or to the scope you can finish by their date.
6. Check whether a single number is a target. In McConnell's words (2006), "A single-point estimate is usually a target masquerading as an estimate."

Put together, an answer sounds like this: "Three to six weeks, most likely four, if the design holds and the payment provider is ready. We can commit to the booking flow by the end of next month. Payments would follow about two weeks later."

When the date is fixed, scope is what moves, not effort. A launch tied to a trade show, a regulation or a contract does not slide, so the uncertainty has to go somewhere, and McConnell says where: with a fixed schedule, the variability lands on the features you can deliver in the time available. Effort is the wrong dial. Overtime borrows from the following month. Agree early on what is in the first release and what follows it, and the date becomes one you can keep. It is the same conversation as the one about small requests with large ripples: state the consequences and the trade-off before agreeing, not after.

An estimate describes what you know. A commitment is a decision about what to do with what you do not know yet. Give the first freely, and the second on purpose.

Written by Eslam Hamed, a Technical Lead and AI Solutions Architect working on enterprise software delivery, from pre-sale to handoff.