Introduction

This is an excellent place at which to pause for a tour of PRINCE2’s Business Case theme and its analysis techniques. They’re put to good use at the next step: Initiation Stage. This is when the opening view of a project’s justification is developed in detail, and then subjected to closer scrutiny.

The theme is an expansion upon the principle of continued business justification. In addition to advice on the initial preparation of a Business Case, there’s an explanation of how this is then maintained and kept under review. Guidance is also given on benefits measurement, and the preparation of plans to track benefits delivery both during a project and after it has closed.

The approach advocated by PRINCE2 is based on a common method of making business decisions: evaluating the balance between costs, benefits and risks. For a project to run, the benefits must outweigh the costs involved and the risks that will be taken.

With a nod to PRINCE2’s product focus, it’s only right to start with the key deliverable: the Business Case.

What’s in a business case?

A PRINCE2 project explains the rationale for its existence in a Business Case document. This records the reason for undertaking the venture, and acts as the ultimate reference point for all important project decisions. For example, if a call is needed on whether a product sits inside or outside of scope, or there’s doubt about a requirement’s priority, the impact on the Business Case is the yardstick used for arriving at the right conclusion.

The fundamentals of a PRINCE2 Business Case are:

• the reasons why the project is required;
• the recommended option for the meeting requirement, and why this is best;
• the expected costs and benefits, and key risks involved;
• taking into account the above, the overall value of the project.

All of the above need to be described in terms that its intended audience can understand, and presented in a way that’s consistent with any established standards within the organisation.

Business case – table of contents

A Business Case documents the business justification for a project. It would typically include the following sections:

Section	Typical contents
Executive Summary	A short (one page) summary of the business justification for the project; covering the recommended option and its costs, benefits and risks
Background	The background to the project and an overview of the analysis work conducted
Project Need	A description of why the project is needed, explaining how it’s aligned to the overall strategy of the organisation
Recommended Option	A clear description of the business option being recommended and a summary of other discounted options, along with their relative merits and drawbacks. For the recommended option, the high level time-line for project and benefits delivery
Costs	An account of all of the resources (e.g. financial and people) that will be needed: (a) to deliver the project; and then (b) to operate and maintain its outputs over the period covered by the Business Case. A description of how the resources will be funded or obtained
Benefits	An assessment of the expected net benefit of the project. This includes identification of positive benefits and negative consequences (dis-benefits)
Risks	Identification of key risks to project delivery and benefits attainment; with estimates of their probabilities and impacts, and proposed mitigations
Investment Appraisal	An assessment of the value of the project through an analysis of costs, benefits and risks. A description of any factors which would have a significant impact on the analysis if they deviated from expectations. Objective conclusions as to the strength of the Business Case
Assumptions and Dependencies	A list of any significant assumptions that have been made during preparation of the Business Case, and identification of external dependencies

With the Executive taking overall responsibility, the Business Case is prepared in outline form during Pre-project and then developed in detail at Initiation Stage. It’s subsequently kept up to date all the way through to closure.

The Executive has overall responsibility for the Business Case, with the Senior User owning the benefit descriptions. The analysis and authoring of the document can be delegated, for example, to a business analyst or the Project Manager. The Project Assurance team may also have some useful expertise to call upon, such as advice on financial appraisal techniques.

Keep the Executive at less than arm’s length from the Business Case. Use their knowledge of the audience to shape what’s included and how this is presented. Ensure they’re 100% bought into the final result too. Your lead salesperson needs to be convinced to be convincing!

Initial assessments of timescales, costs and risks are provided through the preparation of a Project Plan by the Project Manager. This exercise contributes information for the recommended option, and for the primary alternatives that have been discounted. A degree of iteration between the Business Case and Project Plan can be expected; as planning information helps to shape business alternatives, and refined options are reflected in the developing plan.

The planning process also adds to the list of assumptions and dependencies. Once the project is underway, data are regularly refreshed with actual values and revised forecasts.

Risks

The third leg of the Business Case argument is risk. This deals with possible events that would negatively or positively impact costs and/or benefits. The assessment encompasses risks to delivery and to successful on-going operational use of the results.

The first port of call is the project’s Risk Register. This source is also assessed during construction of plans, with identified threats and opportunities helping to shape the approach. This is an example of iteration between the planning process and development of the Business Case. For example, the cost of eliminating an adverse risk completely may prove prohibitive, and so some toing-and-froing would be required until the best compromise is found between level of investment and risk exposure.

The Business Case highlights the key threats to, and opportunities for, the forecast benefits at the price quoted. It also summarises the overall risk profile.

When presenting negative risks, in the same breath explain what’s included in the plan to manage them. This inspires significantly more confidence in your audience than a simple list of what might go wrong.

Techniques for describing benefits

To be compelling, a Business Case has to be crystal clear about the benefits that it’s claiming. It also has to have credibility. Experience shows that vague or unsubstantiated claims don’t play well with senior managers, and are likely to result in a swift ‘no thanks’ in response.

