Why Your Estimates Are 30% Off — and How to Stop Apologising for It

The most common piece of feedback I get from agency owners about their estimates is some version of: "We're getting better, but we're still 25–35% off on the actuals." It's said with a slight wince. The implicit message is we're working on it; the estimates need to improve.

The wince is the wrong reaction. The variance isn't usually a function of how the estimate was written. It's a function of three structural causes that exist outside the estimate document, and that the document cannot fix on its own.

This is a piece for the people who write estimates and the people who pay the price when those estimates are wrong. The three causes are diagnosable. Each has a structural fix. The fixes don't require the team to be more careful or more disciplined; they require the estimating process to see things it currently can't see.

Cause 1: the meeting the estimate didn't see

Between the moment the brief leaves the client's desk and the moment the agency receives it, there is, at almost every client of size, an internal meeting. Sometimes more than one.

In that meeting, the client reshapes the scope. Sometimes they add an outcome that wasn't in the original brief ("while we're at it, we should fix the X flow"). Sometimes they remove a constraint that the briefing party assumed was hard ("actually we have to ship by Q3, not just want to"). Sometimes they include or exclude a stakeholder whose involvement will materially change what the project becomes ("we'll need to bring in legal on every screen change; let's add that to the kick-off").

The output of this meeting is almost never sent back to the agency in writing. The agency receives the original brief plus, perhaps, a one-line email — we'd like to speed it up; can you start in two weeks instead of four? — that the agency reads as a scheduling change. It is not a scheduling change. It is a change to the constraints of the project, and it almost always implies more work than the original brief priced for.

We measured this on our own engagements over a six-month window. Of the 38 estimates we wrote in that window, 22 had a "client side internal change" event that we discovered later — usually mid-project — that should have re-priced the engagement. The estimates that included a re-pricing on the back of that discovery landed within 8% of the actuals on average. The estimates that absorbed the change without re-pricing landed 27% over.

The structural fix is small in process and large in effect: add a 30-minute "alignment workshop" between estimate signature and project kick-off. This is not a planning session. It is a deliberately structured conversation that asks four questions:

• What has changed on your side since you sent us the brief?
• Who else has weighed in on the scope, and what did they ask for?
• Is the date you'd like still the date you actually need, or is one of those harder than the other?
• Is there a related piece of work we should know about that's coming up after this?

The conversation is between the project lead, the account director and the equivalent people on the client side. It produces a one-page note that goes back to both sides as a confirmation of the actual scope at kick-off, not the scope at the moment of brief.

About a third of those workshops produce a re-priced estimate. Another third produce a clear scope statement that lets the project run cleanly later. The remaining third produce nothing different from the original brief, and that's the most valuable third — because you've ruled out a class of variance that was previously eating 27% of your projects.

Cause 2: the role mix that wasn't defended

The second cause is the one we wrote about in the role-based estimating piece: an estimate written at headline-hours level cannot defend its role mix during the project. When the senior absorbs mid-level work, the labour-margin report shows nothing wrong because nothing has gone wrong on labour terms — the senior was budgeted to be on the project, and the senior is on the project. What the report doesn't show is that the senior is doing work that was costed at the mid's hourly cost, which means the project is paying £85 per hour for an hour that was priced to cost £45.

The structural fix is also one we wrote about: estimate by role rate. The fix is genuinely small at the document level (10–15 extra minutes per estimate) and it's the single biggest reduction in margin variance we've seen install at any agency.

What's worth adding here, in the context of estimate accuracy specifically, is what role-based estimates do to the pre-project conversation. A role-based estimate is much harder to negotiate down without rebalancing the role mix. A client who wants 15% off has to engage with the question "which role's hours are we cutting, and what's the implication for delivery?" — a conversation the agency wins more often than it loses.

