Skip to content
Recorded

All notes  /  Foundations

Why Timesheets Are Wrong

Most timesheet data is reconstructed from memory days later. What that does to the numbers, and which of the causes are fixable.

Analysis

Timesheet data is treated as a measurement and is usually a recollection. Knowing how it degrades is a precondition for using it.

How it actually gets filled in

At the end of the week, from memory, which is the most common pattern in professional services and the least accurate.

Rounded to the nearest convenient unit, which is rarely the recorded increment.

Reconciled to expectations. People adjust to reach a plausible total — a full day, a target utilisation — because a number that looks odd invites questions.

Reconstructed from calendars and email, which captures meetings well and everything else badly.

Copied from last week, for recurring work.

What that does to the numbers

Systematic bias, not random error. Reconstruction loses the short fragments and the interruptions, so the recorded day looks more contiguous than it was.

Small tasks disappear into whatever was being worked on around them.

Totals cluster at the expected figure, which makes the distribution suspiciously tidy and is the easiest signal to check for.

Unbilled and internal work is under-recorded, because it is the first thing forgotten and the least rewarded.

The error is largest where the work was most fragmented, which is usually the work you most wanted to understand.

The causes that are fixable

Delay. Accuracy falls sharply with the gap between doing the work and recording it. Daily recording is much better than weekly, and in-the-moment better still.

Friction. If entering time takes minutes and requires navigating a structure nobody understands, it happens later and worse.

Too many categories. A project list with hundreds of codes produces guessing. People pick something plausible.

No visible use. If nobody ever acts on the data, it is filled in as an administrative chore.

The causes that are not

Fragmented work is genuinely hard to record. Someone interrupted eleven times cannot reconstruct the day, and asking them to try produces fiction.

Some work does not belong to one code. Thinking about a problem while doing something else is real and unrecordable.

Judgement about boundaries — where preparation ends and the task begins — varies between people and always will.

What to do about it

Reduce delay. This is the single largest lever and it is mostly a tooling and habit question.

Reduce categories to what someone can hold in their head.

Pre-fill from calendars where the work is meeting-shaped, with the person confirming rather than typing.

Show people their own data, which is both a courtesy and the thing that makes them care whether it is right.

Act on it visibly, because a dataset that never informs a decision will be filled in accordingly.

Reading it honestly

Treat weekly-reconstructed timesheets as accurate to a wide band, not to the recorded increment.

Do not make individual comparisons on data with this error structure.

Look at shape rather than level: how effort distributes across projects is more robust than how many hours any individual recorded.

Check the distribution for tidiness. Totals landing exactly on the expected number are a sign of reconciliation rather than of a well-run operation.

The tidiness check

One query that tells you how much of your data was recorded and how much was composed.

Plot daily and weekly totals as a histogram.

Real work is messy. Reconstructed work spikes at round numbers and at the contracted total.

Compute the proportion of days landing exactly on a whole or half hour.

A high figure means reconciliation, not a well-run operation.

Run it before any analysis is presented, because it determines how much weight the rest will bear.

Reading the data honestly

How to use a record you know is imprecise, without either discarding it or over-reading it.

Treat weekly-reconstructed data as accurate to a wide band, not to the recorded increment.

Use it for shape and trend: how effort distributes across projects and activity types, which is robust.

Do not use it for individual comparison, which the error structure cannot support.

Report the recording method alongside the figures.

And state the known omission, since unbilled and internal work is always under-recorded and the total is therefore understated by an unknown margin.

Turn the principle into a test

For an example that can make this requirement testable, consult time tracking software. Treat the page as a starting point rather than proof: reproduce the workflow with real roles, exceptions and permissions before relying on the result.