PRINCE2 gives the job of describing benefits to the people who should be best placed to hit the mark: the people who’ll specify and then use what the project will deliver. The Senior User holds overall responsibility for specifying the expected benefits. In addition, each benefit is assigned an owner, who is then accountable (along with the Senior User) for delivering the promised benefits. This accountability certainly focuses the mind and encourages realism.

Looking for a way to tell your benefits story? Try summing up the achievements you’re after with answers to the following questions:

• What’s the current problem?
• What’s going to be done about it?
• What’s the intended outcome?
• How will that benefit us?

PRINCE2 recommends that all benefits are expressed in a way that’s measurable; including those that are non-financial. Benefits which are quantifiable in monetary terms are relatively straightforward to describe; for example ‘an increase in value of sales by 10%’. Other non-financial benefits can be quantified too, for example, ‘halving the average number of accidents per month’.

Sometimes it can be challenging to produce practical direct measures. Imagine that a manufacturer wants to improve its factory’s emergency evacuation plan. The expected benefit is a reduced probability of injury in the event of a catastrophe. Putting this into direct quantifiable terms would require detailed knowledge of how workers would respond to a whole range of emergency scenarios – both now and after the improved plan is implemented. This information is unlikely to be available, so it’s reasonable to identify some indirect measures of benefit delivery. This might include demonstrating a 100% target of staff receiving improved emergency training within the previous 12 months, and evidence of successful evacuation exercises being run at least every 6 months.

To be of value as part of the Business Case, it must be practical to take an initial baseline measure and then to repeat this once the benefit is believed to be delivered. If this isn’t feasible, there’s no real point in including the claim since no one will ever know if it’s been achieved.

Does a ‘benefit’ make it into the Business Case? Only if it is:

• Quantified: it incorporates a tangible measurement.
• Measurable: there’s a practical way of measuring it – both before and after the project has delivered.
• Owned: someone appropriate has agreed to take responsibility for delivering it.
• Linked to the project: there is a clear connection with the project’s outputs and the impact that these will have.
• Linked to the organisation: it’s consistent with the wider aims and objectives of the organisation.

There should be a traceable link between a project’s benefits and its products. This provides a handy cross-check. Every product needs to contribute to at least one benefit – either directly or indirectly – or it has no useful purpose. Similarly, it should be clear that each claimed benefit can be achieved through use of the proposed products. Understanding this relationship also helps future decision making; for example, when debating scope or assessing the impact of a fumbled product delivery.

Use the list of benefits to sharpen up your quality targets. If achieving a return demands a specific capability or feature, make sure this gets a specific mention in Product Descriptions and/or acceptance criteria.

Investment appraisal

If an overall value can be put on a project, the Executive is lent a hand when determining whether to proceed or to call a halt. These data also allow a like-with-like comparison between one proposal and another.

The source information needed to arrive at this value lies in the cost, benefit and risk analysis undertaken. There is a variety of investment-appraisal techniques for comparing total costs and net benefits, and for including a quantification of risk. PRINCE2 doesn’t prescribe the techniques to use, and so these are selected based on the nature of the project and standards set by the organisation.

Investment appraisal techniques

Here’s a simple scenario to illustrate some metrics that can be used within a financial Business Case.

A project has implementation costs which will all be incurred in Year 1. From Year 2 the outputs are used and this turns a profit – albeit with an uplift in operating costs. This Business Case is being considered over a five-year timeframe.

Three metrics are calculated:

• Net benefit = the value of the benefits (profit) less implementation costs and increased operating costs.
• Return on investment = the profits expressed as a proportion of the costs (implementation and operating).
• Payback period = the time that will be required for the investment to break even.

In this example, there’s a net profit over five years (6,000) and a healthy rate of return (40%). However, some investors might be put off by how long they’d have to wait to be up on the deal (more than four years).

The relative weight attached to costs, benefits and risks varies from one organisation to another. For example, if you’re strapped for cash, a proposal that requires significant up-front investment will be a non-starter even when there’s an attractive long-term prize to be won. The desired balance between these factors can also alter over time. So a change in fortune or an evolving attitude to risk might open up options that weren’t previously on the table.

The cost and benefit figures plugged into the investment appraisal are only estimates. So what if they turn out to be wrong? This is a question addressed by a sensitivity analysis. This explores the impact that estimate variations have on the overall strength of the Business Case, and uncovers the factors that exert the biggest influence. Attention can then be focused on the relevant figures’ level of accuracy and reliability. That way, the overall project value can be calculated for a range of credible scenarios, and any important health warnings attached.

A measure of success

The time and effort spent crafting benefit descriptions, constructing a Business Case, and weighing one option against another counts for little if this remains a purely academic exercise. Some hard data are called for if a project’s true worth is to be established.

Consequently PRINCE2 insists that a Business Case is accompanied by a plan to track benefits delivery. The Benefits Review Plan, as it’s known, explains how and when benefits will be measured and who’s responsible for this.

