Where the budget allocated to a project quietly disappears

A number was agreed at the start. Three months later the work is roughly two thirds done and the number is roughly gone. Nobody made a bad decision that anyone can point to, no single line item explains it, and the spend report is accurate. The budget allocated to the project was real. What happened to it is genuinely hard to reconstruct, because the leaks were small, spread out, and mostly recorded as ordinary work.

This is a measurement problem before it is a discipline problem. Most small teams track one number, which is money out the door, and that number cannot tell you whether a project is in trouble. Understanding why requires separating three things that get called the same word.

Allocated, committed, and spent are three different numbers

"Budget allocated" usually means the amount assigned to the project when it was approved. That is the only one of the three that is a decision. The other two are consequences, and they move at different speeds.

Number	What it means	Changes when	Visible in the accounts
Allocated	The amount assigned to the project	Someone reopens the budget	At approval, then static
Committed	Money promised but not yet paid, such as a signed contract or an open purchase order	A contract is signed or a vendor is engaged	Often not at all
Spent	Money that has left the account	An invoice is paid	Yes, with a lag

The gap that causes the most surprise is between committed and spent. A retainer signed in January is committed in January and spent across six months. On a monthly spend report the project looks comfortable in February and alarming in June, and nothing changed in between except the calendar. Teams that only watch spend discover commitments in the order the invoices arrive.

Internal labour makes this worse, because it is usually neither committed nor spent in any visible way. A developer working four days on a project consumes budget that appears in a payroll line unconnected to the project. On teams that bill or budget by time, the largest single component of a project's cost is frequently the one that never appears on a project cost report at all.

A spend report cannot tell you whether a project is in trouble

The reason is simple: spend has no denominator. Half the money gone is good news at eighty percent complete and very bad news at twenty percent.

This is the founding observation of earned value management, and the Wikipedia article on earned value management states the trap directly:

To those unfamiliar with EVM, it might appear that this project was over budget through week 4 and then under budget from week 6 through week 8. However, what is missing from this chart is any understanding of how much work has been accomplished during the project. If the project was actually completed at week 8, then the project would actually be well under budget and well ahead of schedule. If, on the other hand, the project is only 10% complete at week 8, the project is significantly over budget and behind schedule.

Full earned value management is heavy machinery. It requires a time phased spend plan and pre defined rules for what counts as work accomplished, which is more apparatus than a team of six will maintain. But the underlying comparison is not heavy at all, and a light version of it is available to anyone with a board and a set of estimates.

The light version: for each deliverable, record what it was expected to cost in hours, and record what is done. Sum the expected hours of completed deliverables. Compare that to the hours actually logged. If the logged hours exceed the expected hours of the work that is finished, the project is over budget right now, regardless of what the spend report says. That comparison takes a few minutes a week and catches the problem two months earlier than the invoices do.

The five places a project budget leaks

Money rarely disappears in one visible event. The leaks are recurring and individually defensible.

Unrecorded internal hours

Someone spends an afternoon on a project that is not theirs, helping with a question. It happens eleven times over a quarter. None of it is recorded anywhere, so the project's true cost is understated and the next project of the same shape is estimated using the understated number. Estimates then drift low as a structural matter, not as an error of judgement.

Rework that looks like new work

A deliverable is finished, reviewed, and rebuilt. On most boards the rebuild appears as a new task or a reopened one, and the hours attach to it as though the work had not been done before. Nothing in the record says this is the second attempt, so the pattern never becomes visible. Rework is the single easiest leak to measure and almost nobody measures it, because measuring it requires a field that says so. A checkbox on the card is enough. Once a quarter of the hours on a project sit behind that checkbox, the argument for spending longer on reviews earlier stops needing to be made.

Coordination

Meetings, status updates, chasing approvals, and the reconstruction of context after a gap. This is real work that produces no deliverable, and it scales with the number of parties rather than with the size of the job. A project with a client, an agency, and two internal teams spends a materially different fraction of its budget on coordination than the same work done by three people in one room.

Scope added without reallocation

A request arrives, it is small, someone says yes. The allocated number does not change because reopening the budget is a conversation nobody wants. Ten small yeses is a scope change that was never approved and therefore was never funded. The defence is not refusing requests. It is making the increment visible at the moment of the yes, even if the answer stays yes.

The last stretch

Finishing costs more per unit of progress than the middle. Edge cases, handover documentation, the review that finds something, the environment that behaves differently. Estimates are usually built as though the last ten percent of the work is ten percent of the effort, and it rarely is. Budgets that were tight at ninety percent complete are not tight. They are overspent and the overspend has not landed yet.

Hours are the unit that actually moves

