What to track on client projects, and what to ignore

Agencies fail at project tracking in two opposite ways. Some track nothing and find out how a project went when the invoice goes out. Others track everything — task-level statuses, tags, custom fields, percentage sliders — and drown in data that never changes a decision.

The useful middle is small. Five numbers tell you whether a project is healthy. Anything you're recording that doesn't feed one of them is costing time and buying nothing.

The five that matter

Hours by person, by project, logged the same day. This is the foundation. Every other number is derived from it, which is why it has to be accurate and why it has to be same-day.

Percentage of budget consumed. Hours used against hours quoted, or cost against fee. One number, updated weekly.

Percentage of work complete. A judgement call from whoever is doing the work. It doesn't need to be precise. It needs to be honest and it needs to be weekly.

Approvals outstanding, with dates. What you're waiting on from the client and how long you've been waiting. This is the single best leading indicator of a project slipping, and almost nobody tracks it as a number.

Scope changes, with an hours figure attached. Every agreed change, even the small ones, with an estimate of what it added. Not to bill for all of them — you'll waive plenty — but so you can see at the end that you gave away 40 hours, which is a different fact from "the project went a bit over."

That's the list. Budget consumed against work complete is the diagnostic; approvals and scope changes are the explanation when the diagnostic goes bad.

What to stop tracking

Commonly tracked	Why it doesn't help
Task-level status on everything	The status of 60 tasks tells you less than one honest percentage-complete
Time in six-minute increments	The precision is fake; nobody remembers to that resolution
Individual utilisation, weekly	Meaningful quarterly; weekly it's noise that makes people defensive
Number of revisions	Only matters if it's outside what was agreed, which is a scope change
Hours by task within a project	Interesting for estimating later, useless for steering now
Anything nobody has looked at in a month	If it hasn't changed a decision, it isn't a metric

The test for every field: has this number ever caused someone to do something differently? If not, delete it. Every optional field on a time entry form reduces the odds the form gets filled in at all, and the form getting filled in is worth more than any field on it.

Same-day logging is the whole game

Everything above depends on hours being roughly right, and hours reconstructed on a Friday afternoon are not roughly right. People remember the big blocks and lose the fragments — the call that ran over, the half hour on a revision, the twenty minutes finding a file.

Suppose someone loses four hours out of a 35-hour week that way. That's 11% of your cost base invisible, and it doesn't distribute evenly — it comes off the messy projects, which are exactly the ones you most need accurate data on.

Play it through on a project quoted at $30,000 for 200 hours, with a loaded cost of $95/hour:

	Hours	Cost	Margin	Margin %
As logged	200	$19,000	$11,000	36.7%
Actually worked	225	$21,375	$8,625	28.8%

Twenty-five unlogged hours — 12.5% — turn a 28.8% project into an apparent 36.7% one. You price the next job against the wrong number, win it because it's cheap, and repeat.

Three things make same-day logging stick, and none of them is a reminder email:

• Make it fast. Under a minute for a day. Project, hours, one line of note.
• Never use it to police individuals. The moment time data appears in a performance conversation, it stops being accurate. This is not negotiable.
• Show people the output. A team that sees the margin numbers their entries produce logs better than a team filling in a form for management.

Percentage complete, honestly

The obvious objection is that percentage complete is subjective. It is. It's still more useful than any objective alternative, because the alternatives — tasks closed, deliverables shipped, weeks elapsed — measure activity rather than remaining effort.

Two ways to keep it honest. First, ask for it as "how much is left," not "how much is done" — people estimate remaining work more realistically than completed work. Second, never let it go backwards silently. If a project was 60% complete last week and it's 50% this week, that's the most informative number of the week and it deserves the conversation.

Beware the 90% plateau. A project that has been "nearly done" for three weeks is not nearly done, and the budget line will tell you the truth even when the progress line won't.

Track approvals like they're deliverables

Waiting on a client is the most common cause of a slipped project and the least recorded. Give it a place:

OUTSTANDING WITH CLIENT
Homepage copy sign-off     — requested 12 Jul — 9 days
Product photography        — requested 18 Jul — 3 days
Legal review of disclaimer — requested 2 Jul  — 19 days

Three lines in the project record, updated weekly. This does two jobs. It tells you where the project will stall next, and it gives you the factual basis for the timeline conversation later — because "the disclaimer sat with your legal team for nineteen days" is a fact, whereas "there were some delays on your side" is an accusation.

Right-sizing by project

A $4,000 job doesn't need the same instrumentation as a $120,000 one. But it still needs hours logged, because small projects are where margin leaks fastest and where nobody's paying attention.

A reasonable split: everything gets same-day hours and a weekly budget-versus- progress check. Projects over some threshold you set — a month of team time, say — also get the approvals log, the scope change log and a written weekly status.

Do this week

Take your project tracking, whatever form it currently takes, and count the fields. Then ask of each one: when did this last change a decision?

Delete the ones that fail. Then add the one thing that's almost certainly missing — the outstanding-approvals list with dates on it. It takes three lines per project and it's the earliest warning you'll get that a project is about to go sideways.