Estimating From Your Own Historical Data

Estimates are wrong in a predictable direction. Almost everyone underestimates, most of the time, by a factor that is reasonably stable per person and per team.

Which means the practical move is not to estimate better. It is to measure your own factor and apply it.

For a vendor-side perspective on stealth monitoring software, see further details from Monitask.

Why estimates run short

Not carelessness. Several mechanisms, all consistent.

Decomposition misses the connective work. Listing tasks and adding them up omits the setup, the switching, the handover, the clarification, the waiting. That connective tissue is frequently a third of the total.

We estimate the good case. The version where nothing is ambiguous and nobody is unavailable.

We forget the rework. Revisions, corrections, the thing that came back.

Interruptions are invisible in advance. Nobody estimates the four unrelated conversations.

Past experience is optimistically remembered. The last similar job is recalled as having gone faster than the records show — which is why records beat memory.

And unknowns are asymmetric. Surprises make things longer far more often than shorter.

Finding your factor

The whole method, and it takes an hour if you have data.

Take your last several completed pieces of work. Five is usable, ten is better.

For each: what did you estimate, and what did it actually take? Total hours, including the non-billable parts.

Divide actual by estimate. That is the factor for that job.

Look at the spread. If most sit between 1.3 and 1.6, your factor is about 1.4. If they range from 0.9 to 3.2, you have a different problem — see below.

Apply it. Estimate as you always do, then multiply.

This works because the bias is consistent. You are not trying to remove it; you are correcting for it.

When the spread is wide

A factor only helps if it is stable. Wide variation means the estimates are not comparable, and the fix is categorisation rather than a single number.

Split by type of work. Familiar work has a tight factor; unfamiliar work has a wide one.

Split by client. Some clients generate far more revision cycles, and that belongs in the estimate rather than in the disappointment.

Separate the outliers and look at what they had in common. Usually one of: new domain, unclear requirements at the start, or a dependency on someone else.

Then use different factors for different categories, which is more useful than one average nobody trusts.

Estimating by comparison

Better than decomposition for most work.

"This is like the Henderson job, which took 34 hours, and slightly larger" produces better estimates than listing tasks and adding up — because the comparison includes the connective work automatically, and the decomposition does not.

Which requires a record of what past jobs took. That is the argument for tracking, stated compactly.

Keep a short list of reference jobs with actual hours. Five or six covering your range. Estimate against them.

What to include

The parts people leave out, which are the reason estimates run short.

Briefing and clarification.

Revisions. How many rounds do you actually get, historically?

Admin. Contracting, invoicing, the chase.

Waiting. Not your hours, and it is calendar time, and it belongs in the deadline even when it does not belong in the price.

Handover and documentation.

And a contingency you name. Not padding hidden inside the numbers — a stated allowance, which is easier to defend and easier to release. For broader independent background, see ILO guidance on working time.

Presenting an estimate

Give a range, not a point. A single number is heard as a commitment and it is a guess.

State what it assumes. How many revision rounds, what you need from them and when, what is out of scope. Most overruns trace to an assumption nobody wrote down.

Separate hours from calendar time. Twenty hours of work is not three days if you are waiting on approvals.

And say what would change it. Scope, delay in feedback, additional stakeholders.

Using the data honestly

Record actuals even when they are embarrassing. The job that took three times the estimate is the most informative data point you have, and it is the one people quietly leave out.

Record what actually happened, not what you billed. These differ, and the difference is your real rate. See time tracking for freelancers.

Note why the outliers happened, in one line, at the time.

Review quarterly, not per job. Individual variance is noise; the pattern is the signal.

And accept the accuracy your data supports. Approximate honest records give a usable factor. Precise defensive records do not. See why time data is almost always wrong.

For teams

The same method, with two additions.

Individual factors differ, and that is not a performance measure — it reflects the work each person gets and how they estimate, not how fast they are.

The team factor is what matters for planning. Estimate at team level, apply the team factor.

And do not use estimate accuracy to evaluate people. The moment you do, estimates inflate defensively and the entire method stops working. See what time data must never be used for.

The short version

Everyone underestimates in a consistent direction — so measure your factor rather than trying to estimate better.

Actual divided by estimate, across several past jobs. That is the method.

Wide spread means you need categories, not a single factor.

Estimate by comparison to past jobs, because decomposition misses the connective work that decomposition always misses.

And record the embarrassing overruns — they are the most informative data you have.