The Money Files

Last time I looked at 7 types of expense that are worth mentioning in your business case, to show that you’ve got a rounded handle on all the costs.

The Better Business Cases^TM model that I mentioned last time goes on to describe even more different cost types that you should be aware of. I did know about some of these, but this list has some in that I wouldn’t routinely think of.

We might not need to mention or use them all in business case preparation, but it is worth having a general awareness of them, not least so you can ask your Finance colleagues smart questions!

1. Sunk costs

If your business case represents a Phase 2 or subsequent investment, then it’s worth mentioning the sunk costs: the money already spent on other parts of the work that you cannot get back. These might be in contracts already issued, purchase orders already raised that must be fulfilled or previous steps of the project.

They get a mention in the business case but they aren’t part of the appraisal. In other words, talk about them so that decision-makers have the whole picture, but don’t include them in the cost assessment or budget figures for this part of the project.

2. Full economic costs

This is another term I wasn’t aware of but it only means including direct, indirect and attributable costs for each option mentioned in the business case. In other words, flesh out your finances so they show the whole, true picture. Use a bottom up approach to get the real figures.

3. Attributable costs

Wondering what attributable costs are from the section above? These are generally the costs related to staff time. If your team members are caught up delivering the project in this business case, they aren’t doing work on other business cases, that might be equally or even more important. So attributable costs are things that don’t fall into the direct or indirect category but are relevant as they round out the business case.

I think too many managers forget that if you are working on Project A you can’t be working on Project B at the same time (because they expect that everything gets done, most likely!). It’s worth calling out that if you tie up a team full-time on this initiative, their costs go towards the project and their staff time is allocated.

4. Organisational development

Organisational development costs are the figures related to change management. These are definitely worth including. I can’t even remember the number of times I’ve had a project budget handed to me and there has been no allocation for training, printing, change management, travel and room hire for workshops or town halls, or anything else. Make sure your business case includes the costs of what it will take to go from the current way of working to the new way of working, including any process updates, change activity and staff development required to make proper use of the thing you are delivering. 

5. Contingent liabilities

Now, I confess to including these in business cases in the past but not knowing the correct term for them. You are probably aware of them too: they are the expenses related to future events. For example, the costs you may incur to buy yourself out of a contract early. Make a mention of those in your financials as well.

So, we have all those, as well as capital, revenue, fixed, variable, step, opportunity costs and inflation that I covered last time.

It feels like this business case is going to be weighty! Remember to draw on your sponsor, finance analyst and the finance team more broadly for support with the numbers and to make sure your maths stacks up. Ideally, they should be providing the underlying assumptions and algorithms that make up the financial parts of the business case template. As the business case is a major input to how much money you get to do the work, it’s important.

In this part of my occasional series on program cost management, inspired by The Standard for Program Management (Fourth Edition), I’m talking about 9 financial management tasks that you should expect to do as a program manager.

1. Identifying changes

First up, be aware of what might be coming over the horizon to influence the budget baseline and what factors are leading to changes. This is basically being aware of what might create a change so you can be on the look out for any changes. It’s proactive listening and always considering what a course of action might do to your budget.

2. Monitoring for impacts

Part of the daily work of a program manager is keeping your eye out for any environmental factors that might impact the program overall, and budget changes are part of that. These could be environmental factors like changes in regulation, access to skilled resources from the local hiring pool, or access to the right technology – anything that could have an impact on the budget.

3. Managing changes

What happens after you scout the horizon for things that might change your program budget? You find things. Part of a program manager’s tasks is to manage those changes. The change could be to scope, to the schedule, to the resource profile, procurement plan, or anything else, and we have to play back what impact that is going to have on the budget and build in the changes.

4. Monitoring cross-project impacts

As I mentioned in my last article, part of my role as a program manager is being able to shift funds between pots to ensure the overall program goals are met. That’s what this task is all about: monitoring the impact of what happens when costs are reallocated and making sure that overall the program components are balanced – or at least as balanced as they can be.

I mentioned cross-project impacts in the heading, but programs often include an element of BAU work and that can just as easily be affected by changes.

5. Monitoring supplier contracts

Some suppliers might be contracted at a program level, so it’s the program manager’s job to ensure that suppliers get paid in line with their contracts. With one supplier I worked with, we had contractual milestones in place. When each milestone was reached, another stage payment was due.

Part of my work was ensuring Finance was aware that a stage payment was due so they could have the right amount in the bank accounts ready to pay when the time came.

6. Earned Value Management tasks

If your program uses earned value management, you will work with control account owners, project managers and other experts on the team to make sure EV practices are implemented and adhered to. Part of the role will also be making sure everyone can interpret the outputs of EV reports and manages their part of the schedule accordingly.

