.png)
Why Software Estimates Are Always Wrong
Every few weeks someone asks me why software people cannot estimate. The question usually arrives with a story attached. A project quoted at three months that took seven. A budget that doubled. A vendor who shrugged.
I build software for a living, and my estimates have been wrong too. After two decades I can tell you this much: the estimates are not wrong because software people are bad at arithmetic. They are wrong because of what an estimate actually is.
Building software is not like building a wall. When a mason quotes a wall, the wall has been built a thousand times before. When we quote a system, the core of the work is learning: finding out what the requirements actually mean, what the old system really does, and what your data looks like once someone opens the box. You cannot know the size of what you have not learned yet.
That is why an estimate made on day one is the least informed number that will ever exist about the project. Everything the team learns afterwards makes the picture sharper. The industry has a name for this shape.
Estimates do not start wrong and get better. They start unknowable and get narrower.
At the idea stage, a serious range is something like a quarter to four times the final effort. That sounds absurd until you watch it happen. We once quoted a document workflow at eight weeks and it took five, because the client's data was cleaner than anyone believed. The next project, quoted with the same care, took double its estimate because a fifteen-year-old ERP spoke a dialect nobody had documented.
Where does the time actually go? Not into typing. Building the part everyone described at the kickoff is a minority share of any real project.
The known part is the small part.
Edge cases eat the first hidden quarter. Every process has them: the customer with two billing addresses, the order that was cancelled and reactivated, the umlaut that breaks the export. Nobody mentions them in the kickoff because nobody thinks of them as special. They are just Tuesday.
Integration eats the second. New software rarely lives alone. It has to read from and write to the systems you already have, and those systems have opinions, undocumented quirks, and occasionally a maintenance contract with someone who left the country. The connector that was one line in the proposal becomes three weeks of archaeology.
And then there is waiting. For a test account, for a decision about a field name, for the one person who knows how discounts really work to come back from holiday. On some projects, waiting is the single largest line item, and it belongs to neither side entirely.
So what do you do with this as a buyer, other than despair? A few things, all of which we practice ourselves.
Ask for ranges, and distrust single numbers. A vendor who says nine to fifteen weeks and can explain what decides the difference understands the work. A vendor who says exactly eleven weeks is either padding heavily or guessing politely.
Spend the first money on shrinking the range, not on building. A one or two week discovery that opens the real data, reads the old system, and builds a thin slice of the riskiest part teaches more than any workshop. It costs a fraction of the project and regularly changes the plan.
Do the riskiest part first, not the easiest. Teams like starting with the login screen because it is familiar. Start with the ERP connection instead. If the project is going to surprise you, arrange to be surprised in week three, not in month five.
Re-estimate at milestones, and treat the new number as better information, not as a betrayal. The estimate after the first working slice is worth ten of the estimate from the proposal. Projects go wrong when everyone keeps steering by the day-one number out of politeness.
And decide what is actually fixed. Scope, date, budget: you can fix two, and the third has to breathe. The version that works best in practice is a fixed budget and a fixed date with scope that flexes, shipping the most valuable slices first. Then a surprise costs you the least important feature instead of the deadline.
Estimates will stay wrong on day one, because that is the nature of learning work. The difference between a good project and a bad one is not the accuracy of the first guess. It is how fast the guess gets better, and whether anyone updates the plan when it does.
Questions I hear about estimates
Why are software estimates so often wrong?
Because a software estimate is a guess about learning, not construction. It is made on day one, at the point of least information, before anyone has seen the real data, the edge cases, or the quirks of the systems the new software must talk to. The estimate is not bad arithmetic. It is an early answer to a question that is not fully known yet.
What is a realistic accuracy for a software estimate?
At the idea stage, plus or minus a factor of four is honest. After a proper discovery on real data, plus or minus 50 percent. After the first working slice, plus or minus 20 percent. Any vendor promising day-one precision beyond that is padding the price or guessing.
How do I get more reliable estimates from a vendor?
Ask for a range and for what decides where you land in it. Pay for a short discovery on real data before committing to the full project. Insist the riskiest part is built first, and re-estimate at each milestone. Reliability comes from shrinking uncertainty early, not from a firmer handshake.
Should I insist on a fixed-price software project?
Fixed price means the vendor charges a risk premium and defends scope line by line, which you pay for in money and in flexibility. A fixed budget and date with flexible scope usually serves buyers better: the most valuable features ship first, and surprises cost you the least important feature instead of the deadline.
