Back to notes

July 11, 2026 · 5 min read

Why My Estimates Are Usually Wrong in the Same Direction

I pulled estimate-versus-actual data across two years of projects. The errors weren't random. They clustered in one predictable, correctable direction.

FreelanceProcess

I finally did the exercise I'd been avoiding — pulled every project estimate I'd given over two years and lined it up against actual hours billed. I expected scatter, some projects over, some under, roughly balancing out. Instead I found a consistent pattern: I underestimated by an average of 28%, and it was worse on exactly the kind of project I'd call myself experienced at.

That last part surprised me most. I assumed familiarity would make estimates more accurate. It made them more confident, which isn't the same thing. On unfamiliar project types, I padded estimates out of explicit uncertainty. On familiar project types, I estimated as if the client's environment would look like the clean version in my head, not the messier real one I'd find once I actually opened their GTM container.

Where the underestimation specifically clustered

  • "Integration with existing systems" line items — I consistently estimated these assuming documentation existed and was accurate
  • Anything involving a third client-side stakeholder's approval cycle, which I estimated as a scheduling delay, not the multi-round feedback loop it usually turned out to be
  • Data migration tasks, where I estimated based on data volume and consistently ignored data quality, which is the variable that actually determines the time
  • QA and validation at the end of a project, which I routinely estimated at a flat percentage regardless of how messy the underlying build had turned out to be
My estimates weren't wrong randomly. They were wrong in the specific, repeatable places where I assumed the client's reality would match the clean case in my head.

What changed after seeing the data

I now apply a specific multiplier to exactly the categories that historically ran over, instead of a flat contingency buffer across the whole estimate. It's not more sophisticated than that — it's just evidence-based instead of vibes-based, and it's brought my estimate accuracy within about 8% on average since. The fix wasn't getting better at estimating in general. It was noticing where specifically I was consistently wrong and correcting that one thing.