How Simplistic Accounting Destroys Business Benefits

Banking benefits from projects should be a ‘no-brainer’ – yet it seems to be a big problem.

Indeed, fewer than one-third of organizations worldwide even attempt to measure the benefits from their project investments.  And those that do, tend to adopt approaches that decrease rather than increase the value of their benefits…

In this TOP-ThoughtLeader we explain one of the most common “benefits management” approaches – and why it destroys the very value it is intending to ensure.

Then we outline TOP's approach and explain, not only how much easier and simpler this is, but also how it actually ensures that you do get the business results and value you intend from the project.

Note: “Benefits Management” is the commonly used term to describe the activities and measurement processes needed to ensure that projects deliver business results and investment value.

If benefits management was as simple as ‘baking in’ the business case’s financial benefits into future budgets…

“You, Mr. Sponsor, have asked us (the Investment Committee) for funds. In return you promise to deliver a set of financial benefits that will be realized over time”

“We (the Investment Committee) will grant you the funds. But - we will deduct the promised benefits out of your future budgets as they fall due, according the business case you have prepared.”

“This will ‘encourage’ you to realize the benefits. And even you don’t feel 'encouraged', we’ll still get the value of the benefits anyway because your budget has been reduced.”

If benefits management was really this simple, then all of the benefits for every project ever proposed would always be realized!

The “baking benefits into budgets” approach – we call this the Simplistic Accounting approach - to enforce benefits realization and value delivery has so many problems that it is hard to know where to start debunking it! But here goes…

The top six problems with the Simplistic Accounting approach…

1. It ignores the reality that the financial value can – and most likely will – legitimately change during the course of the project (and beyond).
2. It does not actually measure benefits realization and value delivery anyway.
3. It penalizes anyone who is already correctly accounting for their planned benefit value in their future plans and budgets.
4. It does not cope with dynamic, changing business circumstances.
5. It encourages value minimization.
6. It measures the ‘scorecard’ – rather than the ‘main game’ – which is realization of the desired future business results and investment value.

Hardly a ringing list of positives for a benefits measurement approach. We will go through each of these six problems in more detail below.

But first, we need to define some TOP terminology…

When you successfully implement change, you will achieve a new working business-as-usual (BAU) environment:

• Desired business outcomes – clear specific measurable statements that describe the future BAU environment when it is working “just right”.
• Benefits – these are the positive consequences of achieving the desired business outcomes.
• Financial Value – which can be calculated for any or all of the benefits by building a financial model which converts the input value drivers into $. Value can also be measured by measures e.g. changes in error rates.
• Change activities – which must be done to deliver the outcomes, benefits and value.

This is the TOP Value Equation™ and we will use it to explain exactly what the problems occur when you use only one measure – the financial value..

1 The financial value of a project or strategy can legitimately change

When you develop a Value Equation for a project, of the three elements – the desired business outcomes, benefits and financial value to be delivered – the least stable element is the financial value.

The reason is straightforward: the financial values computed by creating a financial model, will take some historical or base data, project this into the future (the baseline) and then assess what is likely to happen to this as the project-induced changes take effect.

The financial model will take the input value drivers – base information, assumptions, extrapolations and estimates of varying quality and convert these to an output dollar value.

While the best efforts should go into finding the most accurate data so that the model correctly anticipates the value that will be delivered, there are four main reasons why the output financial value may change:

1. the financial bases on which the benefit value was calculated can legitimately change
2. the extrapolations from the base value into the future are misleading or wrong
3. the assumptions or estimates of what the project will change are be wrong
4. the actual values of changes affected by the project can under – or over – perform.

During the course of a project, many external events can occur to impact the financial bases and the value drivers. For example, if the central bank increases interest rates, then this will impact any benefits that have a reliance on interest rates in their calculations. Exchange rates can change, the market size can change, the reputation of the firm can change — these are all factors that are well outside the control of the organization and indeed the project and governance team but which can directly impact the value of the financial drivers and resultant financial values.

Example: Reduction in overdue receivables, value: $40m

In one organization, one key financial value driver was the total amount of monies due in Accounts Receivable. At the time the benefits were calculated this amount was $40m. During the timeframe that the project was underway,  a new CFO joined the organization, saw this amount outstanding and set up a small team to reduce it by chasing down the payment of late invoices. This team reduced the amount outstanding to $20m which had the effect of halving the value of the project’s main benefit and, therefore, based on the investment versus value returned, challenged the project’s continued viability.

Extrapolations, assumptions and estimates can obviously be wrong. They may be marginally out or grossly so.

