Benefits Realisation Management (Book Review)

– A Practical Guide to Achieving Benefits Through Change, by Gerald Bradley, Gower Publishing Ltd (Farnham, Surrey) 2010
ISBN 978-1-4094-0094-3, 352 pages, RRP £80 (review copy supplied free of charge by the publishers)
PragmaticPMO Rating:       ****

This well-written book starts by explaining the fundamentals of Benefits Realisation Management (BRM). It debunks popular myths, and explains why adherence to outdated beliefs can prevent organisations realising all of the benefits that could arise from change. However most of this “practical guide” is devoted to applying BRM to various situations.

First it covers how to apply BRM to projects and programmes (as early in the cycle as you can), then extends this to portfolios (projects or programmes applying BRM well are far more likely to deliver their business case benefits), and closes with implementing BRM across an entire organisation (run it as a programme and apply BRM to it to demonstrate the benefits). The text is peppered with real examples from the author’s extensive experience, and the liberal use of colour diagrams helps to cement understanding.

The book explains how best to apply BRM now if you are part way through the project/programme lifecycle, and also highlights the most important aspects to apply if you have limited time or resources (although this will not generate full returns).

It even has a section that summarises the entire book “in a nutshell” so that you can quickly find a summary of the principle you need and refer to the more detailed section of the book if necessary.

At an RRP of £80 this book is not cheap, but it has 300-odd pages of wisdom and insights to impart, some of which I have listed below to give you a flavour of what to expect.

  • Most current organisational change focusses on acquiring and implementing enabling technology (solutions looking for problems), without any subsequent steps to embed its use (business change).
  • Benefits are often derived to justify implementing some attractive capability. But benefits should be the reason sponsors commission projects. So begin with the end in mind. Don’t just implement capability; plan to use it to create value.
  • Starting with benefits increases sponsor buy-in and accountability, as the project flows from the sponsor to the implementation.
  • Stakeholder = anyone who could screw things up!
  • Stakeholders deliver benefits by changing their behaviours to use new capability, so work with them.
Benefits realisation
  • Sometimes organisations “realise” benefits by removing benefit amounts from future budgets. However this can leave the organisation worse off (e.g. reducing headcount without improving efficiency)
  • The Project Sponsor is accountable for benefits, but realisation of each benefit should be “owned” by an operational manager. This person  will be highly motivated if they are also the beneficiary.
Projects and Programmes
  • Projects are usually defined in terms of delivering enablers. The business case benefits are often forgotten once the project is up and running.
  • To focus on benefits rather than enablers, name the project or programme after the outcome to be achieved (e.g. Crime Reduction, Customer Satisfaction), rather than the enabling deliverable (e.g. CCTV network, Ordering System).
BRM-Specific Roles & Responsibilities
  • Benefits Facilitator – Educates, challenges and guides projects and programmes on BRM. Ideally independent from projects and programmes, and business- rather than IT- or PM-aligned. Exists before the project (contributes to the business case), and afterwards (oversees benefit tracking). A role for the Enterprise PMO (EPMO)?
Planning for Success
  • “Proper” BRM costs about 5% of total project costs, but has a VERY high ROI.
  • BRM practitioners are scarce, so use them where they will have maximum impact and return.
Application of BRM to Projects and Programmes
  • Mapping benefit/dis-benefit distribution across stakeholder groups can identify gaps and disparities. If no-one will own a benefit, is it real?
  • Categorising benefits by type (Definite, Expected, Logical, Financial, non-financial) and by change type (starting new things, stopping old things, doing old things better) can identify duplication, and help with consolidation.
  • It is tempting to value each benefit financially, to derive an NPV for the entire benefit set. Whilst possible, this can conceal assumptions (redundancies will result from higher productivity), and may produce double counting.
  • Measurement illustrates whether BRM is on track. “What you measure is what you get”, so choose KPIs carefully to encourage desired behaviours.
  • Set targets if the outcome is well defined, otherwise just track the measure and note the trend, with a view to informing future initiatives.
  • Start measurement (to provide baseline data) immediately the measure is agreed, or as soon as measurement is possible (to track trends).
