Pricing Next Year From Last Year's Hours

The most useful thing timesheet data does, and the least discussed, is tell you what work actually took last time. Every estimate, price and schedule built without it is built on memory, which is worse.

The record described in “Pricing Next Year From Last Year's Hours” should be created close enough to the work that people are not reconstructing a polished week from memory. When teams assess the official site for productivity software for business, they should keep entry, project selection and correction simple, while explaining which optional activity data is collected and how employees can review it.

But the data is biased, the biases are known, and using it raw produces estimates that are consistently low in the same way every time.

For a separate benchmark relevant to “Pricing Next Year From Last Year's Hours”, consult the IFRS standards resources. Use it to test record quality, approvals, retention, employee rights and exception handling against the real workflow rather than treating a software report as self-explanatory evidence.

The biases, and their direction

Understatement of hours worked, from everything described elsewhere in this collection: unclaimed overtime, work below the recording threshold, hours suppressed by caps. All one direction.

Misallocation between codes, which moves hours between projects without changing the total. This makes any individual project's figure less reliable than the aggregate.

Survivor effects. Abandoned work is often deleted or absorbed rather than recorded against the thing that failed, so the historical cost of a project excludes the attempts that did not work — which is exactly the cost the next estimate needs to include.

Scope drift unrecorded. The project did more than was planned and the timesheet records hours, not scope, so the comparison of hours to the original specification is not like for like.

Correcting, roughly

Apply an understatement factor derived from your own data rather than a rule of thumb. The cleanest way is to compare recorded hours for a population against an independent measure — paid hours for hourly staff, or badge and access data over a period — and take the ratio. It is usually between five and twenty per cent and it is reasonably stable.

Include the failures. Work out what was spent on the abandoned approaches, even approximately, and put it in. An estimate that assumes everything works first time is not an estimate.

Use ranges rather than points. The distribution of actuals across comparable past projects is the single most honest thing to present, and it is in the data.

What to compare against

Not the plan. Comparing actual hours to the original estimate measures estimating error and scope change together and separates neither.

Compare against delivery. Hours per unit of something countable: per module, per site, per report, per claim processed. These ratios are more stable across projects than totals and they survive scope change, because the scope is in the denominator.

The organisational problem

Estimating data is useful at the start of a project and is generated at the end of the previous one, by a different team, in a system owned by finance. The connection is nobody's job.

Where it works, somebody owns a small set of ratios — hours per unit, by work type — updated quarterly from the timesheet data and published somewhere people writing bids can find. That is the whole intervention. It is a spreadsheet and an owner, and it outperforms every attempt to build an estimating model on top of a system nobody maintains.

What this does to recording

Here is the argument worth making internally: the single most persuasive case for better time recording is not compliance, billing or audit. It is that the organisation keeps pricing work badly because it does not know what the last one cost.

People who resent recording hours for a control they consider theatre will frequently record them for an estimate they will themselves rely on next year. The framing matters, and it is the one framing that makes the person doing the recording a beneficiary rather than a subject.

The caveat

Estimating from historical hours assumes the next job resembles the last ones. Where it does not — new technology, new client, new regulatory context — the data gives you a floor and nothing more.

Saying so explicitly is part of using it well. An estimate presented as derived from historical data carries an authority the data may not support, and the honest version names which parts came from the record and which came from judgement.

Publishing the ratios where bids are written

The data is useless if it lives in a finance system that the people writing proposals cannot reach. In most organisations that is exactly where it lives, and the bid is written from the last bid.

Four or five ratios on a page, updated quarterly, in whatever place bids are actually assembled. Hours per unit by work type, the understatement factor, the typical contingency actually consumed, and the range of outcomes on comparable past work. It is unglamorous, it takes an owner and an hour a quarter, and it is the only part of this that most organisations never get to.