The only way you’ll know is if you track them from day-one when you build the financial model, to verify how the projections compare to reality. That some assumptions are wrong may become clear early in the project. In that case you can update your financial model accordingly. Where incorrect assumptions become visible only after the project has finished, it may be too late to adjust the model in response.

Note: changes to assumptions can increase the available value as well as decrease it.

Example: Increased customer take-up, value: $?m

In another organization, the value calculation model estimated the customer take-up rate of 15% of the customer base per annum for a new facility. During the project timeframe, that organization suffered massive adverse publicity and lost about half of its customers. On implementation, the take-up rate was the 15% as estimated, but this was 15% of a much smaller customer set – so the value of the benefit was effectively halved.

In both of the above examples, factors well outside the control of the project changed the value of the benefits.

While you cannot avoid changes such as these occuring, you can understand how the changes will impact the projected value by tracking any changes, computing the variances and impacts and assessing the ongoing viability of the project as a result of the changed benefit values.

That means you need to track your financial model for correctness from day-one as soon as you have built it – even in advance of getting a project business case approved – and then continuing through the delivery period of the project through to point where the tracking either ceases or becomes part of business-as-usual reporting.

There are two reasons why you track and monitor your financial model

1. to ensure that the project remains viable - and -
2. to have the information so you can take corrective action.

Benefits/value measurement entails continuous tracking of all major financial values and the input value drivers, to assess their impact on the value, the project’s viability and future value delivery expectations.

2 Benefit realization and value delivery needs to be explicitly measured

The second problem with the Simplistic Accounting approach is that it does not actually measure benefits realization.

The ‘bake it in the future budgets’ approach measures budget achievement, not project benefits and value realization.

Let’s look at a simple example to illustrate this. Let’s suppose:

Example: Reduction in inventory holdings, value: $10m

A project is implementing a straight-through manufacturing-to-delivery process that eliminates some warehouse storage. The projected inventory saving is 10% of the current $100m inventory value (just to make the numbers easy). This saving is going to be realized in 2015. The accountant “bakes in the benefit” by reducing the inventory budget for 2015 by $10m to $90m. Easy.

2015 comes around and the inventory figure is $90m. Hooray! But what delivered this reduction

The project’s successful delivery?

The elimination of a product line in the meanwhile, leading to reduced inventory? 

A successful sales campaign that reduced existing inventory?

A change in product manufacturing specifications that reduced the cost of goods stored?

The point is that the budget achievement could have been achieved by any or a combination of these reasons.

The Simplistic Accounting approach does not know which and, if the project did not deliver its planned improvements, just using the budget performance figures would allow this fact to go unnoticed. This means that the available project benefits can go unrealized.

In a variation on the example above, let’s say that:

At the beginning of the benefits realization year, 2015, the inventory is already $90m – what value should we now expect from the project?

The $10m that was computed (10% of $100m)?

Or was the benefit supposed to be 10% of inventory — which is now only $9m (10% of $90m)?

As you can see, this is all getting messy and mis-focused. Whatever the correct answers the questions above are, the Simplistic Accounting approach is not measuring benefits realization; only final status against budget, which is a vastly different thing.

Your benefits management approach must actually track and measure actual benefits realization and value delivery if it is to drive the change needed.

3 The benefits and value should already be in the future budgets

Projects are one of the primary ways in which strategy is executed. You devise, plan and deliver projects so as to deliver your business plans and strategy. At least you should.

So when your organization is creating a forward business plan, the planning process should look at the current state and trends, planned operational improvements and identify what else needs to change to achieve your future strategy and associated financial goals. You then identify a series of projects that will move you from where you are now to where you need to be. These projects may reduce costs or increase revenues or margins, remove a competitive disadvantage, or deliver some other benefits. Where these benefits have a quantifiable financial value this is reflected in the future business plan.

For example, “We’re going to do project X that will take 15% out of our operational costs, a financial saving of $15m per annum from 201X”. The financial plan for 201X and beyond then incorporates the $15m saving.

This is how planning should work.

If you then take the Simplistic Accounting approach to benefits management you would then take out a further $15m from the future budgets! This is double counting and penalizes anyone who is planning correctly and reflecting their project’s planned benefits in their future financial plans.

So, the Simplistic Accounting approach to benefits penalizes good planners.

If you have a 3-year project, the world can (and will) be quite different in years 3, 4 and beyond when many of the benefits are due to be realized. Indeed, it is this continuous level of business change that some use to discredit the notion of measuring benefits at all. 

“How will you be able to identify which benefits came from which project in 5 years time?”

