Last month we looked at what goes into a programme financial management plan. One of the components of that document is, of course, the initial budget. You can’t track what you haven’t baselined, so there is an effort involved in making sure that the programme budget is put together in a robust way.
Creating a programme budget that is appropriate, timely, relevant, accurate, detailed enough to get through the scrutiny of the CFO, defendable, transparent and more is a huge, time-consuming task.
So where do you start?
Creating the programme budget
The initial programme budget is put together in the same way that a project budget would be: you bring together all the financial information you have from the business case, estimates, quotes, contractual arrangements and more to plan out what money is available and when it will be spent.
With a programme, you might also need to work out where the funding is coming from and on what schedule. For example, if it’s a grant-based programme of work, perhaps funding is issued in tranches, or made available on the completion or publication of particular milestones. If it’s a multi-year programme, perhaps funding is only available for this financial cycle and the expectation is that more funding will be available from next year’s pot.
Agree financial metrics
Next, work out how you are going to track and monitor the budget and what metrics will be used for benefits tracking. Again, this is no different from project budgets, although the figures might be larger and you may also have opex costs to consider – many projects are able to capitalise their costs so as a project manager I rarely had to worry about opex tracking.
The financial indicators are important because these feed into the health of the programme and will be reported regularly. But on a programme that spans many years and perhaps has difficult-to-quantify benefits, how will you check that work is proceeding as it should? Earned value management is one way, but if your company isn’t set up for that you’ll need an alternative.
The metrics you choose for indicating the financial health of the programme and also the benefits realisation measures will very much depend on what the programme is delivering. Sellafield, which is a multi-year nuclear decommissioning initiative, has a 20-year corporate plan. However, they have set out very clear milestones for each project as part of the transformation timeline.
A digital transformation programme spread over 2 years would have very different financial constraints and would be tracked with different metrics.
You may find that validating the metrics as you go is a suitable approach, if all the stakeholders buy into that. It’s important, however, to get the metrics as ‘right’ as you can because future decisions will depend on them. As you report progress, produce updates or even make decisions to move into different stages, you’ll be presenting the financial numbers using the measures for performance tracking that were agreed when the programme began. So it’s worth spending some time making sure they are the right ones and that people understand them.
Part of the budget planning is also being aware of the financial risk. In Sellafield’s case, for example, the timescale spans 4 government spending reviews which may impact the funding available to the team.
There will surely be budget-related risks that should be added to your programme risk log. They are likely to include similar risks that you’d see at project level, but with a programme focus, such as:
There will also be risks that are more programme-focused, specific to your particular programme.
The more risk analysis you do, the easier it will be to calculate an appropriate risk budget. Be careful not to count the risk budget twice, once at project level and then again at programme level, if it’s for an escalated risk.
All this goes into the mix for working out contingency appropriate for the programme, and at what level you wish it to be attributed to the work. At project level? At the overall programme level? Some mix of several methods for assigning contingency?
Ultimately you end up with a programme budget that will no doubt change and flex as time goes on, but should give you a reasonable baseline from which to start.
How do you know when you’re ready?
The outputs of getting ready to track your programme budget will tell you if you’re ready to go ahead. You should have the following:
When all those things are in place, I’d say you were in a pretty good position for the programme’s financial management. What would you say?
Last month I looked at what you need to consider when setting up programme financial management, drawing on The Standard for Program Management, Fourth Edition (2017).
Today I wanted to write some more about financial planning at programme level (as we would spell it here in the UK), again, using The Standard as the foundations but sharing my experience as well.
The financial management plan for a programme
The Standard talks about having a financial management plan which is made up of:
This all fits into the overall programme management plan, but could be a separate document.
The document is supposed to outline a lot of information about how money will be managed during the work. It should go into detail about:
In addition, as with all plans, you should include how the budget is going to be approved and what that authorisation process looks like.
In my experience, we did not have all this written out, although we did have a Finance team who were very much on the ball and probably had considered it without making it my job (thank you, wonderful Finance Manager!). In addition, the detailed technical budgets, which represented most of the cost (aside from staff) were put together by the technical architect, and were comprehensive. By the time it was my turn to look after the numbers, the paperwork seemed solid and it was very much a tracking exercise. I can’t take too much credit for the planning effort.
We were using international resources so the currency issue was very much relevant, and so was the risk reserve because we were doing something new to us with a high degree of uncertainty.
To be honest, I’m not sure we had a formal process for risk reserves either. Contingency had been added to the budget, but we did not allocate budget to risk management activities on a per risk basis. Given the scale of the investment, that was probably a mistake! I don’t recall any terrible dramas happening as a result of not having funding assigned in that way, even when the programme timeline was extended.
Contract payment schedules were documented in the contract instead. Our legal team bound up the contract and relevant schedules into little A5 booklets and I had one that sat on my desk and became my go to reference for all things to do with service level agreements, contract expectations and when I had to approve certain milestones to issue payments.
One time, I issued the payment notification and requested the funds be paid, but I had not warned Finance such a large request for cash would be coming so the actual payment was delayed a few days. That taught me I needed to start my process earlier so that Finance had notice that a large payment was due as part of our contract schedules.
Planning at a programme level feels harder because there is generally a bit more uncertainty, the timescales might be longer than your average project, more people are involved, and the numbers are higher. However, it’s never one person’s job. As you come together as a team, experts can provide their input to make sure the final result is something the governance team, finance team and programme management team can be confident with.
Project costs feels like a topic I’ve revisited many times over the course of writing this blog (can you believe I started it in May 2010?) and today I want to use my monthly video to go into the differences between direct and indirect costs and fixed and variable costs. They are terms new project managers might get confused about and we hear them thrown around in discussions. What do they mean for projects?
In this video I share a few examples of each so you can get a feel for how these might play out for your work. If you want a text-based post to refer back to, then this article on 5 types of project cost also includes some information on the topic.
Do you have different definitions or examples to share? Leave a comment under the video as this community is better for all the different voices in it!
Sunk costs… what a headache when it comes to decision making. In this video, I talk about what they are and why they are a problem. If you don’t feel they are a problem for you as a project manager, then all credit to you!
In summary, sunk costs are those that have already been paid out. They are budgeted expenditure that has already been committed – the company can’t get those funds back. I agree they absolutely that this expense shouldn’t cloud your judgement, but unfortunately not everyone in the project sphere feels the same way and often decisions are made with sunk costs playing a large part in what next steps are taken.
In my view, project sponsors who feel that saving face is more important than business value are most at risk from making choices that perhaps wouldn’t stand up to too much audit scrutiny when the project is reviewed for benefits in a couple of years’ time post-delivery. Having said that, everyone is at risk of feeling invested when they have poured effort into working on something.
We have to work really hard to make sure that sunk costs, and the emotion attached to a project, don’t play a part in tough decisions about the project’s future.
Watch the video and then share your thoughts in the comments below: am I right, or is there more to it? Can’t wait to hear your views!
If you’ve been working in project management for some time, you might be familiar with the idea of variance. However, new project managers, or those who haven’t had to prepare financial information about their projects before, might find the idea a bit harder to get their heads around. Keep reading – this is for you!
I was speaking to one such project manager recently. While she had a ton of experience, she hadn’t needed to provide financial information for her projects as it wasn’t part of her stakeholders’ expectations. When the costs are mainly internal resource, many companies don’t require project managers to work that out in money terms. We tend to just estimate in days or some other unit of time and that’s good enough.
However, there will come a point in your career where you will most likely be asked to start crunching budget numbers for your projects. As you move into environments with greater levels of project management maturity, for example, it becomes more important to track things across projects in a standard way.
Budgets for money are the same in principle as budgets for time: you still need to work out how much you need and how much you are using, just like you would for time tracking on a project where you are only estimating in person hours/days. There’s another ‘however’ coming though…
However, in many organisations, including those where I have worked, it isn’t always necessary to track time. You create a project estimate at the beginning that states how many hours etc are needed from a resource in order to secure that resource, but after that, people are simply expected to manage their own time and the project is expected to conclude on the day you said it would. Timesheets don’t feature.
So, moving from this loose ‘we make a guess at how long things will take and go from there’ environment to one where you are expected to submit project reports with variance figures each week can be quite a challenge!
Luckily, the maths is not complicated and while it might seem daunting (especially if the numbers are big), variance is easy to track.
Here’s how to calculate budget variance.
Variance = Actuals + forecast – budget
In other words, you add up what you’ve spent so far with what you still have left to go, and compare that the original approved budget. The difference is the variance and shows whether you are under or over spent.
At the very beginning of the project the actuals are zero as you haven’t done anything yet. Each reporting period, simply pop the actuals into the right column and adjust the forecast down. Assuming you are on track, that is!
If you aren’t on track to hit your original estimates, you should be reforecasting the still-to-do work and noting those figures in the forecast column. Forecasts can change for lots of reasons including:
If you keep your forecast and actuals columns up to date, the rest is easy!
Normally there would be some tolerance agreed for the variance. For example, being under or over by 10% of the budget is OK but anything over that needs escalating to management or a change request etc.
Setting tolerance with your project sponsor will prevent you from having nightmares every time your project report says you are a few percentage points over budget.
How to get started
Make a spreadsheet that has the various columns. The simplest way is to have one column per field (actuals, forecast, budget, variance) and note the figures overall. As you get comfortable doing that, you might want to break them down by month to get a better idea of how things are tracking over time.
Once you’ve played with your project’s figures and have put together a spreadsheet to track them yourself (I recommend doing that instead of starting from someone else’s template so you can see how they fit together and what sums sit behind the columns) then you’ll get used to working out the numbers in this way.
I’m not a maths whizz by any means and I can manage it, so I’m sure you can too!