The Money Files

Last time I wrote about the business benefits that you might want to consider for your business cases. But identification of the benefits is only the first step. The training I was putting together was an hour-long overview, so nothing really deep dive, but I wanted to cover the process for managing benefits beyond simply brainstorming the things we could list to justify the business case.

This is the process I included in my presentation.

1. Identify

This is the step covered in my last article. Define what benefits the project is expected to deliver. Consider financial, customer, operational, strategic, employee, and ESG benefits.

As well as the list I shared last time, go back to some past business cases and see what kind of things they included, as well as the level of detail expected. For example, some business cases I’ve seen are really high-level with hardly any detail and they still got approved! I think it depends on how much you have already socialised the idea and how much the exec team want to do the project… But don’t waste too much time doing the work if you don’t need to in order to get it approved. Maybe stick to two or three good quality benefits instead of listing out 15 non-quantifiable benefits instead.

2. Define and quantify

Make each benefit SMART (Specific, Measurable, Achievable, Relevant, Time-bound). Where possible, quantify in financial terms or KPIs.

This is the step where you’ll spend the most time. It’s normally quite easy to work out the kinds of benefits you’ll get from the project activity. It’s really hard to agree what the baseline is and how you are going to work out the measures going forward.

3. Map and align

Link each benefit to project outputs and strategic objectives. Ensure they support organisational goals.

Do this on a slide to include in the business case or just in a paragraph. This bit doesn’t have to be too much work but you will want to evidence to the decision makers that you have thought about strategic alignment.

4. Plan for realisation

Clarify how and when each benefit will be achieved, who owns it, and what dependencies exist. Go back to step 2 – normally it’s the person who owns the baseline data who will own the ‘new’ data for the benefit. Think about when the benefit kicks in. If it’s about more sales, do they happen in the same month as you made them on the call? If customers have 60 days to pay their invoice, maybe you need to recognise the revenue 60 days later?

This step is another time-consuming one as you work out and negotiate all these pieces.

5. Track and measure

Include plans to track benefits through delivery and beyond. Does the project need to deliver a new dashboard to track sales or some other target? Add those tasks to the project plan otherwise you’ll get to the end and have no way of measuring your achievements.

6. Review and update

I wish I could have made this into 5 steps for the training because 6 doesn’t fit so nicely on a slide! But there is this final step which is to keep benefits under review. Update the business case as the project evolves or as assumptions change. This might mean going back around the approval process if the benefits are hugely different.

Hope that helps with your next business case and benefits discussions! Let me know what else you do in the comments below.

As much as we’d love to have everything working to plan, sometimes we can take some aspects of project management for granted. I wonder how many of these project challenges you have but you haven’t openly recognised within the team?

I don’t want you to have your head in the sand, so below I share 10 things that you might be missing on your project.

(I didn’t want to bury my actual head in the sand, so you got a photo of my feet buried instead! Not quite the same, I know.)

1. Stakeholders are reading your communications

We might believe that stakeholders are reading our project comms, but are they really?

It’s hard to tell, but if you aren’t seeing any action, or people are asking questions you have already answered in your comms, then they probably aren’t.

2. The training you’ve scheduled is enough

I expect it isn’t, even if it feels like it should be. People won’t turn up or won’t use the online training to teach themselves. Plan to have post-launch training support because your users will need it.

3. Your change management plans are adequate

Hopefully they are, but as above, there will always be someone who says they didn’t get the memo, or couldn’t access the materials. Make sure you’ve got post-launch training in the diary as well, and do more change management activity and engagement than you think you should have to.

4. The UAT plans are long enough

UAT is the one thing that gets squeezed in my experience. Add in an extra cycle if you can. It’s easy to take it out – not so easy to squash it back in if you do need more testing time.

This obviously depends on your project – if you are doing something you’ve done a lot before you should have a high degree of confidence in your deliverables, but you might need more if you are working on something new.

5. Risk identification has spotted everything

It hasn’t!

Make sure risks are constantly mentioned in all meetings, and that you are always listening out for what might be a new risk.

6. Team morale is OK

Team morale is something to keep an eye on. The team can get demoralised for the smallest of reasons, from a change not being approved to a reschedule for whatever reason. That negativity can spiral.

Even if things are going well on your project, events outside the project can influence morale, such as a change in leadership, redundancies, an increase in BAU work or pretty much anything else.

7. Benefits are understood

We’d like to think the financial and tangible benefits are understood, but how well have those assumptions been documented? I’ve worked on a couple of projects where we think we understand what we are tracking, only to find that we can’t replicate the exact formula the finance person (who has now left) used, or some other difficulty.

You should be able to answer straightforward benefits-related questions like ‘is this incremental revenue or total revenue’? So make sure you can.

8. There is no conflict in the team

There probably is, but people are too polite to mention it. You should dig for it! Some conflict is healthy so don’t worry about bringing it up.

9. Quality is being managed OK

Are you finding bugs in your deliverables? And more importantly, are you squashing bugs? What are your criteria for exiting testing and how does quality play into that? Ideally, you should have great quality measures, and be performing in line with those, but sometimes project teams get swept up in the desire to deliver and that means some lower-risk bugs are left in for now.

10. There is no technical debt

Are your project deliverables introducing technical debt? Are you breaking things elsewhere or for other teams, or introducing workarounds or degrading the solution for someone else? Sometimes your part of the world might be fine, but a process you’ve implemented ends up in many additional steps or a new report being needed for someone else.