On a services team or any team where people are the main cost, tracking money is tracking a lagging derivative of hours. Hours move daily. Money moves when someone invoices.

That makes hours the place to instrument, and it makes the quality of hour records the limit on how well a budget can be managed. Three properties matter more than precision.

Hours have to be attached to a project, not only to a person. A weekly total of forty hours per person is a payroll record. A weekly total of forty hours split across three projects is a budget record.

Hours have to be recorded close to when they happened. Reconstructing a week on Friday afternoon produces round numbers that sum correctly and distribute wrongly, which is worse than useless because it looks authoritative.

Hours have to be cheap to enter. Any system that takes more than a minute a day gets filled in retroactively, and retroactive entry is the previous problem. This is the part where tooling actually decides the outcome, and where the range of contract types a team uses matters: hourly, fixed monthly, and per project work each need a different treatment before the totals mean anything.

For teams working with contractors, the same records serve two purposes at once, since the basis for an invoice and the basis for a budget reading are the same hours. Keeping the entry surface next to the board where the tasks live removes the main reason people skip it, which is that it lives somewhere else. The board types and what a card can carry are set out in Features, and what is included at each tier is on Pricing.

Reallocating without reopening the whole budget

Once the leaks are visible, the response is usually a small reallocation rather than a new budget. That is a different and much easier conversation, and it works best with three things prepared.

A statement of where the project actually stands, in hours: expected for completed work, actually logged, expected for what remains. Three numbers.

A named cause. "Coordination on the client side is running at roughly twice what was estimated" is actionable. "The project is over budget" is not.

A specific ask with an alternative. Either move a defined amount from a named reserve or another line, or cut a named deliverable. Presenting the choice rather than the problem is what gets a decision in one meeting instead of three.

What does not work is waiting until the number is breached. A reallocation requested at seventy percent spend and sixty percent complete is a routine adjustment. The same request at a hundred percent spend is an incident, and it changes how every subsequent estimate from the same team is received.

Where the numbers have to live

A budget tracked in a spreadsheet that one person owns is accurate when that person updates it, which is weekly at best and in practice monthly. A budget that reads its inputs from the place the work is recorded is accurate continuously, because updating it is a side effect of doing the work.

The practical test is whether anyone other than the owner can answer, without asking, how many hours have gone into a given deliverable this month. If the answer requires a conversation, the budget is a monthly artefact and the leaks have a month to run before anyone sees them. Boards that carry both the work and the hours against it remove that lag. The trade off is that every person doing the work has to enter something, which is a cultural change with a real cost, and it is worth being honest that some teams decide the lag is cheaper. Teams comparing approaches often look at monday.com for the same reason, since the question of how much structure a team will tolerate is the one that decides whether any of this gets maintained.

What to change first

Pick the current project and produce three numbers this week: hours expected for the deliverables that are done, hours actually logged, hours expected for what remains. If the second exceeds the first, there is a conversation to have now rather than at the end. If the hours cannot be produced at all, that is the thing to fix first, and putting the entry surface next to the board people already open is the cheapest way to fix it. Pinateca is one option to check against what is in place now.

Q1. What is the difference between allocated and committed budget?

Allocated is the amount assigned to the project at approval, and it only changes when someone deliberately reopens the budget. Committed is money already promised through a signed contract or an open order but not yet paid. A project can look comfortable on spend while being fully committed, which is why a monthly spend report often turns alarming without anything having changed that month.

Q2. How often should a project budget be reviewed?

Weekly for hours and monthly for money, because those two things move at different speeds. Reviewing money weekly produces noise, since invoices arrive in clumps. Reviewing hours monthly means a month of drift can accumulate before anyone notices, which is usually enough to make the correction uncomfortable rather than routine.

Q3. Is earned value management realistic for a team of six?

The full method is not, because it requires a time phased spend plan and defined earning rules that a small team will not maintain. The core comparison is realistic and takes minutes: sum the estimated hours of the deliverables that are finished, compare that to the hours actually logged, and look at the gap. That single comparison carries most of the diagnostic value.

Q4. Should internal hours be costed into a project budget?

They should at least be counted, even where no internal rate is applied. Hours are what gets consumed, and a project whose internal effort is invisible will be re estimated next time using a number that was never true. Applying a rate is a separate decision, useful mainly when projects compete for the same people.

Q5. What is the cheapest way to start tracking where a budget goes?

Attach an hour estimate to every deliverable before work starts, and record actual hours against the same deliverables. Nothing more elaborate is needed to see the two leaks that matter most, which are rework and coordination. Precision is less important than consistency, since the value comes from the trend across weeks rather than from any single figure.