Re-evaluating the business case – good money after bad?

iStock_000016744642Small business caseThe business case is one of the critical documents produced during the initiation of a project or programme. It sets out the expected costs and benefits, both financial and non-financial, that the project will incur and deliver. But given the level of uncertainty at the outset of a project, the chances of getting all the information right are pretty slim. The business case represents your best view of the costs and the outcomes. It will state the assumptions you have made in arriving at your assessment and should include a level of contingency to counter the risks and uncertainties.

Those uncertainties are one of the reasons your business case should be a living document, one that gets revisited and re-evaluated during and at the end of the project. It needs to be re-evaluated during the project to confirm it is still valid or to assess what course of action to take if some elements in the dynamics of the project have changed. The business case should also be assessed at the end of the project to ensure it has met its objectives and the benefits have, or on track to be, delivered. This post is concerned with the mid-project re-evaluation.

Now, I have said before “There are lies, damn lies and what some people will put in a business case to get it approved”. Many or even most sponsors and project managers do their best to give a fair representation of the costs and benefits when getting their projects and programmes approved. But, I have also seen many business cases that have been prepared with excessive optimism, naivety and, at times, out-right misrepresentation and lies. At the re-evaluation mid-project is when that excessively rosy picture often comes under the spotlight.

Any re-evaluation should have two elements: looking back at what was expected verses what has happened, and applying the lessons from that assessment to the remainder of the project. The sorts of things you are looking back at are:

  • Were the project assumptions valid and have they been borne out by experience
  • How accurate were the estimates
  • Is the basis for calculating the expected benefits still valid
  • Is the project on track in terms of time, cost and quality compared with where is should be according to the original plan
  • Are the reasons for doing the project still valid

With that information you can now reassess the need for the project. If the need still exists, the next stage is to assess what is still required to deliver the project to the required standard. The question arises whether you should include the costs to date – the sunk costs – in any financial re-assessment.  Whilst the full cost should be considered when assessing performance at the end of the project, at any intervening point, it is the cost to completion in order to achieve any unrealised benefits. So if you’ve spent half the budget but realised the majority of the benefits, it may not make sense to send the rest.

There are many factors to consider, and this early realisation of the benefits would be unusual. It is much more common to realise that the original business case was either flawed or the rationale for the benefits has evaporated. A real example of this was the implementation of a major new accounting and risk management system for a bank with the benefits being derived from much improved balance sheet management driving down funding costs. In reality, a major restructuring greatly reduced the scale of the balance sheet severely eroding the basis of the benefits.

So in assessing whether to complete a project you need to consider what return you will get from the extra investment to complete the project. Stopping the project and ‘wasting’ the spend to date, is never a consideration,  as hard as that might seem. Just be sure the mistakes of the initial business case are not repeated in justifying the continuation.

What are your experiences with business cases? Leave a comment below.

Tagged with: , , ,

Leave a Reply

Your email address will not be published. Required fields are marked *

*