6

Business case

This chapter covers:

•creating and maintaining the business justification

•the relationship between outputs, outcomes and benefits

•developing and managing a business case

•PRINCE2’s requirements for the business case theme

•investment appraisal techniques

 

6 Business case

6.1 The business case theme

Organizations undertake projects because they want to make measurable improvements in one or more aspects of their business. These measurable improvements are called benefits.

PRINCE2 projects deliver outputs in the form of products, the use of which results in changes in the business. These changes create outcomes. The outcomes allow the business to realize the benefits that are set out in the business justification for the project. Outcomes that are perceived as negative by one or more stakeholders are called dis-benefits.

Figure 6.1 shows the relationship between outputs, outcomes and benefits.

In PRINCE2, all projects must have a documented business justification. This sets out not only the reason for the project, but also confirms whether the project is:

•desirable: the balance of costs, benefits and risks

•viable: able to deliver the products

•achievable: whether use of the products is likely to result in envisaged outcomes and resulting benefits.

The business justification is usually documented in a business case.

The senior user(s) is responsible for specifying the benefits and subsequently realizing the benefits through the use of the products provided by the project. The executive is responsible for ensuring that those benefits specified by the senior user(s) represent value for money, are aligned with corporate, programme management or customer objectives, and can be realized. See section 7.2.1 for information about these roles and the project board.

It is a PRINCE2 principle that a project must have continued business justification. This requires that the business justification is not just developed at the beginning of the project, but that it is kept under regular review and updated in response to decisions and events that might impact the desirability, viability or achievability of the project.

If the business justification ceases to be valid then the executive must stop or change the project following review by the project board.

6.2 PRINCE2’s requirements for the business case theme

To be following PRINCE2, a project must, as a minimum:

•create and maintain a business justification for the project; usually a business case (PRINCE2’s continued business justification principle)

•review and update the business justification in response to decisions and events that might impact desirability, viability or achievability of the project (PRINCE2’s continued business justification principle)

•define the management actions that will be put in place to ensure that the project’s outcomes are achieved and confirm that the project’s benefits are realized (PRINCE2’s continued business justification principle)

•define and document the roles and responsibilities for the business case and benefits management (PRINCE2’s defined roles and responsibilities principle).

PRINCE2 requires that two products are produced and maintained for the business case theme:

•Business case Provides the costs, benefits, expected dis-benefits, risks and timescales against which viability is justified and continuing viability is tested. It is acceptable to use an alternative document such as a corporate business plan to replace the business case for part of the project lifecycle.

•Benefits management approach Defines the management actions that will be put in place to ensure that the project’s outcomes are achieved and confirm that the project’s benefits are realized.

In PRINCE2 the business case is developed at the beginning of the project. Throughout the life of the project the business case is reviewed and updated as it develops and evolves (see Figure 6.2). It is formally verified by the project board at each key decision point, such as at stage boundaries, and confirmed throughout the period that benefits accrue.

Appendix A, section A.2, provides a product description and suggested content for the business case.

In the context of Figure 6.2:

•Develop Means getting the right information upon which decisions can be made

•Verify Means assessing whether the project is (still) worthwhile

•Maintain Means keeping the business justification updated with actual costs and benefits and with current forecasts for costs and benefits

•Confirm Means assessing whether the intended benefits have been (or will be) realized. Confirming benefits will mostly take place post-project, although benefits may be realized during the project.

The business case is at the centre of any impact assessment of risks, issues and changes by asking the question: How will this risk, issue or change affect the viability of the business case and the business objectives and benefits being sought?

6.2.1 Developing the business justification

In PRINCE2 the executive is accountable for ensuring that the business justification is produced and approved. Development of the business justification may be delegated (for example, to the project manager).

If the project is part of a programme then an approved business justification may be provided as part of the project brief. Whoever is given the task of developing the business justification, it is important to ensure that they have the appropriate business skills required (e.g. understanding the difference between a cash-flow forecast, a profit-and-loss account and a balance sheet).

An initial version of the business justification should be derived from the project mandate as part of the starting up a project process if it is not provided by some other pre-project processes. Typically, this will be documented in a formal business case, although some organizations may use other documents, such as business plans. The initial business justification has to be approved by the project board in the directing a project process to initiate the project.

In most cases the project costs, timescale, products and risks will not be sufficiently understood to provide a robust justification of the project and this initial version will need further development and refinement as the project progresses. The initial version of the business justification is referred to as the ‘outline business case’ in the rest of this manual.

