Writing a Business Case
A business case is intended to convince key decision-makers of the merits of a particular course of action.
It is a key part of your project documentation: if a project brief describes what needs doing, and a project plan explains how, the business case sets out why.
A good business case will explain the problem, identify all the possible options to address it, and allow decision-makers to decide which course of action will be best for the organisation.
It will also allow any changes to the scope or timescale of the project to be assessed against the original purpose.
What has Already Happened?
Before you write a business case, you should have carried out a fair amount of research into the problem and possible solutions. This page assumes that you have already done that work, whether on your own or as part of a working group.
The Structure of the Business Case
A business case needs to lead the reader through the problem, to consider various solutions, and finally decide on which option is best. It therefore needs a clear structure, with plenty of headings and sub-headings to guide the reader.
Many organisations have a template for business cases, setting out the required structure and format, so check whether there is one in your company before you start.
Sections that are usually required in a business case are:
1. Executive Summary
The executive summary summarises the business case, including your recommendation. It is often best written last, when you’re clear about your recommended course of action, and why. Remember that some decision-makers may only read the executive summary, so you need to make sure that you have included everything relevant.
This section introduces the business case and briefly sets out what it is about.
3. Statement of the problem
This should be a brief paragraph stating the problem. It should relate back to the organisation’s strategy or vision to demonstrate how solving the problem is important to the organisation.
This section provides a more detailed account of the problem and why it is important to address it. It should include any analysis you or others have carried out to identify the impact of, or the reasons for, the problem. Hard evidence is always helpful: the number of people affected, or the cost to the company or to its customers. At this point, it is appropriate to mention anyone who has been involved in the work within or outside the organisation.
5. Discussion of Possible Options
You should identify and discuss all possible options for addressing the problem, including doing nothing. For each one, you need to discuss:
- The benefits: why it would be a good idea to do it, including how far it addresses the problem;
- The costs, including resource requirements. It’s often helpful to include figures and graphs here;
- The likely timescale for the project, and to see a return on the investment, with reasons; and
- The risks, both of doing it, and that might prevent successful implementation.
As far as possible, these should be realistic, and preferably supported by solid data. Where you have estimated, this should be based on a reasonable source, which you should cite if possible.
Finally, you should make a recommendation for which option is best, weighing up the costs and benefits.
7. Details of your Chosen Option
Depending on your organisation’s preferences, the nature of the business case, and how you feel about it, you may at this stage wish to include a more detailed consideration of your chosen option. Alternatively, you could include a more detailed analysis in an appendix, including all the supporting data, or provide a later report with all the project details.
If you are including more details, this is a good opportunity to include an outline project plan (see our pages on Project Management and Project Planning for more) and a more thorough and complete risk analysis (see our page on Risk Management for more).
These will demonstrate that you have thought through the project in some detail, and have a reasonable idea of how long it will take, what resources will be necessary, and how to mitigate the risks. This should help you assess whether the organisation is currently capable of carrying out the work, or whether additional resources will be needed.
You should also make some proposals for project governance, including a group to oversee the project and any critical decision points.
Your organisation may require a detailed financial appraisal, including opportunity costs of the project, and some discounting if the payback period is several years. If so, there will almost certainly be detailed guidelines somewhere, including a discounting factor, which you will need to follow.
The opportunity cost is a measure of what else you could have been doing with the money instead of investing in this project. At its simplest, it is the rate of interest that it would have been earning in the bank but, in tough economic times, it’s also a measure of what other projects won’t go ahead if this one does.
Discounting is a way of measuring the present value of payments to be received in the future to allow direct comparison of projects with different payback times. It takes into account the value of having something now, rather than later.
The easiest way to think of it is the interest that you pay on a loan or mortgage: you want the money to buy something now so you’re prepared to pay more rather than wait until you’ve saved. Economists have calculated what ‘the average person’ is prepared to pay to have something ‘now’ and this is often applied as a standard ‘discounting factor’ to investment analysis.
It is also helpful to include information about outcomes and success criteria: how will you know that your project has been successful?
You should conclude the business case with a reminder of why it is important to address the problem and the action that you wish the reader to take as a result of reading, for example, agree a course of action or approve further work. Make sure that you have made clear why your proposal is the best way of addressing the problem.
Style and Language
A business case is often aimed at people without a detailed knowledge of the subject area. You therefore need to avoid jargon and keep the language as simple as possible.
Use short sentences and break up the text with plenty of sub-headings.
Paragraphs should be no more than about four to five lines long, and you should leave a line between paragraphs. Shorter is better than longer.
You should also try to develop a sense of the urgency. Make clear when you need a decision and why that date is crucial.
A brief note on checking and proof-reading
As with anything written, it is always a good idea to look again at your work after a break. If possible, make it a day later but, if this is not possible, then at least a few hours. It’s also a good idea to get someone else to check your work.
Keep referring back to the business case
Once approved, your business case is not a static document. Every change to the project should be considered against it and, if agreed, incorporated so that the business case remains a complete record of the project. This is a vital part of managing any project (see our page on Project Management for more).
It can also be helpful to refer back to the business case when monitoring and assessing progress to check against your original objectives and to make sure that your project is still going to deliver the proposed benefits.