It’s a good question.

It points to the difficulty, if not impossibility, of trying to isolate and allocate future changes in budgets or business results to specific projects when, usually, more than one project has impacted the same area, in addition to all of the external changes that we discussed earlier.

But this is not a reason for giving up on benefits measurement, rather it is a reason for changing how you go about benefits measurement.

Example: Reduction in staff costs in call center, value: $380k

In one organization, the project was making the call center more efficient resulting in the staff numbers being reduced by eight which calculated as a value pa of around $380,000. But, during the project timeframe, someone in marketing decided to change the call center service and move from a 16-hours/5 days a week service to a 24/7 service.

This meant that, far from reducing staff numbers, the call center was hiring more staff. At the end of this project the call center costs would not have gone down by the $380,000 planned, but would have increased substantially.

The Simplistic Accounting approach does not cope with this example. If your only measure of benefits realization is the output salary cost reduction of $380,000, then too many input value drivers have changed and made this amount incorrect and irrelevant.

The problem arises because you are only measuring the outputs (the salary reduction benefit). If you change instead to tracking the changes to the inputs – the realization of the planned business outcomes and the associated benefits – you can then show how these feed through into variances to the project value.

In this example, using the financial model that calculated the original value, and the running the changes to the input Value Drivers through the model to assess the variances, we were able to show that:

The project delivered exactly what it was commissioned to deliver, that the workload in the call center was reduced by the promised efficiencies and, as a result of the delivered benefits, 12 less staff were recruited than would have otherwise been needed when the call center went 24/7.

The Simplistic Accounting approach to benefits management cannot cope with business dynamics and changing circumstances – which is everyday life.

But your financial model - when constructed according to TOP's principles - can estimate variances and the reasons, both positive and negative for these.

Your benefits management and measurement approach needs to cope with the realities of business dynamics by tracking the changes to input Value Drivers and how these variances affect the output value.

5 Benefits need to be maximized, not minimized

Projects are often commissioned with high hopes. But projects do not have a great track record of reliable delivery and frequently lose scope, focus and value along the way.

While most managers may not understand the dynamics of project success (and failure) and benefits, they pragmatically know that things change and usually for the worse. Therefore to rely on the project delivering everything as planned, within the timeframe proposed, is a hazardous and potentially career limiting for the business manager made accountable for realizing one or more benefits.

Most business managers – when they know the accountants are taking the Simplistic Accounting approach of “baking in” these benefits to their budget but not allowing for any project failures or deficiencies, and simply adjusting budgets for the promised benefits – will make very sure that the claimed benefits in their business case will defined well within their ability to realize them.

They will, therefore, reduce their projected benefits to the minimum that they need to generate an acceptable return on the investment!

That leads to a cascading problem.

There is an often unspoken assumption that if the benefits exist, that they will be realized regardless of whether there are any proactive benefits management/measurement processes. This is the “build it and they will come” myth.

What the research shows will actually happen is that:

• there are ‘compulsory’ benefits – benefits that you cannot avoid as a result of implementing the project  – usually about 20-30% of the total;
• some specific business benefits will be realized as the business seeks to get some value from the project – again usually around 20-30% of the total;
• and the remaider of the benefits will be lost, missed or destroyed – often over 50% of the total available – when you allow for the subsequent loss of benefits post implementation.

Thus the real benefit value opportunity will under delivered compared to investment value on the table that could actually be reaped

So when the Simplistic Accounting approach is applied there is a multiplying effect – managers miminize the benefits that they will be accountable for and then the organization reaps a much lower proportion because these are not actively realized.

A benefits management/measurement program needs to encourage (and validate) the identification and pursuit of maximum possible available value. If you are going to incur the costs of delivery, you may as well maximize the value.

Delivering the project does not automatically realize the benefits. Only direct, focused and managed benefits delivery realizes the benefits. But if you don’t identify all the benefits, maximize their value, quantify them and plan to realize them; you’re highly unlikely to realize them.

6 The financials are the scorecard, not the ‘main game’

When you play sport, you play to have a great game and win (usually). The score is a tracking mechanism but it is not the main game itself.

To use our sports analogy, in the Call Centre example above:

the salary reduction of $380,000 is the score – the financial value. The game – is to deliver to the call center the outcomes and benefits that enable workload reductions and efficiencies; so that the call center staff can provide an improved level of customer service more easily and at a lower overall cost.

So the game is a more efficient, improved service call center; the financial value of $380k is the consequential score.

