The Hours That Never Reach the Sheet

A timesheet records what somebody chose to write down. The gap between that and the hours actually worked is invisible in the data, uniformly in one direction, and larger than most organisations assume.

The record described in “The Hours That Never Reach the Sheet” should be created close enough to the work that people are not reconstructing a polished week from memory. When teams assess the product website for key person dependency, they should keep entry, project selection and correction simple, while explaining which optional activity data is collected and how employees can review it.

This matters less for pay — in salaried populations the unrecorded hours are usually unpaid by design — and enormously for everything else the data is used for. Capacity planning, project costing, pricing, workload assessment and the question of whether a team is overstretched all rest on a number that systematically understates.

For a separate benchmark relevant to “The Hours That Never Reach the Sheet”, consult the ACCA technical 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.

What goes unrecorded, routinely

Hours beyond the contracted week by someone who believes claiming them would reflect badly on them. This is the largest category by a distance and it is strongly correlated with seniority, insecurity and team culture rather than with workload.

Short pieces: the evening email, the weekend check, the twenty minutes before a meeting. Each falls below whatever the person considers worth recording, and the threshold is personal and uncalibrated.

Work that has no code. Helping a colleague, fixing something outside your own project, the unfunded half-hour on a bid. If the code list has no home for it, it either disappears or gets mislabelled, and both outcomes damage the data.

Work people are not supposed to be doing: overtime that was not authorised, time on a project they were moved off, hours above a cap. Here the system actively prevents the record, and the work happens anyway.

The cap problem

Where a system refuses entries beyond a limit — a weekly maximum, an unspent budget, a closed work package — the hours do not stop. They are recorded somewhere else, usually on whichever code still has room.

This produces a specific and severe form of corruption: the constrained code looks exactly as planned, and an unrelated code absorbs the overflow. Every subsequent estimate built on either is wrong, and the error is invisible because both totals look reasonable. Caps enforced at the point of entry are the most reliable way to destroy allocation data, and they are extremely common because they look like control.

Why the direction is always the same

There is no incentive to overstate in a salaried population and several incentives to understate. Nobody is praised for recording more hours. Several people might notice. In a project environment it makes the project look worse. In an appraisal context it can be read as slowness.

Hourly and contractor populations have the opposite incentive and behave differently, which is worth remembering: the two populations should not be analysed with the same assumptions, and an organisation containing both has two different biases in one dataset.

What the understatement does to decisions

It makes projects look cheaper than they were, which means the next one is priced and scheduled on a false baseline. It makes teams look like they have capacity. It makes a reorganisation that removed two posts look successful. And in the particular case of a stretched team, it removes the only quantitative evidence that could have supported them.

The last is the one worth dwelling on. A manager arguing for more resource with timesheet data is arguing with numbers their own team deflated out of caution, and they usually lose.

Making the record honest

Decouple recording from approval of overtime. The person records what they worked; the question of whether it is paid, authorised or recoverable is a separate decision made afterwards on the same record. Systems that refuse the entry conflate the two and lose the data permanently.

Provide a code for everything, including the unglamorous: internal support, unbilled work, bid writing, learning, rework. A short list with an honest "other" that someone actually reviews is better than a long list with no home for reality.

And say out loud, repeatedly and from senior people, that recording hours worked is not a complaint and will not be read as one. This sounds soft and it is the binding constraint. No configuration change will produce honest hours in a place where recording them is known to be a bad idea.

Asking, because the data cannot tell you

The size of the gap is not derivable from the timesheet, by construction. The only way to know is to ask, and the only way to get an answer is to ask in a form that carries no consequence for the person answering.

An anonymous question once or twice a year — roughly how many hours did you work last week, and how many did you record — gives a population estimate good enough to use. It is not precise and it does not need to be: knowing that the record understates by something like ten per cent changes how every capacity and costing conversation is conducted, and knowing nothing means treating the recorded figure as the truth.