How to spot a project going over budget while you can still fix it

Almost every project that loses money was diagnosable weeks before anyone noticed. The information existed. It just wasn't being compared to anything.

The reason is that agencies watch two numbers that both look fine until it's too late: time elapsed and work delivered. Neither tells you about budget on its own. The signal is in the gap between them.

The one comparison that matters

Percent budget consumed = hours to date / budgeted hours
Percent complete        = value of scope delivered / total scope value
Burn ratio              = percent budget consumed / percent complete

A burn ratio of 1.0 means you're spending exactly in line with progress. Above 1.0 means the project will overrun by that multiple unless something changes. Below 1.0 means you're ahead, which usually means someone has mis-estimated the completion figure.

The projection follows directly:

Projected total hours = hours to date / percent complete

That single line is the whole early warning system. It works from week two.

A worked example

A fixed-price project, quoted at $60,000, budgeted at 400 hours across ten weeks. At a loaded cost of $100 an hour that's $40,000 of delivery cost and $20,000 of margin — 33.3%.

At the end of week four:

	Planned	Actual
Weeks elapsed	4 of 10	4 of 10
Hours consumed	160 (40%)	210 (52.5%)
Scope delivered	40%	35%

The team is not panicking. They're 50 hours over on a 400-hour project, which feels recoverable, and everyone assumes the back half goes faster.

Run the arithmetic instead:

Burn ratio            = 52.5% / 35% = 1.5
Projected total hours = 210 / 0.35 = 600 hours
Projected cost        = 600 × $100 = $60,000
Projected margin      = $60,000 − $60,000 = $0

A $20,000 margin has become zero, and it happened by week four. Nothing dramatic occurred — no crisis, no blown deadline, no angry client. The project is simply running at 1.5 times its estimate, and it has been from the start.

Why week four and not week eight

The same calculation at week eight gives the same answer. By then 420 hours are gone and the project is 70% complete: 420 / 0.70 is still 600 hours. The projection was never wrong. What changed is what you can do about it.

	Week 4	Week 8
Hours spent	210	420
Hours remaining in the projection	390	180
Scope still unbuilt	65%	30%
Can you re-scope?	Yes	Barely
Can you raise a change request?	Yes, credibly	It looks like a rescue invoice
Can you change the team mix?	Yes	Onboarding cost exceeds the saving

At week four you have three live options. Cut the remaining scope so the project lands at 500 hours and keep $10,000 of margin — 16.7%. Or raise a change request for the extra work at $12,000, taking the fee to $72,000 against $60,000 of cost, which is also 16.7%. Or move a senior off and a mid on, and take the saving in cost per hour.

At week eight you have one option, which is to absorb it.

Getting percent complete without lying to yourself

The hard part isn't the arithmetic. It's that "percent complete" is the number teams get wrong, always in the optimistic direction, and always by the same mechanism: work that is nearly finished is counted as finished.

Three rules that fix most of it:

Break scope into deliverables before you start, and weight them. Ten named deliverables with a rough share of total effort each. Percent complete is the sum of the weights of the ones that are genuinely done.

Binary status only. A deliverable is done or it isn't. No 90%. The last 10% of anything at an agency is client feedback, revisions and final assets, and it routinely costs more than the first 50%.

Someone other than the person doing the work confirms it. Not for suspicion — because you cannot see the remaining work from inside the task.

If a project is genuinely too fluid for deliverables, use a weekly forecast instead: how many more hours does the team think it needs? Track how that number moves. A remaining-hours estimate that doesn't fall week over week is the same warning in a different form, and it's often the earlier one.

The three signals that arrive before the numbers

The arithmetic is the proof, but there are behavioural tells that show up first and cost nothing to watch:

• The estimate to complete stops moving. Two weeks of work, same "about three weeks left." That's a scope discovery, not a slow week.
• The same deliverable appears in three consecutive status updates. Something is stuck and nobody has said so.
• Meeting hours grow. When a project starts consuming more calls, more check-ins, more clarification, the work isn't understood yet — and unclear work is expensive work.

None of these prove an overrun. All of them are worth twenty minutes of asking.

Set the threshold before you need it

Decide now what burn ratio triggers a conversation, and with whom. Something like: above 1.15 the project lead flags it; above 1.3 it goes to whoever can authorise a change request or a scope cut. Written down, in advance, so it isn't a judgement call made by the person least able to be objective about it.

The threshold matters less than having one. Without it, every overrun becomes a debate about whether it's really a problem yet, and that debate reliably lasts until it's too late to matter.

This week

Pick your largest active project. Get two numbers: hours logged to date, and the share of scope genuinely delivered by the binary rule above. Divide the first by the second.

If the projection lands past your budget, you've just bought yourself the weeks you'd otherwise have spent finding out. Do it for every active project on the same day each week and you have the entire system — no software required, though it stops being a manual job somewhere around your fifth concurrent project.