In the world of programmes and projects success is hard to achieve and often hard to prove. When your measurement of success isn’t hard cash but people’s health and happiness, life gets even more complex. Programmes struggle because we dive into the complexity without stepping back into the basic principles that show the key things they are meant to achieve.

People often talk of chains of cause and effect, however these are more usually cause – effect nets. It’s rarely the case that A links to B links to C in nice neat straight lines. Here is a diagram that shows in very basic terms the connections between means, ways and ends.

Simplest model, the cause effect net between the proposed solution and results

Concerns are things that make us take action. They can be instructions from above, practical problems we want fixed or things we believe ought to be.

The Initiative is what we will do within feasible limits. It has to have boundaries to keep it manageable. This stops us boiling the ocean, eating the elephant, creeping the scope.

We take appropriate resources, use them well and achieve good results for the right people (for whatever we believe are appropriate, good and right in our specific context. After all, decision making is a subjective exercise).

Let’s bring this closer to home for those of us interested in projects and information. Here’s a generic model for any information based project.

An information project, a less simple model

There’s a bit more detail here. The Means are split into Products, the broad topics and their particular Features. For example, Input will cover the processes of getting data and Economy and Currency mean we want the Input to be cheap and up to date. At the other side of the diagram, the Ends are split into Benefits for the various stakeholders and strategic Objectives that the organisation wants, categorised here by Balanced Scorecard.

I haven’t yet found an information project that can’t be overlaid onto these boxes. The connectors may move and not all the boxes will be needed but the general concepts will apply. We get, change and send information in ways that highlight its relevant attributes (cheap, quick, etc) so it is used to best effect for the chosen stakeholders.

Let’s make this generic diagram a bit more specific. Integrated Care Records is a public sector topic that’s pretty popular at the moment so here’s a hypothetical case that ought to work as a broadly applicable example.

Data driven integrated care, a bit more specific

Here, Service Leaders are the people who control the care, e.g. commissioners of services or budget holders. Who they are will depend on the scale of the programme or project in question. Service Providers can be the institutions delivering services, down to individual staff members and again this depends on scale. The Service Users are mostly patients who get direct, personal impact from the care provided. There may be broader societal that impact lands on the general population. They’re often listed as ‘The Community’, ‘The Taxpayer, or ‘UK plc’.

It’s still pretty generic. What happens when we concentrate on one requirement? Someone who commissions care believes an integrated care record can bring more empowerment to service users. The next diagram shows a) why they believe this is a good thing and b) how the record will empower the service user.

A simple model, integrated care to empower service users

There’s a whole separate discussion to be had on who a project’s actually for and what they really want from it (see Six Dumb Questions). Looking at the objective of ‘Less demand on resources’, it’s pretty clear that the benefit recipient here is the commissioner who’s paying, not the Service Users. We would usually expect Service Users to get some value out of the project but they’re not the reason why this one is happening. The model shows clearly what end we have in mind. This then tests the reasoning of what a good result is and how we will prove it. In this case, wanting less demand on resources means that we will want the Service Users to be more empowered to look after themselves, not more empowered to band together and demand more out of the NHS. The project will have to be planned and managed to ensure this.

One great thing about this sort of model is that it helps you spot the unintended consequences, “If we do this then we get that. But we really don’t want that so let’s step back and see where it went wrong.” Iteration works and the third version of the diagram is usually far better than the first.

We have created a simple model of a complex project. It gives us the opportunity to agree that it’s the right project for the right reasons. It’s certainly better to have the arguments about the project’s purpose at the beginning than argue about its fitness for purpose (which was never really agreed) once most of the money has been spent. When someone asks what it’s all for, we have the makings of a sensible reply.

Try this on one of your own projects. It should trigger some interesting debate.

Benefits in bite-sized bits…

Agile delivers time-bound pieces of functionality. It has the flexibility to adapt to circumstances and lessons learned from previous time boxes.
Benefits Management can work well in an Agile setting but it may have to run to keep up

Flexible targets

