timesheet
Most project overruns are discovered by accident. Someone opens the invoice folder, adds up the hours a contractor billed, and finds that a piece of work budgeted at eighty hours has consumed a hundred and thirty. The work is not finished. The client has not been told. The conversation that follows is about blame, because by that point there is nothing left to decide.
The comparison of budget against actuals is not hard arithmetic. What makes it useful or useless is when it happens and where the actual number comes from. A variance report produced monthly, from timesheets submitted at the end of the month, cannot catch anything early by construction. It reports history. The question worth answering is how to get the same comparison in front of the person running the work while the work is still adjustable.
An actual is what has already been consumed. On a project that is mostly people, that means hours, and hours are the number that arrives last and least reliably.
There are three usual sources and they disagree with each other. Timesheets are the most complete and the slowest, because they depend on someone remembering a week later. A task tracker with time logged against cards is faster and less complete, because people log the work they think is worth logging. Invoices from contractors are the most authoritative and the latest of all, often arriving after the month closes.
The disagreement matters more than the accuracy of any one source. A project can look fine in the tracker, slightly over in the timesheets, and badly over once the contractor invoices land. Teams that use different sources in different meetings spend the meeting reconciling rather than deciding.
The practical position is to pick one source as the number of record for in flight decisions, and accept that it is approximate. A rough actual available on Tuesday is worth more than an exact actual available in three weeks. The exact figure still matters for billing and for the post mortem, but it is not a steering instrument.
There is a second component people forget. Money spent is not only hours. Licences bought for the project, stock photography, a subcontracted translation, cloud costs for a staging environment. These are small individually and they are the ones that never make it into the budget line, so a project can be on budget for labour and over budget overall.
The mechanism is simple and worth stating plainly, because the usual explanation blames attention.
A budget is a total. Consumption happens continuously. Comparing a total against a partial consumption tells nobody anything unless there is an expected shape for how the consumption should accumulate. Forty hours spent out of a hundred is good news in week four and bad news in week two, and the number on its own does not say which.
What makes the difference is a planned curve, however crude. If the hundred hours were expected to land as twenty, thirty, thirty, twenty across four weeks, then twenty two hours in week one is fine and forty is a signal. This takes two minutes to write down at the start and it turns a total into something that can be checked weekly.
The second reason for invisibility is that percentage complete is guessed. A task reported at seventy percent complete has consumed sixty hours of an eighty hour budget, so the project looks healthy. The problem is that seventy percent is an estimate made by the person who wants it to be seventy percent. Completion percentages on unfinished creative or engineering work drift upward and then stall at ninety for a long time.
The way around it is not better estimating. It is to stop using percentage complete as the progress measure and use something binary instead. Deliverables shipped, screens approved, pages signed off, tickets closed. Six of ten screens approved against sixty percent of the budget consumed is a real comparison. Seventy percent complete against seventy five percent of budget is two guesses next to each other.
Most variance reports contain too many columns and one missing comparison. Three are enough for a project in progress.
The first is consumed against planned to date. This is the curve check. It answers whether the project is spending faster than intended right now, and it is the only one of the three that can trigger a decision this week.
The second is consumed against delivered. This is the efficiency check. Sixty percent of hours for forty percent of deliverables means the remaining forty percent of deliverables will not fit in the remaining forty percent of hours, and the arithmetic says so before anyone has an opinion about it.
The third is forecast to completion against total budget. This is the landing check. It takes the burn rate so far, applies it to the work remaining, and produces a number that either fits or does not. Most teams never produce this one, which is why the overrun arrives as a surprise rather than as a forecast that was ignored.
None of these requires software. They require the planned curve, a count of deliverables, and a number of record for hours. A team that runs all three every Monday for fifteen minutes will catch the overrun weeks earlier than a team with a sophisticated monthly report.
One refinement is worth adding once the habit exists. Run the three comparisons per workstream rather than for the project as a whole. A project that is on budget overall frequently contains one phase running badly over and another that came in light, and the total hides both. Design overspending while development underspends is not a neutral outcome, because the development estimate was probably made before the design changed, and the underspend is not real yet.
The granularity to aim for is the level at which one person is accountable. Any finer and the numbers become noise from rounding, since nobody logs time precisely enough for a two hour bucket to mean anything. Any coarser and the comparison cannot name who to talk to, which is the main thing it is for.
The tooling question is narrow. It is not which tool is best, it is how many places the numbers have to be copied between before the comparison can be made. Every copy is a place the process stops when someone is busy.
| Setup | Time to produce the comparison | Breaks when |
|---|---|---|
| Spreadsheet, hours typed in from timesheets | Thirty to sixty minutes, monthly | The person who owns the sheet is on leave |
| Time tracker with project budgets | Minutes, on demand | Task state lives elsewhere, so delivered count is manual |
| Board with time logged on cards | Minutes, on demand | Rates and non labour costs are not in the tool |
| Board plus tracker, no shared identifiers | Never reliably | Immediately, because tasks cannot be matched |
The fourth row is common and worth avoiding deliberately. When the tracker's project list and the board's project list were created separately by different people, matching them is manual work that has to be redone every month, and it is the reason many teams quietly abandon the comparison after two cycles.
Tool budgets are usually a paid feature, which is worth knowing before a process depends on one. On Toggl Track, time estimates and budget alert thresholds begin on the Starter plan at nine dollars per user per month billed annually, and labour costs, revenue and margin arrive on Premium at sixteen dollars per user per month billed annually. On Trello, the free plan allows up to 10 collaborators and up to 10 boards per Workspace with unlimited cards, and the Calendar and Timeline views that show a planned curve begin on Premium at ten dollars per user per month billed annually. On Asana, the free Personal plan covers two users with list, board and calendar views, and Timeline and Gantt views begin on Starter. Those are all current as of September 2026 and all worth confirming on the vendor's own page before committing, because plans change.
A tool where the timetable and the Gantt view are present without an upgrade removes one variable from this decision, and the features page shows which views are included. Whether that matters depends entirely on whether the board is already where the work is tracked.
A comparison with no threshold produces a discussion every week and a decision none of them. The threshold is the part that makes the number actionable, and it has to be agreed before the project starts, because agreeing it afterwards is negotiation.
Two numbers do the work. The first is the point at which the project owner is told, which is usually when consumption runs ahead of the planned curve by around ten percent. The second is the point at which the client or sponsor is told, which is higher and should be written into the engagement rather than decided in the moment.
The interesting one is the first. Telling the project owner is cheap, so the threshold should be low enough to fire several times on a healthy project. A threshold that never fires is set wrong. A signal that fires and turns out to be nothing is doing its job, and a team that treats every alert as a failure will stop setting them.
There is a third number that is more useful than either and almost never set: a stop line on a single task. If a task budgeted at eight hours reaches twelve, the person doing it stops and asks, rather than finishing it at twenty because stopping felt like admitting defeat. Individual tasks quietly running to two or three times their estimate is the most common way a project budget goes without anyone noticing a line being crossed.
By the time an overrun is confirmed, the options are limited and known. Naming them as a short list beats discovering them one at a time.
Reduce scope, which needs the client's agreement and is the only option that does not cost someone money. Absorb the cost, which is a real decision that should be made explicitly rather than by default. Ask for more budget, which depends on whether the reason is defensible. Extend the timeline, which helps only if the overrun is a rate problem rather than a volume problem, and often it is not.
What determines which of these is available is almost entirely the record. An overrun with a documented cause, a date on which it was first flagged, and a note of what was changed in response is a conversation about the project. An overrun discovered at the end with no trail is a conversation about competence. The record costs a sentence a week while the work is happening, and it cannot be reconstructed afterwards.
The other thing worth doing at this point is writing down the estimate error for later. A team that consistently runs twenty five percent over on one category of work does not have a discipline problem, it has an estimating multiplier it has not applied yet. That is only visible if the comparison from finished projects was kept.
Write the planned curve for the current project in whatever tool already holds the tasks, pick one source for hours and call it the number of record, and run the three comparisons once a week rather than once a month. Teams considering holding the plan, the task state and the time log in one place can see how Pinateca is arranged, or check the pricing page for what is included without an upgrade.
Weekly for anything running longer than a month, and the comparison should take fifteen minutes. Monthly reporting is fine for accounting but useless for steering, because a month is long enough for a project to consume a third of its budget before anyone looks.
A variance looks backward and states the gap between what was planned to date and what was consumed. A forecast looks forward and applies the burn rate so far to the work remaining. Only the forecast can tell you whether the project will land inside its budget, which is why it is the more useful of the two while work is in progress.
No, and waiting for accuracy is the main reason the comparison never happens. A consistent approximation is enough to spot a trend, because the signal is the rate of change rather than the absolute figure. Accuracy matters for billing and for improving estimates on the next project.
They should at least be counted in the same total, even if they are recorded elsewhere. Licences, subcontracted work and stock assets are individually small and collectively the reason a project can be on budget for hours and over budget overall. A single line for other costs, updated when an invoice arrives, is usually enough.