The story is nearly always the same. The quotes are signed, the project starts, the invoices arrive one by one and each looks reasonable. Then the last one lands, and the total is well above what the business had in mind. Nobody lied. Nobody was looking at the right number at the right time, that is all.
Project budget tracking is part of my work as a digital project director, alongside the schedule and the decisions. I learnt to hold a budget, a schedule and a team against a date that would not move when I started out in film and television production, and I have kept a few habits from it. Here is how I turn quotes into a baseline budget, what I track each month, how I spot an overrun and what I do about it.
01Why digital project budgets drift without warning
IT projects have a quirk that the average hides. Bent Flyvbjerg and Alexander Budzier studied 1,471 IT projects in an article for Harvard Business Review: the average cost overrun was 27%, but one project in six overran by 200% on average, with a schedule overrun of almost 70%. The danger is not the small overrun everyone expects. It is the project that runs a very long way off course without anyone seeing it go.
The second cause is more mundane: estimates are too low. HM Treasury says so plainly in its guidance on optimism bias. People who estimate projects tend to be over-optimistic, and cost and time estimates should be adjusted using data from past or similar projects.
On a digital project, I add three causes I see often. Scope grows in small steps, each too small to justify a change request. Internal work (reviews, content, acceptance testing) is in nobody's quote. And progress is reported by feel: a task stays "nearly done" for weeks.
02From quotes to a baseline budget
The total of the signed quotes is not a budget. It is the visible part. Before any money is spent, I write a dated baseline budget that will serve as the yardstick until the end.
What I add to the quotes
- Internal time: who in the business will review, approve, produce content and test, and how many days that represents.
- Running costs that start during the project: licences, hosting, tools.
- Acceptance testing and the fixes that follow go-live, rarely priced at the right level.
- A contingency, kept separate from the lines, with a written rule: who can draw on it, for what kind of spend, and at what point the sponsor is told.
To size the contingency, I would rather look outside than inside. In a conversation with Rita McGrath, Bent Flyvbjerg describes reference class forecasting: instead of adding up costs from the inside, you look at what projects of the same kind actually cost, and assume yours will do the same. If your organisation has past projects, their overruns are worth more than any gut feeling.
I break this budget down by deliverable, not by supplier. "Online product catalogue" is easier to track than "agency A". And I version it. On an integration between an ERP and an online shop, the specification changed at almost every meeting, and I updated it version after version so that everyone was talking about the same document. A baseline budget works the same way: when it changes, it gets a new number, and the old one stays readable. This work belongs to project scoping, not afterwards.
03Track three numbers each month, not a total spend
The usual reflex is to compare what has been spent with what was planned to be spent. That number alone says nothing: having spent half the budget at the halfway point is good news if half the work is done, and bad news if only a quarter is.
Earned value management solves this. The Project Management Institute has published a guide to reading the numbers with a simple example: a 100,000-dollar project, four months in. The work planned by then was worth 40,000, the work actually finished is worth 36,000, and 45,000 has been spent. That is 80 cents of work for every dollar spent, and if nothing changes the project will finish at around 125,000. The overrun shows up in month four instead of month ten.
You do not need software to apply it. The same guide points out that the method works on a small project, and on agile teams, as long as an item only counts as finished when it is genuinely done and accepted.
The table I keep
One line per deliverable, with these columns:
- the budget for the line, taken from the baseline;
- what should be finished by this date, as a share of the line's budget;
- what is finished and accepted, in the same unit;
- what has been spent or committed;
- a green, amber or red status;
- for any amber or red, a sentence on the cause and the decision requested.
One rule comes from my content machines. In the machine that writes this blog, a check that did not run produces a red, never a green by default. The budget is the same: a line whose invoices or progress are not up to date is not "on track", it is unknown, and I show it as such.
04Spotting an overrun before the last invoice
The PMI guide to earned value gives two pieces of advice I follow. First, read the trend, not the single point: one month below the line may be noise, three months in a row is a pattern. Second, be wary of subjective progress. A task reported as 90% done three weeks running is not 90% done.
The signals I watch on a digital project:
- a line that spends faster than it delivers, even slightly;
- small requests agreed in meetings without being priced;
- a supplier waiting for an internal sign-off while their team stays booked;
- a schedule slip, which nearly always ends up costing something.
That last point is why I track the budget together with the schedule built on dependencies, not next to it. When several suppliers work in parallel, one supplier's waiting time becomes another's invoice, which I cover in the article on coordinating multiple suppliers.
Then there is the human side. In the same conversation, Bent Flyvbjerg makes a point of it: leaders have to thank the person who comes to say the project is going wrong, otherwise problems stay hidden for months. I apply the same rule in my own tools: an amber only goes through with a written explanation. An amber status that arrives early, with its cause, gets dealt with. The same variance discovered at the end turns into an argument.
05Dealing with a variance: a decision, a name, a date
A variance is useless if it stays a number in a table. The PMI recommends ending every review with a decision and an owner, and offers four options that I use as they are: monitor, correct, escalate, replan.
How I prepare a decision
- Check that the variance is real: a late invoice or badly recorded progress creates false variances.
- Name the cause in one sentence: "three screens added to the checkout without a change request", not "drift on work package 2".
- Offer two or three costed options: take a feature out of the first release, draw on the contingency, move a work package, increase the budget.
- Say which one I recommend, and why.
- Write down the decision taken, who owns it and by when.
These decisions go to the sponsor or the steering committee when they go beyond what the project team can commit to. One lesson from past assignments helps here: a monthly report that goes out on its own and a committee that decides are worth more than a dashboard nobody reads. So the table goes out a few days before the meeting, and the session is for deciding, not discovering.
What this tracking does not do
It does not rescue an unrealistic starting budget. If the baseline is wrong, you are measuring variances against fiction. It also has a cost: keeping real progress line by line takes an hour or two a month, and suppliers who agree to share their burn. On a project of a few weeks with a single supplier, I often settle for one midpoint review and a simple rule on new requests. I am a trained Scrum Master and Product Owner, and on a sprint-based project I tend to read the budget as the number of sprints left against the scope left.
06Where to start on your next project
If you have a project under way, start with one thing: take your quotes and write down what they do not cover. Internal time, licences, acceptance testing, contingency. You will have your first baseline budget, and probably a surprise.
Then pick the day of the month the table goes out, and the person who receives it. Three numbers per line, one sentence per variance, one decision requested. The rest comes with practice.
This is part of what I do in digital project direction, often from the scoping stage. If your budget is worrying you, we can talk about it.