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.