Why is a single-number estimate a bad idea?

Because a single number hides how uncertain the work really is. New software has parts nobody has figured out yet, so the honest truth is a range of possible outcomes, not one date. A single number forces the estimator to either add a large amount of extra time or guess low, and either way it hides the uncertainty that actually decides the result.

What is a good way to estimate a software project?

Give a range instead of a single number, and say what would push you toward each end. Break the work into small pieces so more of it becomes known, estimate the pieces, and be explicit about the risky parts you cannot yet measure. A range with clear assumptions is more honest and more useful than a confident single number.

Why do software estimates go wrong so often?

The usual cause is unscoped risk: work that was uncertain, complex, or simply unknown at estimate time, and that nobody accounted for. Research on large IT projects found they go far over budget on average, largely because they are big and full of unknowns. The cause is usually risk that nobody measured, and the team's speed is a smaller factor.

What does it mean to give an estimate as a range?

It means saying something like "this is likely six to ten weeks" rather than "this is eight weeks," and explaining what decides where in that range the work will finish. The width of the range should reflect how much you do not yet know. Confident, well-understood work gets a narrow range. New, uncertain work gets a wide one, honestly.

How does breaking work into smaller pieces help estimates?

Small pieces are easier to understand, so more of the work moves from unknown to known, and known work is far easier to estimate accurately. Breaking down the work also shows the risky, unclear parts that were hidden inside a big, vague piece of work, so you can name them instead of being surprised by them later.

What is unscoped risk?

It is the work you did not account for because you did not see it or did not understand it yet: a tricky integration, an unclear requirement, a hard technical problem, a dependency on someone else. Unscoped risk is the single biggest reason estimates fail, because the parts you never measured are exactly the parts that take longer than planned.

Should I add extra time to my estimate to be safe?

Adding extra time to a single number is a crude way to handle uncertainty, and it hides the real situation. It is more honest and more useful to give a range and to name the risky parts explicitly, so everyone can see where the uncertainty is. Then you can reduce that uncertainty deliberately instead of hiding it in a bigger number.

How can I make an estimate more accurate?

Reduce the uncertainty before you commit. Break the work down, and for the riskiest unknowns, do a small, quick experiment to learn how hard they really are before estimating the whole thing. An estimate made after you have tested the risky parts is far more reliable than one made while they are still unknown.

Why are big projects harder to estimate than small ones?

Because a big project combines many uncertainties, and they add to each other. More parts means more assumptions, more places a wrong guess early on breaks something later, and more risk that goes unscoped. Estimating and delivering in smaller pieces keeps the uncertainty small enough to reason about and correct.

What should I tell a stakeholder who wants one firm number and date?

Tell them the honest version: for genuinely new work, one firm number is a guess presented as a commitment, and it usually costs more in the end through overruns and rework. Offer a range with the assumptions written down, and offer to reduce the uncertainty by starting with a small first piece so the next estimate is far more reliable.

How does Reveneau estimate work?

We give ranges, not false-precision single numbers, and we are explicit about the risky parts that drive them. Where the uncertainty is high, we propose a small first piece to test the hardest unknowns before committing to the whole, because the most reliable way to improve an estimate is to reduce the unknowns behind it rather than to guess harder.

How to estimate a software project: Reveneau

Someone asks how long the project will take, and the pressure is to answer with a single number. Eight weeks. Ninety thousand dollars. It sounds decisive and professional, the kind of answer a competent person gives. But for any software work that is genuinely new, that single number is a guess presented as a promise, and everyone in the meeting proceeds to treat it as a commitment. When it turns out to be wrong, and it usually does, the story becomes that the team was slow or the estimate was careless. The real story is almost always different: the estimate was a false-precision answer to a question that did not have a single-number answer, and the parts that took longer than planned were the parts nobody ever actually measured. Estimating honestly is a skill, and it starts with refusing to give a false single number.

The single number is the mistake

Begin with why the single number is so misleading. New software has parts nobody has figured out yet. That is not a sign of a bad plan. It is the nature of building something that did not exist before. Because those unknowns exist, the honest truth about how long the work will take is a spread of possible outcomes, not one point. Reducing that spread to a single number hides the uncertainty without removing it, and hidden uncertainty is the most dangerous kind, because everyone plans around the number as if it were certain.

When you force a single number out of an estimator, you push them toward one of two bad choices. They add a large amount of extra time to cover everything they cannot see clearly, which makes the work look more expensive than it may be and hides the real situation. Or they guess low, often to sound confident or to win the work, and create an overrun that appears later as delays and extra cost. Either way, the single number has taught the people relying on it the wrong thing. We wrote about how the same thing happens in pricing and proposals in what custom software actually costs: the price of anything new is driven by how much you still do not know, and a confident number does not make the unknown go away.

Give a range, and let the width mean something

