The business case is the central document to a project or programme life cycle. The reason for defining a life cycle with phases, tranches and/or stages is to enable go/no go decisions to be made that prevent wasted investment.
These decisions are primarily made based on the viability of the business case.
Templates:
- Background
-
This initial section will explain the context of the project or programme. Any assumptions made in preparing the business case will be documented here along with constraints and dependencies on other projects or programmes. Any impact that this work will have on other projects or programmes should also be noted.
- Project or programme summary
-
All aspects of project or programme delivery will be summarised at a sufficient level to enable the justification for the work to be understood.
-
The summary will typically comprise:
- Scope – summary of objectives, in terms of outputs, outcomes and benefits as appropriate;
- Schedule – high level schedule with start and finish dates for major sections of work such as phases, tranches, stages or projects within a programme;
- Finance – funding arrangements and a summary cash flow;
- Risk - Major risk events and the overall risk profile;
- Resource – sources of resource, contract arrangements, summary volumes;
- Change – breadth and depth of change required;
- Stakeholders – key supporters and opponents.
- Justification
-
This is the key section. It weighs the benefits of the work against the investment needed to achieve them. In this context the terms benefits and investment can be broadly interpreted.
-
The simplest justification will be purely financial. If the benefits have a certain cash value and the investment cost is less, then the work can be justified.
-
However, justification is often not that simple. A project or programme will have to balance the ‘investment’ in terms of risk taken; it may need to consider ecological ‘costs’; intangible benefits may need complex valuations; it may simply be that the ‘do nothing’ option has unacceptable consequences.
One of the tricky parts of writing a business case is where to place all the information. For example, should:
- An assumed constraint be placed in assumptions or constraints?
- An uncertainty about funding be placed in the finance or risk section?
- A reference to another project that affects the benefits be placed in dependencies or the change section?
In the outline business case it doesn’t matter too much as long as all the information is in there somewhere. When it comes to the full business case, the document is summarising other more detailed documents. The allocation of information in the business case must therefore reflect those detailed documents. For example, anything derived from the risk register should be summarised in the risk section of the business case and so on.