Traditionally, programme management sets more flexible targets than individual projects do. The scope and timescale of programmes are such that it’s clearly recognised that the world is moving on as they happen. Programme objectives can still be SMART, they are just a bit more fluid than project ones.
The use of iteration, feedback and performance management (‘so far, so good’ benefits tracking) in programme benefits management helps keep the programme on track to deliver value, even when that value is emergent and unforeseen.
The same approach can be scaled down for an Agile project. We can start with a SMART objective that’s defined by its boundaries, e.g. benefits of no less than X, delivered by time Y in location Z. The Benefits Realisation Plan will be coordinated with the Agile timetable and benefits will be staged with the project deliverables.
Where Benefits Management starts running to keep up is in the need for constant review that fits with the Agile timetable. The developers meet regularly to assess what they achieved last period and how it will affect the plan for the next. This has to be controlled by the business’s assessment of the relevant benefits realisation. Every change to the plan must be weighed against the question, “Will it maintain or enhance the objective?” The business will consider:
• Will the change realise our desired benefits?
• Will it take us off-track?
• Will it offer new opportunities that we must take?

A developer’s flash of inspiration takes seconds, “I can tweak the code and give you X”. The appraisal of X is a significant exercise in quality control. The business skill will be in allocating the appropriate time and effort that trades off the new value you may get from changing the project specification against the cost and delay of assessing that value and making the change.
It won’t be an easy task and it will require some mental stamina to keep up. However, it’s a task that has to be planned to ensure that your project delivers benefits and not just capabilities.

A strategic wrap around tactical Sprints

Sprints begin with Product Owners describing their requirements and prioritising what gets done next. MoSCoW (must, should, could, won’t do) selection of what they want and the order they want it in sets the Product Backlog for the developers to concentrate on in the next round of work.

---

It’s about delivering product increments, which suggests that you’ve a fair idea of what the end product should do, you’ve got a partially working model and the developers are adding that quality polish. It all seems a little tactical.
Where’s the assurance that the optimum choices are being made in the first place? Where’s the strategy? Benefits-led Agile development puts a strategic wrap around tactical Sprints.

Every change to the plan must be weighed against the question, “Will it maintain or enhance the objective?” The business will consider:
• Will the change realise our desired benefits?
• Will it take us off-track?
• Will it offer new opportunities that we must take?

A developer’s flash of inspiration takes seconds, “I can tweak the code and give you X”. The appraisal of X is a significant exercise in change control. The business skill will be in allocating the appropriate time and effort that trades off the new value you may get from changing the project specification against the cost and delay of assessing that value and making the change.
It won’t be an easy task and it will require some mental stamina to keep up. However, it’s a task that has to be planned to ensure that your project delivers benefits and not just capabilities.
Use tools to help you choose good things fast. Some are psychological, ways of thinking that get you past the traps we all fall into when we see shiny things that we want. Others are more practical, devices to add rationality and logic to your choices. The more you can structure and program the administrative decisions, the more mental effort you can devote to the creative stuff. Here we concentrate on the two key points, knowing where to start and knowing when to stop.

The Subjective Start – Starting with the End in Mind

The purpose behind any course of action has a direct and significant effect on the way it is undertaken. The reasons why affect the ways we go about things. If Nelson had gone off to Trafalgar simply with the intent of using up his budgeted stock of gunpowder then he would have fought a very different battle from the one that actually took place.
The same applies for any project, the ends affect the means and ways. Projects talk of acceptance criteria, the things that decide when the project has ended successfully, a sort of, “No-one goes home until…” Define your acceptance criteria in terms of objectives and benefits before you start. Don’t install the kit and then wonder what to do with it.

The Subjective Stop – Endgame

There will come a point when the analysis has to end and the decision made, where you stop asking, “Why” and start acting. The trick is knowing that you’ve reached the right point at which to stop.
Starting with the end in mind requires a clear and simple description of what that end will be. We can affect the process through the way we describe the end state. Only a very confident (or deluded) chess player would describe the endgame in terms of where the pieces will be. Yet we are often very granular in describing our programme objectives. Too often Output Based Specifications run to hundreds of pages with sheets of individual requirements, desires and benefits, a pound saved here, ten minutes there, etc.
This sort of mass objective twists individual priorities and breaks down any common purpose. It’s like playing chess as a team with each player responsible for a single piece. Each heads for its assigned position and sits there without contributing anything to the whole or supporting its team mates in winning the game. That’s why clear and simple objectives are crucial.

Psychological tools

There’s some excellent stuff on the ways that psychology affects economic decision making in Daniel Kahnemann’s book Thinking, Fast and Slow. For now, just be aware that these things exist. Recognising them is a step towards compensating for them.
Prediction:
• Optimism Bias
• Strategic Misrepresentation – Flyvberg
• Anchoring
• WYSIATI – What You See Is All There Is, Kahnemann
• Correlation, not Causation

Delivery
• Illusion of Control
• Confirmation Bias
• Framing
• Regression to the Mean
• Endowment Effect

