Business Case - Introduction

The business case documents the justification for undertaking a project and consists of:

•   Summary

Describe in simple terms what the project is, with a brief outline of the desired outcomes / benefits and the methods to be employed to achieve those outcomes.

Plus any of the following elements that are relevant to this project:

•   Reasons / Background

Why this project is required.

If this project is resolving a sensitive problem you can flag this section [and others] as hidden so that they do not appear in reports.

•   Business Options

What other solutions were considered and the analysis and reasons for choosing this particular solution over the others.

•   Expected Benefits

Describe in detail the benefits the project it to deliver and for how long they will be available. Identify any "in project" benefits (i.e. benefits delivered during the duration of the project).

If financial, include discounted cash value (DCV) over the period the benefits are projected to be available; these values would normally be broken down by period and in manner similar to that used by the organisation for short and long term budgeting.

If it will take X years for the cash benefit of the project to materialise then the value of each £100 of benefit will, in real terms, be worth less than £100 today. The DCV is what the benefit would be worth today and is used to calculate the real ROI not the simple mathematical one.

•   Any Disbenefits

Any outcome that is perceived as negative by one or more stakeholders.
Record any advice the Project Board has given to stakeholder(s) on handling or mitigating the effect of any disbenefit and their response / mitigation plan.
The difference between a disbenefit and a risk is that a disbenefit is a predicted outcome, whereas a risk has a degree of uncertainty i.e. it is a “maybe”.

•   Timescale

How long will the project take to complete, please be realistic rather than overly optimistic, factor in holidays and other types of absences.

•   Costs

A brief description of the projected costs, the method used to calculate them and of any on going operational and maintenance costs.

•   Budget

Has a budget been set by the customer / project board? Is the budget set in stone or does the project manager have a tolerance they can work within before having to come back to the sponsor for additional funding?

•   Funding

How is the project to be funded? Is any financial authority required before the project can start? Will the cash be there to pay everyone on time?

•   Investment Appraisal (ROI)

The result of comparing the aggregate of the benefits less:
disbenefits + ongoing and incremental operational costs + any additional maintenance costs + where appropriate, any depreciation.
The objective here is to be able to define the value of a project as an investment to give a Return on Investment figure.

•   Major Risks

A summary of the key risks associated with the project together with their likely impact and action plans should they occur.

Management Approach

If any of these sections are required you will need to click the MORE button at the bottom of the Business Case screen.

Most projects, especially expensive or risky ones, will require a formal method [approach] for dealing with situations or problems.

It is important to agree a strategy on how to approach these issues at the outset.

•   Communication

Describe the means and frequency of communication between parties, both internal and external to the project.

•   Quality Management

Define the means to be used to verify that the products [features] meet the project brief and are fit for purpose.

•   Risk Management

How risks are identified, assessed and pre and post event remedial action agreed. How risks are communicated to the parties that may be affected, including stakeholders.

•   Change Control

The procedure for handling change requests. Who can make a request, the format to be used, who can authorise changes, how all affected parties are to be informed, who / how documentation is updated.

•   Version Control

Projects involving any form of product design are likely to generate various designs or models before the final product is created. It is important to have an agreed and logical method of uniquely identifying each version.