Month: June 2012

The Business Case is one of 7 PRINCE2 Themes (things that must be attended to throughout the life of a project).

The Purpose for the Business Case

A basic principle of PRINCE2 is “Continuous Justification”, which asks the question, “is the project (still) worth investing in?”. The project’s Business Case documents the answer to this question.
Different projects will measure success is different ways, for example ROI or legislative compliance.  Nevertheless, all projects must be evaluated to see if the right  approach is being taken to achieve benefits with available resource. In order to do so, the Business Case provides the means to evaluate the project on whether it is:

• Desirable = Is the project worth investing in, given its anticipated costs, benefits and risks (CB&R)?
• Viable = Is the project possible? Will it produce the intended products?
• Achievable = Will the products of the project provide the intended benefits?

Delivering a project’s products doesn’t mean benefits of these products will be realised. For this reason, it is important to distinguish between the project’s products (or outputs), outcomes and  benefits.

• Output = a specialist product of the project, e.g. new web site
• Outcome = result of using project’s outputs , e.g. more sales
• Benefit = measurable change that is advantageous to stakeholders, e.g. increased profits

In  contrast to a project’s products, its outcomes (and therefore benefits)  may not occur until some time after the project closes. To avoid the  danger of loosing sight of benefits and focusing on products, the  Business Case must make the relationship of products, outcomes and benefits explicit.

The Contents of the Business Case

The Business Case must contain sufficient information to determine if project is DVA i.e. will give a ROI (return on investment). A typical Business Case will contain:

1. An executive summary
2. Reasons for undertaking the project, including options that have been considered
3. The anticipated benefits and and dis-benefits
4. Estimates of costs and time-scales
5. A risk profile
6. An investment appraisal

The Reasons for the Project and the Options Considered

This section outlines the reasons that the project is required, given corporate strategies and objectives. These reasons may be derived from the Project Mandate, but clarification should be sought if that is not the case.
The options considered should be included in sufficient detail for stakeholders to determine which gives the best ROI for business. It will include estimated CB&R (costs, benefits and risks for each option).
PRINCE2 recommends that options should include:

• Doing nothing (default)
• Doing the bare minimum
• Doing something

As the project progresses, the Business Case will be continually updated with regard to CB&R.

Expected Benefits and Dis-benefits

The project’s products are determined by the benefits desired from the project. The business case should list the tangible and intangible benefits anticipated from the selected option. (Intangible benefits might be “increased employee morale”)
Details of each benefit should include:

• How the benefit fits with corporate objectives and strategy
• How It relates to the projects outputs and outcomes
• How much benefit is expected (with tolerances)
• How the benefit will be measured (even for intangible benefits)
• Who benefits

To enable continuous justification of the project:

• The relative importance of benefits should be recorded
• Benefits should be objectively quantifiable

In addition dis-benefits should be included in the Business Case. Dis-benefits are those perceived as negative outcome by at least one stakeholder. The difference between risks and dis-benefits is that risks are uncertain whereas dis-benefits are expected.

Time-scales and Costs

Information about time-scales will include:

• When resources will be required
• When benefits will be realised and verified
• The earliest / latest feasible project start / end dates

Information on costs will include:

• Project costs based on the Project Plan
• Ongoing operational and maintenance costs
• The basis of costings
• Funding arrangements

The time-scales and costs in the Business Case are used as basis of tolerances as the project progresses.

Risk Profile

Projects are uncertain, and therefore risky. Risks can impact both benefits and resources both positively and negatively. The justification needs to take major sources of risk into account, so a summary of risks will be included in the Business Case, and major risks will be. The recording of risk should  focus on benefits, and should therefore includes both project and ongoing operational / maintenance risks.

Investment Appraisal

An Investment Appraisal is a comparison of costs and benefits over a period of time (a fixed period, usually in years, or life of product). It will includes both project costs and ongoing costs, and is intended to demonstrate the value of the project to stakeholders.

The Life of the Business Case

There are 4 stages in the life of a Business Case:

1. Development
2. Review
3. Maintenance
4. Confirmation of Benefits

Developing the Business Case

Initially, the information in the Business Case is based on approximations. These estimates should be iteratively refined as more is learned, and this may lead to project replanning.

Process	Development of the Business Case
SU	An Outline Business Case is drawn up based on the Project Mandate. The Outline Business Case forms part of the Project Brief.
IP	The detailed Business Case id based on the Outline Business Case and Project Plan, and may include information from the Project Brief and Risk Register. The Business Case forms part of the PID.

Reviewing of the Business Case

At various times throughout the project, the Business Case will need to be revised and re-evaluated to see if the project is still justified. This will occur:

When	Why	Who
At the end of the SU process	To ensure project is worth investing in	Project Board
At the end of the IP process	To authorise the project	Project Board
As a result of changes to the project’s anticipated costs, benefits or risks	To assess the impact of the revision on the project	PM
Following an exception	To approve an Exception Plan	Project Board
After each stage	To authorise the next stage	Project Board
During final stage	To ensure project will provide expected benefits	PM
As part of the benefits review	To ensure that benefits are realised	Corporate / programme management

Maintaining the Business Case

The Business Case is continually updated regarding CB&R. This is especially important at the end of each stage before the next is authorised. Updates will include benefits already realised as the project progresses.

Confirming the Benefits

