Estimating from what previous work actually took

Most estimating advice is about technique: decomposition, three-point estimates, reference classes. All of it helps, and all of it works far better with a record of what previous work consumed.

Without that record, every technique is applied to a guess. When estimates depend on memory or self-reported data, this page is a useful reminder of the bias that can enter the record.

What to record per project

• Quoted hours or price, and the date.
• Actual hours, split roughly by phase — design, build, revision, project management, admin.
• Number of feedback rounds against the number assumed.
• Anything that came in as a change, and whether it was charged.
• Elapsed weeks from start to sign-off, and how much of that was waiting.

Five fields, filled in once per project, taking about ten minutes. After a dozen projects this is the most valuable commercial document a small studio owns.

Segment by type, not by client

Overrun clusters by kind of work rather than by customer. Integration projects overrun more than static builds. Anything involving migrating someone else's data overruns more than anything else. For a broader framework, PMI's overview of project management summarises the standard concepts behind planning and delivery.

Three or four categories is enough resolution to be useful. More than that and each bucket has too few projects to say anything.

Find where the hours actually went

The phase split is where the surprises are. Studios discover that project management is twenty percent of delivery, that revision exceeds original production, or that a specific phase always doubles.

Each of those has a different response — pricing project management explicitly, limiting rounds, or breaking the problematic phase into its own quoted stage. None of them is visible from a single total.

Getting the phase split requires time recorded against the work rather than reconstructed at the end of the month. A spreadsheet is adequate if it is filled in daily; where a studio already runs a timer, tools such as Monitask report hours by project and by person over a period, which is the same data with less friction. The thing that determines whether the numbers mean anything is when they were written down, not what wrote them.

Review estimates against actuals, quarterly

Twenty minutes, once a quarter: for each completed project, quoted against actual, and the ratio. Look at the outliers rather than the average.

The outliers are where the lesson is. A project at 3.4 times the estimate usually had one identifiable cause, and it is almost always a cause that will recur.

Tell the client the basis

'Similar projects have taken between fifty and seventy hours' is a far stronger position than a bare number, because it is evidence rather than assertion.

It also changes the negotiation. A client pushing back on a number is arguing with your opinion; a client pushing back on a range derived from six comparable projects has to argue with the projects.