A business case captures the reasoning for initiating a project or task. It is often presented in a well-structured written document, but may also sometimes come in the form of a short verbal argumentation. The logic of the business case is that, whenever resources such as money or effort are consumed, they should be in support of the business. An example could be that a software upgrade might improve system performance, but the "business case" is that better performance would improve customer satisfaction.

Business cases can range from comprehensive and highly structured, as required by formal project management methodologies, to informal and brief. Information included in a formal business case could be the background of the project, the expected business benefits, the options considered (with reasons for rejecting or carrying forward each option), the expected costs of the project, a gap analysis and the expected risks. Consideration should also be given to the option of doing nothing including the costs and risks of inactivity. From this information, the justification for the project is derived.
Review

At various stages in the project, the business case should be reviewed to ensure that:

* The justification is still valid,
* The project will deliver the solution to the business need.

The result of a review may be the termination or amendment of the project. The business case may also be subject to amendment if the review concludes that the business need has abated or changed, this will have a knock on effect on the project.

[edit] Formal business cases

Formal business cases are evaluated to ensure;

* the investment has value and importance
* the project will be properly managed
* the firm has the capability to deliver the benefits
* the firm’s dedicated resources are working on the highest value opportunities
* projects with inter-dependencies are undertaken in the optimum sequence.

[edit] Objectives

The business case process should be designed to be:

* adaptable - tailored to the size and risk of the proposal
* consistent - the same basic business issues are addressed by every project
* business oriented - concerned with the business capabilities and impact, rather than having a technical focus
* comprehensive - includes all factors relevant to a complete evaluation
* understandable - the contents are clearly relevant, logical and, although demanding, are simple to complete and evaluate
* measurable - all key aspects can be quantified so their achievement can be tracked and measured
* transparent - key elements can be justified directly
* accountable - accountabilities and commitments for the delivery of benefits and management of costs are clear.

The principal purposes of the formal business case process are:

* introduce a way of thinking that causes people with the authority to recommend projects to firstly consider their value, risk and relative priority as a fundamental element of submitting the project proposal
* require those proposing a project to justify its value to the firm and to self-cull any proposals that are not of demonstrable value
* enable management to determine if the project proposed is of value to the business and achievable compared to the relative merits of alternative proposals.
* enable management to objectively measure the subsequent achievement of the business case’s benefits.

[edit] Generating a business case

Generation of the business case should not be mechanical. Indeed, the case must demonstrate that the issues have been thought through, the full benefits will be realised on time, any technical aspects have been thoroughly evaluated and costed, and track and measure their achievement.

A business case should contain some or all of the following information types (depending on the size, timing, scale and availability of information):

* Reference - Project name/reference, Origins/background/current state
* Context - Business objectives/opportunities, Business strategic alignment (priority)
* Value Proposition - Desired business outcomes, Outcomes roadmap, Business benefits (by outcome), Quantified benefits value, Costs/ROI Financial scenarios, Risks/costs of not proceeding, Project risks (to project, benefits and business)
* Focus - Problem/solution scope, Assumptions/constraints, Options identified/evaluated, Size, scale and complexity assessment
* Deliverables - Outcomes, deliverables and benefits planned, Organizational areas impacted (internally and externally), Key stakeholders, Dependencies
* Workload - Approach, Phase/stage definitions (Project (change) activities, Technical delivery activities, Workload estimate/breakdown, Project plan and schedule, Critical path)
* Required resources - Project leadership team, Project governance team, Team resources, Funding
* Commitments (required) - Project controls, Reporting processes, Deliverables schedule, Financial budget/schedule

[edit] Public sector projects

Most public sector projects are now subjected to a business case. This leads to political argument between socialists and non-socialists. The socialist view is that a business case is irrelevant to a public sector project. The test is: "Is the project in the national interest?". If it is, it should go ahead and the money should be raised through taxation. There are now few socialist governments left in the world so most public sector projects are now subjected to a business case. This may help to keep taxes down but it also means that some important projects are delayed or cancelled. The most striking example in the UK is railway electrification. This is clearly in the national interest on the grounds of energy security and environmental protection but there is no national programme. Some electrification is taking place but a separate business case has to be made for each project (e.g. Heathrow Express and Crossrail) so progress is very slow. Uncertainty about the extent of future electrification is also hampering the Intercity Express Programme