Picking the next Objective

The Idea Test is a way of testing new ideas against your strategy, goals and context. Before running away with a brilliant new idea, it needs to be checked to see how good it really is and how well it fits with who we are and what we do. It contains three checks to take us from hypotheticals to practicality.
First, we have to understand the context in which we operate.
Choose to change – A new idea, Base Hypothesis. At this stage, this is probably a loose statement of, “Why don’t we…?”
First filter – test the Hypothesis against the context to see if it’s relevant and feasible. Should we do it, can we do it?
Turn the Hypothesis into a Goal. “Why don’t we do X?” becomes, “We will do X, because…”
A Goal / Objective is something with purpose. Start with the end in mind. Then optimise the value of the goal. Determine the benefits required, expected.
Second filter – do the benefits validate the objective? Is your grand plan sensible? What’s it worth and who gets the value?
Next, plan to realise the ends. You want to do it, now work out how you are going to do it.
Third filter – is it practical and economical? Do the benefits outweigh the costs? Do you have a rational and sensible solution that will actually work in practice?

Practical Tools

This is where practical tools come in. If you can program as much as possible into the decision making processes then you save thinking time that you can put to better use.
One of the best practical tools is the Benefits Dependency Network. It is one of the key tools in the Benefits / Value arena. It shows the chains of cause and effect between what you use, do and want, i.e. between the means, ways and ends.

In the Sprint you work towards creating the product increments, the capability that serves your purpose. You make the Means that serves the Ends. Benefits-led Agile is the approach that governs the ideas selected to feed this line.
If new capability is discovered then we have to check that it’s useful. New Means may give us new Ends, a new Objective. So you test the idea, select or discard the Objective and move on.
The BDN sets the strategic boundaries. It determines the limits of what’s desired and the scope of the solution. The Agile development is the tactics that control how the strategy is delivered.

Requirements capture

Scrum and Product Backlog has an assumption that the Product Owner has already done the analysis to select the best product increments to go in the Backlog. What have they used to make their MoSCoW selection? Where is their sense of proportion?

The Benefit Profile form has a lot of headings and can look intimidatingly methodical (or just plain boring) at first sight. It works well when everyone remembers that the tool should fit reality and we don’t force reality into the tool. It’s not so much the detailed list as the things that go into it. They are cultural and fit the enterprise in question.
The aim is to get the right thinking into the requirement, “I want these results (i.e. benefits) and I think this piece of functionality (product increment) will deliver them in the context in which I operate.” We phrase the requirement as Ends from Ways from Means, starting with the End in mind. Having drawn the BDN, we already know what we want (at a high level) and how the connections work. This form puts a bit of rigour and detail into the requirements.
It gets us away from the instant answer of, “I want this solution, the reasons are self-evident but hard to express”, “It’s a no-brainer, I just can’t put it into words”.
By describing each item in the Product Backlog using the same form and process, we can compare our options in a rational way by seeing their value relative to each other. The cultural context of the enterprise will have its own significant impact here. Some groups will go totally anal in the detail they complete. If that works for them, fine. Others will be fast and loose. Again, it’s whatever works. Where both types of group gain from the same process is that they’ve filled in the boxes in the form, in the right order, using a rational mindset and so have both raised the quality of the choices they make.
Put rationality into MoSCoW
Use the Benefit Profile to capture requirements:
• Who’s it for?
• What do they want to see happen?
• How big a deal is it?
Fit the tool to reality, make it work in context
Choose Ends from Ways from Means

Things to watch

Preference for action, something must be done. This is something. We must do it.
Incubators, great so long as you resource them properly and let them fail effectively if they have to. Know when to pull the plug and don’t blame the failures. Don’t even call them failures.
Effective failure means you don’t bet the farm. Have a position to fall back on if you have to.
Benefits-led Agile, being rational but not rigid, keeps your tactical Sprints within a strategic wrap.

Picking ‘Good’ Benefits

Rather than concentrate on the methodology, this page describes the output of Benefits Management. The processes, tools and forms are there to help you produce good benefits. They are not ends in themselves. Instead of getting bogged down in the paperwork we must understand what we actually want to achieve.

---

First, we have to agree what a benefit is.

A benefit is a result that a stakeholder perceives to be of value.

The key points are stakeholder and perception. Who is the specific stakeholder under consideration? Is it patients in general or a Hospital Trust’s Finance Director? What sort of things do they perceive as valuable, improved clinical outcome, a better experience or hard cash in the bank?