Typically, a more detailed business case will be developed from the outline business case during the initiating a project process. It might be that the business case will undergo further refinement across management stages as project costs, timescale, products and risks are further understood. This manual uses the term ‘detailed business case’ to describe this business case and its refinements; other approaches may use the term ‘full business case’.

6.2.2 Verifying and maintaining the business justification

Continued business justification drives all decision-making by ensuring that the business objectives and benefits being sought can be realized. The business justification must be reviewed and verified:

•at the end of the starting up a project process by the project board, to authorize project initiation based on a reasonable justification

•at the end of the initiating a project process by the project board, to authorize the project

•as part of any impact assessment by the project manager of any new or revised issues or risks

•in tandem with an exception plan by the project board, to authorize the revised management stage and the continuation of the project

•at the end of each management stage by the project manager, to determine whether any of the costs, timescales, risks or benefits need to be updated

•at the end of each management stage by the project board, to authorize the next management stage and the continuation of the project

•during the final management stage by the project manager, to assess the project’s performance against its requirements and the likelihood that the outcomes will provide the expected benefits

•as part of the benefits reviews (possibly by corporate, programme management or the customer), to determine the success of the project outcomes in realizing their benefits.

It is the responsibility of the executive to assure the project’s stakeholders that the project remains desirable, viable and achievable at all times.

6.2.3 Ensuring and confirming that benefits are realized

As shown in Figure 6.1, projects deliver outputs, the use of which results in outcomes in the business that provide benefits to the organization. The principle of this linkage is straightforward; however, reality is often much more difficult. In order for the benefits to be realized, the outcomes have to be achieved, which means that the outputs from the project actually have to be used and used in the way intended.

Many organizations will be able to identify projects that have produced products that were never fully utilized, organizational changes that were never fully implemented and IT systems that were never fully used. There are many reasons why this might be the case, including:

•The scope of the project explicitly excludes benefits realization. This will commonly be the case where the project is part of a larger programme and the project only delivers some of the products required to achieve the outcomes from the programme or project.

•Failure of the project team to fully understand everything that needs to be done to help the organization use the project product. For example, it is a common failure that project teams provide an IT system and training, but no post-training or ongoing support to ensure that any post-training issues are addressed.

•Commitment to the changes introduced by the project is either overtaken by more pressing business-as-usual priorities, or simply just fades.

•Parts of the organization were never fully committed to the changes.

In practice, benefits are seldom realized unless they, and the prerequisite business changes, are proactively managed during the life of the project, even if the outcomes and benefits realization are not within the project’s scope. If the project management team does not understand the benefits the project is to realize and the business changes (outcomes) needed, it is unlikely to be able to develop the right outputs and also unlikely to be able to build and sustain the commitment to and confidence in the changes during the project’s lifespan.

The senior user, who is responsible for specifying the benefits from the project, is also accountable for confirming that the forecast benefits are realized. This may involve a commitment beyond the life of the project as it is likely that many benefits will not be realized until after the project has closed. For this reason, it is usually advisable that the senior user comes from an area of the business impacted by the change.

This poses a dilemma because, when the project closes, the ‘temporary organization’ is disbanded along with the framework (and in particular the funding and resources) to carry out any measurement activities.

The benefits management approach defines the management actions that will be put in place to ensure that the project’s outcomes are achieved and to confirm that the project’s benefits are realized. It is first created by the project manager in the initiating a project process during the initiation stage and is submitted to the project board for approval when seeking project authorization. If corporate, programme management or the customer are to manage or participate in the benefits reviews, the project board may need to seek their approval.

The benefits management approach should be updated during each management stage with actual benefits achieved and any updates for benefits management activities or benefits reviews (whether within or beyond the life of the project).

The benefits management approach may be managed by the project, by corporate, programme management or by the customer, and is likely to be managed beyond the life of the project. PRINCE2 recommends that it is kept separate from the project plan and stage plans.

Any benefits that can be measured during the life of a project should be confirmed by the senior user for formal reporting by the project manager in the end stage report(s) and project closure report. When benefits can be reviewed during the life of the project, the benefits management approach should include appropriate mid-project benefits reviews. Any residual benefits should be re-examined and their forecast updated as part of the managing a stage boundary process.

