Budgeting for Projects – the Case for Change

Budgeting creates problems for business change projects.

Change projects are often something of an anomaly for Finance when it comes to expenditure control and resource allocation. At least that’s the way that it’s felt. The problem, however, is really budgetary control.

When I was doing management reporting for functional expenditure areas, that’s what I used to feel with projects.

And the problem was that we were trying to manage project expenditure in the same way as every other kind of expenditure.

We’d create cost centres for projects as if they were business departments. That would mean the nomination of a cost centre manager, and the inclusion of the project costs within the ‘actual vs budget’ variance analysis each month for each function.

When it came to forecasts, we’d collate the data in the same way as every other cost centre. And we’d challenge their forecasts, and their spending against budget in the same way as every other cost centre.

And that meant project costs were always a major variance to explain. They always clouded the picture. It was a pain in the butt!

To be specific, I’ll outline a few of the pain points before I suggest some solutions.

Budgeting for projects that haven’t started yet

Traditional budgeting techniques lead us to gather information for the budget for the following financial year about 6 months before it starts. That means for a January to December financial year, we start budgeting around July, perhaps even a little earlier.

Budgeting is problematic for projects and vice versaThe problem I saw regularly was that, especially within functions going through a lot of change, the functions didn’t always know what projects they would be doing in 6 months, 12 months or 18 months time. They knew they would want to make some investments, but even if they knew what process or system they wanted to address, they usually didn’t know how much the project would cost.

It was a circular problem. If they didn’t put a request in, they wouldn’t get to do the project next year. But because they didn’t know how much it would be, they would either get allocated too much, or allow themselves to get cut because the Finance Director wanted every budget item to be really specific.

The problems get worse when the expenditure control procedure says that there are different approval limits for expenditure within or outside of budget.

If a department identified a need for a project part way through a year, they would either go through layers of bureaucracy to get an “out of budget” approval, or they would pull budget from other areas and reprioritise so that they could say it was within budget. Pain on the one hand. On the other hand, the business ends up doing different things to what it planned in the budget!

Project budgets don’t fit in financial years

Another big problem is that project expenditure doesn’t usually confine itself neatly into financial years. It’s unusual for a project to start and finish in the same financial year.

The reason that’s a problem is that each budget is done for a financial year.

So, when the budget is prepared, we may not know that the project we are just starting will be behind schedule by the end of the year. So, unwittingly, we don’t budget enough next year, but we are heading towards underspending the budget this year. And critically, we can’t carry forward the unused budget to next year – “use it or lose it!”

That leads to several dysfunctional behaviours. In no particular order…

Using the underspend to fund other projects and initiatives. If there is a budget that isn’t going to be fully used, it is usually thought to be ok for the functional leader to reallocate it to other parts of his/her function. But that wasn’t what was envisaged in the plan/budget, so why bother with the plan/budget?

Manage projects with business cases not budgetsThere may be nothing wrong with that – we should be trusting senior executives, especially if the business strategy is pretty clear. The problem is that it only sometimes works the other way. So, the following year when their project overspends in that financial year (not overall), theoretically they should make cuts in other places to stick within the function budget. But normally the executive bleats and moans to the Finance Director about unfair cuts and cuts in services, so the FD normally then pulls in some budget from elsewhere. Or they take an educated guess that there will be underspends elsewhere, and let them off.

The other spin-off behaviour, if this is not dealt with, is departments working hard to convince Finance that their forecast is per budget while they look like they’re underspending – “it’s just phasing!” They assure us that their spending will catch up, and we can’t take that budget away in the Q3 forecast (which, in my experience, is what tends to happen). And because we’re business partners, and we like to please the business and help them out, we let them do it.

What they’re really employing are delaying tactics, while trying to work out what else they can spend the money on. Quite often those end up being “nice to have” discretionary pieces of work.

They are so parochial that it doesn’t bother them that the FD is trying to find some spare budget to give to a really important strategic project that didn’t make the budget. That project can’t go ahead because underspending departments are playing games with the forecasts.

Raising spurious accruals (i.e. accruing for things not yet technically spent) is bad accounting. It’s dishonest sandbagging (as I spoke about in one of my other articles). But that is what happens when cost centre managers want to carry budget over from this year to next year. It gives them extra flexibility. And this is especially true on project, and especially with projects that are underspending and progressing slower than originally planned.

Misclassifying expenditure as revenue expenditure or capital expenditure, depending what suits the budget variance. Projects are normally a mix of some capital and some revenue expenditure. Project managers, close to year end, like to draw on their Finance business partners’ expertise sometimes to abuse the judgments that can be made in the capitalisation rules.

