Why Benefits need FOCUS!

The issue of benefit realisation is long standing and in my opinion is one of the prime reasons there is a pernicious perception of high rates of project failure. If there is no benefit to be relaised why invest the expense and effort in delivering change, yet despite many efforts to be smarter at identifying the benefits and managing their realisation, we are nowhere near where we need to be.

The fall back position is a focus on the products of change ie the systems, the new structures and processes, or even worse just on activity, meetings, reviews, workshops etc, to justify the allocated resources. I have seen this happen too often to be happy.

One of the reasons is that it is quite complicated to understand the mix of benefits financial and non-financial, tangible and intangible, discrete and synergistic (ie relying on the connected delivery of some other change or event). It does not fit into an neat, data centric framework that works in the "industrial" management systems most compnaies have and is frought with uncertainty and risk.

There have been a number of well thought out and rigorous frameworks for Benefit Realisation Management, that, while mandated by methodologies and some public sectors, have failed to engage the real business leaders and become an administrative exercise in their own right.

The old maxim that if it is not measured it does not happen is true, but before that if the motivation and understanding is missing then it does not even pass the starting line. Often in the white heat of trying to mobilise change the business glosses over the failings in our understanding of the benefits and then once they have initial approval try and forget the promises and hope others will too.

In the light of this challenge I don't proclaim to have the magic answer to the whol problem, but I have a suggestion for a simpler language and approach that will aid and enhance the initial and subsequent engagement with stakeholders. It is something I have called the Benefit Function, goes by the acronym FOCUS and use the slogan

Benefits need FOCUS!

The benefit function is a framework that helps prepare and plan for change, manage the con-
sistency of the components and assess the outcome. It is defined as


where

B is the realised benefit;
O is the opportunity to deliver benefit, eg increased revenue, improved productivity, better client satisfaction, etc;
C is the capability required to satisfy that opportunity ie what do you need to meet the opportunity;
U is the utilisation of that capability - how will the business embrace and use the new capability; and
S is the additional synergy or synergies that can be generated

The main element of the benefit function is a product; if any one of O, C or U are poor or
absent then the main part of  the function will also be poor or absent.

S, the synergy element, is the bonus that happens when this change works with one or more
other changes, but only then.

Why do we need a Benefit Function?

A project, and the project manager, are usually focused on creating an agreed capability, with no one really managing the other elements.

Programme managers or programme offices may have some handle on synergies, but these are often lost in the heat of project delivery. The development of programme management has certainly placed greater emphasis on benefits and, within that, a whole field of Benefit Realisation Management (BRM) has grown up.

This is usually based on benefit maps that  link benefits to enabling changes and through them the relevant measures in order to evidence success. The effort required is not trivial and requires a different mindset to that of project management. Despite this, it is still a project manager who is often considered responsible for delivering benefits.

In the UK, BRM has found greatest traction in the public sector through the mandated use of standard methodolgies (Prince2 and MSP).  In the private sector take up is poor with benefits often used to justify a project at inception then conveniently forgotten; the focus instead moving to managing cost.

In my experience, and despite claims to the contrary, most business managers and project sponsors understand “doing things” far better than “creating benefit”.

How is the Benefit Function used?

Successful and lasting change must be based upon a framework that is easily accessible to a wide stakeholder community and one that can quickly be seen as both pragmatic and effective, rather than difficult and ineffective.

The primary use of the function is to recognise that there are four discrete components that need to be owned and managed. We can then explore them in sequence, cycling back for if we need to, until the picture is clear.

• Opportunity relates to a need that exists, which, if satisfied, will result in a benefit. A benefit can be considered as any positive outcome, as perceived by a stakeholder.  Ownership of an opportunity must fall into the domain of“business”.

Usually this falls to the sponsor who needs to understand and be able to articulate the value (scale, scope and probability) of the opportunity as well as any influencing factors. The sponsor should also determine how satisfaction will be determined or measured. This will not always be financial, but should require real evidencing.

Responsibility to monitor and review the opportu nity, reflecting changes back to those concerned with governing change and/or building capability,also falls to the sponsor.

• The satisfaction of an opportunity will be delivered by a new or changed Capability. This may be a the new organisation (people, process and/or systems) required to satisfy that need ietake advantage of an opportunity. Responsibility for the detailed design and delivery of this capability usually falls to the project manager and requires a clear understanding of the sponsor’s vision, even as that changes.

Responsibility for changing the design and plans for delivering the new capability falls to the project manager.

• Utilisation is the use of a new or changed capability to satisfy the identified opportunity. Only when it is used can we realise the benefit. Utilisation needs to be planned, both the acceptance and transfer from the project into business as usual (or BAU) and the subsequent use within the relevant business process(es).

It is this latter element that is often lacking or poorly performed. It requires an identified and specific benefit owner. This person is not the project manager, but must work with the project if full benefits are to be realised with confidence.

The monitoring of utilisation will use the measures specified by the sponsor and may last well beyond the life of a specific project. There needs to be a body responsible for this; often it falls to a programme office.

The planned utilisation may need to adapt as the world changes, but there needs to be a steady eye on the expected results.

• The last element is Synergy and is the additional benefit derived from delivering more than one change in a way that one augments the other. This depends on both changes happening, the control of which falls outside the direct control of sponsor and project manager and needs separate oversight. This falls into programme and portfolio management where responsibility for the optimisation of total benefits rests.

Synergy by definition is not the reason to justify a capability build. If it appears to be the case then they two changes are probably merely two parts of the same change.

And at Programme/Portfolio level?

Well the same model will work, summing individual benefits, but removing any double counted
synergies.




where

PB is portfolio or programme benefits
B is a realised benefit;
S’ is an adjustment for any double counted benefit.

I have found that using language such as this is far more effective with most business managers and sponsors. By all means adapt it for your own environment.

If you are more interested in benefits and this function I gave a webinar for the Enterprise Management Association that can be found here.