Estimating agency work: why the number is wrong before the project starts
Published 5 November 2026
Most estimates that go wrong were never wrong in the spreadsheet. The hours added up and the rate card was right. The problem was everything the number quietly assumed.
An estimate is a prediction with a price on it. When the project overruns, the conversation usually turns to delivery: who was slow, who changed their mind, who underperformed. Very rarely does anyone go back to the estimate and ask what it assumed, because nobody wrote that down.
This post covers three places the number goes wrong before work starts, and five checks to run before you send one.
Optimism: you estimate the project you hope to run
When someone estimates a task, they picture it going well. The brief is clear, the feedback arrives on time, the data is clean, and the person doing the work is free on the day. That is a possible outcome. It is rarely the typical one.
The tell is an estimate built from the best case for each task and then added up. Ten tasks that each have a one in five chance of running over don't have a one in five chance of overrunning as a set. Most of the time, at least one will.
A useful habit is to look at the last three similar projects before you estimate this one. Not what you quoted, but what they actually took. The gap between those two numbers is the optimism in your process, and it is usually consistent.
Padding: the buffer nobody can see
The usual response to optimism is padding. Each person adds a little for safety, then the account lead adds a little, then someone rounds up. By the time the number reaches the client, nobody can say what the buffer is for.
Hidden padding gets spent. If a task has an extra 20 percent that nobody has named, it tends to take 20 percent longer.
Hidden padding can't be defended. When the client asks for a reduction, the only option is to cut hours across the board, because nobody knows which hours are real.
A named contingency works better. A line that says "Contingency: 10 percent, covers one extra round of revisions on each deliverable" can be discussed, reduced with a trade off, or released at the end if unused. It also tells the client what the risk is.
Unbilled discovery: the work before the work
The third gap is the one agencies tend to absorb without noticing. Before the estimate exists, someone has read the brief, joined two calls, looked at the existing site, asked questions about the data and drafted an approach. That is real work, and it rarely appears in the number.
The larger cost is what discovery produces. The team learns things during those calls that change the estimate: the legacy system has no API, the client needs sign off from legal, the content doesn't exist yet. If those findings are not written into the estimate as assumptions, they live in one person's head. When that person moves to another project, the knowledge goes with them.
Five checks before you send the number
1. List the assumptions on the estimate itself. If it says "content supplied by client by week two", then week three is a change request, not a delay.
2. Compare against actuals, not quotes. Pull the real hours from the last three comparable projects. If your number is well below them, explain why.
3. Show the contingency and the risks it covers. One line, one percentage, and the two or three named risks it is there for.
4. Check it against capacity. An estimate that needs 120 hours of a designer in a month when that person has 60 free is not an estimate, it is a wish. This is where the Capacity Planning System earns its place.
5. Attach the scope. The estimate and the Scope Statement should be sent together, so the number and what it buys are never separated.
The assumptions are the part that matters most. A short table is enough:
| Assumption | If it proves wrong | Who owns it |
|---|---|---|
| Client supplies final copy by week 2 | Each week of delay adds a week to the timeline | Client lead |
| Two rounds of revisions per deliverable | A third round is charged at the rate card | Account lead |
| Existing CMS exports content cleanly | Migration estimate is reviewed, likely up | Technical lead |
| Design lead available at 60 percent from week 1 | Resourcing reviewed before kickoff | Delivery lead |
An example. Yours will be specific to the project, and every row needs a name against it.
Assumptions are not the same as risks. An assumption is something the estimate relies on being true. A risk is something that might happen and cost you time or money. Plenty of risks start life as an unrecorded assumption: "the client will supply copy by week two" becomes "copy arrives late" the moment you ask what happens if it doesn't. Keep both in the same log, and size the contingency against the top few risks rather than a round number.
Check your last estimate
Take the most recent estimate you sent and ask five questions.
Could someone else read it and tell you what it assumed?
Do you know what a comparable project actually cost?
Is the contingency visible, or spread through the line items?
Did anyone check it against who is actually free?
Could you name the risks your contingency is there to cover?
If the answer to most of these is no, the number is a guess with a price on it. Writing the assumptions down doesn't make the estimate more accurate. It makes the next conversation about it a much shorter one.
The estimate wasn't wrong. The assumptions behind it were never written down.
A line item estimate with a visible contingency, an assumptions register with owners, a check against who is free and a comparison with what past projects actually took. Founding members get it free, with the Scope Statement and Capacity Planning System.
11 templates live · lifetime access · 14 day refund