The programme’s objectives can be viewed as the SRO’s benefits. The SRO is the programme’s primary stakeholder. Their objectives are the results they perceive to be of value, the reasons why the programme must go ahead.

Within the programme, good benefits start from good objectives.

Good Objectives

The purpose behind any course of action has a direct and significant effect on the way it is undertaken. The reasons why affect the ways we go about things. The objectives we choose validate the action we take so it’s vital we start with the right objectives:

Programme / project objectives must relate clearly to the organisation’s business drivers and strategic objectives

Objectives should be SMART and stretching, don’t de-scope into something short-term or easily measured

Objectives must be strategic. “We will implement on time” or “We will work well together” are given statements of how the programme will operate, not valid descriptions of what it will achieve

Keep to a few key objectives. Too many are unmanageable and will conflict with each other.

Good Benefits

Benefits provide the evidence that our objectives are being met and our programme justifies its existence:

Benefits are identified up-front (at least in high-level terms). They are why you are doing the programme, not why you did it.

Benefits are tightly linked to objectives, if not then the programme is being run for the wrong reasons

Benefits are not simply treats to win stakeholders’ commitment

Describe the benefit in verbs; improve, reduce, stop. It gets us away from picking project deliverables and functionality

Each benefit has an Owner who is responsible for its delivery

Each benefit has one Recipient, the stakeholder or stakeholder group who can say that the benefit has been realised. You can’t prove a benefit that is spread over multiple stakeholders

Benefits should be SMART and stretching, don’t de-scope into something short-term or easily measured. Set a target or predict the value for a successful benefit

Set a baseline. If you don’t know where you started from then you can’t say how far you got and you can’t prove it was worth the effort

Keep to a few key benefits. Each one will have a significant amount of work behind it. A hundred benefits may look good in a business case but they’ll never happen.

If you’re not sure of a benefit, keep asking the ‘so what?’ questions until you know who it’s for and why it’s important

Look out for the ‘usual suspects’. Make sure the benefits are appropriate for your programme. Not every project has to improve patient care.

Iteration works, the third pass will look much better than the first one.

Just because it looks like one doesn’t mean it is one

Are your networks fit for purpose or are you drawing them out of superstition?

Variety is (not always) the Spice of Life

Cargo cults were first seen in the Pacific after WWII. Islanders watched US forces build airstrips. Then planes arrived full of cargo. The war ended, the airstrips closed and the planes stopped coming. Logic suggested that if you build airstrips, the planes will come. And so the islanders copied as best they could in the vain hope that they could attract new planes with more cargo.

A quick search on “cargo cult management” will bring up a raft of articles on how the same logic gets applied in business circles. We make assumptions and copy without a proper understanding of the original situation. And then, like the poor old Pacific islanders, we wonder why the planes won’t come.

A few years back I worked on a programme that introduced BM into parts of the NHS. Within a couple of months we saw that people were drawing their Benefits Dependency Networks in a variety of ways. Some of this was due to the tools they had. Visio obviously offered more depth than filling cells in a spreadsheet and the diagrams would look very different in style, if not in content. But it wasn’t just the tools. People adapted the BDN to their own understanding of the method and their personal preferences. At the time I viewed it as the evolution of local dialects, a natural progression and not a major issue. Indeed, possibly a good thing.

Now, I’m not so sure. Maybe natural selection isn’t yet happening as it should and the weak are thriving. I’ve started to come across a few BDNs that can’t perform their function. Ones where the links are all right angled connections that overlap so it appears that everything in one column connects to everything in the next. Others have objectives in the middle so the chain of cause and effect isn’t rational and the cart is pulling the horses. There are people out there who are mistaken about the quality of their method and the subsequent benefits they choose to deliver. They are not doing quite as well as they think they are.

The APM specific interest group wrote a pamphlet on embedding BM in the enterprise. I think it’s time we all worked on embedding good BM in the enterprise. I don’t want to go as far as mandating one methodology. I’ve got my own (superior, naturally…) way of doing things and I don’t want to give it up. Many other people will feel the same way. However, I think there’s scope to use our formal and informal networks to share good practice on the fundamentals. When people work in a vacuum their practices change over time without anyone checking if they are still valid. Before long the minor dialect change risks turning into nonsense that’s performed more out of superstition than business value.

Imagine your programme is pickling a shark. Do you know what the shark is worth?

This is one of those analogy things so please suspend your disbelief and work with me. It should all make sense in the end. I’m going to apply some ideas from the World of Art to the world of intangible benefits, the ones that don’t result in an easily counted bag of cash.

