Project management and time tracking: connecting hours to the work they paid for

Project management and time tracking get sold as one thing and used as two. Project management asks what is happening and what is next; time tracking asks where the hours went. Joining them is genuinely useful — it is the only way to learn what work actually costs — but the join has to be coarse, or you spend more time coding hours than doing the work they describe.

The practical test is whether anyone will act on the answer. If knowing that onboarding took 40 hours rather than 25 would change how you quote the next one, the tracking is worth it. If it would not, you are building a reporting habit with no reader.

Track at the level you plan at

This is the rule that decides everything else. If you plan in projects, track hours to projects. If you plan in phases — discovery, build, launch — track to phases. Tracking one level finer than you plan produces data you cannot compare to anything; tracking one level coarser produces totals that cannot explain an overrun. Card-level tracking is the classic mistake: hours logged against forty cards, none of which map to a number anyone quoted.

• Choose the unit: project, phase, or work type. One of them, and the same one for everybody.
• Cap the list. If people scroll to find the right code, they pick the first plausible one.
• Log daily, in quarter hours. Precision beyond that is invented at the moment of entry.
• Separate billable from non-billable if you invoice, because the mix is usually the real finding.
• Keep a small internal bucket — admin, meetings, support — instead of forcing everything into projects. Hiding overhead inside project codes is what makes estimates wrong.
• Compare to the estimate at the end of each phase, not at the end of the project when nothing can be learned in time.

Estimates improve from comparing whole phases, not from precision inside them. A team that learns "our discovery phases run about 40% over" corrects better than one that knows exactly how many minutes went into each card and still has no ratio to apply.

Making the join without the overhead

1. Run the work visually — a board of columns and cards is enough for most teams to know what is in flight.
2. Give each project or phase a short code, and put that code on the board and in the time sheet so the two vocabularies match.
3. Keep hours in a separate weekly sheet: one row per person per day, project code, hours, billable flag.
4. Total by code weekly. Two pivots — hours by project, hours by person — cover almost every question that gets asked.
5. At each phase close, compare actual hours to the estimate and write down the ratio. The ratio is the reusable asset, not the raw hours.
6. Feed the ratio into the next quote instead of arguing about whether the last one was unusual.
7. Prune codes quarterly. Dead projects on the dropdown are what push people into logging against the wrong one.

Where Ettex fits, and where it stops

The work side lives in Ettex Board: columns and cards with drag-and-drop, assignees, colour labels and priority flags, due dates, checklists inside cards, lists and swimlanes for larger boards, and WIP limits so flow stays honest. Every move and edit is logged per card, and the board updates live for everyone. The hours side sits in Ettex Sheets — a row per person per day with a dropdown of project codes, pivots for hours by project and by person, and export to CSV or XLS when finance or a client asks. The join is the shared code, maintained by hand, which for a small team is a minute a week.

Said plainly: Ettex Board has no built-in timer, no hours field on cards, and no automatic roll-up of time into projects or invoices. The connection described here is a naming convention between a board and a sheet, not a feature. It works well up to a few dozen people; beyond that, or if you bill by the hour at volume, a dedicated project-and-time product will pay for itself.

Hours tell you what was spent, not what is about to go wrong. A RAID log carries the other half: assumptions nobody confirmed and commitments owed by people outside the team, reviewed on a cadence rather than at kick-off.

Signals the join is doing harm

• People spend longer choosing a code than doing the increment of work.
• The code list has more entries than the team has weeks in a quarter.
• Hours are logged to cards, so no total corresponds to anything that was ever estimated.
• Overhead is smeared across projects, making every project look more expensive and none of them explainable.
• The report is produced monthly and read by nobody — the clearest sign to stop producing it.
• Hours are compared between people rather than between estimates and actuals, at which point the numbers stop being true.

Not everything needs this. If the only question is attendance and overtime, free printable time sheets are faster to run and easier to get signed. The moment someone asks which client paid for Tuesday, the sheet cannot answer, and that is the point at which the extra structure earns its cost.

Project management and time tracking join best at one shared code, kept short and pruned often. Run the work on a board, keep the hours in a sheet, compare phases to estimates — and let the ratio, not the raw hours, be the thing you carry into the next project.