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 time-scale 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 a Business Case

A business case needs to lead the reader logically through the problem, objectively consider various solutions, and finally recommend which option is best. It therefore needs a clear structure, with plenty of headings and sub-headings to guide the reader.

Sections that are usually required in a business case include:

1. Executive Summary

   The executive summary summarises the entire business case, including your final recommendation. It is often best written last, when you are completely clear about your recommended course of action and the supporting reasons. Remember that some time-poor decision-makers may only read the executive summary, so you need to make sure that you have included all the most critical, high-level information.

2. Introduction

   This section introduces the business case and briefly sets out what the document is about and why it has been created.

3. Statement of the Problem

   This should be a concise paragraph clearly stating the problem or opportunity. It should relate back directly to the organisation’s strategic vision to demonstrate exactly how solving this problem is important to the broader company goals.

4. Analysis

   This section provides a more detailed account of the problem and why it is critical to address it now. It should include any analysis you or others have carried out to identify the impact of, or the root reasons for, the problem. Hard evidence is essential here: state the number of people affected, or the quantifiable cost to the company or its customers. At this point, it is appropriate to mention anyone who has been involved in the investigative work within or outside the organisation.

5. Discussion of Possible Options

   You should identify and rigorously discuss all possible options for addressing the problem, including the baseline option of doing nothing. For each option, you need to discuss:

   • The benefits: Why it would be a good idea to pursue it, including exactly how far it addresses the core problem;
   • The costs: Including financial budgets and resource requirements. It is often highly effective to include financial projections and graphs here;
   • The likely time-scale: How long the project will take to implement, and how long it will take to see a return on the investment, with reasons; and
   • The risks: Both the risks of undertaking the project, and the operational risks that might prevent successful implementation.

   As far as possible, these metrics should be realistic and supported by solid, verifiable data. Where you have estimated, this should be based on a reasonable source, which you must cite if possible.

6. Recommendation

   Finally, you should make a clear, definitive recommendation for which option is best, carefully weighing up the identified costs and benefits.

7. Details of Your Chosen Option

   Depending on your organisation’s preferences and the complexity of the business case, you may at this stage wish to include a more detailed operational consideration of your chosen option. Alternatively, you could include this detailed analysis in an appendix, including all the supporting data, or provide a separate report with all the project details.

   If you are including more details, this is an excellent 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 additions demonstrate that you have thought through the project in granular detail, have a reasonable idea of how long it will take, what resources will be necessary, and how to effectively mitigate the risks. This should help decision-makers assess whether the organisation is currently capable of carrying out the work, or whether additional resources will need to be procured.

   You should also make some concrete proposals for project governance, including proposing a steering group to oversee the project and identifying critical decision points.

   Your organisation may also require a detailed financial appraisal. A robust business case often includes a Cost-Benefit Analysis (CBA) and calculates the projected Return on Investment (ROI). This proves to stakeholders that the financial gains justify the initial expenditure. You will also need to account for the opportunity costs of the project, and apply some discounting if the payback period spans several years. If these are required, your finance department will almost certainly have detailed guidelines and a standard 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 highly recommended to include information about outcomes and success criteria: what are the Key Performance Indicators (KPIs) that will prove your project has been successful?

8. Conclusion

   You should conclude the business case with a powerful reminder of why it is critical to address the problem, followed by the specific action that you wish the reader to take as a result of reading (for example, to agree to a course of action or officially approve the budget for further work). Make absolutely sure that you have made it explicitly clear why your proposal is the best way of addressing the problem.

Using AI for business cases

It is not just possible, but often advisable, to use AI to help you write a business case.

An AI assistant can help you to work through ideas and develop a clearly-written business case. However, you will need to provide clear information and structure, and also set out any constraints (and our page on Using AI Effectively: Prompt Engineering will help here).

The prompt that you use might need to be multi-stage and quite long. For example, the UK government’s AI Knowledge Hub provides a detailed prompt that can be adapted for use in business cases (and you can see the prompt in full at ai.gov.uk/knowledge-hub/prompts/write-a-business-case/).

The initial prompt is set up to ask the AI to prompt the user for more information, including outline structure, the type of business case, and key details across the five areas required for bids for government projects.

In other words, you don’t have to give the AI all the information upfront, as long as you tell it that it will need more information.

There are also new AI-based tools that are designed to help with writing proposals and bids for projects. For example, Bid Writer is a tool from London-based start-up Engine for small and medium-sized businesses and public sector organisations without much experience of using AI. It aims to streamline and accelerate the process of writing bids and business cases.

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.

---

---