Benefits Management for Programmes, Projects, and Related Work

Benefits do not happen by themselves - they need careful planning, delicate management, and rigorous reporting. They need a midwife.

Just as a midwife should be involved before, during, and after the birth to ensure the health and well-being of both mother and baby, the benefits manager needs to be involved at key stages to ensure that benefits are both realistic and realised.

And here is a difference: the midwife is not usually present at conception. A benefits manager should be.

Steps of Benefits management in programmes, projects and other related work

The previous articles in this series were about portfolio management. There is no such thing as a stand-alone project. Every project contributes to the direction of an organisation or alliance of organisations. If it does not – why are we doing it?

I recently joked that most projects happen because a salesperson wants to sell something; too many people in the room nodded and agreed with me. The benefits manager should change this dynamic. To begin at the beginning: benefits managers should be involved in designing and understanding the big driver for the project – the need or opportunity that it answers.

BS 202002 Clause 8.3 Define the need or opportunity.

Clause 8.3 of BS202002, and the first step of Figure 1, illustrate that the start point for benefits management is before the start of a typical project, before the options or business case. It should begin with the need, defined by the gap between current portfolio forecasted benefits and expected benefits, in combination with the organisation’s strategic objectives.

An example: if we want to improve school attendance, there will be a few different solutions that work either in concert or individually. The first step is to define the problem, the size of the problem, the value of making a difference, and the likelihood that the organisation can make a difference. This will determine whether it is worth investing resources in taking the idea through the next few stages, including the definition and valuing of benefits, the outline and full business cases.

Sometimes the original aim needs redefining (the organisation cannot make a difference). A project to “reduce truancy” might identify that there are a few different reasons for young people to not attend schools, and that the term “truancy” is inappropriate. The benefits manager might identify the sizes and costs of various aspects of non-attendance at school problem, and pinpoint where investment would be most effective in addressing each aspect. This focus ensures that organisations direct all investment and activity toward achieving their strategic objectives, through strategic benefits aligned to these objectives.

This definition stage naturally leads into the planning stage:

8.4 Plan benefits and contribute to the business case

Many approaches to benefits management have broken this planning stage up into more than one stage because traditional benefits management focuses almost exclusively on this planning stage. For example, the UK Infrastructure and Projects Authority (IPA) has a five-stage model, with two stages (Appraise and Select; and Plan to Realise: Define¹). APMG similarly has five practices including Value, Appraise, and Plan³ (Jenner 2014). Both pairs of stages are subsumed into Clause 8.4, the “plan benefits and contribute to the business case” stage in BS 202002².

Success in this planning stage requires stakeholder engagement. Benefits mapping sessions are part of stakeholder engagement, although we will describe benefits mapping in a later article. Benefits mapping in a group provides the opportunity for stakeholders to build off each other’s understanding. This point is often lost when stakeholders are contacted individually or are represented by members of the project team. Figure 2 illustrates an example of a benefits map using the results chain approach.³ Note the use of a timeline to show when activities occur and when benefits (one of the types of outcomes) are likely to be measurable.

There is only a finite amount of resources to work through benefits management, so the criterion for benefits prioritisation (which benefits should we analyse in more detail) should be “Which benefits will have the most impact on subsequent decisions?” Not necessarily the biggest number, but the benefit most likely to influence decisions. These are the ones that we do more work on.

There are no projects where benefits management is not useful. Organisations often use meeting regulatory requirements as an excuse to avoid benefits management. However, once they know the cost of compliance, they can decide either to comply with the requirement and pay any fines, or withdraw operations from a regulated marketplace. Benefits management informs that decision.

A benefits map (of any type recommended in BS202002) illustrates the causal link between activities and benefits. Changes to activities will result in changes to the realisation of benefits. The benefits map might show that some activities proposed by the design team have little impact on realising benefits. One should question the reason for including these activities. The benefits map might show that the activities proposed will not realise the benefits required – this might require revisions to the activities proposed. It is always cheaper and faster to spend more time on planning and get the planning right than to find shortfalls after spending all the money.

This planning stage should output a few costed and valued options (including a confidence level). From this, an investment panel can decide which option to take forward, and the composition of the project.

It is possible (using Hoshin Kanri) to calculate the “value” of each of the activities that contribute to the benefits, as a quick method for understanding the impact of delays or cancellation of any of the activities. How accurate the results of this calculation are depends on confidence in the initial information.

Now the project can begin.

8.5 Recommend decisions to optimise benefits realisation

Many organisations do not involve benefits management during project delivery. This is a mistake. Benefits do not happen by themselves; every decision to change the activities, whether changing the delivery date, product specifications or communication channels, can impact the benefits realised positively or negatively. Since benefits are the reason we do projects, the impact of any alterations on the benefits should play a part in these decisions.

I have had feedback from project leadership teams about the use of benefits management during delivery. Benefits management is (amongst other things) a communications tool - by talking to stakeholders about benefits for them, many of the obstacles to successful project delivery melt away. A little bit of communication pays dividends, and benefits provide the focus for communication.

We can use lead measures to check whether the project is going in the right direction and is likely to realise the main benefits. It is better to know while there is still time to change the project. Lead measures are a measurement of interim change which increases our confidence in the future benefits realisation.

8.6 Monitor Benefits Realisation

After handover; and this applies even when handing over interim deliverables, it is important to remind the users or recipients of a change about the behaviour and process changes they need to make to realise benefits. This requires tact and diplomacy. However, the main tool in our toolbox is reporting.

People go to work to do a good job. The reason so many people get disillusioned at work is that important things are not measured or reported – they cannot tell if they are making a positive difference. We benefits managers, can measure the realised benefits and show people whether their actions are achieving the desired results. Even though they must measure to create the data for those reports, they will love us because now they can tell their children and grandchildren “I did a good job this week”.

This is not creating a whole lot of new work. We do not need to measure until the benefit is realised. Instead, we should measure until we gain some level of confidence in the amount of benefit that will be realised. We might not get it all, or we might get some emergent benefits which justify bonuses (and everyone loves a bonus!) way beyond what we could have wanted in the first place, but we will only know about the bonus if we measure and report.

Conclusion (#Call to action)

In the same way that projects have a beginning, a middle, and an end and then handover, benefits have an inception, planning phase, delivery of change, and benefits realisation. Traditional benefits management is focused on the planning phase: all four phases are important to achieve benefits realisation.

The project leadership team should monitor changes to benefit forecasts carefully during project delivery and use this to inform adjustments to the project (whilst there is still time to make these changes i.e. before the project is completed) to improve benefits realisation. Typically, we will not get exactly the benefits we plan for, for a variety of reasons including incorrect assumptions, changes in the environment, and changes in the stakeholders. However, by reviewing the impact on benefits of each decision, we are likely to get at least as much benefit and identify emergent benefits which multiply the total benefits to the organisation and stakeholders.

Reference Literature