Benefit dependencies
  • Holding workshops to generate benefits dependency maps scored with weighted paths helps to determine the order in which changes should be carried out, increases stakeholder buy-in to the changes, and gives a framework for realisation tracking.
  • Tracing benefits backwards to their enablers facilitates the creation of draft project briefs. If these changes are not already in progress, they can be costed and prioritised.
Structuring Change Delivery
  • Even if PMs only deliver enablers and outputs, they should keep an eye on benefits and the business case throughout the whole of delivery.
  • If programmes close on the completion of significant change activity, benefit tracking may suffer unless this is handed over to a function such as the EPMO.
  • Projects and programmes should be independently reviewed regularly to ensure the benefits are still viable. The project should only continue to completion if it is demonstrably worthwhile.
Relationship with Project, Programme and Portfolio Management
  • Benefits should be at the heart of PgM and PjM. For example, the Risks and Issues log should primarily contain risks to the realisation of benefits; Stakeholder engagement should focus on gaining benefit owners’ commitment to the realisation of benefits.
  • BRM can be used to maximise the benefits arising from change portfolios, and to assess the fit of proposed new Projects and Programmes with those already running.

How PMOs improve project governance

One of the benefits of having a Project Management Office (PMO) is that good governance reduces the risks of project delivery and increases its predictability. I will explain how this works in practice using as a case study a Portfolio PMO that I managed.

How PMOs improve Project Governance

The organisation ran a fairly large number of relatively short term projects to set up software systems for new distribution clients. These Client Onboarding projects were run by project managers, but without reference to a documented methodology or a central co-ordinating body. The timescales were often unrealistically tight, and projects would often either miss the due date, or would overspend on additional resources in order to meet the due date.

The tight timescales were usually imposed as a result of sales representatives making ambitious promises to clients without reference to the organisation’s capacity to deliver. Overspend to achieve the deadlines was authorised by the same sales representatives that set the deadlines, but the money to fund the overspend did not come from the Sales budget, and no assessment was made of the effect of the increased effort on the other projects under way.

We were tasked with turning this situation around.

We made the following changes:

  • We set up a “pipeline” list of all the projects likely to be started in the near future, and put in place an approval mechanism so that no new projects (including client onboarding) would be started without the approval of a Portfolio Board.
  • We developed a monitoring approach to enable the Portfolio Management Office (PfMO) to detect situations where a project Change Request may be required. A discussion between the PM and the PfMO would be prompted by the triggering of either of two indicators:
    • Finances: Actuals to Date and Estimates At Completion (EAC) were monitored against approved Budgets At Completion (BAC), with indicators to show when EAC exceeded BAC by more than a tolerance amount (expressed in both absolute and relative terms).
    • Schedule:Key project milestones were monitored, with indicators to show if these were forecast to be late against the baselined dates.
  • We measured changes from baseline on both a cumulative and incremental basis, to prevent large changes being concealed as a series of small changes.
  • We escalated the authorisation of Project Change Requests to an organisational level dependent on the size of the change (in terms of costs, time, and business value)
  • We devised templates to support PMs in requesting changes and determining the approval level required, and monitored numbers of approved and rejected changes (to identify “noisy” projects).

As a result, project changes were reviewed and approved at an appropriate organisational level, the highest of which included a full review of the change impact on the rest of the portfolio. In the space of a year, this (along with other initiatives) moved the Client project portfolio from a situation in which all Client projects missed either time or budget constraints (and around 15% missed both!) to a situation in which just 20% of Client projects missed time or budget constraints, and none missed both.

Even if you are cynical and take the view that implementing such a Change Request process merely sanctions the breaking of initial Time and Cost constraints, then at the very least it ensures this is done with eyes open and in the full knowledge of the impact on the project portfolio as a whole.

This approach effectively reduces the execution risk to the portfolio, and enables the Portfolio Board to consciously decide where to focus the organisation’s limited resources.