7. Dealing with over and underruns

It’s unlikely that your program will be perfectly on budget every month because that would rely on your estimates being perfect and no ‘real life’ happening during the work. It’s more likely that you’ll be a bit under or a bit over.

Part of the program manager’s role is to manage within that tolerance and to advise and support project managers on the program to do the same.

8. Working with stakeholders

Another big part of program management is communication and engagement with stakeholders around changes. The sponsor, customer, client and governance groups (including auditors) need to have access to transparent information around the program’s financial measures. You have to provide that.

9. Managing within tolerance

Finally, the main, most obvious part of the role is to manage the program’s spending within the levels expected. You may have set tolerance at individual component level, or there may be other ways you are managing to within the expected parameters. These should be clear, so everyone knows how the work is being tracked.

And, if you spot that you are not managing within the parameters and boundaries set, then as the program manager it’s your role to take steps to get back on track, whatever those actions might look like.

The Standard for Program Management (Fourth Edition) talks about how to track program financial metrics once your financial management plan is up and running. I thought it would be worth comparing the guidance to what I’ve done as a program manager to see how I measure up – and you can compare your own practice to what’s in the Standard too.

Program financial management, as a refresher, is defined in the Standard as:

Activities related to identifying the program’s financial sources and resources, integrating the budgets of the program components, developing the overall budget for the program, and controlling costs during the program.

Once you’ve got the program going, your work as a program manager shifts to tracking the money and making sure you are on track.

Spoiler alert: I’ve never used earned value to do this in real life, although I’m well aware of the benefits of doing so on projects and programs.

I think the techniques you use for tracking very much rely on your organisational culture and maturity levels, and I’ve not worked anywhere where EV is considered part of the way things were done. If you’ve got experience working in an EV environment, let me know how that goes in the comments.

The program manager’s role shifts to monitoring spending and controlling spending, ensuring what is being paid out is in line with the budget. In my experience, as a program manager, I’ve had a fair amount of latitude to move money between ‘pots’ (or projects) to ensure the overall goals of the program are met. And I have to say, I’ve enjoyed being able to make those decisions.

What I haven’t enjoyed is the financial scrutiny. I know we need governance on programs, and I’m all for it, but sitting in a meeting having to present the numbers has always been uncomfortable for me. Not because I don’t believe in the numbers, but because I’m normally presenting to people with an accounting background and honestly they could dance rings around me if they wanted to pick holes in my maths. So I have to put extra effort into making sure I can justify how numbers are put together.

My top tip is to make sure you keep detailed records of how you came to land on certain figures. For example, on a program I’m working on at the moment, we track committed spend, forecast and then actual “out-the-door” spend. But there are a couple of other strands within the program that are accounted for separately (don’t ask, it’s just the way it works best) so I have to make sure I’m clear as to what’s in and what’s out of the numbers so I can justify them every month and make sure we are reporting to the PMO on a consistent basis.

Because trust me, if I didn’t, I’d forget from month to month what the basis of calculation was and report something that wasn’t internally consistent and that I couldn’t justify reliably. Which would be bad.

Governance serves a purpose: it makes sure that a program is operating within approved cost limits and challenges programs that are forecasted to go out of those budget targets. Then the organisation can decide if it wants to continue with the program or not.

I’ve luckily never worked on a program that has been cancelled because of financial issues – but I imagine that is largely luck and the kind of programs I have been involved with rather than any skilful cost management on my part.

My experience of program cost management has been very similar to managing large project budgets: the skills are the same, and business acumen comes into play too. I think that having the bigger picture and goals in mind helps. What do you think?

In my next article, I’ll look at some typical financial management activities as outlined in the Standard and talk a bit more about those.

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.

Financial risk

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:

• Changes to exchange rates
• Changes to the price of goods or services
• Strategic changes that alter the course of the programme

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:

• The programme financial management plan including the metrics you will use to track performance
• The initial programme budget, made up of the elements above
• Programme funding schedules showing where the income is coming from
• Payment schedules for each project, component or workstream, at least as far as you know them right now
• Operational costs for the programme e.g. resourcing that cannot be capitalised
• Risks for the risk register.

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:

• Funding schedules and milestones (financial timeline)
• Initial budget
• Contract payment and schedules
• Reporting activities and how reports will be managed
• Metrics for reporting and controlling finances

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:

• How risk reserves will be accessed and used
• How the programme will deal with financial uncertainty e.g. international exchange rate fluctuations, changes in interest rates, inflation, currency devaluation etc
• How the programme will deal with cash flow problems and if any are already identified
• What the local laws and compliance regulations are and how these will be met
• Incentive and penalty clauses in contracts.

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.