In this guide 6 sections
Projects lose money after the date holds. Time sheets show how. Compare budgeted and booked hours by task and person, hunting for overtime that rescued the deadline, change requests never billed and senior staff doing junior tasks. Hours reveal what the delivery date hides.
Why a kept deadline hides the loss
A delivery date is easy to see. Hours are not. The team can meet the date by working evenings and weekends, so the client sees only a tidy handover on the promised Friday with no trace of the weekend. Nobody sees that Saturday. The invoice stays silent too.
The cost lands later, in a margin that looks thin on the closed project and that nobody can explain at the review. Only the time sheet explains it.
Set budget against booked hours, task by task
Export the estimate with hours per task, as signed off in the proposal or statement of work, before any rework or revised scope crept in. Export the time sheet entries for the same project, grouped by task, and set the two side by side with variance columns for hours and cost.
Totals alone mislead you. Task lines tell the truth. A project can look level overall while design ran far over budget and testing ran far under, which hides the habit of underestimating design. Design usually runs over.
- Budgeted hours per task
- Booked hours per task
- Variance in hours and in cost
- Tasks with no budget line at all
Find the overtime that saved the date
Filter the time sheet entries made on weekends, after seven in the evening or in the last week before delivery, and note which people carry them. Bunched long days mean a rescue.
Overtime may be unpaid in a salaried team, yet it still costs burnout, mistakes in the next release and a following project that starts tired. Record it for the next estimate. Ask for the dates. Count every Sunday worked.
Spot unbilled changes and mismatched people
Scan task names and notes for words like revised, extra, added, new page or client request, because each one marks a change request that needs logging. Did the client approve it in writing? Did the hours ever reach an invoice?
Then read hours by person against billing rate, since a principal booking hours on layout work or a junior stuck on architecture both distort the cost of the task. The task was not wrongly priced. The staffing was wrong. Put the right person on each line, and note the grade next to every task in the estimate so the next quote starts from the correct mix.
- Entries mentioning client requests
- Scope changes without a signed note
- Senior hours on junior tasks
- Rework tagged to the same task twice
Fix the next estimate, not just this report
Take the three tasks with the largest overrun, such as design, data migration or user testing, and raise their base estimate before the next quote. Add a line for change handling. Agree that any extra beyond a few hours needs a written quote, approved by the client, before anyone starts work on it.
Close the project review within a week of handover, while the team still remembers why design, testing or migration ran over the estimate. Pull last month’s closed project and run this comparison on it, then compare the result with what you quoted for the project now in progress.
Closed project hours review
A one-page review template. The left block lists tasks with budgeted hours, booked hours and variance, and the middle block lists people with hours, role and rate. The right block tracks change requests: date, approver, hours spent and invoice number, with a footer asking for the three biggest overruns and one fix to the method.
Open a blank worksheet to printQuestions owners ask
What if the team did not book time carefully?
Expect a patchy review. That patchiness is itself a finding. Start with a rule that hours are booked daily against a task, never weekly against a whole project, and let the project manager check entries each Friday.
Should we bill the client for the overrun?
Only where the client asked for a change and agreed to it in writing, because overruns that come from your own estimate are usually yours to absorb. Use them to sharpen the next quote.
How detailed should tasks be for time booking?
Detailed enough to separate design, build, testing, meetings and client changes, so each overrun points at one kind of work rather than at the project as a whole. Too many tasks tire people into guessing. Too few hide the cause.
Can one report show this across all projects?
Yes, and it is worth building. A report of budget against booked hours by task type across closed projects shows which kind of work you underestimate, whether that is migration, testing or design.