Headline-hours estimates absorb price negotiations into the blended rate. The headline number drops, the team still does the work, the margin compresses invisibly. By the time the project is over, the variance shows up in the closing pack and everyone remembers the project as having been "tighter than we thought". The blame, by then, lands on the team's discipline. It belongs on the estimate's structure.

Cause 3: the support tail that wasn't priced

The third cause is the one nobody likes to look at, because it's a direct accounting of work the team gave away.

Every project ships with a tail of post-launch support. The original scope acknowledges this — usually with a phrase like "two weeks of warranty support included" or "post-launch hypercare for 30 days" — and almost always under-prices it.

Our internal data: across the 38 estimates we measured, the average post-launch support consumption was 3.4 weeks of senior time per project. The average scope budgeted for 1.0 weeks. The 2.4-week gap, at senior rates, is roughly £6,000 per project of unbilled work that lives inside the project's cost line.

The variance gets worse for retainers. A 12-month retainer at "support 4 days/week" is, on average, supporting 4.7 days a week in months 3–9. The marginal time is unbilled. By month 6 the retainer is showing a cost line that's 17% above what was budgeted, but no invoice line has changed.

Three structural fixes, in increasing order of intervention:

• Price support honestly. Most agencies can defend a 4-week support tail in the original estimate. The price goes up by 5–8% and the variance disappears.
• Sub-project the support tail. Move post-launch support into a separate sub-project (a separate engagement number, separate hours, separate cost line, separate margin report) so it reads cleanly and can be re-priced or terminated without affecting the build's margin reporting.
• Move support to a fixed-fee monthly retainer. Convert the warranty period into a small monthly retainer with a defined SLA. The agency controls the hours; the client gets a predictable bill; the build closes cleanly.

Of these three, the second is the cheapest to install and produces the biggest immediate benefit. We use it on every engagement now. The build closes when the build closes. Everything afterwards is on a different sub-project with its own pricing model.

What the three causes cost together

In the same six-month window we measured ourselves on:

• The "alignment workshop" change reduced post-kick-off scope variance from 18% to 6%.
• The role-based estimate change reduced role-mix variance from 11% to 3%.
• The support-tail change reduced unbilled support cost from 6.2% of project value to under 1%.

Aggregate variance fell from 30%-ish to roughly 8%. The change was install-able inside one quarter, didn't require a new tool, and didn't require the team to do anything they hadn't been doing — just to have a different shape of conversation at three specific points in the project lifecycle.

The structural-fix-not-discipline-problem framing is the key one. If you ask your team to "be more disciplined about scope" or "log time more accurately", you'll get marginal improvements at best. If you ask the process to surface the meeting that didn't happen, the role mix that wasn't defended, and the support that wasn't priced — the variance falls to single digits without any change in the team's behaviour.

The four questions to ask yourself this week

If you want to diagnose the 30% variance in your own estimates, here are the four questions worth asking your team this week:

1. What's the average gap between the date the brief was received and the date the project actually kicked off? If it's more than 10 working days, there's almost certainly a client-side internal meeting in there that reshaped the scope.
2. Of the last 10 projects, how many had a senior absorb work that was budgeted at a more junior role? If the answer is more than two or three, the role-rate variance is your single biggest fixable problem.
3. What's the average length of the post-launch support tail on your last 10 builds, vs what was scoped? If the actual is more than 50% longer than scoped, you have a support-pricing problem.
4. What's the average gap between estimate value and final invoiced value, including change orders? If it's more than 30%, you have a re-pricing process problem rather than an estimating accuracy problem.

The answers tell you which of the three causes is dominant in your setup. Each of them has its own structural fix. None of them require you to apologise for "being 30% off". The fix is in the process between the brief and the close, not in how the estimate is written.

If you want to see your current variance broken down by cause on your real Jira data — role-rate vs employee-cost variance per project, support-tail length per build, scope variance by client — that's what Saldo does. The 15-minute demo on your own data answers more diagnostic questions than a quarter of pricing reviews. We don't ask for card details up front, and we don't follow up if it doesn't land.