Guidance for effective PRINCE2 business case management 

Developing the PRINCE2 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 PRINCE2 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).

The PRINCE2 Outline Business Case

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 must be approved by the project board in the directing a project process to initiate the PRINCE2 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’ 

The PRINCE2 Detailed Business Case

Typically, a more detailed PRINCE2 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 and refined. In the rest of this manual the term ‘detailed business case’ is used to describe this business case and its refinements.

The business justification for a project should include not only the costs of developing the products produced by the project but also any changes to operational costs post-project. Most organizations have policies that define how these costs should be accounted for in business justifications.

Verifying and maintaining the PRINCE2 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:

• Starting Up a Project – at the end of the starting up a project process by the project board, to authorize project initiation based on a reasonable justification
• Initiating a Project – at the end of the initiating a project process by the project board, to authorize the project
• Revised Issues or Risks – as part of any impact assessment by the project manager of any new or revised issues or risks
• Exception Plans – in tandem with an exception plan by the project board, to authorize the revised management stage and the continuation of the project
• Management Stages – 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
• Final Management Stage – 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
• Benefit Reviews – 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 always.

Ensuring and confirming that PRINCE2 benefits are realized 

PRINCE2 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. For the benefits to be realized, the outcomes must be achieved, which means that the outputs from the project must 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’s products. 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.
• Organizational Commitment – 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.

Business Benefits and The Senior User

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 the funding and resources) to carry out any measurement activities.

The PRINCE2 Benefits Management Approach

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 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.

Reviewing PRINCE2 Project Benefits

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.

Business Benefit Reviews

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’s products in operational use and identify whether there have been any side-effects (beneficial or adverse) that may provide useful lessons for other projects.

PRINCE2 Business Benefits Within A Programme

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).

PRINCE2 Business Justification

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.

• 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.
• Incremental Delivery. 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.
• Business Justification Formats. 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.

PRINCE2 products need to be used, not just delivered

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:

The PRINCE2 Investment Perspective

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 using 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).

PRINCE2 Multiple Business Cases

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.

Customers 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.

PRINCE2 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.

PRINCE2 Projects using an agile approach

A PRINCE2 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 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.

PRINCE2 Masterclass

If failure is not an option for you – then get your hands on Project Academy’s PRINCE2 Masterclass – Your Guarantee of gaining PRINCE2 Practitioner at your first try!