There’s one thorny issue to be cracked: most benefits for most projects are finally attained some time after closure. So there’s a real risk of a Business Case being quietly forgotten once the team members have headed off in different directions. PRINCE2’s solution is two-fold. First, the Benefits Review Plan sets out all of the required inspecting and reporting activities – not just those scheduled for the period when the project is still active.

Second, responsibilities are defined up-front to ensure that the benefits-tracking baton gets passed on as part of closure. These are assigned to a part of the organisation that represents a logical long-term choice for benefits assessment work. In fact, the duty could be taken on centrally from the outset. If not, the Executive initially starts off in the driving seat.

The Business Case analysis provides much of the information needed for the Benefits Review Plan. The practicalities of obtaining benefit measures are considered, and a decision is made as to when it’s best to record the baseline and then to follow up. In recognition of the fact that benefits delivery is unlikely to pan out precisely as intended, some additional effort is budgeted for. This anticipates time to investigate the extra benefits and unforeseen drawbacks that pop up, and to unpick why these have occurred.

Benefits review plan – table of contents

A Benefits Review Plan describes how and when the project’s benefits will be measured. It is first prepared by the Project Manager during Initiation Stage, and would typically include the following sections:

Section	Typical contents
Background	The background to the project and the benefits that it is expected to deliver
Planned Benefits	An inventory of the benefits, with their owners and measures
Benefits Measurement Plan	How benefits are to be measured, when measurements will be taken, and the resources required. Includes arrangements for reporting results and handing over tracking responsibilities at project closure
Benefits Baseline	A set of measurements that provide a baseline against which the impact of the project can be evaluated

The Benefits Review Plan is maintained through the project with information on benefits delivered to date and revised forecasts of future benefit delivery.

It’s recommended that the Benefits Review Plan is kept distinct from other plans, so that its activities can easily be separately managed.

Business case lifecycle

The Business Case is a thread that runs the full length of a project. Its lifecycle starts with the issuing of a project mandate. From there it runs all the way from initiation through to closure, and then on to final benefits delivery. PRINCE2 summarises the set of activities involved as:

• Develop: build the Business Case so that initiation and delivery go/no-go decisions can be made.
• Maintain: as delivery progresses, update the analysis with actual data and revised forecasts.
• Verify: formally revisit the Business Case at defined review points to assess whether or not a business justification still exists.
• Confirm: assess whether expected benefits have been achieved, and revise future benefit forecasts.

Business Case development spans Pre-project and Initiation Stage, resulting in the outline and detailed versions respectively. Once delivery is underway, the detailed Business Case is maintained with actual data and revised forecasts as they become available.

The Project Board verifies that the project is still worthwhile at all key decision points. This includes the checkpoints for moving to initiation and to delivery, and at each stage boundary. It’s also an important consideration when new risks or issues are indentified and their impacts investigated.

At all times a PRINCE2 project must be:

• Desirable: taking into account the estimated resources required and the risks involved, the expected benefits provide an attractive return.
• Viable: there’s confidence that the project will deliver its products.
• Achievable: there’s good reason to believe that if the delivery commitment is met, the promised benefits will be attained.

If at any time it doesn’t meet these criteria, the project must be changed or stopped.

The Executive is ultimately accountable for ensuring that the project remains worthwhile. The assistance of the assurance function is enlisted to ensure the information on which this judgement is based is accurate.

Figure 5.1 Business case lifecycle

At the end of each delivery stage, and adhering to the course of action set out in the Benefits Review Plan, benefits are confirmed. This entails:

• taking measures for those benefits which are due to be delivered;
• reconsidering the estimates for remaining benefits;
• making refinements (as required) to the plan.

Measurement will almost certainly have to run on beyond project closure, to allow for a full assessment to be made of the extent to which forecast benefits are achieved.

Summary

A Business Case is the driving force behind a PRINCE2 project, and it’s used as the reference point for all major decisions. It summarises the outline justification for initiation, and then the detailed argument for advancing to delivery. As each stage concludes, and if circumstances change at any point, the Business Case either continues to stack up or the project is wound up.

With input from the Project Plan, the Business Case is built upon an assessment of costs, benefits and risks. A wide perspective is taken. Dis-benefits are added to the equation, and the analysis looks beyond implementation and ahead to operational use.

Making claims about future gains is fine, but achieving them is what really matters. PRINCE2 pushes for objective evidence to be produced. So the upsides have to be measurable – both before and after – to be included within the Business Case. Furthermore, a user representative is needed to endorse each benefit on the list. Finally, a Benefits Review Plan ensures that responsibilities for tracking the impact made aren’t dropped post-closure.

• A PRINCE2 project records its business justification in a Business Case document.
• The Executive is accountable for the Business Case, with the Senior User taking overall responsibility for the definition and achievement of benefits.
• Develop, maintain, verify and confirm: a Business Case lifecycle runs for the duration and even beyond closure.
• To make the grade, benefits must be: quantified, measurable and owned.
• The Benefits Review Plan is where benefits measurement and reporting responsibilities are recorded.