Post-project benefits review(s) will involve corporate, programme management or the customer holding the senior user(s) to account by asking them to provide evidence of how the individual benefits allocated to them have been gained in comparison with those benefits promised to justify the cost and risk of the project when it was authorized. The post-project benefits review(s) will also review the performance of the project product in operational use and identify whether there have been any side-effects (beneficial or adverse) that may provide useful lessons for other projects.

By default, the executive is responsible for ensuring that benefits reviews are planned and executed, but there are circumstances where this may not always be the case.

For projects in a programme environment, the project’s benefits management approach may be produced and executed by the programme, as one of the roles of the programme is to coordinate the realization of the benefits of its projects.

For post-project measurement activities, the responsibility for benefits reviews will transfer from the executive to corporate, programme management or the customer as the project closes (as the reviews will need to be funded and resourced).

6.2.4 Business case responsibilities in PRINCE2

Responsibilities for managing the business case in PRINCE2 are set out in Table 6.1. As described in Chapter 7, if roles are combined then all the responsibilities in this table must still be undertaken (see section 7.2.1.10).

6.3 Guidance for effective business case management

6.3.1 Business justifications can take many forms

The business case itself, whether outline (from the starting up a project process) or detailed (from the initiating a project process or managing a stage boundary process), need not be a distinct document nor have that label.

The structure, contents and format of a business justification will often depend on the maturity of the organization, the type of project and the delivery approach used. For example:

•Organizations with mature project management will often have annual (or similar) business plans, with an entry in the business plan constituting the initial business justification for the project. Typically, a detailed business case would only be developed when the project has been fully scoped.

•Some projects may need to deliver incrementally in order to fund subsequent stages/phases/deliveries of the project. This is where an agile approach may be particularly beneficial as, without it, the business case would not be justified.

•In some cases it might be more effective and efficient to present the business justification as a slide deck than it is to create a lengthy document.

In organizations with mature project management it will usually be the case that the structure, contents and format of the business justification will be mandated at some corporate level and aligned with the preferences of the governance body that authorizes investment in the project. For example, the finance function in the organization may own and mandate the structure, contents and format of a business case. Even very simple projects need some form of explicit business justification, no matter how this is documented or expressed.

6.3.2 PRINCE2 products need to be used, not just delivered

A problem that commonly occurs is that projects are often successful from a delivery perspective, but fail from an investment perspective.

Although one of PRINCE2’s principles is a focus on products, it is important to remember that the benefits underpinning the business justification of the project are delivered through the use of the products produced by the project, not just their delivery. As the project’s outcomes and benefits are often only realized after the project has closed, it is easy for project teams to become focused solely on creating products (the outputs).

The link from the project’s outputs to outcomes and benefits needs to be clearly identified and made visible to those involved in the project, otherwise there is a danger that the original purpose of the project can get lost and benefits will not be realized.

6.3.3Customers and suppliers will usually need their own business cases

The business case for a customer’s project is separate from a supplier’s business case for bidding for and working on that customer’s project. The customer needs to ensure that its project is viable and risks are acceptable, bearing in mind the suppliers chosen. A supplier would have to ensure that it will benefit from the work it undertakes on the project. In other words, the project will be profitable from the supplier’s perspective.

6.3.4 Projects within programmes

If the project is part of a programme, the programme will typically define both the approach to business case development and provide an outline business case for the project.

The project’s business case will typically be aggregated into the overall programme business case and is likely to be reduced in content. It may comprise just the details of the budget and timescales, a list of benefits (and the benefits tolerance), and a statement of what the project contributes to the programme outcomes. The justification aspects of the project business case should be in the programme business case.

Benefits will usually be defined, tracked and managed by the programme management team, and the project’s benefits management approach may be part of the programme’s benefits realization plan.

6.3.5 Projects using an agile approach

An agile approach may require more information (and possibly emphasis) on the tolerances around benefits with respect to priorities, timescales and how much of the scope will be delivered in the product. One way to present a business case is to show the best case, expected case and worst case of the amount of the project product requirement that will be delivered given a fixed cost and time.

When creating a business case, it is important to understand how incremental delivery of a product, and the value associated with it, could impact project viability (positively or negatively) and also the ability to achieve the early realization of some benefits. If there is a high level of uncertainty, the business case should be developed very quickly and the assumptions tested quickly.

6.4 Techniques: investment appraisal

There are many investment appraisal techniques, and organizations will often have preferences on which to adopt for specific projects. The selection of technique may be influenced by the type of organization (e.g. public sector accounting rules) or the organization’s own standards.