---

As a Benefits Manager, part of my job is to work out if / why Plan A is the best use of our scarce resources, what makes it better than Plan B and all the other plans we could spend on. This isn’t helped when there is no common understanding of Plan A’s added value, how much its benefits will outweigh its costs.

Part of the reason we struggle to value any intangible product / service is because we don’t think about the market where it’s bought and sold. Our programme is going to create something of value, a solution that realises benefits worth more than its costs. Think of it as our Masterpiece. It’s a work of art, not a commodity. Its value will be set by a select few stakeholders in the art market, not by hundreds of traders in the stock market.

It’s bespoke, complicated and unique. Other programmes’ outcomes may be similar, but they are not exactly the same. It’s not so much one barrel of oil out of millions, it’s more like Damien Hurst’s big dead shark in a tank of formaldehyde. It is considered an exemplar of artistic skill (by the people who like that sort of thing). It’s made from relatively cheap materials, so there’s no scrap value worth talking about. If it succeeds, then it’s a priceless art. If not, it’s worthless junk. It’s original and outside any established school or style so there’s no benchmark against which to compare it.

Like the dead shark, it could be worth £millions, but it will depend on who you ask and how you ask them. Pricing your programme’s intangible benefits is like selling a work of art, so let’s look at our stakeholders in some different art markets. Our market for the Masterpiece consists of four stakeholder groups:

• The one client who wants to buy the Masterpiece and has the funds to pay for it
• One or more suppliers who want to build the Masterpiece
• Consumers who will use the Masterpiece or the system that delivers it (e.g. our staff and their customers)
• Influencers who have opinions about the Masterpiece and the alternative ways to spend the money

The value of the Masterpiece will be determined by these four groups. It’s going to sit at the balance point between each group’s understanding of value and their influence / power over the others. The market is where they come together to set the price. So, from an art world point of view what sort of markets could apply here?

The Private Commission

This deal is done in private. The client wants something personal and has money burning a hole in their pocket. They find a supplier (artist) they like, and a deal is done between them. No-one else is involved. There are no consumers to work the system between client and supplier and no influencers to affect the price. There is only one benefit, the client’s happiness. The client says that their satisfaction is worth the price they paid.

The Art Gallery

This time, the client may not have a single supplier in mind and goes shopping for an artwork. The consumer is the gallery owner who introduces artists to buyers, brokers the deal between them and takes a commission from the sale. The supplier is our artist with an established reputation for high-class modern art. Influencers are a small community of gallery owners, art critics and competing art buyers with money to burn.

If it’s not a private sale, say the client is buying something to put in a public gallery, then influence expands to people with an opinion on how the client is spending their public money. Or at least, to those people whose opinion the client cares about. The client acts in anticipation of what these stakeholders will think and do.

The client still decides the value, but that decision is heavily influenced by their understanding of the competition. “I want it because I want it. If I don’t pay £££s, then I will lose it to someone else. I’m comfortable paying £££s. And if it’s not my money, I think I can justify my decision to the press, public, auditors, etc.”

The Online Auction

This time, the sale has been advertised world-wide so many more influencers know the art is for sale. Everyone can see the value change in real time as the bids come in. The client still decides the value, but this time they’re better informed. “I paid the market rate for it (which was a lot) but I’m comfortable paying that price.” Or “Bidding stopped much quicker than I expected. I got a bargain…or maybe everyone else knows something I don’t.”

The Street Market

Our supplier, the artist decides to ditch the bourgeois art world and take his work to the people, so he hires a market stall for the day and sets up his masterpiece.

On a busy Saturday there are lots of people passing by who will see his work, but no motivated clients with huge budgets looking for art, maybe the occasional tourist with a bit of spending money. There are certainly lots of influencers around who are happy to voice their lay person’s opinion on the merits of modern art and this piece in particular. Assuming it actually sells, the price will be nowhere near what the gallery could have got.

Even though we’re talking about the same work of art, the different markets involving different stakeholders come up with vastly different values. The same applies to the intangible benefits of any project / programme. The stakeholders, their beliefs, needs, expectations, resources and power all affect the value they put on the results.

The Programme as Art

Very few Benefits Managers get brought in at a programme’s inception to advise on the wisdom of the investment. Usually, the core decision has been made long before the costs and benefits get analysed. The programme sponsor / Senior Responsible Officer, the client in my story wants something big and striking, they’ve cleared the space for it and they’re ready to spend. They’re toying with buying the business equivalent of a pickled shark and want to know if it’s worth the asking price.