The honest alternative is a range. Instead of "eight weeks," you say "likely six to ten weeks," and then you say what would push you toward each end. That extra sentence holds the real information.

The width of the range is a measurement of how much you do not yet know, and it is one of the most useful things you can tell someone. Work you understand well and have done before gets a narrow range, because there is little uncertainty to reflect. Work full of new problems and open questions gets a wide range, honestly, because pretending it is narrow would be a lie. A stakeholder who sees a wide range learns something true and important: this part is uncertain, so we should treat the plan around it as flexible and find ways to reduce the uncertainty. A stakeholder handed a single number learns nothing except a date to be disappointed by.

Giving a range also changes the conversation in a healthy way. It moves the discussion from "is the number right" to "what would make this finish at the good end instead of the bad end," which is a question you can actually do something about. That is a far more productive use of the conversation than defending a single-number estimate that could never be defended.

Break the work down to reduce what is unknown

A range is more honest, but you also want it to be as narrow as it truthfully can be, and the way to get there is to turn unknown work into known work. The tool for that is breaking the work into small pieces.

A big, vague piece of work, "build the backend," is nearly impossible to estimate well, because all its uncertainty is hidden inside it where you cannot see it. Break it into small, concrete pieces and two good things happen. First, most of those small pieces turn out to be things you actually understand, and understood work is far easier to estimate accurately. Second, and more valuable, the breakdown makes the genuinely risky parts visible. That one tricky integration, that one unclear requirement, that one hard problem: they were hidden inside the big piece, where they would later have ruined your estimate, and now they are named pieces you can see and reason about. This is the same reason strong teams deliver in small increments rather than one big release, which we wrote about in move fast without breaking the product. Smaller pieces are easier to estimate, easier to correct, and easier to learn from.

Unscoped risk is what actually ruins estimates

Here is the part that matters most, the cause of almost every estimate that went badly wrong. The single biggest reason estimates fail is unscoped risk: work that was uncertain, complex, or simply unknown at the time of the estimate, and that nobody accounted for at all. The parts you never estimated are, again and again, exactly the parts that take longer than planned, because they were the hard parts, which is why they were unclear in the first place.

The numbers on this are clear for large projects. A study by McKinsey and the University of Oxford of large IT projects found that they ran on average 45 percent over budget while delivering 56 percent less value than predicted. Those overruns come mostly from unknowns that were never measured: risky pieces that were assumed to be simple, dependencies that turned out to be complicated, requirements that were less clear than anyone admitted. And the bigger the project, the worse it gets, because a big project combines many uncertainties, and they add to each other. This is one more reason to keep the pieces small: it keeps the risk small enough to actually see and account for.

So when you estimate, spend most of your attention on the risky, unclear parts, not the parts you already understand. The known work will finish close to its estimate. The unknown work decides whether the whole project succeeds or fails, and treating a risky unknown as if it were a simple known is the exact mistake that produces a confident estimate and a painful overrun.

Reduce the uncertainty before you commit

The most reliable way to give a better estimate is to reduce the uncertainty behind the estimate before you commit to it. If a piece of the work is both risky and hard to measure, the right step is often a small, quick experiment that tests that unknown directly, done before you put a number on the whole project.

If you do not know whether an integration with someone else's system is simple or hard, build a small test against it in a few days and find out. If you are not sure whether a technical approach will even work, try the hardest part of it first, on its own, before making the plan depend on it. An estimate made after you have tested the risky parts is worth far more than one made while they are still unknown, because you have converted a guess into knowledge exactly where the guess was most dangerous. This is also the honest answer to a stakeholder who demands one firm number and date on new work: the most useful thing you can offer is to start with a small first piece that reduces the biggest unknowns, and then give a narrower estimate on the rest.

Put all of it together and honest estimation stops being a single number that looks certain and becomes a way of managing uncertainty openly. Give a range, and let its width show honestly how much you do not know. Break the work down so more of it becomes known and the risky parts become visible. Spend your attention on the unscoped risk, because that is what actually ruins estimates. And where the uncertainty is high, reduce it with a small experiment before you commit, rather than guessing harder. That is the version of estimation you can defend after the work is done, which is the only kind worth giving.

AI writing the code changes which part of the estimate is uncertain, and it is worth being precise about how. The build phase became far more predictable: producing a working first version of a well-specified thing now takes days and varies little. The work on either side of it stayed unpredictable. How long it takes to decide exactly what you want has not improved at all, and reviewing the output and making it reliable is where most of the variation now is. So the form of an honest estimate changed. The wide range belongs on the specification and on the work to make the output reliable. The narrow range belongs on the build, which used to be the part nobody could predict.

Sources

McKinsey and University of Oxford (2012), "Delivering large-scale IT projects on time, on budget, and on value": https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value

How to estimate a software project honestly