Why Your Team Underestimates Every Project (And How to Fix It)

02. Bias 1: Planning Fallacy

The planning fallacy, named by Daniel Kahneman and Amos Tversky, is the tendency to estimate based on the best-case scenario for the task at hand rather than on the base rate of similar tasks. When you estimate a 'website redesign,' you imagine a client who responds quickly, a brief that stays stable, a design direction that clicks in the first round, and a team that has no other priorities competing for its attention. That's the best-case scenario. It happens occasionally. More often, the client takes five days to respond (not two), the brief shifts after discovery, the first design direction gets killed, and a competing urgent project pulls half the team's attention for a week. The planning fallacy produces estimates that are accurate for the ideal scenario and wrong for the realistic one. The gap between those scenarios is the overrun.

03. Bias 2: Anchor Bias

Anchor bias is the tendency to be influenced by the first number introduced in an estimation context, even when that number is arbitrary. In agency project estimation, the anchor is typically the client's budget, the competitor's price, or the rough number the salesperson mentioned in the proposal call. When the anchor is 'around $5,000,' the estimation process often works backward from that number rather than forward from the actual scope. The question becomes 'can we make this work for $5,000?' rather than 'how many hours does this actually require?' The honest answer to the second question might be $7,500 worth of hours, but the anchor has already shaped the estimate. The fix is structural: never start the estimation process from a price or budget. Start from deliverables and hours. Generate the number from the work, then compare it to the market context.

04. Bias 3: Optimism About External Dependencies

External dependencies are the parts of the project that depend on the client — approvals, feedback, access to assets, sign-offs, getting the right people in a room. Most estimates assume these happen at the speed the agency hopes for, not the speed the client actually moves at. This is the most consistently underestimated source of project time. A project that requires four client approvals, each taking 3 days instead of the estimated 1 day, adds 8 days to the timeline. That's not scope creep — it's the client's approval velocity, which is largely outside the agency's control. Correcting for this: use your actual historical approval cycle data, not your hoped-for cycle. If your average client takes 4 days to approve creative work, build 4 days into every estimate that includes a creative approval step — not 1 day.

05. Bias 4: The Unique Characteristics Trap

When asked to estimate a project, people focus on its unique characteristics — the specific client industry, the particular deliverable type, the unusual requirement that makes this project different from the last similar one. The unique characteristics feel most salient, so they dominate the estimation. The problem: unique characteristics are a small part of what drives project hours. The bulk of hours on any project go to universal activities — project management, client communication, revision cycles, quality review — that are consistent across all projects of a given type. By focusing on what's different, estimators systematically ignore what's the same. Building an estimation template that starts with universal activities, then adds unique scope items, corrects for this bias structurally.

06. Bias 5: Absent Invisible Work

Invisible work is the project overhead that doesn't attach to a deliverable: kickoff preparation, brief clarification, file organisation, handoff packaging, and the recurring async communication thread that runs for the project's duration. Because it doesn't produce a visible output, it often doesn't appear in estimates. Invisible work typically accounts for 15-25% of total project hours. On a 40-hour project, that's 6-10 hours of real labour that the estimate left out. These hours are worked, but not anticipated — so they appear as overrun.

07. The Reference Class Fix

The most effective correction for all five biases is reference class forecasting: instead of estimating based on how this specific project feels, estimate based on how similar projects have actually performed historically. This is Kahneman's actual recommended fix for the planning fallacy. The question isn't 'how long will this specific task take under ideal conditions?' but 'how long do projects like this typically take?' How to build a reference class for your agency: pull your last 10-15 projects of a given type (website redesign, brand identity, content retainer, etc.). For each, record: estimated hours, actual hours, and the ratio (actual/estimated). Average the ratios. That average is your correction factor for this project type. If your last 8 website projects averaged 1.35× the estimated hours, every new website estimate should be multiplied by 1.35 before presenting it to the client. This isn't padding — it's using data to correct a known bias.

08. Building an Estimation Library

A reference class only works if you have the data to build it. Building an estimation library is the ongoing operational practice:

• Every project gets an estimate recorded at the start, with deliverable-level hour breakdowns.
• Every project gets actual hours recorded at close, with the same deliverable breakdown.
• The ratio for each deliverable type is calculated and added to a running library.
• Estimates for new projects use the library ratios as a correction factor.

09. The Pre-Mortem

The pre-mortem is a structured bias-correction exercise that runs before the project starts. Ask the team: 'Assume this project ends up 40% over estimate. What caused it?' Write down the answers. These are the project-specific risks that your estimate may not have accounted for. The pre-mortem works because it shifts the framing from 'what will happen' to 'what went wrong.' This future-backward framing bypasses the planning fallacy by asking people to imagine failure rather than success. Common pre-mortem answers: 'The client changes direction mid-project.' 'The approval chain includes stakeholders we haven't met yet.' 'This client's feedback cycles take longer than our default estimate.' Each of these is a buffering opportunity — a specific risk identified in advance that can be translated into a specific hour buffer.

10. Changing How You Quote

The reference class fix and pre-mortem together produce better estimates. But better estimates only improve margins if the quotes reflect them. There's a common temptation to 'shade down' accurate estimates to hit a price point the client expects. This is the anchor bias re-entering after the estimation is done. The discipline: quote what the work costs, not what the client expects to pay. If the reference class data says a project costs $8,500 and the client expects $6,000, the appropriate responses are to adjust scope to fit $6,000 or to explain the cost structure and propose $8,500. Discounting the estimate to close the deal is how the margin problem perpetuates.