The Money Files

I’ve been managing a programme for a while now, and it’s quite different from managing projects, or the very large projects that we call programmes that are really not programmes!

Programmes need their own budget as well as the budget of the projects, and here are the things I think should be included in that.

1. Costs of running the programme

It seems silly to point it out explicitly, but there are costs incurred from running a programme with a programme management structure.

For example, my time as programme manager needs to be costed and included along with any support resource from the programme office. Even though we are not full-time, the programme wouldn’t run without us so our costs have to go somewhere.

Ideally, there would also be a programme-level risk budget for handling unforeseen issues.

You may also find that on your programme there are other costs associated with running the programme, such as office space, software licences for third parties to access your programme management software (which is likely to be the same project management software everyone else uses, so hopefully not too large of an overhead there).

2. Assurance costs

Are you planning on having internal (or external) audits and reviews as part of the programme? If so, those costs should be picked up by the programme budget.

Internal reviews, in my experience, don’t cost anything except time, but if you are bringing in consultants or external auditors, there is definitely a cost associated with that (as well as time). Certification or compliance programmes may have extra costs here too, for example, if you have to comply to certain standards, going through the accreditation process is both time-consuming and normally costs something. There’s also often an annual cost to main the accreditation so factor that in too if your programme is multi-year.

Plan all those costs into the programme budget at the frequency and estimate required.

3. Benefits realisation costs

Benefits might be realised at project level, but you’ll likely have some programme benefits to track as well. And the cost of delivering and tracking those should be included somewhere – in your programme budget.

For example, you may need to programme software to create new reports. You may need a new role, and someone hired to go into that role. Some benefits might include making staff redundant due to organisational restructure, and there are costs associated with that activity too.

Plan all of those in at programme level. You may find that it’s useful to take the project-level benefits realisation costs into the programme budget as well so you can track benefits all in one place, but that’s up to you.

Project costs

Of course, there are costs to running the projects too, and in your overall programme budget, you’ll want visibility of those for forecasting and tracking. But these are the ‘obvious’ costs so it’s likely you already have them.

The project costs would normally include the large infrastructure type items that are necessary for the programme to move forward. The first project would normally take the hit for any large infrastructure-type investment, but that makes the business case for that project rather wobbly. You might decide that large capital costs are picked up by the programme as an overhead instead, and then each project goes forward on its own merit without having to fund the infrastructure required to make it and future projects work.

Talk to your financial analyst or project accountant for how best to apportion the costs across the programme and projects so it’s transparent and reasonable.

You’ll see that at various points in the project management lifecycle you are supposed to review the business case and check it is still fit for purpose, but what does that actually mean? What are you looking for?

I’m not sure that continuing commercial justification of a project sits solely on the project manager’s shoulders, but you can do a first pass review and raise any concerns with the sponsor. After all, power sits with them to make changes to the project or cancel it, should it no longer be fit for purpose and likely to achieve its goals.

Here’s what to look for when you do a business case review to check if the project is still viable.

Strategic alignment

Hopefully your strategy doesn’t change that often, but if you’re managing a multi-year project or program, or you’ve just had some strategic change at the top, it’s worth checking to see that your project still aligns with the organisation’s goals.

Affordability

Can you still afford to do the project? In other words, have costs spiralled due to unforeseen issues, scope changes, requests from the client that have to be included because the contract was so vague they are saying you have to pay for it (of course, that never happens…) and so on.

The challenge with assessing for affordability is that it then opens up a conversation about sunk cost. If you’re three weeks off finishing the project, it may well be worth the cost uplift to get you across the line. If you’ve got two years still to go, not so much.

Riskiness

Look at whether the riskiness of the project has changed. Hopefully as you know more, risk levels have decreased. But a portfolio manager would probably want to assess the risk of this project along with the risk of the portfolio overall, and if the whole portfolio risk profile has changed, there are some conversations to have.

Look at whether your risk budget or contingency time in the schedule is adequate to cover the risk. If not, if you added more, would that make the project unviable?

Achievability

Consider whether you can still complete the work. Achievability might be challenged if key resources have left, deadlines have changed, a supplier has gone bust, or there are plans for a merger. Anything might affect your ability to achieve the plan as it is today.

