How to write a Business Case

Work in any business or industry long enough, and you will come across a Business Case. You may be asked to review a business case, contribute or even write one. The problem is that very few of us have been trained to write business cases, so the quality varies wildly - even reviewing a business case can be a challenge. Here then, is a step-by-step guide to writing better business cases.

The Decision Maker’s View

In my career, I’ve been on most sides of business cases. I’ve had to write, contribute, review and give my approval to proceed - or postpone or even shut them down.

As a CEO or decision maker in a business, what you see below is what I would look for from a business case.

This will help you understand how to write the business case so you can answer the questions your decision makers will have.

A Chicken and Egg Situation

As you develop a business case, you will find a classic chicken and egg problem:

• You won’t know all the resources and costs until you’ve done detailed planning.

• Detailed planning may reveal financials that sink the business case.

So how much work do you need to put into a business case and the related planning and analysis?

The best way to solve this problem is with an iterative approach. Each iteration gets more detailed and the supporting plans and financials more precise.

Your first version of a business case may be the proverbial back-of-a-napkin idea. The next version could be a rough draft, with some financials with an accuracy of, say, -10% / +50%. Each successive version can then be refined, and as long as the details makes sense, you continue working until you have a final version for formal approval.

The iterative approach has the advantage that all your stakeholders are familiar with the business case and related financials by the time they get to approve the final version. Aim to present two or three but no more than 4 iterations - more results in decision fatigue.

With that in mind, let’s look first at the purpose of a Business Case.

What is the purpose of a Business Case?

To develop a compelling business case, we first need to understand how it will be used. The first key is that a business case does not stand alone:

A Business Case is one of a set of documents that define a project or initiative.

Most projects or initiatives will have at least three key documents:

• Business Case

• Project Charter

• Project Plan

If you’re very clear about the purpose of each document, it becomes a lot easier to decide which information belongs where. Here are the definitions I use in project management work:

• A Business Case justifies the investment in a project. It is used by decision makers to determine if the investment makes sense for the business, is financially attractive and should proceed.

• A Project Charter is used by decision makers to determine if everything is ready to execute a successful project. Once approved, it authorizes the project team to start the project, engage resources, and spend money.

• A Project Plan defines what needs to be done, when it will be done, and who will do it. During project execution, it is used to track progress.

Your definitions may differ, and that’s OK.

The key to a successful business case is to define its purpose - and the purpose of the other key documents relative to the business case - clearly. Make sure all your stakeholders understand this and how the iterative development process works.

Based on our definitions, we can now determine what should go into a Business Case.

What goes in a Business Case?

We’ve said that the purpose of a Business Case is to justify the investment in a project. It is used by decision makers to determine if the investment should be made.

Therefore, we need to give our decision makers all the information they need to make an informed decision.

As a decision maker, I need to know four things to determine if a business case should be approved:

1. What is the problem or opportunity?

2. What are the potential and recommended solutions?

3. What are you proposing to do?

4. Are the financials compelling?

To answer each of these questions, we will need a little more detail.

The Problem or Opportunity

Here’s the decision maker’s view:

As a decision maker, I need to understand there is a very real problem or opportunity. I need to be convinced that the benefits of solving the problem or addressing the opportunity outweigh the cost of doing nothing.

My questions will include:

• What is the problem or opportunity?

• What happens if we do nothing?

• What benefits could we get if we solve this problem, or take advantage of this opportunity?

Avoid these common mistakes:

• Don’t mix problems with solutions. Just state the problem and quantify it where you can.

• Don’t use adjectives. Your definition of “serious” is going to be different from other people.

Once we know what the problem is, and the benefits seem compelling enough, we need to know the different ways we can solve it.

Potential and Recommended Solutions

As a decision maker, what I’m looking for here is the following:

You’ve objectively considered all the potential solutions to the problem, and you have no bias towards one or another.

This is important, because (for example), an IT team will have a natural bias towards a technology solution. A marketing team will have a natural bias towards a marketing solution (as opposed to say, a customer care solution). In either case, there may be other types of solutions that deliver similar results.

Your decision makers will typically have the following questions:

• Which potential solutions did you consider?

• Which one of these is the recommended one?

• Why are you recommending this specific solution (and not any of the others)?

We’re now ready to make a proposal or recommendation.

Proposal or Recommendation

I now have the following questions:

• What do you propose to do?

• What will it cost (and what do the longer-term financials look like)?

• Who would be involved?

• How long would it take?

If you’re using an iterative development process, early versions of your Business Case may not include a proposal. You may even run financials on two or more options to determine the most attractive one.

Note that some of this information will be detailed in your project charter or plan. Provide just enough information to make it easy to understand and make a decision on the business case.

Financials

As a decision maker, I am responsible for the financial performance of my business, division, or department. I need to know that the proposal makes business and financial sense, and we can afford to do it.

How sophisticated you get with financials depends on the type and size of the investment.

If the benefits of the investment are financially quantifiable, your job is relatively easy. You’re either going to save money or make more money - ultimately improving the bottom line.

If the benefits are difficult to quantify (for example “improve employee engagement”), you should still try to quantify some measures which can be used to determine the success of the investment.

At the very least, you will need to include:

• Total investment.

• Cash flow requirements (how much you will need every month or quarter).

• Return on investment (if financially quantifiable).

• Break-even analysis (if applicable).

Depending on the size of the investment, you may also need to include Return on Investment (ROI) and Net Present Value (NPV). Engage with the financial professionals to help with the appropriate calculations.

An outline for a Business Case

Putting all of this together, here’s a top-level outline for a business case:

• Executive Summary

• Problem

• Potential and Recommended Solutions

• Proposal or Recommendation

• Financials

• Request for approval

We’ve defined what needs to go into each section except for the executive summary and request for approval.

The Executive Summary

The common wisdom is to write the executive summary last - and it’s absolutely correct. Here’s how to write a good executive summary:

• Summarize the problem or opportunity in one paragraph. Only describe the problem, stating the facts and avoid adjectives. Quantify where possible.

• Summarize the potential solutions in one paragraph. If you considered a host of potential solutions, just mention how many you looked at.

• Summarize the proposal in one paragraph. Include why you chose this option, briefly state the key players involved and the expected timeline.

• Summarize the financials in one paragraph. Include only the key financials, for example total investment, ROI and break-even.

• Request approval to proceed.

The principle (as you can see) is to summarize each section of your business case in no more than one paragraph. Condensing a lot of information in a few sentences is fine - if they need more information, it is available in the relevant section.

The Request for Approval

I usually include a Request for Approval as the last section of my business cases. Depending on where you live, and the culture of the organization, this can be more or less formal.

Here’s one version:

We respectfully request your consideration and approval for this investment. The project team is at your disposal to answer any questions.

And follow that up with your key team members’ names and contact details.

Remember - you’re asking your decision makers to not only invest in solving a problem or realizing an opportunity. You’re also asking them to trust that you can deliver on the promise - so they are putting their money and reputation on the line. Treat your business case, and the people who you’re asking to approve it, with the appropriate respect.