2026-10-27 · Gavril team

70% of projects run over budget. Your estimates should be allowed to say "I don't know."

The estimation numbers have barely moved in a decade. 70% of software projects exceed their initial budget, by an average of 27%; large IT projects run 45% over; and only around 29.7% fully meet time, budget and quality goals, with half "challenged" and a fifth failing outright (2026 project failure data). Scope creep shows up in 52% of them.

A calculator on a paper ledger

The expensive part isn't being wrong

Every agency knows estimates are guesses. What actually costs money is a guess delivered with a straight face to a client. "Mid-November" said confidently becomes a date they plan a launch around, brief a reseller on, and hold you to. When it slips, you haven't lost two weeks — you've lost the credibility of every date you give after it.

An estimate that admits its own uncertainty costs one awkward sentence. A confident wrong one costs the relationship.

A forecast is arithmetic, not an opinion

You don't need a model to know whether a date holds. You need two numbers:

remaining estimated hours ÷ hours actually delivered per day

Measure delivery over a recent window — the last two weeks, not the project average, because the team you have now is the team that will finish. That gives a projected date next to the promised one, and the gap between them is the conversation to have this week rather than in November.

The important design decision is what happens when the inputs are thin. If half the open work is unestimated, the honest output is "unknown" — not an optimistic number produced anyway. "We don't know yet" and "we're on track" are different answers, and only one of them is safe to give a client.

Estimating the backlog without a planning offsite

Estimates go stale because writing forty of them is nobody's favourite afternoon. Gavril's estimation view puts the open tasks in one grid with a suggested number beside each — calibrated on what this project's finished tasks actually took, not on a general sense of how long a login screen should be. Accept, adjust, save. The moment a suggestion is accepted it's just the estimate; we don't keep a second column of what the machine thought, because two answers to "how long will this take" is how boards stop being trusted.

Then the timeline draws the same arithmetic as the milestone forecast — the chart is never a second opinion on whether a date holds.

Estimates feed the two conversations that decide the margin: what a change actually costs, and what the scope of work already covers. Both work better when the number attached is one you're willing to defend — including when the number is "not yet".

← All posts