Seven Signs a Software Project Is About to Go Over Budget
Overruns are visible weeks before they are announced, but the signals are behavioural rather than financial. Here is what to watch for, and what to do in the week you notice.
Software overruns are almost never announced at the moment they become inevitable. They are announced later, when they can no longer be absorbed, and by then the useful options are gone.
The signals arrive much earlier and they are behavioural rather than financial. None of these are proof on their own. Two or more together, and the schedule you were given stopped being true a while ago.
1. Demos stop showing working software
Early on, review meetings show the thing running. Then they become slide decks about architecture, or a walkthrough of designs, or a discussion of what is coming next sprint.
This is the earliest and most reliable signal. Teams show working software when it works. When it does not, the demo quietly changes shape and everyone is too polite to name it.
What to do: ask to see one complete journey working end to end, on their environment, this week. Not a recording. The response tells you more than any report.
2. Everything is ninety per cent done
Several features have been nearly finished for three weeks. The remaining work is described as "just wiring up" or "final touches".
The reason this happens is structural: the visible part of a feature is quick and the invisible part is not. Error states, edge cases, permissions, what happens on a slow connection, what happens when two people do it at once. A feature that looks complete on screen can be genuinely half-built.
What to do: stop accepting percentages. Ask what is not done, specifically. A team in control can list it. A team that has lost the thread will repeat that it is nearly there.
3. Nobody will commit to a date any more
Early answers were specific. Now they are ranges, then conditional ranges, then "it depends on a few things we are working through".
This usually means the team has discovered something they do not yet understand well enough to size — which is a legitimate situation, but it needs saying rather than absorbing into vaguer language.
What to do: ask directly what they have found that they did not expect. The question is easier to answer than a date, and it gets you the actual information.
4. Scope keeps growing quietly
Not through change requests, which are visible, but through accumulation. A field added here, a rule refined there, an "obviously it should also" in a meeting.
Every one is small. None is worth an argument. Together they are three weeks nobody scheduled, and because there is no paper trail, the overrun looks like poor delivery rather than expanded scope.
What to do: keep your own list of everything asked for since the brief was agreed. Review it monthly against the original scope. If the list is long, the timeline moved and it moved because of you — which is fine, but it should be acknowledged rather than argued about later.
5. The team has gone quiet
Fewer updates. Slower replies. Meetings shortened or moved. Communication frequency tends to track confidence, and a team having a difficult month often withdraws before it reports.
What to do: do not escalate immediately. Ask what would help. Frequently the honest answer is a decision they have been waiting on from your side for a fortnight — which is your overrun, not theirs.
6. Testing is being deferred
"We will do a proper QA pass at the end." Test coverage falling. Bugs logged and pushed to a later phase in bulk.
This is borrowing against the end of the project at a punishing rate. Defects found late are far more expensive to fix, and a large deferred bug list makes the final weeks unpredictable in exactly the way you cannot plan around.
What to do: ask for the open defect count, weekly, plotted over time. Flat or falling is fine. Steadily climbing means the end of the project has an unknown amount of work hidden in it.
7. One person holds everything
All the difficult work routes to one developer. Nobody else can explain the important parts. Their holiday is a schedule risk.
This is a delivery risk and a business risk simultaneously. It also usually means there is no code review happening, which means quality problems are accumulating unseen.
What to do: ask who else could work on the hardest part of the system. If the answer is nobody, ask for that to change over the next month.
What to do in the week you notice
Ask for a re-forecast, not reassurance. Not "are we on track" — that invites yes. Ask: given what you know now, what is the realistic date, and what would have to come out to hit the original one?
Then cut scope, not quality. It is the only lever that works reliably. Adding people slows the team down before it speeds it up, and overtime buys a fortnight and costs a quarter in mistakes and turnover. Removing features works immediately and predictably.
Decide what launch actually requires. Most projects can ship a smaller version and add the rest afterwards. The list of things that genuinely must exist on day one is nearly always shorter than the list agreed in the brief.
Get the situation in writing. Not to build a case, but because vague agreements about a difficult schedule are how the next argument starts.
The structural fix
Most overruns are made possible by a project shape that hides them: one large phase, a distant deadline, and progress reported as percentages.
Short phases with working software at the end of each make an overrun visible in week three instead of week fourteen — while cutting scope is still a decision rather than a rescue. That is the main practical argument for phased delivery, and we cover the contract side in our post on fixed price versus time and materials.
If you are part-way through a project and something feels wrong but you cannot name it, tell us what you are seeing. Sometimes the answer is that it is fine, and that is worth knowing too.