What market forces will affect their decision? Think about the context of the programme and the stakeholders involved, its governance and evaluation arrangements. Who are the four stakeholder groups and how do they interact to determine the programme’s value?

It could be a privately commissioned piece where the sponsor has a requirement to meet and the cash to spend. They make a deal with the supplier and don’t involve anyone else. They decide if it’s all worthwhile. This is only going to happen for the small stuff within spending limits. Unless you own the company, there will be rules to stop you making big private deals.

A gallery sale involves the supplier’s sales team in bringing sponsor and supplier together, “What you need is a big dead shark. And we know just where we can get you one.” Once again, the sponsor sets the value. This time though, including the sales team will add a bit to the cost and trim the value.

Most likely, it will be an auction sale, a job put out to tender within procurement rules. More stakeholders are involved, but they’re all professionals and specialists. They may set boundaries, “You cannot spend more than this. That supplier is not acceptable…” Governance and evaluation influence the choices made and so affect the value. It’s no longer the sponsor’s sole opinion.

The street market may be a supplier with a solution in search of a problem, “I’ve invented this wonderful app, who wants to buy it? Anyone?…” More likely, it’s supplier and client working together to spread the cost, risk or blame for a choice they’ve already made. “See, it’s not just us. We showed it to everyone and lots of other people thought it was good and wanted a bit of it.”

At the end of the day, the purpose of Benefits Management is to lend an air of rationality to the exercise of power, and all benefits are a result that a stakeholder perceives to be worthwhile. When it comes to the intangible stuff, there are no simple right or wrong answers, and stakeholder perception is everything. We bring in the rationality by considering the key stakeholders, how they interact and the context in which they operate together, i.e. their market. And hopefully, we get them to agree on a reasonable value for their benefits.

In accounting terms Goodwill isn’t having nice thoughts towards other people. It’s what you pay for the intangible stuff. When you buy a business you don’t just pay the book value of the tools, stock and all the things you can see and touch. You also pay for the staff’s brains, the brand, the established customer base, the intangibles.

Individually they’re unquantifiable, priceless. Mrs Jones is indispensable and everyone loves the company logo. Together, you know exactly what they are worth because you’ve just paid it.

---

So why don’t we do this in our business cases? It would give us a consistent way to benchmark programmes and work to a common hurdle rate or value for money ratio. It might save a lot of grief and gaming around the enabling and infrastructure programmes where the direct identified benefits are less than the costs. It might also cull a few pet projects where saying we don’t need to count anything hides the fact that there is nothing to count.

Usually, we garner the benefits for a typical public sector business case in the following order:

• Cash-releasing, the hard savings that we can tick off against the costs
• Non-cash, the efficiency and productivity gains described in money terms, not quite as good as real money though
• Societal, the stuff outside our budget. “Do it online – save a bus fare!” again in money terms
• Quality, just possibly the big strategic reason to do the project in the first place. Health and happiness, that sort of thing

I dare say the private sector cases aren’t much different.

All those quality benefits sitting in a table at the back of the business case. We can’t possibly price them but they must be big because they’ve a weighted score of 852/1000, whatever that means.

We know what the programme has to deliver in RoI or VfM to meet the hurdle rate target it has been set. We have quantified the tangible benefits (cash, non-cash, public). So, the shortfall is the price of our intangible quality benefits. That’s the goodwill, the overall value we put on all the hard to measure stuff to justify our investment.

Once the quality benefits have been costed like this, we have a way to benchmark our programmes. We can set a common hurdle rate. We don’t need different rules where the mundane stuff must make a profit but the innovation doesn’t have to break even. Instead, we can see how crucial the quality benefits are to each programme. How big is the goodwill relative to the quantified benefits and the costs? Is it a figure we can live with? Are we comfortable that our quality benefits will be sufficient to justify it?

So, what gets in the way? Goodwill is the programme’s willingness to pay. To find it, you get the relevant people together and ask, “How much would you pay for X?” It’s open to anchoring, group-think and a host of other errors and abuses but it’s not alone in this. The programme cost estimates will be going through exactly the same set of biases. In this case we’re not asking, “How much would you pay?” but, “Would you pay this much?”. A much more closed and leading question.

The accuracy and consistency of the price will vary widely over time and between situations and individual opinions. The market we work in isn’t perfect. The analogy here is more the Stock Market than the Supermarket. With stocks and shares things are much more fluid and the prices are nowhere near as stable. So long as we treat our intangibles more like shares than cereal there’s no reason why we can’t put a price to them though.