As we saw earlier, the financial value or score can be achieved by many other means over time, or be impacted by many other changes from other initiatives, events and projects. So while financial value is the score which can indicate how well and completely you’ve played the game – which is to realize the outcomes & benefits – it is not the only measure.

To measure how well you have played the game, you need to be able to answer for each project:

1. Did we achieve the desired business outcomes – did we deliver the business end states working "just right" we sought?
2. Did we then realize the associated available benefits in full?
3. What were the benefits worth financially at the time of realization? Are the reasons for the variances acceptable to us? Are we happy with value returned compared to the investment?

The financial worth or value of the benefit is one of the scores. But not the only one.

This is not to denigrate the importance of Financial Value or its impact on your business results, but simply to illustrate that financial values are the result of the delivery of the business outcomes and benefits. The outcomes are the drivers, enablers and deliverers of benefits, not the financials.

But, focusing solely on the financials often causes the true game of outcome and benefits delivery to be overlooked. It misses the point – which is that you need to focus on the drivers, enablers and deliverers of benefits. If you measure them you’ll know if the benefits are available and how well you’ve achieved them (and if you can recover any shortfalls).

You are now managing your benefits rather than just measuring them.

So, is there an easier, simpler approach?

The Simplistic Accounting approach focuses on the output scorecard. TOP's easier, simpler approach is to track and measure the inputs to the delivery of the benefits and their value. By ‘inputs’ we mean

1. The project and business activities that deliver the change that
2. Leads to the delivery of the desired business outcomes that
3. Enable and deliver the business benefits and their value.

This ‘inputs’ approach is illustrated by the TOP Value Equation™:

• Outcomes – define the future state when everything is working “just right” – these deliver
• Benefits – are the positive consequences of achieving the Desired Outcomes.
• Some of those benefits can be calculated to have a monetary measure –  Value.
• The Value is determined by the input Value Drivers.
• And in order to realize the Outcomes, Benefits and Value, we have to undertake change Activities.

If a project is set up correctly you should be able to track every project activity (A) back to the desired business outcome (O) that it is contributing to. This requires you to identify your desired end states/outcomes at the outset in clear, specific, measurable terms, and then link all of your project activities to the delivery of these outcomes. This may sound obvious but this level of clarity is not the norm for most projects.

When every activity is linked to an outcome, 100% completion of each activity (A) is a measurable step towards the delivery of the outcomes. Again, this may sound obvious, but few organizations actually measure the level of task completion and allow 95% complete tasks to be treated as 100% complete, but this just compromises the results and loses the value.

Each ‘desired business outcome’ (O) should be clear, specific and measurable by a true/false question – can we or can’t we? do we or don’t we? have we or haven’t we? Black or white – the outcome has either been fully delivered or not.

If not, then the benefits (B) associated with the outcome will be compromised – but now this situation is measurable. By linking benefits to business outcomes, the number and nature of the benefits identified increases – a topic for another article; but a doubling of the quantified value of the benefits is not uncommon.

For example, if the desired outcome is:

“We accurately invoice all service calls within 24 hours” then we can clearly state “we either do or we don’t”…

If only some service calls are invoiced within 24 hours or only some are accurate, then we can clearly see that the outcome has not been fully delivered and the benefits associated with this outcome will have been compromised. But you now know why the value has been compromised and how you can recover the lost value.

Linked to each outcome (O) are the (B) benefits that are enabled by the outcome. Therefore, when an outcome is delivered, the benefits can be realized. Some Benefits will be automatically realized by the outcome being delivered, but most will require additional work and change to be realized. These can all be tracked in the same way project activities are tracked to 100% completion.

And, when the benefits (B) are realized their value (V) can be recomputed. The financial model is constructed in such a way so that value can be recomputed based on the tracking data. Over time (as we discussed earlier) some of the value drivers (D) (the bases of the calculations) may have changed and increased or decreased the available value. By using the up-to-date value drivers you can calculate what value is available to be realized now vis-à-vis what value is actually realized and highlight the size of the variances and what remedial action must be taken.

It really is that simple.

This approach does require that you track the value of these value drivers (D) throughout the project and beyond so that you know their current value and, in extreme circumstances, know if the project is no longer viable due to changes to its benefits’ value. Being able to identify that a project is no longer viable, can increase the net value of the project portfolio by eliminating wasted expenditure on no longer-viable projects.

The TOP Value Equation is easy, simple and actually increases the value identified and realized.

It avoids all the problems of the Simplistic Accounting approach and can be embedded in your existing project delivery approaches to avoid any extra workload. It starts, not with the financials, but with the desired business outcomes. This changes the whole game—as you can discover here: