Why map benefits? And other uses for a Benefits Dependency Network

A Benefits Dependency Network (BDN) (or Benefits Map) makes your projects more successful. Not by itself, but because of the way it makes you focus.

A BDN is a visual representation that shows how activities (projects) generate benefits, and how these benefits contribute to bigger benefits. As part of a Benefits Management Framework, it shows how individual projects and programmes contribute to the strategic objectives (and the success) of the organisation.

BDNs show, on a page, interdependent projects; how they combine to create outcomes and business change; and how this creates benefits which deliver business objectives (goals).

When to use a BDN

A benefits dependency network (BDN) is the fabled “programme on a page”. It’s a useful summary, explaining why we are doing this project / programme, and what success is. BDNs can be developed for individual programmes (showing all the projects in that programme) and for a whole portfolio (showing the projects and programmes in that portfolio).

Developing a BDN should always be a collaborative effort. You may think you know everything about your programme or portfolio, but you need other points of view, the points of view of the delivery team (those doing) and of the business (those done to). The formal benefits mapping process identifies gaps in knowledge and understanding that may not be obvious in a verbal or email discussion. Ideally, get everyone in a room together, although it’s also possible with modern cloud software and conferencing to work remotely.

There are two types of benefits map – those used to define the problem and the options for solving that problem, and those which plot the likely consequences of a change initiative, project or programme. When you use these in combination, you hope that the benefits realised by the programme you choose to implement will match as far as possible the problem you identified in the first place.

Define the problem

A problem can be positive or negative. An example of a positive problem is to take advantage of a new market or launch a new product. An example of a negative problem is the need to cut costs or manage a restriction on trading such as legal or regulatory requirements. The point of defining the problem is to determine whether it’s worth investing to find a solution.

One method to use is the Investment Logic Map (ILM).

1)     What is the problem (or opportunity) that is driving us to consider a new investment?

2)     What causes it, and what impact does it have? With this knowledge, should we redefine the problem, e.g. the cause of the obvious problem is the actual problem?

3)     What difference can we make? Is the difference (the benefits) big enough in value terms to be worth the investment?

4)     What are some options for making that difference and realising those benefits?

An ILM may be a precursor to a Business Case, presenting the case for investment. It should include options and may include a recommendation. In the diagram below, the numbers refer to the steps listed above

For example, Step 1 Define the problem:

A product may be uncompetitive compared to rival suppliers. Initial thoughts on Step 2 effects are that a product line is not selling, production line is idle, and space is taken up in the warehouse by unsold items and unused stocks of parts. But the causes (also step 2) of it being uncompetitive could be that:

a)      The production line is inefficient,

b)     The product is poorly designed for manufacture,

c)      The whole production site itself is inefficient,

d)     Site fixed costs (heating, lighting, maintenance, senior management) are inappropriately weighted so as to favour some lines, making this line appear to be expensive. 

Identifying potential causes could result in a re-definition of where the problem lies. GO back to Step 1 and, for example if the problem is (b) above, get an industrial designer to redesign the parts for efficient manufacture in these quantities.

Conversely, a BDN might identify that we can’t influence (step 2 effects) the problem. If we’re trying to sell outmoded smartphones with a manufacturing cost higher than the realistic sell price, consider mitigation – shut down that product and divert resources to something else.

Why identify the likely benefits (step 3)?

Identifying the scale of the benefits gives a start point for investment. If the benefits added together are worth ￡100 million, then a ￡100,000 solution is likely to leave many benefits unrealised (“on the table”) – a 1000:1 ratio is unlikely to be realised so the investment will probably deliver far fewer benefits. Conversely spending ￡80 million on a solution with the same reward, taking into account risk and uncertainty, may not be cost-effective.

Going around the steps 1 – 3 until the problem is defined and the benefits assessed, step 4 presents some options.

The BDN allows an investment board to make two decisions:

• Whether to pursue the resolution to the problem, or mitigate / manage / ignore the problem?
• Which option(s) to examine in more detail and potentially invest in

If this looks like an Outline Business Case (OBC), that’s because it is. It’s also a useful structure for providing the basis of a Full Business Case (FBC).

Alternatives to ILM

We’re used to reading from left to right. As you will see below, many BDNs go from initiative (change) to benefits to objectives from left to right. But from right to left they read

? from investment objectives

? to the benefits that measure progressive realisation of objectives

? to what we need the business to look like

? to what needs to change

? to what we need to do to bring about that change

In other words, if you read a conventional benefits dependency network from right to left, you’ll get the same effect as ILM.

