What is 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!
The Statement of Case
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 Statement 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:
Writing the Statement of Case
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 –
- preempt 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 preempt 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.