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!
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!
Project financial analysis is what happens before a project is approved, and is a way of making sure that the company is spending its investments wisely by making smart choices about what projects to take forward. Thorough analysis is important to ensure that you don’t end up doing projects that lose money.
According to The Harvard Business Review Project Management Handbook: How to Launch, Lead, and Sponsor Successful Projects by past PMI Chair Antonio Nieto-Rodriguez, there are 5 common financial metrics: opportunity costs, payback period, IRR, NPV and ROI. Let’s take a look at those.
Opportunity costs are a way of looking at what you aren’t going to do because the business’ resources will be tied up on this project. If the other projects are worth more to the business (however that is decided), then this project should be put on hold and instead the other projects should be taken forward.
You’ll need a relatively mature portfolio management approach to do this because you’ll have to identify the other projects that will be put on hold, and have budget/resource assessments for them to calculate what it would cost to do those – and have information about their benefits. If you’re in the kind of business that only does full business cases when the idea is pretty much ready to go, then this could be hard.
Even so, you should be able to include a paragraph in the financial evaluation that talks about the fact other projects will not be going ahead if the company decides to invest in this work.
This measure relates to how long it takes before the project starts to generate a return. On a programme, that could be before the end (and I’d hope it would be) because individual projects should be generating benefits as they complete.
Nieto-Rodriguez talks about the duration of the payback period being set by the organisation. Then if the project earns back the investment before that time is up, it’s a worthwhile investment. If it’s going to take longer than that, it’s time to think again. Typically, shorter payback periods are better, as it means the project starts to earn back more than it cost to do in a shorter time.
Internal Rate of Return (IRR)
I used to find IRR a difficult concept to understand, because rate of return is quite clear, but what’s the ‘internal’ all about? IRR refers to the amount the project ‘earns’ for the business. IRR is expressed as a percentage, and relates to the efficiency of the investment.
Let’s say you put your project budget in the bank and didn’t do the project. Instead, you just claimed the interest that the bank paid on the money. Your investment is safe, and you make some money back. But bank interest rates are pretty rubbish for the most part.
What if you did the project instead? The IRR calculation tells you what the ‘interest’ rate would be – it’s a different way of looking at the way project’s generate return. If the IRR is better than what you’d get in a bank, then the project is worth doing. If the IRR is less than what the bank could offer, you may as well save your time and effort and put the cash in the bank – assuming that financial returns are what you want to get.
Net Present Value (NPV)
NPV is really useful, because it helps you work out project financials as they relate to what money is worth today. A positive NPV is what you are looking for: that translates as the project forecasts being worth an amount that generates future cash at an acceptable rate.
NPV targets, minimum rates and discount rates may be set as industry standards or by your finance team, so check how if there are any specific variables or values you are expected to consider in the calculations (or better still, get a finance person to give you a template where you just plug the project forecasts in and get the NPV out). NPV is expressed as a financial value.
Return on Investment (ROI)
This measure relates to the project’s financial return given the investment made to deliver the project. In the business case or financial documents, it is expressed as a percentage of the total anticipated project cost, often including the Year 1 to 5 opex or running costs too, but the exact calculation will depend on the criteria set by your finance team.
ROI is a way to clarify what the business gets back from its investment. Typically, the higher the ROI, the better, as it means that the company is going to receive more income from the investment and it will pay off in a better way.