I suspect that what will really get in the way is its transparency. It opens up judgement calls to scrutiny, which is not the greatest motivator.

Does anybody want to give it a try?

“We’ve agreed what sort of benefit it is, now we are simply haggling over the price.”

If you look hard enough, there are no qualitative benefits. How should we measure the benefits we create for our customers / service users? If the new system will improve lives, how much of an improvement will it be? Where’s the breakeven point that shows if we’ve spent wisely?

---

Instead, I see business cases that say this stuff is qualitative and shouldn’t be given a money value. If it’s to be measured at all then it will be in a table of weighted scores buried in an appendix where no-one will give it much thought. There we can compare quality benefit A against quality benefit B. What we can’t do there is compare quality benefit A with cost £C.

So how can we ever tell if the investment is worthwhile? When we make comparisons between our quality benefits we create a currency for them. A is worth more quality points than B so within our business case we have a local currency of ‘Quality Points’.

That currency can be converted to any other and at some point we can match our Quality Points for £s. I know that it’s not real money. We won’t end up with a bag of cash. What we will get is a sense of scale, a feeling for just how relatively important these benefits are. We have a means to compare our local project against all the others.

The exchange rate depends on the market involved. I accept that the market is going to be small and imperfect. It’s going to be the stakeholders in the portfolios around our project. It will be their willingness to pay for all the various options they face that will determine the relative value of our benefits.

When our projects take this approach, the portfolio doesn’t have to choose between your weighted score and mine without knowing how we picked our weights. Their choice won’t be perfect but it will be a bit more rational and fair.

“Would you pay £50 for this benefit?”

“Certainly”

“Would you pay £50,000?”

“Of course not”

“Then we’ve agreed what sort of benefit it is, now we are simply haggling over the price.”

How do you choose between options when you can’t put a price on them? When you are comparing the multiple criteria in your decisions, what currency do you use? How can you make it ‘common currency’?

You’re building a case to invest and you use points to prioritise the results we want to see and the extent to which each option will deliver them.

---

It’s a good way to add some rationality to the business case but it might not paint the whole picture of how important your project is in relation to everything else you have to do.

Money is tokens of relative value. It is the middle-man in a barter system. I swap the stuff I do / make for money that I then swap for stuff you do / make. So, if money is just tokens then it’s basically no different from gold stars, Brownie Points or whatever currency we use for quantifying the intangible things we seek.

In my imaginary Bureau de Change I can convert any currency to another once I know the market rate. Sadly, we work in imperfect markets that make it difficult to convert between these currencies. I can ask what you would be willing to pay but willingness to pay is subjective. It is limited by the players involved, the context in which they operate, even the time and place where they make their decisions. It’s too hard and costly to do so people don’t use it in their options appraisals.

However, willingness to pay in £s really isn’t much different from assigning point values to options. The points will also depend on people and circumstances. We just feel more at ease with points because they are not real money.

Maybe it’s because we’re not playing with real money and can’t be held to account for the points we ‘spend’ that we inflate the importance of the quality options. When we pick up to 100 points on our options, we are only ranking them against each other. Nowhere does it say that the best option is only worth 50 points in the whole scheme of things.

An alternative is to use money. Instead of 100 notional points, allocate the actual discretionary spend budget. How much free money do you have to splash out on something new? If you have £50k to spend then decide how much out of the £50k each option is worth.

You are now starting with a sense of proportion. It’s now real money, not imaginary tokens. If you’ve got £millions to play with then it’s serious. If you’ve only got a couple of hundred then stop sweating blood over trivia.

Once you are comfortable with the sense of proportion then there’s another piece of reality to bring into the mix. That’s the matter of comparing what you can spend on this project against what you are spending on everything else that you could do. Determine your total discretionary spend. Think about all the new stuff you want to do as well as this particular project. If you’ve got a formal costed list, all well and good. If not, just go with your gut feel.

Take your total discretionary spend figure and split it between this project and everything else. Say you have £1M and this project isn’t so big or important, so you split it £50k for this and £950k for everything else. Write at the top of all your options appraisal workings (put it in the document header if you must): “This project £50k, everything else £950k”

Use this as a reminder of your project’s relative worth before you even start appraising the options within it.

When you’ve done all this and quantified your options in terms of £s, remember that it isn’t real money and it can’t be put against your costs. At the end of the day, it’s all still a comparison of relative value using tokens. This time though, the tokens are more realistic and the final decision made with closer acquaintance to real life.