Benefits mapping the other way => Consequences of a change initiative

BDNs are often drawn up once the decision has been made to invest in a particular project or programme – ideally the benefits from this investment will be more or less the same as the benefits needed to solve the initial problem.

We’ll use an example of investment in a high-speed rail link, since this is in the news at the moment:

A facilitated workshop will quickly determine the business benefits of the investment. If the Investment Objectives were pre-assigned from the Investment Logic Map, the investment board can see if the business benefits are likely to fulfil the investment objectives.

This reveals one of the advantages of using ILM and BDN together. If you create a BDN from right to left, then it’s tempting to leave all of the steps in place and assume that your initiatives on the left hand side are correct and will lead to the business change, benefits and strategic investment that you first thought of.

If you create an ILM and then a BDN, the two are separate and you can follow the logic chain across the “consequences” BDN to see if they really do lead to the original investment objectives. If they don’t, then go back to the initiatives. Benefits maps are relatively quick and inexpensive, certainly much less expensive than cutting ground and laying ballast (to continue the High Speed Rail example).

How to create a BDN

In the author’s opinion, the best way to create a BDN is in person, in a room, on a wall, with post-it notes (other moveable pieces of paper can be used). The group can be anywhere between 5 and 100 people, although it’s often better to aim for no more than 20. Each major stakeholder (organisations investing money, staff groups, end users, project delivery team, customers, board) should be represented.

It’s best done over 2 – 3 hours, although if time is really constrained then a good facilitator can get people to create a passable BDN in 30 minutes.

The BDN applies as a minimum to a whole programme. A programme may contain a number of projects, which may be listed; alternatively, some people skip the projects or initiatives and only list business changes (what will happen as a result of the projects or initiatives). 

The aim of the workshop is to agree on common goals (objectives) and common projects (initiatives), define some of the benefits (many of which will be specific to a single stakeholder), and understand other stakeholders’ benefits especially where they may conflict - a benefit for one stakeholder (e.g. profit for the supplier) may conflict with the benefit for another stakeholder (lower price). 

Members of the investment board, and the original sponsor, should take part. With the expertise in the room, they may realise that the problem isn’t what they thought it was. They will also become committed - if they aren’t in the room, they may dismiss the BDN and changes to the programme because it wasn’t what they first thought of. The programme delivery team and representatives of the business should also play an active part - we’re going to ask for them to change, and the best way to get change is to get involvement.

If facilitated well, a BDN workshop will complete the BDN and define measures for the benefits and objectives. If they aren’t defined in the first workshop it’s common to define these in a second workshop after people have had a chance to digest and send corrections. 

Updating a BDN

A BDN is a living document, it should be available to all stakeholders to review.

Each project, each business change, benefit, and strategic objective, has defined measurements at defined time intervals, and these measurements need updating. When a project incurs further costs, the information should go into the project “card” in the BDN, which tracks whether the project is on track.

Delays to a project will have knock-on effects. Benefits dependent on that project will also be delayed. This should be illustrated as a delay (or reduction within a set timeframe e.g. 5 years from go-live) in forecasted benefits. This information is used for scenario planning, answering questions like:

• “If we disinvest/ cancel that project - how much would it actually impact on benefits?”
• “How much are we losing as a result of this delay? How much should we invest to make up for the delay?”
• “If circumstances have changed, what do we need to change?”

The project delivery team or business as usual staff can update lead indicators and benefits as the information becomes available. This is enormously motivational.

A BDN isn’t an end in itself: it facilitates communication, agreement and understanding of different points of view. Different approaches and different points of view create new and effective solutions which improve the chances of success.

Different types of BDN

We’ve looked at basic BDNs for clarifying a problem and tracking a solution. In reality, there are more ways to develop a BDN, each with their merits and challenges. The different approaches focus on different aspects or illustrate different information on the map.

We’ve already looked at the Investment Logic Map above. Here are some more. Note that the column headings (the words used) are often quite fluid – there isn’t a hard and fast set of names.

Just to emphasise the differences, I’ve also used different tools to draw the maps.

Cranfield (sometimes called Cassandra Benefits Model)

The Cranfield (sometimes called Cassandra) benefits model is the one that most people are familiar with. It’s normally laid out in columns, with a specific type of “card” in each column. There’s flexibility about which columns you have, there’s certainly flexibility about the names you use to head a particular column, and some forms allow you to have cards which lead to other cards in the same column (e.g. a project which leads to other projects, or a benefit which results in another benefit, before it contributes to a business objective).

