Why Tracking Billable Hours by Project Alone Isn't Enough
A project can look profitable in total while one team member quietly burns three times their estimated hours. A person can look fully utilized while their attention is split across so many projects that none gets real focus.
01. The Two Views Most Teams Use, and What Each Misses
Most time tracking and reporting systems offer two views: hours by project (how many hours went into each project this period) and hours by person (how many hours each team member logged this period). Both are useful. Neither is sufficient on its own. A project view tells you the total hours on a project and, if you have rate data, the cost. It does not tell you which team member contributed those hours or whether the distribution was appropriate. A project with 60 hours logged looks the same in a project view whether one person logged all 60 or six people logged 10 each. A person view tells you the total hours a team member logged and, if you have utilization data, their billable percentage. It does not tell you which projects those hours went into or whether the split made sense. A person with 42 hours logged looks the same whether they spent 40 hours on one focused project or 6 hours each across seven different projects.
"A project with 60 hours logged looks identical in a project view whether one person logged all 60 or six people logged 10 each."
02. Scenario 1: Project Profitable in Total, One Person Burning Out
A web development project is quoted at $12,000. The total hours logged are 95, against an estimate of 90. At the blended rate, the project is slightly over estimate but still profitable overall. The project-level view shows a green margin. Break that 95 hours down by person: the senior developer logged 68 hours against her estimate of 30. The junior developer logged 22 hours against his estimate of 45. The PM logged 5 hours, as expected. The picture is completely different at the person level. The senior developer is running at 227% of her estimate on this project. Either the task was significantly harder than anticipated, or she absorbed work that should have been done by the junior developer. Either way, she is on track for burnout on this project, the next estimate for similar work is going to be wrong again, and nobody who looks at the project-level view would know any of this. The cross-tabulation, hours by project broken down by person, surfaces this in seconds. The project view alone cannot.
03. Scenario 2: Person Looks Utilized, but Attention Is Too Fragmented
A project manager logs 44 hours in a week, above target utilization. The person-level view shows them as fully engaged. Break down those 44 hours by project: 6 hours on Client A, 4 hours on Client B, 5 hours on Client C, 3 hours on Client D, 6 hours on Client E, 5 hours on Client F, 4 hours on Client G, 7 hours on Client H, 4 hours on Client I. Nine projects in a single week. An average of under 5 hours per client. No single project got more than 7 hours of focused attention. The PM is technically utilized but operationally fragmented, context switching between nine client relationships with no ability to build meaningful momentum on any of them. This kind of fragmentation correlates with lower quality output, higher error rates, and PM burnout, and it is completely invisible in a utilization metric that only shows total hours.
Flat-fee · No seat tax
Done paying per seat? Melororium covers tasks, time tracking, and client CRM for teams of 4–25 — one flat monthly price.
04. What a Proper Cross-Tabulation View Needs
A useful hours matrix view requires four capabilities.
- Rows and columns you can pivot: projects as rows with people as columns, or people as rows with projects as columns, depending on what question you are asking
- The ability to expand from project level to task level, so you can see which specific tasks consumed a person's hours on a project, not just the total
- Comparison to estimates: the matrix should show logged hours alongside estimated hours so you can immediately identify where estimates and reality diverged
- Date range filtering, so you can look at a specific period (this sprint, this month, this project phase) and not just all-time totals
05. How to Read a Hours Matrix
**By project: where are the outliers?** Look for projects where total hours are significantly above estimate (potential scope creep or estimation error) or significantly below estimate (may indicate incomplete work or poor time tracking discipline). Then drill into the person breakdown to understand who drove the variance. **By person: who is over-distributed?** Look for team members whose hours are spread across more projects than makes sense given your team's focus philosophy. A design team member on six simultaneous projects is probably delivering lower quality on each than they would on two or three. **Cross-reference: where do person and project problems intersect?** The most valuable insight from the matrix is often the intersection: a project that is over-hours AND the over-hours are concentrated in one person. That pattern points to a specific intervention: either the estimate for that person's contribution was wrong, or they absorbed work that should have been distributed, or there is a skill mismatch between the task and who was assigned to it.
06. What This Reveals That Neither Dimension Shows Alone
The two scenarios above, one person overloaded within a seemingly healthy project and one person over-distributed despite high utilization, represent some of the most common hidden management problems in agency teams. They are common precisely because the standard reporting views do not reveal them. Project managers who know to look for these patterns check them regularly. Project managers who only look at project totals and utilization percentages find out about them through burnout resignations, client quality complaints, or missed deadlines, when it is too late to intervene.
07. Building This View in Your Current Tool
Melororium's Work Reports generate this cross-tabulation automatically. Filter by project and date range to see hours by team member on that project. Filter by team member and date range to see hours by project for that person. Expand any row to see task-level detail. Estimates are shown alongside actuals where they are set. If your current tool does not support this view natively, you can build an approximation in a spreadsheet: export hours by project and by person for the same period, and use a pivot table to cross-reference. It is more work than a native view but produces the same analytical value. The goal is to see the matrix regularly, not just when something feels wrong.
08. Frequently Asked Questions
**Why should I track billable hours by person, not just by project?** Project-level hours tell you the total cost of a project. Person-level hours tell you how that cost was distributed and whether the distribution was appropriate. A project with 80 hours logged looks the same in a project view whether one person did 70 hours and another did 10, or whether the work was split evenly. Those two situations have very different implications for team health, estimation accuracy, and individual workload, but they are invisible without the person breakdown. **What is billable utilization and why does it matter?** Billable utilization is the percentage of a team member's total working time that is logged against billable client projects. A person working 40 hours per week with 30 billable hours has 75% utilization. Utilization matters for two reasons: it tells you whether team members have enough work (low utilization) or are at risk of burnout (sustained high utilization above 85-90%), and it tells you whether your billing rate needs to account for the non-billable overhead that consumes the remaining hours. **How often should I review hours by project and person?** Weekly for active projects, so you catch overruns and distribution problems while there is still time to adjust within the current project phase. Monthly for the bigger picture: who is trending toward burnout, which project types consistently run over estimate, which team members are consistently over-distributed. The weekly check is operational; the monthly check is strategic. Both are easier when the data is in the same system rather than requiring export and reconciliation. **How many projects should one person work on at once?** Two to four concurrent projects for most delivery roles, and up to six for a project manager whose work is coordination rather than production. Past that, you'll usually see the same pattern in the matrix: high total hours, no project receiving enough continuous attention to move, and quality problems that appear a month later. The number is a team decision, but it should be a decision rather than an accident. **Does the hours matrix matter for fixed-price projects?** Yes, and arguably more. On fixed-price work the hours are your cost rather than your revenue, so a project that ran 30% over on hours concentrated in one senior person is both a margin problem and a workload problem. You can see from the matrix which of the two you're looking at, and that decides whether the fix is pricing, scoping, or task assignment.
See hours by project and by person in one view.
Melororium Work Reports show hours by project broken down by team member, with estimates alongside actuals. Expand any row to task level.