All this happens because we’re trying to manage the spending of a project against a financial year budget, when a project’s end-to-end spending profile is, by nature, quite unpredictable.

Budgeting usually ignores benefits

It’s unusual for a project to be genuinely self-funding – in other words, the financial benefits exceed the costs in the year of implementation. That means that, most of the time, the costs of the project will be in one budget year, and the benefits in later years.

Who remembers to budget for the benefits after the project has finished?!

When we’re thinking about budgeting for the following year, there’s a temptation to simply think, “oh, we don’t have to budget for that project next year because it will have finished.” Unless cost centre managers and Finance managers are close to projects, and their project managers, it isn’t in the front of their minds that there may be benefits to plan for. And if the benefits are in the revenue lines, that’s even further removed from the project budgeting process.

Don't forget to budget and forecast for project benefitsAnd if no one is taking the business cases and ensuring that the benefits are built into the budget, then there’s a danger that either cost centre managers will end up with budgets that are more than they need, or that sales targets will not be challenging enough. No one is going to complain about that. But they may just go and spend their unexpected leftover budget on something unnecessary.

The long and short of it is that this doesn’t drive the business to perform. It doesn’t stretch the business. And it doesn’t give any accountability for delivering the benefits we want out of projects.

Budgeting sees projects as purely costs rather than value-adding initiatives

In summary, budgeting treats projects as purely costs – as a resource allocation exercise for the next financial year. It doesn’t see them holistically, as value adding initiatives, or even as something other than Business As Usual.

But there are solutions to these problems. Here are a few of my ideas:

A portfolio approach to project budgeting

First, allocate funds for investment, but manage drawdown with strong portfolio management.

By that I mean that your financial plan for the future should contain funds set aside for known projects, with some contingency, plus a pot for strategic and tactical initiatives yet to be agreed. A “portfolio management” governance structure should then be put in place to assess requests for project funding, strongly linked with the agreed strategic agenda.

In effect, your planning should identify how much the business can afford (cash and profit) to put aside for investment in strategic initiatives. And it should be kept separate from the allocation of resources to ongoing operations.

A once a year round of budgeting is not the time to get all projects lined up in principle for the following financial year. That’s just not agile. So, put In place a process that allows requests to be made when initiatives are better defined, and can therefore be better controlled.

Manage projects against business case, not against budget

Secondly, keep all projects separately tracked, outside the normal P&L. If you have to track against a budget, do that at total portfolio (or segmented portfolio) level. And don’t use budgetary constraints to control individual projects.

Instead you should be always referring to the project business cases. When looking at project performance, you should be looking at the forecast spend against business case and milestone plans, and forecast benefits.

Effectively, if the business case is kept updated, as it should, at each project stage, then the performance measures are not just the costs, but time, quality, risk and benefits. So long as the business case is still on track to the satisfaction of the project board, then it doesn’t matter whether they’re spending faster or slower than first thought. What matters is that the promised benefits are going to be achieved for the same cost in the end.

Link forecasting process with project management – costs and benefits

Thirdly, the forecasting and planning process should have a strong link into the portfolio and project management organisation. The expected costs and benefits should be tracked, and fed into the financial forecasting process.

Keep projects separate from BAU in planningAdditionally, if business cases are prepared correctly, benefit owners should be identified. And since they own the benefits, the forecast is another way of ensuring they’re on the hook for delivering them.

In businesses that have implemented Beyond Budgeting, the rolling forecast is integral, and therefore this part becomes critical.

Building on the segregation of projects from BAU, recommended above, this effectively means that expected costs and benefits of projects form an “overlay” of the impact of strategic and tactical initiatives.

The project isn’t finished until the benefits are owned

Finally, building on the last point, what starts as an “overlay” on top of operational results has to become BAU at the point of handover. The projects costs cease, and the benefits become operationalised, and therefore part of BAU operational forecasting. At that point the benefits are well and truly owned by the people who should own them.


Projects are often seen as problems for budgeting and variance analysis, because they just don’t seem to fit the model.

Really the problem is the other way around. Budgeting is the problem. Its restrictiveness, its focus on financial years, its focus on spending, lead to what’s been described as “gamification” – suboptimal management and skewed accounting.

The solution in a nutshell is to treat projects as the special strategic initiatives that they are, and to focus on why they exist – to improve business performance. That will lead you to manage them in a way that actually does just that.

Leave A Response

* Denotes Required Field