The Money Files

I really liked what Carlos Serra had to say at last month’s PMI Global Congress EMEA about managing the project management benefits processes and I have a few more titbits from his presentation to share with you today.

One of the things I find the hardest about project management methods is that often they specify what to do without actually giving you practical steps for how to do it. Stakeholder management falls into that category (and is one of the reasons I wrote my book, Customer-Centric Project Management). Benefits management is another. I think benefits management is so hard to codify because project managers don’t really know if it falls to them or the senior managers or operational teams or someone else, so it disappears through the cracks and isn’t given the attention it deserves.

Hopefully these bits of advice will help address that.

Tools for benefits realisation management

What practical tools have you got at your disposal for benefits realisation and managing those processes? Carlos discussed several:

• Benefits maps (Showing linked benefits, and maybe you could link this back to the task that delivers the output as well?)
• Dependency networks (I’m not actually sure what this is in the context of benefits – something to do with how projects or benefits link to each other? If you have a better understanding, let us know in the comments section at the bottom)
• Benefits profile or identity sheet (This describes each benefit and documents the way you will measure it, how much it should deliver in terms of monetary value, covers KPIs and so on. As we have work package documents or WBS descriptions, this is the equivalent for benefits)
• Business case (Doh! Of course this is the most relevant way of a project management working out what the planned benefits should be. It’s also influential when it comes to how the project is judged at the end and whether it is deemed a success, so you should definitely use this as the basis for establishing benefits)
• Benefits realisation plan (assigns a timeframe to each of the benefits)
• Benefits control sheets (I guess this is a way of tracking benefits when they occur and establishing whether they are in acceptable limits. I studied process control as part of Six Sigma and this smacks of something similar)
• Portfolio dashboard (So you can see everything on a single screen, although you have to set it up with the right measures first)
• IT systems (Carlos suggested a few that are specifically designed to help you measure benefits and to support the process. Personally I haven’t used any software tools that work in this way but it is good to know that if you are in a highly systemised environment and want software to help, the tools are out there)
• Health checks (A way of auditing your benefits and the processes as the project progresses)

Roles and responsibilities for benefits realisation management

Carlos covered the roles and responsibilities expected from a benefits realisation exercise within a company.

If you want to implement successful benefits realisation management in your own business then this is what you should look to get set up:

Programme and project governance

This covers the normal governance functions of any project management activity including having the work aligned to overall strategy. You should also make sure that you have the work prioritised and that there is executive leadership in place to support you.

Done by: Project Sponsor

Programme and project management

Here you’re looking to be able to deliver the required outputs, ensure everyone knows what success looks like and manage stakeholders’ expectations with that in mind.

Done by: Project Manager/Team

Benefits ownership

Finally, you want someone to take responsibility for owning the benefits when they are delivered. They are the people who receive the outputs and whisk up their magic to turn outputs into tangible business value.

Done by: Project customer

All this strikes me as vastly similar to the rest of the project management techniques that we have available to us. That’s good news, because it means that benefits management is not difficult or scary and that project managers have the transferable skills to be able to put all this into practice already.

The presentation reassured me that much of what I am doing to ensure my projects deliver tangible benefits is good and solid practice. The theme of value ran throughout the Congress and it’s great to see that (finally) project managers are waking up to the idea that delivering value is not something that someone else does.

Prioritising projects is pretty easy when you can look at the business case and see which one is going to bring you the most return financially. Whether you’re looking at sales, profit, return on investment or some other cost benefit analysis the great thing about money is that it is tangible and numbers-led. So the comparisons are straightforward. Many execs would opt to work on the projects that bring in the most financial return with the least effort. Simple.

Why projects don’t use financial prioritisation

Organisations don’t use financial methods for prioritising for several reasons, including:

• They don’t know how
• There is no mechanism to measure costs or benefits
• Budgets only include external costs, not resource time or internal costs
• There’s no need to because projects are funded centrally so money “isn’t a problem”

In reality, projects don’t just deliver financial tangible returns. Some projects would struggle to put any money-related measures down on paper. They simply don’t compute that way.

In those situations it is a much harder job to compare projects and choose which ones to work on first. Prioritisation becomes more of a shouting match: the manager who shouts the loudest wins. You also risk priorities changing quickly because someone had lunch with someone else who is influential in deciding these things and suddenly your resources are pulled and given to another team.

Without clear prioritisation, it’s impossible to establish which project is the most important. Let’s look at ways that you can prioritise projects when it’s not about the money.

Other ways of prioritising

By the need to stay in work

The main category of project that I’ve worked on that does not have an easy monetary value is the ones that revolve around staying in business. Examples are:

• Regulatory projects
• Compliance projects
• Legal projects
• Projects to address a crisis
• Projects to maintain the status quo e.g. moving from one software tool to another, maintaining infrastructure or networks etc
• Projects to enhance the status quo slightly e.g. moving to a new version of software, upgrading telephony infrastructure

Projects that allow you to continue to operate should be considered high priority. However, they might not be urgent if you can put the work off a bit. So that’s a YES the project must be done but a NOT NECESSARILY NOW for the work schedule.

By the value added

If you can’t compute value in monetary terms, this categorisation of project becomes quite difficult to measure and therefore compare. Narrative is good: have the discussion and thrash it out but use objective questions to force ‘enthusiastic’ project sponsors to fully justify where the value will be added.

