How to Write a Business Case

A Business Case is a rigorous (and usually financial) advocacy of a preferred course of action, clearly presented for objective scrutiny.

What is a Project?

A Project is a programme of effort and capital expenditure arising from acceptance of a Business Case.

What is a good idea?

All ideas are good insofar as they provide the raw material of further development and improvement. Ideas should be welcomed and encouraged on the understanding that only a few will prove fruitful.

How do you prove/disprove an idea?

By an honest attempt to refute it - if you can't, it's probably a good idea!

This is the document that sets out the Business Case for discussion and eventual approval. In many companies there will be a Finance Meeting (or equivalent) that will formally accept or reject the Statement of Case. As rejection is likely to bury the project for several months, possibly forever, it is vital to prepare a high quality Statement of Case to give the idea the best possible chance of acceptance.

The Statement of Case:

• Defines and formalises the proposal
• Persuasively advocates the proposal
• Must win approval for the proposal

Who writes it?

Typically, the Statement of Case is written by the "Project Chair" in close liaison with the Project Manager. Precisely how the writing is divided between them depends on the individuals and the nature of the project, but in general -

• Project Chair as "owner" writes the business case
• Project Manager as "implementer" provides specific analysis

The Statement of Case is an active document. It should be written to win approval often in the face of competing proposals (since the total budget is finite). It is not a passive reference document.

Document Structure

Many companies will have an established document structure that must be followed in every case. This will vary from company to company, but a typical Statment of Case would include these standard sections:

Summary, Background, Objective, Proposal, Alternatives, Benefits, Disadvantages, Consequences, Finance, Method, Details.

Here's how to tackle each of these sections:

1. Summary

Write it last or it will be inconsistent. Make sure it contains nothing new. Include:

• the proposal
• the key benefit
• essential background only
• essential financial information

The Summary is placed first for convenience. It should stand alone as a piece of writing (i.e. it should be internally consistent) but it need not define and explain all its terms.

It is intended to serve two functions -

• to introduce the proposal to an expert and well informed reader (but note - that does not make it an introduction for the general reader)
• to furnish the reader who has already studied the entire document with all the main points conveniently juxtaposed.

By default, it also serves another purpose - it forces the writer to focus on what is most important about the project and hence to consolidate the overall picture.

2. Background

Do not -

• pre-empt the proposal (or the null option)
• over-criticise the status quo

Do -

• identify and explain the motivation
• facilitate all subsequent sections

The word "Background" suggests something passive and historical. To keep it active, concentrate on the project's key motivation. There are three main motivating forces. Each requires a different approach -

Motivation 1 - Reaction - the need to solve a problem

• Things appear to be going wrong
• Are they really going wrong?
• No? Deal with appearances (no project!)
• Yes? Describe and explain the problem situation.

Motivation 2 - Maintenance - the need to pre-empt a problem

• The status quo appears satisfactory
• You believe 'there may be trouble ahead'
• Can you justify these beliefs?
• No? Put it on hold (no project!)
• Yes? Predict and explain the problem situation.

Motivation 3 - Initiative - the desire to improve matters

• The status quo appears satisfactory
• You believe you can make worthwhile improvements
• Can you justify these beliefs?
• No? Put it on hold (no project!)
• Yes? Describe and explain the potential for improvement.

3. Objective & Proposal

Though distinct sections, the Objective and Proposal should be written as a pair, and must be entirely consistent with each other or the bid will fail. The Objective conventionally comes before the Proposal in the Statement of Case, giving the appearance of the project being Objective-led. However, in practice, the Objective really comes last as it is merely the description of the envisaged outcome of the Proposal.

The Objective -

• quantifies the realistically achievable outcome of the proposed solution to the problem identified in the background
• is set in the future and assumes the project's successful implementation
• is not concerned with details of implementation

The Proposal -

• offers a solution to the problem in order to meet the objective
• does not restate the problem
• does not go into operational detail of method, timescale etc.

4. Alternatives

The Statement of Case should have a section for alternatives to the proposal. It is included to demonstrate that the scenario has been analysed in depth and to avoid the embarrassment of not having considered an obvious alternative when it comes to the Finance Meeting.

Alternatives are refuted by demonstrating, quantitatively if possible, that they are inconsistent with the stated objective. As the objective is, by definition, the outcome of the proposal, all alternatives should be easy to refute.

The do nothing option (null option) should project the problem described in the background into the future and either quantify the cost or demonstrate other unacceptable consequences.

Other options should be selected with care. Time-wasters should be avoided as they discredit the work. Select only those options (one or two) that at first sight seem reasonable. You include them and refute them to show that they have been correctly analysed.

5. Benefits

The Principal Benefit is often similar to the objective, except that it is described in isolation, i.e. pure benefit with no mention of associated costs or other disadvantages.

The same applies to additional benefits. The list should include only the substantial benefits, nothing that appears contrived or trivial.

6. Disadvantages

These should be specific disadvantages resulting from the proposal's implementation, e.g. the unavoidable removal of a useful facility.

7. Consequences

This refers to longer term knock-on effects. In particular, will this project necessitate further, otherwise unforeseen, project work?

8. Finance

It is best to include a detailed financial analysis as the first appendix and to present only a summary of the key points in the body of the main document. The financial analysis is normally written by an accountant (using information provided by the Project Team) and will include details of capital, operating and staff costs, allocation of funds, and probably a discounted cashflow analysis taking account of depreciation and inflation.

9. Method

Method refers to the project management and control systems that will be followed, not to the physical implementation methods. It therefore deals with the process of the project, not the content.

10. Details

This section is arguably misnamed. It should identify the natural subdivisions of the work into "work packages" and briefly describe each package. (The same subdivisions should be used in the timetable.) In particular, it should identify the essential order of implementation.