Is a ‘Benefit’ a benefit until it’s actually used in practice?
When does your Benefit become beneficial?
Those of us who watch popular science programmes will have heard of Schrodinger’s Cat as it gets rolled out whenever someone mentions ‘quantum’. The mythical beast resides in a state of life/death that cannot be resolved until its box is opened and the poor cat examined.
I was looking through a benefits register recently and it struck me that all the familiar ‘benefits’ about the time saved, processes improved and knowledge gained exist in a business version of Schrodinger’s cat-box. You can’t value them properly until you open the box, see what state they’re in and put them to some use.
You can put the cat to 101 uses (or maybe all you can do is apologise and shield your face as it leaves the box). Likewise, the typical non-cash releasing time-saving has many uses and its value depends on what you choose to do with it and for whose benefit.
Until you make that choice, what you have is an asset. It’s potentially useful and in many cases, you can make a fair estimate of its value but it’s not a benefit. Very few projects claim that their ultimate purpose is to create assets. Benefits Management should be even more rigorous in defining its purpose. If we can’t get the benefits right, why should we expect other people to do so?
Image used within copyright guidelines, with thanks to Cristineagoe at English Wikipedia / CC BY-SA (undefined)
I’ve never been totally happy with the focus on benefits over objectives. It’s always felt incomplete. Benefits Realisation / Benefits Management doesn’t provide sufficient emphasis on purpose or strategy. Too often, benefits are rewards promised so people will permit, enable or justify decisions that have already been made.
The Benefits Map or Benefits Dependency Network ought to be a serious tool for selecting and delivering value from change. In many cases, it isn’t used at all. In others, it doesn’t produce the quality results that it could because people drift to the small tactical benefits (rewards to keep the users happy) instead of big strategic objectives.
The Goal Model is a type of Benefits Map. However, its scope is broader than benefits and it applies to more than projects, so I took ‘Benefits’ out of the name. By modelling Goals instead of mapping Benefits, I hope to keep the emphasis on purpose and strategy.
The Goal Model is a picture that shows the net of resources and their cause-effect applications between an initiative (process, project, programme, portfolio) and the strategic objective(s) to which it contributes.
Building the Goal Model
This is a general summary of what the completed Goal Model will contain. It’s a map of the cause-effect nets between the Concern(s) to be addressed and the Initiative that addresses it. It’s a picture of the ‘to be’ end-state. It doesn’t include any project or business change activity that gets you to this end-state. Between the Initiative and Concern are the Means, Ways and Ends that connect them. These are split into items such as Product, Activity, etc. with some example ways to categorise the items, e.g. people, process, technology Products or Balanced Scorecard Objectives.
Concern
The Concerns summarise the business environment, the context in which you operate, often described as the Problem Statement that triggers a change. They may be straightforward, such as a direct order from above, or more subtle like personal beliefs and mores. PESTLE is one method of categorising Concerns.
For the simplest change there may be only one Concern: “Our client demands that we do X”. You may face many Concerns. They will have to be sifted and prioritised if you are to manage them. Plotting them on the model is a strong visual way of appreciating what’s rational and feasible. The key Concern(s) sits closest to the Objective. The others sit further out, in decreasing importance.
Stakeholder
Stakeholders are the relevant actors, impacting and / or impacted by the Initiative. They may be individual people, groups or entire populations. The same stakeholder can play more than one role.
There is only one Client. The Client is the stakeholder who wants the initiative and pays for it. Sponsor or SRO are types of Client. They act for themselves, the consumers and influencers.
Consumers are the ones using the new initiative and / or receiving its effects, e.g. staff and their customers. They live with the results, but they may not have much direct control over it.
Suppliers give the Client what they want. Consumers acting in the design and implementation of the Initiative are temporary Suppliers.
Influencers is a much broader group of stakeholders, allies, adversaries and indifferents, some of whom play no practical role in the Initiative but who affect the client’s decisions. Consumers and Suppliers are groups of Influencers in that they can directly affect the Initiative. Your competitors are major Influencers.
Initiative
The Initiative is a bounded solution, the overall business change to be made, the programme or project. Naming it helps to set the scope and the boundaries. Its description must be concise and meaningful so people can understand what you’re making. The Client, as the ultimate stakeholder wants the Initiative for their own Objectives and Benefits. They permit the Objectives and Benefits of the Consumers, Influencers and Suppliers.
Ends are what you want to achieve. They are Outcomes that lead to Benefits that in turn lead to Objectives.
Objective
Balanced Scorecard is one way of categorising Objectives. Alternatively, you may have specific local categories, e.g. the organisation’s Five Year Plan. There may be separate sets of Objectives for each stakeholder group but the Client’s take precedence. These may all be shown in the single model or acknowledged and referred out to, e.g. Supplier’s profit is their worry and external to the Client’s Initiative.
Objectives should be SMART. Concerns might be nebulous, e.g. mission and vision statements, customer wants, etc. but Objectives must be pretty firm. If you are going to be judged on how well you achieved your Objectives, then you need an agreed way to measure them.
Benefit
Benefits can be split by the stakeholder group that receives them, and also by type (cash, non-cash, etc.) to inform the business case. A Benefit contributes to an Objective and comes from the Outcomes.
Disbenefits are the negative result or detriment to a stakeholder. Categorise them the same way as Benefits.
Outcome
Measurable outcomes are produced by the Ways. Outcomes may be resources created / released.
Activity
Ways are the Activities that consumers do and how they do them. They are business processes or personal actions that use the Means and produce the Outcomes. Note that they are not business changes. They are business activities in the new ‘to be’ state, after the change has been made.
Product
Means are the resources that consumers use. They are new or changed assets that enable the Ways. Means begin with the Product, something provided by the Initiative that is tangible like a machine or intangible like a service.
Feature
Each Product has Features. These are the specific things that make the Product relevant and useful in context. Typically, they may be speed, volume or relevant capability.
External
Some items may be marked as ‘External’, e.g. dependencies, Means and Ways that are outside the project’s control, or the Suppliers’ Objectives beyond the Initiative. They are shown in the model in an ellipse, so they stand out from the internal stuff.
Unlike some Benefits Maps, project work and business change don’t belong in the Goal Model. The Model is all about the ‘to be’ state and not the action that has to happen in order to get there.
Each Product in the Means will have Product and Work Breakdowns (or Agile equivalents) from the project that created it. It’s also likely that Activities in the Ways section will also have similar breakdowns for the business changes and assumptions around them. Behind each item and connection is a set of assumptions and risks. They can’t all fit in the model, but they are important things to consider and must be recorded somewhere. Putting them all in the Model will make it unusable. However, if you have one or two critical items that you can’t afford to ignore, then annotate your Model with some brief comments.
The Goal Model summarised
A picture paints a thousand words (more like 1500 in this case…) This is the Goal Model with explanatory notes. It’s worth study and it’s worth practice. Used well, it’s a terrific tool for making strategic choices and getting the value from your change.
For a deeper explanation of the Goal Model and how to build one, see: https://www.benefitofexperience.com/images/library/The_Goal_Model.pptx
Start with the end in mind – a good motto for life as well as work. It’s blatantly obvious but rarely done properly. 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 Florence Nightingale had set out just to make nursing a respectable job for the daughters of the lower-middle class then her achievements for patients would have been very different.
Here’s a sports analogy, a football manager’s side and tactics will adapt to the objective:
Win at all costs
Put on a show for the fans
Play for the league points
Pace yourselves for the next match
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. Too often, projects leave benefits realisation until it’s too late, i.e. at the end of the project. That’s why benefits should be managed from the start.
Some organisations demand a hard financial return.
Some want intangible improvements like satisfaction and image.
Usually, they want both. That’s when conflicting objectives throw a spanner in the works. That’s why clear objectives are crucial.
Florence Nightingale and other examples are available as phone lock-screen pics:
Dr Johnson said that patriotism was the last refuge of a scoundrel. In business, I think it’s Executives’ implicit willingness to pay.
Willingness to Pay is often cited as a method to set a monetary value on an intangible result like satisfaction. You get the relevant people together and ask, “How much would you pay for X?” Ok, it’s open to anchoring, group-think and a host of other errors and abuses but it’s not alone in this. Asking people what score (of whatever measure) they would give X has all the same caveats. And it’s definitely better to ask than to assume.
Unfortunately, projects don’t make much formal use of Willingness to Pay. It’s considered too subjective and tenuous a way to quantify the value they add. They don’t like asking, “What would you pay for this new capability?”, and they avoid financial measures for intangible results. Yet perhaps the ultimate ‘Willingness to Pay’ is the project sponsor who says, “I’ll buy the story I’ve been given.”
The shoddy project starts when a sponsor is given a sales pitch or a business case and says, “I’m willing to pay £X for the comfort / satisfaction / personal gain I will get from the story I’ve just been sold.” Then it’s disguised in a raft of ‘benefits’ to justify this decision. All the output measures and PR stories that the project will generate as it proceeds won’t hide the sad fact that it all hangs on a single decision based on an unconscious willingness to pay. A bit of sensible, honest analysis at the start can prevent this.
I work from the basis that a benefit is a result that a stakeholder perceives to be of value. Where I think we often go wrong is that we don’t identify (or admit to) the genuine stakeholders or understand their perception of value. Even the most shoddy and disastrous project will deliver some benefits. Unfortunately they will be the wrong benefits for the wrong people.
Typically, we believe our programme is so wide ranging, so culture-changing and so flexible that we couldn’t possibly put a price on the benefits. That’s when we should look at the stakeholders and make an honest admission of just who benefits from all the work. That’s when we might discover that the stakeholders who gain financially are the people being paid to do the programme. The people who gain satisfaction are the ones who sponsor the programme. As for the people being done to, the end users and customers, they’re not getting much out of it at all.
Let’s look at value. I believe that any benefit can be expressed in financial terms. It’s simply (simply!) a matter of currency conversion. That said, the accuracy and consistency of that financial value will vary widely over time and between situations and subjective opinion. Our personal willingness to pay varies with our knowledge of the market, our mood and the cash in our pocket. Multiply that by all the people involved in a business programme and financial value will always be a moving target.
This is why some people argue against hard cash statements. Within programmes and projects it’s possible to compare benefits by means of local weighted scoring systems. In the end though, these turn out to be a local currency. Be they Brownie Points, Beer Tokens or Corporate Achievement Indices, they are still a currency and as such, can be converted by market forces into other currencies just like £ to $.
Market forces set the value of products and services. The numbers drop out of the system. At least they do where the market is established. In creative and innovative projects the firm numbers just won’t exist so we have to stretch the error bars and invest a bit more to mitigate the extra risk.
The Public Sector has its own, unique problems here. Putting a value on human health, wellbeing and happiness in a political context is never going to be straightforward. However, there are ways and means. It is a matter of coming to an agreement on some common standards. Given the size of populations involved, even rough statistical estimates will do. After all, the accountants have been apportioning costs this way for years. Unfortunately, rational argument alone will not suffice here. Politics, pressure groups and personal agendas all get in the way of a common agreement.
If we accept that any common standards are going to be loosely defined to begin with then we can do something here. NICE know about the cost effectiveness of medicines, HSE can tell you how much to spend on avoiding death and injury. Ask DfE what illiteracy will cost someone over their lifetime.
A catalogue of reference benefits would be really useful. It will need both credibility and content though. I suspect the content exists in penny packets. Apart from the Civil Service examples there must be plenty of big firms’ economists and little firms’ Benefits Managers who’ve got their own ready-reckoners. I know I’ve got mine. That’s where the credibility falls down at the start because no-one knows what’s already out there.
So, if this article strikes a chord get in touch. Let’s see what we can create to make our Willingness to Pay explicit and give our programmes and projects a more rational value.
Meanwhile, as Dr Johnson didn’t say, “Implicit willingness to pay is the last refuge of a scoundrel”.
