The business case is probably the single most important document in any project. Why? Because it provides the justification for the very existence and continuation of the project.
The business case is a living document, constantly refined and updated throughout the life of the project. It needs to be maintained because things will change during the lifetime of a project. What sort of things will change?
- As you progress through the project lifecycle, your cost estimates will become actuals for completed stages and better inform the estimates for the work yet to be completed.
- Your understanding of the benefits the project will deliver will improve enabling better validation of those benefits.
- The business itself will change. Changes within the business or in the competitive market place may impact the desirability or viability of the outputs from your project. One example of this was a project to build a new core banking platform for a major retail bank. The key driver was the poor stability of the existing system and the time it took to recover from system outages. However, during the project to replace the system, the existing system was moved on to more modern hardware. This solved the key performance issues at a fraction of the cost and the project to replace the system was now no longer required. The business objective had gone away.
So constant re-assessment of the business case is required to ensure the project is still viable and desirable.
On the assumption your business case is based on a validate business objective, how do you construct it to give yourself the best chance of getting it approved? Let’s start by looking at the structure of a typical business case.
How should you structure a business case?
Many organisations will have a prescribed layout and/or structure for business cases. The structure and content I set out below cover all the key information a good business case should include. I recommend you use this structure to create or gather your content then look at where each element fits into your own company’s format. Make sure you include all the information somewhere.
There may be additional information required or questions to answer. For example, your company may have a set of corporate values and may insist that all business cases demonstrate how they support those values. For example, one business case I wrote had to demonstrate the impact on customers – quite a challenge for a project to implement regulatory financial reporting.
However, the information being reported would eventually be in the public domain and if reported accurately, timely and with complete transparency, this would give customers and shareholders more confidence in the company. If you have used my structure it should be easy to identify the relevant points to answer these additional questions.
When drafting each section, include as much information as you can and be as detailed and specific as you can. You can always refine, edit and trim back the amount of detail later but at least you will have that detail to support your business case should you be challenged.
Rationale or objectives
This section describes the reasons why the project is being undertaken. It should describe how the project supports the immediate and/or longer-term strategy and objectives of the business. These reasons need to be quite specific because they will be the driver for specific benefits that the project will deliver.
Describe your proposed solution to meet the business needs and objectives described above. This should also describe the implementation approach and timescales at a high level.
To arrive at your recommended solution, you will have considered a number of alternatives, including ‘doing nothing’. Each alternative should be described along with the reasons for discarding it. Wherever possible be fact-based rather than emotion-based.
What are the benefits that the project will deliver? These should be described in measurable terms and set against a current baseline so that delivery can be assessed. The benefits should be aligned to the business objectives and strategies the project is seeking to support. There may be additional benefits and these should also be articulated.
Benefits can be both tangible and intangible but for the intangible benefits to having a bearing on the business case approval, they too must be measurable. For example, for customer satisfaction with a help centre, this could be measured by before and after customer surveys. You also need to ensure that the ability to track and report benefits delivery is built into your project delivery and explained in the business case. Saying exactly how you will track benefits gives a lot more credibility to your benefits case.
There may also be some downsides to the recommended approach or dis-benefits. These should also be described and the reasons why they should be accepted explained.
Costs, timescales and resources
This section describes the money and other resources required over what timescales to deliver the project. Your own company may have specific headings or categories that you need to break these down by. Don’t forget to include the impact on the business area(s) you are implementing the project for, both as part of project delivery, and in terms of on-going costs once the project completes.
Many organisations don’t include the costs of existing ‘business as usual’ resources involved in delivering a project. In my view, this is wrong as those business people could be doing other valuable work. There is an opportunity cost in using them on the project and this should be included. Find out how your organisation treats these costs and include or exclude them as appropriate.
All projects involve change and with change comes risk. You should focus on the major risks associated with the project. These could relate to the nature of the project and the objectives or strategies it is looking to support, or they could relate to the scale of the costs or benefits. For example, if the project is to create and launch a new product, there could be a risk that the market will move on or a competitor will beat you to it.
If you are implementing new technology to the company, there may be a risk that you will underestimate the costs or timescale to complete the implementation. A full risk analysis of the project will identify any potential risks. The business case should focus only on those that could have a major impact on its objectives, costs and benefits.
Most companies will have standard investment appraisal tools so that all business cases can be assessed on a comparable basis. These will typically include a financial model to assess the Return on Investment (ROI) and the payback period. The latter uses an analysis method called discounted case flow to look at the current value of future cash flows associated with the project.
Those cash flows would include the project costs, depreciation of any fixed assets bought or created (or written off for that matter), changes to on-going business costs (staff increases or reductions, new or reduced property costs etc) and the other financial benefits such as increased sales. The payback period is the point at which the cumulative cash outflow is balanced by the benefits derived.
One important thing to do with your investment appraisal is to test its sensitivity. By this, I mean what happens to the ROI and payback if costs go up by 10% or 20%, or if benefits go down or are delayed. How sensitive is your project to such variations? If one little delay is going to make it unviable, how certain are you that a delay can be avoided.
Your in-house finance team should be able to assist you with finding and completing the right model for your project. If there isn’t a standard, then get in touch with me for some specific guidance.
Creating an executive summary
Ask ten people how long a business case should be and you will get 10 different answers. In my view, it should be as long as it needs to be to clearly articulate the key information in each of the sections I have described above. However most senior executives – those likely to be deciding on whether to approve your business case or not – are unlikely to read a lengthy document. So you need to provide them with an Executive summary. This needs to draw out the key points of the complete document and refer the reader to the relevant sections if they want more detail.
Some companies will have a business case format that is in effect a form of the executive summary. In this case, the material you have produced in each of my recommended sections becomes your supporting documentation to back up the assertions you make in the business case.
Ensure your business case is an honest reflection of the costs and, particularly, the benefits. Include contingency within costs and timescales to mitigate the identified risks. Keep the language simple and non-technical wherever possible – don’t create the opportunity to be asked difficult questions.
And know your audience. Find out who will need to approve your business case and what their specific angles will be.
About Guest Contributor
Allen is an expert project and programme manager with 25+ years of experience helping clients and individuals deliver their projects and programmes through hands-on delivery management, establishing and running bureaucracy-free PMOs, one-to-one coaching & mentoring, and practical training workshops.
Allen merges the technical project management skills all project managers need with the people management and interpersonal skills necessary for successful delivery in today’s commercial environment.
Allen has managed projects of all shapes and sizes from a ‘solo’ project to restructure the Inter-bank sales team for an international bank, through managing the recovery of a failing settlements system programme, to managing the PMO for a multi-billion pound restructuring programme.
Allen shares his experience through regular blog articles, the publication of a series of free e-books, mentoring and coaching of his teams and colleagues, and delivery of practical training workshops and online training modules. Sign up for his blog