How to track billable hours per project without anyone hating it

Almost every services business tracks hours, and almost none of them trust the resulting numbers. The data exists. It is just not usable: the categories are inconsistent, the entries were filled in on a Friday from memory, and half the team logs exactly eight hours a day because that is the number that stops the reminder emails.

This is not a discipline problem. It is a design problem, and it comes down to four decisions about how you ask.

1. Ask for the issue, not just the project

A timesheet that asks for a project and a number can only ever answer one question: how much did this project cost. That is enough to invoice and not enough to learn anything.

When the entry also names the specific issue, the same data answers questions you could not ask before. Which stories cost multiples of their estimate. How much of the sprint went on work that was not in the sprint. Whether the bug that keeps reopening has quietly consumed a week. What fraction of a month was rework.

There is a second effect, and it matters more: naming the issue is easier than naming the project in free text. The person was working on the issue. It is in a picker, right there, filtered to the projects they are on. Recall is replaced by recognition, and recognition is what people can do at 6pm.

This is why Daily Status Reports in Matrix take a project and an issue, rather than treating the issue as optional detail.

2. Ask daily, and only about today

Weekly timesheets produce fiction. Not deliberately — a person genuinely cannot reconstruct Tuesday on Friday, so they reconstruct a plausible Tuesday instead. The numbers are round, they add to forty, and they are a reasonable person’s guess.

A daily entry about today is a two-minute task with no recall cost. It also fails visibly: a missing day is a missing day, whereas a plausible week is invisible for ever.

The tradeoff is that you now need five interactions a week instead of one, which only works if each one is genuinely fast. That is the constraint everything else has to respect.

3. Make the gap visible, and make it a list

The standard failure here is social: a manager notices someone has not filed, sends a message, feels like a nag, and eventually stops. Two months later nobody is filing.

Replace it with a report. A list of who has not filed and for which dates turns a daily social cost into a five-second check, and it makes the pattern visible — one person who always forgets Fridays is a different problem from a team that stopped in March.

Some organisations want the discipline to be structural rather than social. Matrix has an optional setting for that: with Pending DSR Lock Enforcement enabled, anyone with a missing report is held on the reporting screen until they file it. It is deliberately off by default, because it is a real cost and most teams do not need it. Where it is used, admin accounts are exempt.

4. Give the hours back to the people who logged them

The fastest way to kill a reporting habit is for the data to disappear into a report only management sees. If logging hours costs the team two minutes a day and returns nothing to the team, it is a tax, and people optimise taxes down to the minimum that avoids a penalty — which is exactly the eight-hours-every-day pattern.

Return it. A person should be able to see their own week, their own split across projects, and their own totals. A team lead should be able to open effort allocation before promising anyone’s time to a new engagement, and say so out loud when they do. The habit sticks when the data visibly changes decisions.

What the numbers can then support

Once entries name an issue, arrive daily, have visible gaps and are useful to the people producing them, four things become answerable without a spreadsheet:

• What a project cost. Hours per project for a period, compared against the client hours, internal hours and monthly estimate the project was set up with.
• Where a person’s month went. Effort allocation across projects, which is the only honest basis for a capacity conversation.
• Whether estimates are drifting. Actual hours against the issue they were estimated for, at the granularity estimates were made at.
• What actually happened. The written description on each entry, which is the part clients ask about and no aggregate can reconstruct.

The uncomfortable part

None of this works if the hours are used punitively. The moment a low number becomes evidence in a performance conversation, every number becomes eight, and you have spent the team’s time to acquire a column of noise.

Hour data is a planning instrument. It tells you what work costs so you can price it, staff it and estimate the next one. Use it for anything else and it stops being true — and an untrue number is worse than no number, because people act on it.

Where to start

If you are setting this up from scratch, do it in this order: get the issues into a board and backlog first, because there is nothing to attach hours to otherwise. Then turn on daily reporting. Then, a month later, open the effort reports and check whether they match what you believed was happening. They usually do not, and that gap is the return on the whole exercise.