Estimates don't fail because your team is careless. They fail for structural reasons — which means they can be fixed structurally.
Estimates run over because people estimate the work they can picture, and the work they cannot picture is where the time goes. Review, revision, waiting on someone else, the third round of client feedback, the environment that broke — none of it appears in the mental model, all of it appears in the calendar. The fix is not to try harder; it is to compare estimates against recorded actuals from your own history and let the ratio correct you.
Five causes account for most of the overrun, and only one is about the person estimating:
Notice that none of these are solved by asking for a more careful estimate. They are solved by changing what the estimate is based on.
Most teams have estimates. Very few have actuals recorded against those same estimates. That missing half is why estimation never improves — the loop never closes, so each new estimate is made with exactly the information available last time.
The minimum viable measurement, recorded on the task itself:
Three fields. After two months you can compute a ratio; after six you can compute it per task type, which is where it becomes genuinely useful.
Once actuals exist, compute the ratio of actual to estimated across completed tasks. Use the median rather than the mean — one catastrophic task should not redefine your planning.
Example. Twelve completed tasks in a month, estimated at 96 hours, actually taking 154 hours. The ratio is 154 ÷ 96 ≈ 1.6. So when the team next estimates 40 hours of work, plan for roughly 64.
That correction factor is more valuable than any estimation technique, because it is measured from your team, your clients and your kind of work. And the ratio itself is diagnostic:
The single most effective change to how estimates are made: stop reasoning forward from the task and start comparing backward to similar completed work.
"How long will this landing page take?" invites a mental simulation that omits everything unglamorous. "How long did the last three landing pages take?" invites a lookup — and the historical answer already includes the review rounds, the feedback, and the day the client went quiet.
Reasoning forward gives you the ideal case. Looking backward gives you the real case, because the past already contains everything you're about to forget.
This requires a searchable history of past work with times attached — which is exactly what a well-kept task log is. Without it, every estimate is made from scratch, forever.
Estimation is not a project-management nicety — it is priced into everything. A fixed-price quote built on estimates that run 1.6× is a quote priced at 62% of its true cost. A retainer sized on optimistic estimates is a retainer you deliver at a loss while feeling busy.
So the correction factor is directly a commercial input: it belongs in how you price retainers and in how you assess project profitability. Teams that measure it typically discover their most-loved client is their least profitable — which is a useful, if uncomfortable, thing to learn from your own data rather than from a bad year.
When the gap is not estimation error but added work, catching scope creep in the task log is the next read.
| Root cause | Estimating the ideal path; omitting coordination, review, rework and interruption |
|---|---|
| Minimum to measure | Estimated time, actual time, task type — three fields |
| Correction factor | Median actual ÷ median estimated, across completed tasks |
| Worked example | 96h estimated vs 154h actual → ratio ≈ 1.6 → plan 40h of work as 64h |
| Healthy ratio | 1.0–1.2; services work commonly sits at 1.5–2.0 |
| Red flag | Above 2.5 (scope undefined) or consistently below 1.0 (padded estimates) |
| Best single technique | Compare to similar completed tasks instead of reasoning forward |
Because people estimate the path they can picture — the work itself — and omit the work they cannot picture: clarification, review, revision, waiting on dependencies and interruptions. This is the planning fallacy, and it is structural rather than a matter of carelessness, which is why asking for more careful estimates does not fix it.
Take completed tasks that carry both an estimate and a recorded actual, and compute the ratio of actual time to estimated time. Use the median rather than the mean so one extreme task does not distort the figure. For example, 96 hours estimated against 154 hours actual gives a ratio of about 1.6.
A ratio between 1.0 and 1.2 is healthy. Services work with client feedback loops commonly sits between 1.5 and 2.0, which is workable if you plan with it. Above 2.5 usually means scope is not defined before estimating. Consistently below 1.0 means estimates are padded, which inflates quotes and makes planning unreliable in the other direction.
Record actuals against estimates so the feedback loop closes, estimate by comparing to similar completed work rather than reasoning forward, use ranges instead of single numbers, break anything longer than a day into smaller pieces, and apply your measured correction factor to new estimates. Review misses by asking what was unaccounted for, never why someone was late.
Estimate in focused hours, then convert to elapsed days using a realistic focus factor. Most people have four to five genuinely focused hours in a working day rather than eight, so eight estimated hours is closer to two days than one. Conflating the two is one of the most common sources of missed deadlines.
Directly. A fixed-price quote built on estimates that run 1.6 times over is priced at roughly 62% of its real cost, and a retainer sized on optimistic estimates is delivered at a loss. Your measured correction factor belongs in pricing and in project profitability analysis, not just in project planning.
Merik's task log captures estimated and actual time on the same entry, so the comparison exists without anyone running a separate exercise. Task Insights aggregates it across the log, and predictTime() suggests a duration for a new task by scoring it against similar past tasks — token overlap in the description, plus the same project and client — rather than by asking someone to guess again.
It is deliberately not a language model. It is a similarity lookup over your own history, and it tunes itself: tuneTimeModel() backtests its own weights leave-one-out against tasks whose real duration is already known, keeping whichever settings minimise median error. So the suggestion improves as your log grows, and it is explainable — you can see which past tasks it matched. See the task insights module, the feature list, or how it works.
Same raw material, very different compliance and usefulness.
Turn the hours your team already logs into a per-project margin.
Estimate vs logged hours per project, weekly, turned into a change request in time.