Most benefits are realised after the project has closed, so a mechanism is required to confirm them after the end of the project. This is the purpose of the Benefits Review Plan, which is based on the Business Case. The Business Review Plan will include:

1. Expectations regarding the scope, timing and responsibilities associated with review.
2.  Information required to confirm that the benefits of the project:

• What benefits are expected
• What (objective) measures will be used to confirm these measurements
• What baseline measures will be taken
• How measures will be collected

The Business Review Plan may be updated during the project if benefits are realised before it is closed.

Responsibilities

Corporate or Programme Management

• Provides the Project Mandate, upon which the Business Case is based
• Ensures that the Benefits Review takes place

Executive

• Ensures the Business Case and Benefits Review Plan are written and approved (doesn’t necessarily write them)
• Secures funding
• Ensures that the benefits specified by the Senior User represent ROI, are aligned to corporate strategy and that they are realizable.

Senior User

• Specifies the benefits
• Realizes benefits by using products
• Confirms their realization in the Benefits Review
• Individual beneficiaries may be recruited to support the Senior User

Project Manager

• Assists in writing the Business Case and Benefits Review Plan
• Performs an Impact Analysis following changes in CB&R
• Assesses the Business Case at the end of each Stage
• Reporting benefits realised during project in the End Stage Report

Project Assurance

• Assist in developing the Business Case
• Monitor the Business Case to ensure that events outside the project have no impact upon it
• Verifies and monitors the Benefits Review Plan

Introduction

PRINCE2 is founded upon 7 principles (made explicit in the 2009 refresh) that underpin best practice in project management. These principles are therefore fundamental to PRINCE2, and should be used as a guide to applying of the PRINCE2 methodology. A project cannot be said to be a PRINCE2 project if any of these principles is neglected. They provide the basis for decision making throughout the project’s life-cycle.

The 7 Principles (JERSEPT)

1. Continued business justification
2. Learn from experience
3. Defined roles and responsibilities
4. Manage by stages
5. Manage by exception
6. Focus on products
7. Tailor to suit the project environment

Continued Business Justification (2.1)

There should be a clear ROI (return on investment) for any project, both at the start and throughout its life-cycle. Even compulsory (legislated) projects require justification of the approach taken to solve them. The justification may change as the project progresses, but it should remain valid. If a project becomes unjustified it should be stopped.
The justification is documented in the Business Case, which includes the resources required and the expected benefits for the project. The business case should, of course, be aligned with corporate strategy.

Learn from Experience (2.2)

Throughout the project, all participants should seek out and document learning opportunities. A lesson that doesn’t result in change is not a lesson learned!
At the start of a project, the project team should:

• Consider seeking external expertise
• Review similar past projects

As the project progresses, they should:

• Include lessons learned in all reviews

And at the close:

• Pass on learning at the end of the project

Defined Roles and Responsibilities (2.3)

For a project to be successful, it is essential that:
1. the right people are involved in the project
2. these people know what is expected of them
3. what they can expect from others
The project must have a clearly defined management team who represent the interests of:

• The business – to ensure that the project is justified in terms of ROI
• The users – to ensure that the project produces the intended benefits
• Suppliers – to ensure that the project is feasible from a resourcing perspective

Manage by Stages (2.4)

Every project has a “Planning Horizon”, which is the limit beyond which meaningful planning cannot be undertaken.
To tackle problems associated with this, PRINCE2 divides work into discrete Management Stages. Detailed planning can be undertaken for current stage, whereas plans for the whole project can remain in outline. A significant advantage of this approach is that learning from earlier stages can be carried forward into later stages.
Between each stage are control points where senior management (i.e. the Project Board) undertakes to:

• assess the previous stage
• verify Business Case
• review plans for next stage
• decides whether or not to continue with the project

Longer stages therefore provide less control management control, whereas shorter stages require more work from management.
A PRINCE2 project as a minimum of two stages:
1. The Initiation Stage
2. One additional Management Stage, which includes project closure.

Manage by Exception (2.5)

It is essential that decisions are made at the right level in the organisation, and that each level of authority:

• Has delegated authority to manage at that level
• Is accountable to higher levels of authority
• Can delegate to lower levels in order to use time effectively.

To achieve this, PRINCE2 projects define tolerances at each management level for:

• Time
• Cost
• Quality
• Scope
• Risk
• Benefit

Changes inside tolerance are dealt with at that management level without bothering higher levels. Issues outside tolerance are Exceptions, and are reported to level above. For example, the Project Board normally only hears from the Project Manager in regular reports, unless there is an Exception in which case they are alerted immediately.

Focus on Products (2.6)

A project should focus on outcomes rather than activities. Without clearly defined outcomes, there are no shared expectations. As a result, the project risks:

• rework
• scope creep
• acceptance disputes
• customer dissatisfaction

To mitigate these risks, PRINCE2 Product Descriptions detail outcomes (esp. for quality) and acceptance criteria. Product Descriptions should define such things as the product’s purpose, composition, derivation, format, quality criteria and quality method.
Product Descriptions define the scope of project, and provide the basis for planning resource requirements, dependencies and schedules.

Tailor to Suit the Project Environment (2.7)

PRINCE2 is applicable to all project types, but approach and effort must be tailored as appropriate the project’s needs: environment (e.g.. existing management structure), size, complexity, importance, capability and risk (e.g.. reporting frequency, emphasis on risk).
The Project’s Project Initiation Document (PID) should describe how PRINCE2 will be tailored for that project.