Why Your Software Estimates Are Always Wrong (And the Boring Fix That Works)
Karani Geoffrey8 min readYou said two weeks. It took seven. You did not lie, you were not lazy, and the client was not unusually difficult. It just took seven weeks, the way it took seven weeks the last four times.
Then you did the thing we all do: you decided that next time you would think harder about the estimate. Next time came. You said three weeks. It took nine.
The thesis of this article is simple and slightly insulting: you cannot fix estimation by thinking harder, because the error is not in your reasoning. It is in your sample size. You are estimating from a memory of past projects that has quietly deleted every hour you spent waiting, fixing, redeploying and explaining. The fix is not a better brain. It is a ledger.
Three things the research already settled
The planning fallacy. Kahneman and Tversky described our tendency to underestimate the time, cost and risk of our own future actions while overestimating the benefits. Crucially, we do this even when we know we did it last time. Awareness of the bias does not remove the bias.
The inside view versus the outside view. The mechanism behind the fallacy is that we estimate by imagining the specific plan for this specific project, step by step, instead of asking how similar past projects actually turned out. The inside view feels rigorous and is systematically optimistic, because your mental walkthrough never includes the day the client's server certificate expires.
The cone of uncertainty. Steve McConnell's work popularised the finding that estimates made at initial concept can be off by a factor of four in either direction, giving a total range of roughly sixteen to one, and that the cone only narrows as you actually resolve requirements and design decisions. The cone does not narrow with time. It narrows with decisions.
The practical response to all three is reference class forecasting: instead of estimating this project from the inside, find the class of similar past projects and use what those actually cost. This is where most of us fail, because we have never written down what our own projects actually cost.
Four numbers that are not the same number
Half of all estimation arguments are actually definition arguments. Keep these separate and say which one you are giving:
- Estimate: your honest, unbiased assessment of likely effort. It is a range, not a point.
- Target: what the business would like. "We want it before the audit in September." Legitimate, but it is a wish, not an estimate.
- Commitment: what you promise to deliver. It should sit at the pessimistic end of the estimate, not the middle.
- Quote: the commitment turned into money, with risk priced in.
When a client asks "how long", they are asking for a commitment and you are usually answering with an estimate. That mismatch is a large share of every "you said two weeks" conversation.
Build your personal multiplier in ten projects
Start a spreadsheet today. Three columns: what you said, what it took, and the ratio. Log at the task level, not the project level, because task-level data accumulates fast enough to be useful within a month.
| Task | Estimated days | Actual days | Ratio |
|---|---|---|---|
| Customer portal login and roles | 2.0 | 1.8 | 0.9 |
| Sales order import from Excel | 2.0 | 2.4 | 1.2 |
| Stock reconciliation report | 3.0 | 3.9 | 1.3 |
| Custom invoice print format | 1.0 | 1.5 | 1.5 |
| Approval workflow | 2.5 | 4.0 | 1.6 |
| Bank statement import | 2.0 | 3.6 | 1.8 |
| M-Pesa payment callback and reconciliation | 2.5 | 6.0 | 2.4 |
| Legacy data migration | 3.0 | 9.0 | 3.0 |
Two rules for reading this table.
Use the median, not the mean. The mean here is 1.71 and it is dragged around by the migration outlier. The median is 1.55, which is a better description of a typical task.
Commit at the 80th percentile, not the median. In this sample the 80th percentile ratio is about 2.2. Committing at the median means missing half your commitments, which is precisely the reputation you are trying to escape. Estimate at the median and commit at p80.
Notice something else in the table: the worst ratios are not the hardest engineering. Login and roles came in under. The disasters were integration with someone else's system and migration of someone else's data. That is not a coincidence, and it is the single most transferable finding from any developer's ledger: your estimates are fine for work you control and catastrophic for work that depends on other people.
The invisible line items
The reason your ratios are above one is rarely that the coding was harder. It is that you estimated the coding and delivered a project. Write these down as explicit line items with their own numbers, every single time:
- Environment setup, staging and deployment pipeline
- Waiting for access: credentials, sandbox keys, VPN, the person who has the password and is on leave
- Data extraction, cleaning and migration, including the second and third attempt
- Review cycles and rework after client feedback
- Testing, UAT support and defect fixing
- Training, documentation and handover
- Meetings, status calls and proposal follow-up
- The hypercare period after go-live when everything is urgent
If these do not appear in your estimate, they do not disappear. They just move into your evenings.
Worked example: a "three week" project
A distributor wants a portal where sales reps capture orders, credit limits are enforced, M-Pesa payments are confirmed automatically and management gets a weekly report. Your gut says three weeks. Here is the disciplined version.
Step one: decompose to tasks no larger than two days. Anything you estimate at "about a week" is a task you have not understood yet.
| Item | Days |
|---|---|
| Auth, roles and rep assignment | 2 |
| Customer and product sync from existing system | 3 |
| Order capture screens and validation | 4 |
| Credit limit rules and overrides | 2 |
| M-Pesa callback, matching and reconciliation | 4 |
| Weekly reports and exports | 3 |
| Admin and configuration screens | 2 |
| Raw build estimate | 20 |
Step two: add the invisible items explicitly.
| Item | Days |
|---|---|
| Environments, deployment, backups | 2 |
| Access and sandbox waiting time | 2 |
| Data extraction, cleaning, migration cycles | 3 |
| Review cycles and rework | 4 |
| UAT support and defect fixing | 4 |
| Training and handover | 2 |
| Project management and communication | 3 |
| Itemised total | 40 |
Step three: cross-check with your multiplier. Applying the p80 ratio of 2.2 to the raw build estimate of 20 days gives 44 days. The itemised bottom-up total was 40, and with a small allowance for the two genuinely risky items it lands around 46.
Two independent methods landing within about ten percent of each other is the strongest signal you will get that a number is real. Note the trap though: do not apply your historical multiplier on top of the itemised list if that multiplier was derived from raw estimates whose actuals already contained all this mess. That double counts. Pick one basis, keep it, and use the other as a sanity check.
Step four: turn it into a commitment and a price. Forty-four days of effort is roughly nine working weeks, and with realistic client response times it is closer to eleven calendar weeks. At a day rate of KES 45,000 that is about KES 2.0 million.
Your gut said three weeks. The disciplined number is eleven. If that gap feels absurd, look at the ledger again: it is exactly the gap your last four projects actually had.
Put the client on the clock too
Every estimate you give contains a hidden assumption about how fast the client responds. Make it explicit in the proposal: feedback within five working days, test data by a named date, a named decision maker, staff released for UAT. Then state that the timeline extends day for day when those are missed, and keep a dated log.
This is not aggression. It is the only honest way to give a date at all, and it moves the conversation from "you are late" to "we are both looking at the same log".
Sell discovery when the range is too wide to price
Sometimes the honest answer is "somewhere between six weeks and six months, and I cannot narrow that without two weeks of work". Say exactly that, then sell the two weeks. A paid discovery phase producing a specification, a data assessment and a phased plan is a real deliverable the client owns. Price it at five to fifteen percent of the expected project. Offer to credit part of it against the build if they proceed within sixty days.
Clients who refuse to pay for discovery are usually the same clients who will later refuse to pay for the change requests that discovery would have found.
Three things to stop doing tomorrow
- Stop estimating in meetings. Any number you say out loud becomes the commitment, whatever caveat you attach. The correct sentence is "I will send you a number by Thursday".
- Stop padding invisibly. Silent padding gets negotiated away because it is invisible, and it teaches you nothing because your ledger records the padded number. Price risk as a visible line: contingency, or a stated range with a stated confidence.
- Stop using "days" that mean twelve hours. If your day is eight hours, estimate eight hour days. Estimates that only work if you skip weekends are not estimates, they are debts.
Nobody remembers the estimate. Everyone remembers the miss. The ledger is how you stop having to rely on remembering.