Typically you’ve got two choices:

• Adding value to an existing asset/process/product e.g. new features into existing products, process improvements, staff satisfaction/engagement (as staff are an asset).
• Creating new value e.g. launching a new product, introducing new working practices.

You can see that there is likely to be some overlap – is a new process adding value to existing team members or creating new value? – but I think you get the picture.

By easiness

Why not do the easy projects? They can fit in around the larger, more strategic pieces. To be able to prioritise the easy work and slot it in to the programme, you need to know how easy it is going to be. Subjectivity comes into play here as well, as you will have to take a relatively educated guess about what’s achievable for your business.

If you have done something similar before, you have clear goals, the skills are in-house and the risk profile is low, then that sounds straightforward enough for me.

These three prioritisation options gives you different ways to look at the portfolio of projects and align the work with strategic priorities. If it’s easy and adds value, do it. If it’s important to keep the business functioning, do it. If it looks really hard and you won’t get much value from it, ditch it. It’s not rocket science.

As with anything that is not based on numerical, statistical analysis, you have to be careful that people don’t game the system. Ideally you want to create a questionnaire that is completed by an objective party in consultation with the sponsor. Give each criteria a ranking and then calculate the overall total. Then you can put your projects in order and work on them as they reach the top.

Project prioritisation is something that you have to go back to regularly. The order you set for your team today won’t be the same in a few months as business priorities will have shifted. The NOT NECESSARILY NOW projects may be at the top of the list then.

I’d be interested to hear your thoughts when you have no way of using monetary criteria to prioritise projects. How do you do it?

In this video I talk about the 5 things that you should consider before you start a new professional deal or relationship with a vendor.

Earlier this month I wrote about Carlos Serra’s presentation on benefits realisation at the PMI Global Congress EMEA in London. He had some great practical advice about managing the benefits realisation process, the highlights of which I’ll share with you now.

Carlos talked about the four things that are required in order to actively manage benefits realisation. These are:

• Planning the benefits
• Reviewing and measuring benefits
• Realising benefits

An organisation-level benefits strategy, of which the first three items form part.

The benefits chain

Carlos explained the benefits chain. It’s the reason why you need a benefits strategy and an organisational level, and that underpins everything to do with benefits realisation. It’s actually quite complex, but it looks a bit like this.

He didn’t share what a benefits realisation strategy would look like but said that the formal strategy defines the process and sets the organisation’s approach for benefits realisation. Part of the strategy is a detailed exploration of the other three elements.

Planning the benefits

In this step you decide what the expected outcomes should be and write a clear definition. You also get the business case approved if it hasn’t been already. This is important because it gives you the reference to identify project success at the end.

Having clearly defined strategic objectives are essential to being able to realise any benefits and create value for the business.

Review and measure benefits

You and the team need to acknowledge that reviewing and measuring benefits is not a one-off activity. You’ll have to find ways to continually do this, so create mechanisms that are repeatable or you’ll be reinventing the wheel all the time. Decide how frequently you are going to be carrying out reviews and make sure you are resourced appropriately to do so. I would go for once a month, but it really does depend on the type of benefits you are expecting to see. With something like sales, you can track these monthly but if your project is delivering improved employee satisfaction you may be better off measuring this with a quarterly survey or something even less frequent. It’s impossible to provide a hard and fast rule unfortunately.

At each review take time to look at whether the outcomes are planned and expected and in line with the business case predictions.

Then communicate the outcomes to the stakeholders. They have a vested interest in what is happening and can play a valuable part in helping correct the course if you aren’t seeing the benefits you expected. Many businesses, Carlos said, stop tracking so they never know if they are successful or not. You’ll have to decide when to stop and when those benefits become ‘business as usual’.

Realise the benefits

‘Realisation’ is a set of activities that ensures the project outcomes are fully integrated and monitored after the closure of the project. It isn’t done, Carlos said, by the project team, but in my experience project managers have a large part to play in making sure this part is set up correctly, even if they don’t manage it day to day. Realisation is the organisational work required to make sure the benefits recorded in the business case actually happen.

As you can see, the benefits realisation management process is both part of the project and not part of the project. The early steps around strategy and process definition are either the work of the sponsor or PMO, as are the final parts around realisation. The bit in the middle is where the project manager and team can add value.

On a programme, things might look slightly different as programmes (and portfolios) often include an element of BAU work, such as keeping a project deliverable operational while waiting for the rest of the projects to be delivered and a final handover to operational team members at an appropriate stage.

Either way, the project manager has to play a full part in this so it’s important to fully understand the process to know where you fit in. It helps you ask the right questions:

• Has the business case specified benefits?
• If not, why not?
• What are you expecting this to deliver and how will we know if we’ve met those expectations?
• What benefits tracking are you expecting and how long are we going to do it for?
• Who is responsible for the bits I am not responsible for?

And I’m sure you can think of others.

I really enjoyed this presentation, especially the section on the tools you can use to manage benefits. That’s what I’ll be writing about next, inspired by Carlos’ presentation.

In this video I discuss the three reasons why you should write a business case for your project, even if you work in an organisation that doesn't normally pay much heed to that kind of paperwork.