Estimates are Always Wrong

Here’s something every developer knows and every executive suspects: estimates are always wrong. That doesn’t mean you shouldn’t do them. The value isn’t in the number. It’s in the thinking that produces it.

So why do estimates go wrong, and how do you make them useful anyway?

The box and the balls

Imagine your project is a box, and every task is a rubber ball. The box is fixed: it’s your deadline, your budget and your team’s capacity. But the balls are round, so however you arrange them there are always gaps. That’s the overhead of context-switching, handoffs and communication.

You don’t know how many balls there are, or how big each one is. Halfway through, balls you never saw coming turn up, and the ones you planned for start to grow. Worse, the box isn’t empty when you start. It already holds existing commitments, maintenance and technical debt.

Crunch time and heroics can squeeze the balls, but they stay round. The gaps never fully close. And even if you get them all in, the weight might be more than the box can safely hold.

Your capacity is smaller than you think

A forty-hour week sounds like forty hours of work. It isn’t. There are meetings, email and Slack. There are existing systems to support. Someone’s on leave; someone’s sick. Your actual productive capacity is often half what the calendar suggests, so the box you’re trying to fill is already smaller than you thought, and it isn’t empty.

Big isn’t the same as hard

Every estimate has two dimensions: how big is it, and how hard is it? A big task isn’t necessarily difficult, and a small task isn’t necessarily easy. A large piece of work can be lots of effort but straightforward; a small one can be deceptively complex. Confuse the two, and your estimates fail before you start.

Be honest about uncertainty

Three-point estimation gives you a way to be honest about uncertainty. Instead of one number, you give three: optimistic, most likely and pessimistic.

But look at the shape of reality. It isn’t a bell curve; it leans to the right. The optimistic case needs everything to go to plan, so it rests on your assumptions. The pessimistic case is your risks, and it stretches further, because work rarely shrinks. Planned tasks grow, and new ones appear that nobody saw coming.

If you only give a “most likely” estimate, you’re ignoring all of this, and there’s a much greater chance you’ll overrun than beat it. The wider the gap between optimistic and pessimistic, the less you know. Early in a project the cone of uncertainty is wide; as you learn more, it narrows. That spread is telling you something.

Effort isn’t duration

“How long will it take?” sounds like one question. Teams answer with the work. The business hears a date.

An estimate of 847 hours is a red flag: that precision implies an accuracy you don’t have. 800 to 900 hours is better, because it’s a range. But here’s where it goes wrong. Someone does the maths: five people, forty hours a week, so that’s four weeks. Wrong.

Eight hundred hours of effort isn’t eight hundred hours on the calendar. Nobody has forty productive hours a week; it’s closer to twenty-two, so four weeks is already seven or eight. Then there are dependencies: B can’t start until A finishes. And the more people involved, the more time goes on communicating. Effort tells you the work. Duration tells you the calendar. They’re not the same thing.

A date is a promise

A duration becomes a schedule the moment it’s shared. Until then, a date is just a calculation. After that, it’s a promise. Other teams plan their work around it, launches get booked against it, and customers make plans of their own.

So the date becomes a dependency, and it gets hard to move, even as the estimate improves. A rough guess from the widest point of the cone becomes a deadline the team is held to. And if that date was cut to hit a target, the risk doesn’t stay with the team. It passes to everyone who planned around it.

Cost isn’t price

Every business knows the difference between cost and price. The estimate is the cost: what the work will really take. The commitment is the price: what you choose to charge, or promise. You can choose the price. You can’t choose the cost.

If the cost is too high, there are three honest options. Change the specification. Accept lower quality. Or sell below cost. But do it knowingly.

We worked with a company whose sales team quoted one and a half million to win a contract the technical team had estimated at two million. The estimate was brought down to match. The team worked unpaid overtime to close the gap, and the project still overran. The half million didn’t disappear. It moved onto the team, and then back onto the business. Someone always pays the difference.

Padding hides risk. Contingency names it.

The story rarely ends there. A team that’s been forced to cut one estimate learns to pad the next. Others go the other way, shrinking their own estimates to fit the target and telling you what you want to hear. Both are rational when honesty feels risky.

But padding added out of habit gets used up, whether or not anything goes wrong, so it quietly becomes the new baseline. The business learns that estimates are inflated, so it cuts them. Teams learn their estimates will be cut, so they pad more. Round it goes, until the number stops meaning anything.

Contingency is different. It’s open and deliberate: sized from the risks you’ve named, held separately rather than spread across every task, and handed back when it isn’t needed.

Padding hides risk. Contingency names it.

Estimate more than once

Estimates are always wrong. But they get less wrong every time you revisit them, as requirements are elaborated and as experience shows what the work really takes. That’s how the cone narrows. An estimate isn’t a one-off: estimate once, and you’re stuck with your widest guess.

All of it depends on openness, honesty, trust and communication. Without them, you get padding, cutting and numbers nobody believes. With them, an estimate becomes what it should be: an honest conversation about what’s possible.