If you want to do that then you have to do the full SRoI, focus group, willingness to pay exercise to make a fair comparison between costs and benefits.

Benefits Management and Change Management are complementary methods. They support each other and the whole is greater than the sum of its parts. Both are force multipliers in any change initiative. They are levers that leaders apply to the resources they have so they can achieve more with those resources and meet their objectives.

Both are force multipliers. They are not painkillers to take away the leader’s pain.

A story, adapt it to your own situation

Sir Harold Acme was in pain. He wasn’t sure of the cause but he was certain of the source – that consultant’s latest wheeze to inspire the staff, “Let’s all eat together in the canteen”. It was either the gruel itself that was poisoning him, or the sheer annoyance of sitting with the plebs, but the combined gut ache and throbbing temple were getting too much. He staggered to the medicine cabinet, saw the wide selection of painkillers on its shelves and grabbed the nearest.

An hour later, the pain was less, but still there. He returned to the cabinet. Sir Harold was wise enough not to overdose on the stuff he’d just taken (but not wise enough to check the NHS website for advice on combining painkillers), so he grabbed the next nearest packet and gulped a couple down.

Half an hour later, he was back to his normal dyspeptic miserly self, reading the latest report on his struggling cost-cutting programme. The objective was straightforward, a 10% cut in staffing cost, but it wasn’t happening. You find inspiration in the oddest places, and gazing at the medicine cabinet, the light bulb in Sir Harold’s mind flickered into life. There were two pains in his programme, and he could take two painkillers to fix them both.

First, the 10% cut hadn’t cascaded down the company properly. Half his managers hadn’t realised (or were in denial) that their teams had to go. They had made no plans, nor costed any savings. His forecast benefits were nowhere near the promises in the business case. They were all hopeless guesswork anyway.

Second, even where plans had been made, the changes weren’t happening. The staff couldn’t or wouldn’t get a grip of the new technology to make them more productive so he could sack their colleagues.

Two pains and he could fix both. Combined pains required combined painkillers. That consultant had colleagues she was always trying to sell to him, a Benefits Manager to sort out the promised savings and a Change Manager to see that they got delivered. He hit the intercom, “Tell that blasted consultant that I want to see her tomorrow…lunchtime, in the canteen.”

Six months later and progress has been mixed. The hired-in Benefits Manager has managed to persuade enough people to own enough benefits that his Benefits Register is full enough to satisfy Sir Harold that the programme appears on track. With his nervous repetition of, “That’s not a benefit” and “I wouldn’t have started from here” he’s not made many friends though.

Teams have downsized and productivity has improved overall. However, there are a few patches of resistance (or genuine misunderstanding of the new kit). Attendance at the regular ‘Off on your New Adventure!’ celebrations has become mandatory. Anyone who calls the Change Manager Tigger faces instant dismissal. At least Sir Harold’s remaining managers are happy that they can’t be blamed for any of this.

The moral of the tale

How much of project management exists in the hope of taking away a boss’s pain? Stuff needs to be done, but it’s difficult, new, takes up valuable time and effort. We can’t be everywhere and know everything, so we create roles and outsource tasks for other people to do it for us.

Sometimes, that’s good and sensible. Sometimes, it’s just buck-passing. Usually, it’s somewhere in-between:

“We need to change, but I’m too busy running the shop. Let’s get a Project Manager.”

“I’m too busy implementing the technology to worry about how it will be used. Let’s get a Change Manager.”

“I don’t know if it’s making a difference. Let’s get a Benefits Manager.”

“I can’t get anyone to own the business case benefits. Let’s get an Exec Sponsor.”

“No, I’m too busy running the shop.”

Benefits and Change Managers are good when you bring them in as subject matter experts to assist the organisation’s leaders. A Benefits Manager who’s brought in at the start will raise the quality of your business choices. They will tell you what good benefits should look like. They will map out how your programme will achieve them, and they will monitor its progress as it gets there. A Change Manager will plan a transition from old ways to new that works for your people. They will educate, advise and motivate them to make and accept the necessary change that gets you to your chosen end-state.

Both are force multipliers, support functions like Finance and HR. You don’t expect Finance to spend your money or HR to hire your team for you (I hope). But you do take their professional advice so that you can spend and hire wisely.

The same should apply to Benefits and Change. Neither of them should exist so leaders can abdicate their responsibilities. Benefits and Change Managers are not there to replace leadership. If you think you can outsource the removal of your pain, you will be disappointed.