Overview

If a satisfactory Business Case does not exist a project should not be started, equally if a Business Case which was justified at the beginning of a project disappears once a project is underway the project should be stopped. Developed at the beginning of a project it is then revisited at each key decision point (i.e. End Stage Assessment).

A Business Case should be a thorough document detailing the affect the project will have on the business. It also includes Risks, benefits, savings and costs. Supported by other documents such as the Risk Log it should also, at a minimum, have these topics:

• Reasons - why the outcome is needed
• Options - provides assurance that other options were looked at
• Benefits - described in measurable terms (responsibility of the Executive.)
• Risks - how these could effect the delivery of the outcome.
• Costs and timescales - perhaps redefine these in the business case.
• Investment appraisal (evaluation) - balances costs with the expected benefits over time, includes evaluation.

The Project Executive is the owner of the Business Case. It is their responsibility to ensure that the Business Case is aligned with Business and Programme objectives. It may require a team or in small projects just one person to develop it. That which is created should be given formal approval at the end of IP Initiating a Project. This is not a stagnant document however and may be changed during the course of the project, reflecting decisions made by the Project Board, business conditions, corporate decisions and the results of the project thus far. The Business Case is updated at regular intervals, least during each stage boundary: SB3 Updating a Project Business Case.

Processes (and sub processes) that effect the Business Case:

• SU4 Preparing a Project Brief - 'Outline' Business Case created in the Project Brief and brings it to a basic, recognisable level, developed from the Project Mandate (this is the first sub process to work on the Business Case within PRINCE2).
• IP3 Refine Business Case and Risks - where the full development of the Business Case is refined and updated.
• IP6 Assembling a PID - incorporated into the Project Initiation Document (PID).
• DP1 Authorising Initiation - where the Business Case is reviewed to decide if the project is worthwhile and viable.
• DP2 Authorising a Project - where the Business Case is approved along with the commencement of the project.
• SB3 Updating a Project Business Case - where the Business Case is updated to reflect timing and progress to date as well as business influences (Company direction, corporate decisions/directions.)
• SB5 Reporting Stage End - where it is revised for each End Stage Report.
• DP3 Authorising a Stage or Exception Plan - the revised form affect the Project Board's decision to approve subsequent stages.
• DP3 Authorising a Stage or Exception Plan - where the Business Case is reviewed to decide if the project should continue to the next stage.
• CS4 Examining Project Issues - Project Issues need to be revised to evaluate their impact on the Business Case.
• CS5 Reviewing Stage Status - Status of the project is reviewed against the Business Case.
• CP2 Identifying Follow-on Actions - the Business Case is used to provide the agenda for the Post Project Review Plan.

Tips

• Involve all concerned (stakeholders) about the Business Case to ensure that commitment is gained from everyone.
• Be sure to outlined in the Communications Plan how stakeholders can voice concerns about it.
• Remember that some will require significant work, especially if they are expected to have a major impact on the business.
• This is NOT optional - even in the smallest projects outlining a Business Case is a good way to prevent unrealistic expectations or promises.
• In Customer / Supplier situations there are always TWO Business Cases - the Customer's and the Supplier's - in PRINCE2 the Customer's Business Case is referred to.

Notes

• Justification for undertaking the project and justifies expenditure (based on cost and benefits)
• Topics to cover include reasons, benefits, costs, timescales and investment appraisals
• In PRINCE2 the Project's Business Case is from the Customer's perspective
• Corresponds to the Project Plan
• Business savings and benefits need customer approval
• Usually supplied by the customer, owned by the Project Executive
• Included in the Project Initiation Document (PID)
• Derived from the Project Mandate, Project Brief, Project Plan and the Customer
• Processes using the Business Case include SU Starting up a Project and IP Initiating a Project.

Case studies and examples

• GP-GP Record Transfer Project Initiation Document (UK NHS).

Related links

• Search our forum for 'Business Case'
• SU Starting up a Project
• Project Initiation Document
• Project Mandate
• Project Brief
• Project Plan
• Customer.

• Project Mandate
• Post Project Review

• Acceptance Criteria
• Customer's Quality Expectations
• Daily log
• Initiation Stage Plan
• Job Description
• Project Approach
• Project Brief (Terms of Reference)
• Risk Log

• Business Case
• Communication Plan
• Configuration Item Record
• Configuration Management Plan
• Issue Log
• Lessons Learned Log
• Product Description
• Project Initiation Document
• Project Plan
• Project Quality Plan
• Quality Log

• Exception Report
• Highlight Report
• Off-Specification
• Project Issue
• Request for Change
• Work Package

• Checkpoint Report
• Team Plan

• End Stage Report
• Exception Plan
• Stage Plan

• End Project Report
• Follow-on Action Recommendations
• Lessons Learned Report
• Post-Project Review Plan

• Product Breakdown Structure
• Product Checklist
• Product Description
• Product Flow Diagram
• Product Status Account
• Project Plan
• Stage Plan
• Team Plan