Check that you aren’t creating technical debt by accident – if you know about it, document it and have created it ‘on purpose’ as part of a stepping stone to a different solution, then that’s probably fine.

Which of these might your project be at risk from? Let me know in the comments!

In my early days as a project manager, my business cases and PIDs were full of non-quantifiable benefits. The kind of improvements that I thought we could get but weren’t set up to track.

In my more recent years, I’ve been heavily focused on quantifiable benefits, most specifically the money-related ones. Anything that presents a trackable, cash improvement is something to focus on. If it improves the bottom line, managers want to know about it.

There are also quantifiable benefits that are harder to track like reducing cycle time for invoicing and reducing energy consumption. These would lead to financial savings, but they are more difficult to pin down and measure realistically with no other influencing factors. Cycle time, for example, may lead to bills being paid faster which would lead to better cash flow and increased bank interest, but how do you separate that out as a benefit of just this project and not something to be attributed to one of the many other projects that are doing their bit for continuous process improvement?

Energy consumption can be tracked, but it’s several steps and calculations – it’s doable but harder. That’s not to say we shouldn’t do it, but it is something that you have to put effort into tracking.

Non-quantifiable benefits seem to have dropped out of favour. For example, staff satisfaction survey results is a good one that I used to mention a lot in project documentation. However, there are lots of things that influence staff satisfaction, and I’m sure my projects only played a very small part in influencing the results one way or another.

Also, new initiatives that once seemed completely life changing and a huge improvement quickly become ‘the way things work around here’ and the benefit tails off to nothing. No one would want to go back to the old process, but equally no one is celebrating the new process 6 months later when it’s just normal BAU.

I learned this on a Six Sigma course I took many years ago where the instructor talked about giving customers a biscuit with their coffee in a coffee shop. At first customers were excited they were getting a biscuit for free, but over time they came to expect that service and were disappointed when they didn’t get it, but not more happy because they did.

Therefore there is a balance to be struck with benefits: you want a mix of both quantifiable (financial and other) and non-quantifiable. But not so many that they all become meaningless. And not so few because you can’t be bothered to put the tracking mechanisms in place for more.

Be realistic about what you can achieve with benefits and how much time people really are going to spend on tracking the more difficult ones. If they believe that it’s worth tracking, they’ll do it, but if they feel energy consumption, for example, is tracked adequately through other types of environmental reporting or projects, they probably won’t be falling over themselves to create project-specific benefits reporting.

Talk to the key stakeholders about what sort of benefits you are putting forward for a project and make sure they are reasonable, measurable (where possible) and realistic.

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?

I’m working with organisations who are putting a lot of thought into benefit management at the moment – more thought than I’ve ever seen in past years. I know benefits management has always been something to consider on projects, but how many project/leaders/organisations actually truly do it?

I’m sure the larger projects are geared up for benefits tracking, but smaller initiatives? Those that might only deliver a few thousand pounds/dollars of benefit per year? Are those being tracked?

I think the trend is changing, and I think there is more focus on benefits tracking, particularly in programmes. Where there is a large programme of work, even small projects get to contribute.

So how do you do it?

The first step is to work out what benefits your project is going to deliver. For example, that could be:

• Cost saving
• Increased sales/revenue

In fact, benefits could be lots of things (shorter cycle times, more calls answered, higher customer satisfaction) but most often they can be reduced to money. Shorter cycle times should mean more projects delivered in a year, so more value achieved, or more widgets through the process, so more sales. More calls answered should convert to more sales, so more cash. Higher customer satisfaction results in more repeat purchases and more testimonials that drive new buyers, so more cash.

Even carbon savings and sustainability targets can often be represented as financial benefits. Carbon has a financial figure associated with it, so you can translate carbon reduction into money.

The trouble comes with trying to get stakeholders to agree on how these benefits will be calculated.

More calls in, for example, might not translate to more sales for several months, depending on your business timeframes and processes. You will need some rules and assumptions around how benefit numbers are going to be worked out where the maths is not straightforward.

For example: if we outsource a service, we can reduce headcount in function and probably make a saving on the cost to serve (budgets are part of the outsourcing decision, after all). That’s a straightforward cash saving: those individuals are no longer on our payroll (even if they were moved across to the outsourced party – the UK has TUPE rules for this).

But do we count that saving as a ‘pure’ saving, or do we have to take off the cost of buying the outsourced service? How long can we claim the service for before it becomes BAU? What happens when we need to add a head or two back in, where do those costs go?

We need assumptions to make benefit calculations work, like what’s the average cost of a sale (so if we answer more calls we should convert x% and make y% extra money as a result).

This first step of creating a model on which to base benefit calculations is the hardest part, in my opinion. There are experts to consult, finances teams to engage, data to gather so we have something to use as the baseline, and lots of maths and spreadsheets to test out so we can model what the benefits might look like.

Getting agreement on how the benefits will be worked out is hard. You need everyone to agree, and more importantly, to understand how it all goes together so they can repeatedly work out the benefit using the same calculation, month after month for as long as you decided to track it for.

That’s no small undertaking, especially for organisations starting out. Especially as many projects have multiple strands and multiple things contribute to the benefits.

What’s the journey like for benefits tracking in your organisation? Let us know in the comments what the biggest challenge is for you – I’m interested to see if you agree with me that it’s the setting up and creating the assumptions and rules for calculation, or whether there is something else that is the hard part.