This map is drawn in Amplify?.

Cranfield Benefits maps show a logical chain from project, through project outputs or business changes, to benefits and then objectives.

If the objectives change, perhaps because of a change in the market, demographics, pricing, exchange rates, regulatory or other change, then we can immediately see which projects are affected by this change. So rather than reviewing all projects whenever there’s a change (which usually means that none get reviewed because it’s too big a job), we can focus our reviews on a few. A review reveals whether a project could be stopped and the resources (money, staff, etc) more usefully deployed elsewhere.

Gerald Bradley’s maps are a variation on the Cranfield model, showing more information such as % contribution between different ‘cards types’, or resource used, or progress and completion.

Results Chain (developed by John Thorp and Fujitsu)

The Results Chain?, first published in The Information Paradox in 1998, was developed to support defining, evaluating, selecting and managing complete and comprehensive programmes of change. It’s designed to include changes to the business model, process, people, technology, and organizational structure.

It develops a set of “road maps” that support understanding and proactive management of a programme throughout its full economic life cycle; expected (and often unanticipated) benefits are realized, and value is created and sustained.

It’s based on four core elements of a programme: outcomes, initiatives, contributions, and assumptions, and the links between them. Developing the Results Chain involves a number of facilitated workshops with the key stakeholders. Skilled facilitation is key here as, while the resulting “map” is very useful, what is more important is the process of discovery, understanding, consensus and buy-in that occurs during the development of the “map”. 

An example of a ‘worked-up’ Results Chain, covering a number of projects in a programme, is given below.

Results chains can handle a lot of information, although it would take practice to interpret.

Benefits Value Model

A benefits value model is an approach to identifying, structuring and communicating benefits. It’s designed to illustrate the relationship between new capabilities, operational benefit and strategic value, without the complex spiders’ web type models, of many benefits management approaches.

The information behind the map

Any of these maps are a compressed view of the project, in 2 dimensions. Each initiative has quantity (3rd dimension) and timescale (4th dimension): a profile of what will be produced or achieved by what time, and how much it will cost. Each benefit has a forecast and a measure of success. Some will have more than one measure, for example the number of users migrated from bricks-and-mortar shop to buying online with a click, and the average value of a week’s purchases per customer. 

If a BDN tried to show every piece of information on the one map, it would become very complicated. Bradley models usually select a particular piece of information to show on the map e.g. % contribution or % complete. However, a BDN created using suitable software allows the user to drill down into a particular card to see e.g. costs over time, or benefits forecasts and delays to realisation as a result of the status of the contributing projects.

Dependencies

The key aspect that many BDNs illustrate is dependencies - which benefits will be affected if a project is cancelled or running late. If the benefit can’t start to be realised until the project or a phase of the project is finished, then there will be a Finish-to-Start dependency. We’re familiar with these from Gantt charts (except that Gantt charts rarely include benefits).

We’ve discussed above that when initiatives such as projects are linked through the benefits to the strategic objectives, if circumstances change a strategic objective, we can immediately see which projects need to be reviewed to understand how they contribute now that the strategic objective has changed.

The other side is to see how changes to the initiative (e.g. a component running late) will affect the outcomes and benefits.

One of the challenges in benefits management is that if a project is running late, then we’re still going to get the benefit, it will be a bit late.

With a suitable tool, we can set a window of time (e.g. 5 years) and measure input of resources, and return on investment, within that window of time. Using this approach, an 18-month delay to a particular project will cause an 18-month delay to those benefits that are dependent on that project. The result will be that part of the benefits will be pushed out of the 5-year window. Whilst this is much more difficult to assess on a spreadsheet, because eventually the benefit will be delivered, with a specialist tool, the 5-year window will show the delay in a very obvious way.

The illustration below shows how the forecast differs from the plan, because of a delay.

What If?

Scenarios allow us to try out the effects of different delays to save money, in order to find which saving has the least impact or even if it’s worth going ahead with the full cost programme because the returns in the form of benefits are too valuable.

Conclusions

A Benefits Dependency Network is an enormously powerful tool to:

• Gain consensus on the main objectives and initiatives
• Understand the benefits being sought, both benefits common to all stakeholders, and benefits specific to one or a few stakeholders, and what success means
• Scenario plan around the impact of changes in priority, changes in investment and the effect that these are likely to have on benefits realisation. Decisions on optimum value can then be made.
• Understand the impact of a delay or cancellation, and decide what remedial action is warranted.

A good BDN can drive much greater success, because the information is accurate and timely and the delivery team can make better decisions.