If you can’t achieve the baselined plan, would a replan mean other criteria for viability are not met? For example, you could achieve the plan with more time and more money, but that would mean the project would not be a cost-effective initiative.

Benefits

Check that you are still going to get the benefits, or enough of the benefits to make it worthwhile from a cost/benefit analysis. If the project ticks all the other boxes, it might not tick the box for benefits. For example, a delay in the schedule may push back realisation of the benefits to a point that undermines the business case. Additional resources pushing the price up will eat into benefits. Perhaps the project no longer represents value for money.

Carry out these checks at key governance points and gate reviews. Highlight where there are issues to resolve, and come up with a plan if you can. Then discuss that with key stakeholders, the client and sponsor, and see if you can resolve any business case challenges without having an impact on viability of the project. Ultimately, if the business case is no longer viable, the decision is around cancelling the project – and that’s a tough conversation for everyone.

However, if the business case no longer stacks up, cancelling could be the best thing to do.

In December I wrote about benefits realisation and management, and how you get started in a simple way. That prompted a fantastic question from Markus:

Reflecting on your thoughts about the growing emphasis on benefits management in project management, it's clear that there's a real shift happening. It's fascinating to see this kind of evolution, where both big and small projects are being scrutinized not just for what they deliver but for the actual benefits they bring. This approach feels much more holistic, doesn't it? … What's your take on this evolving landscape? Do you feel that the focus on benefits management is changing how projects are approached in your organization?

So, let me dive into that a little today and reflect further on the shifting sands of benefits realisation.

Change #1: Stakeholders

I think the first big change in the landscape of benefits management is that stakeholders are far more open to the idea that there are benefits.

In other words, they want to see benefits, they want to come along to workshops to define benefits and they want to get the credit for delivering benefits! People seem to realise that they can’t simply ask to do projects and someone on high say yes. It’s not that easy any longer.

I think part of this change has come about because there is not the funding sloshing around for pet projects any more. Going back a few years, we might have had funding for projects that didn’t really need to be justified beyond ‘sounding like a good idea’. These days, there is far more scrutiny on where the money is going, so it’s important that stakeholders are seen to be engaging with the process of benefits identification.

In real terms, that looks like a lot more commitment to the benefits identification and tracking process.

Change #2: Accountability

Having willing stakeholders prepared to go through the hassle of setting up benefits trackers is really only the start. They have to be held accountable and those tracked benefits need to be reported. And if the benefits aren’t there, that should be challenged. Perhaps there are good reasons why the benefits are delayed, and that can be factored into financial plans going forward.

Change #3: Over-reliance on benefits for funding

I don’t see this often, but there have been cases where some very good project idea has not been funded with ‘real’ money because the plan is that it will self-fund from the benefits. In reality, funding something with money that you save is really hard because you don’t get the savings until after you’ve done the work. So you either have to commit to doing the work and be really sure that the benefits will materialise, or don’t do the work because you can’t pay for it before any benefits are realised… it’s a bit chicken and egg.

I hope this doesn’t become a new benefits trend: yes, do any project you want as long as it’s self-funding! Even a bad idea could get the go ahead if that was the attitude.

Change #4: Identifying benefits

When I first started out as a project manager, we often talked about benefits, but only really listed intangible things like improved customer satisfaction generally (which we could have actually tracked, if we’d bothered enough) or staff morale, or brand reputation avoidance. Things like that.

Benefits are often a bit abstract or not immediately obvious, or you can’t take a baseline because you’re developing something new so there is no current baseline that’s easy to grab to track the difference.

I think part of the evolution is coming up with better ways to track benefits and identify them, and to be honest, I think large data sets, online tools, big data analytics and company’s interests in understanding everything in lots of detail paved the way for us to have the right approach to do this, and the data sources to back it up.

Markus went on to write:

The whole process of setting up models for benefit calculations can be quite a maze. You've got to bring in experts, wrangle with finance teams, and then there's the task of gathering all that baseline data. It's like piecing together a puzzle without having the picture on the box. Getting everyone on the same page, ensuring they understand and agree on the calculations, is a Herculean task in itself.

I certainly agree. It’s not about setting it up once and forgetting about it. It’s an ongoing effort that only starts with identification. However, the signs are there that more and more organisations are caring about benefits – probably because they have to, and that’s not a bad thing.

What does the landscape look like with you?