Measure utilisation in hours first

What the number is

A person logs their day against projects. The week has an expected total, forty hours by default. Utilisation is what was logged against what was expected.

The reporting splits it by project, by department and by timesheet status, with a daily chart and a week-over-week comparison. The whole report can be posted to a Slack channel on a schedule.

Hours in, percentages out, and every figure traceable to a timesheet somebody wrote.

Planned and logged, side by side

Planned hours live on the capacity plan, where leave and holidays are already marked L and H. Logged hours live in the timesheets.

Both sit in one database. So planned against actual, for the same person in the same week, is a comparison on one screen rather than a join between two tools.

Projects carry a billable flag and a fixed-price or hourly flag, and both the plan and the reports filter on them. Client delivery and internal time never blur into one figure.

Why hours come first

Most of the arguments a delivery team has are about hours, not margin. Who is oversubscribed next week. Which project quietly absorbed two people. Whether last month's crunch was real or remembered.

Hours answer all three. And an hours number has a property a revenue number does not: everyone can check it against their own week.

A margin figure depends on rates, cost assumptions and overhead allocation, none of which the people being measured can see. Arguments about it become arguments about the model. Arguments about hours become arguments about the timesheet, which is at least a conversation with a record behind it.

What a revenue figure inherits

A revenue view multiplies each hour by a rate. That is useful for pricing, and it inherits every error in the hours underneath it.

A timesheet booked to the wrong project becomes a wrong margin on two projects, now with decimal places. A reconstructed week becomes a confident revenue line.

So fix the hours first. A rate applied to a clean record is a small step. A rate applied to a guessed one is fiction with a currency sign.

The ways an hours number still lies

Simple does not mean accurate. Three things distort utilisation even with no money involved.

Reconstructed weeks. Hours logged from memory on the last Friday are smooth and wrong, and they smooth toward whichever project the person remembers best.

Unapproved time. A report built from a week where half the timesheets are still pending is a partial count presented as a total.

The expected-hours assumption. Forty is a default, not a fact. Somebody part time, or back from two weeks of leave, is measured against a denominator that does not describe their month.

None of those is fixed by better reporting. They are fixed by closing the week properly before anyone quotes a figure.

Reading the number with a team, not at them

Utilisation invites a target, and a target turns it into a game within about two months.

Somebody logs eight hours whether they worked six or ten. The number goes up. Nothing about the week has changed except the record of it.

So the useful version is comparative rather than absolute. Where did the hours go this fortnight against last. Which project absorbed people nobody planned to put on it.

Those are questions the team can answer and argue with, and the answers change what gets planned. A percentage held against a target mostly changes what gets typed.

One database, two questions

A delivery lead asks who is oversubscribed next week. Finance asks what the month earned. Both questions start from the same hours.

When the hours, the leave and the projects live in one database, the first question needs no export and no reconciliation. The plan and the record already agree on who was away.

And the second question starts from a record that has been logged on the day, submitted and approved. It is not rebuilt from memory at month end.