Prince2 header
products page

PRINCE2 - Initiating a Project (IP) part 4



Refining a Business Case and Risks (IP3)

Fundamental principles

It is easy to forget about ‘why’ the project exists. The Business Case indicates why the project is being carried out.

It is important to anticipate any problems or threats that may have an affect on the project so that appropriate actions can be taken.

Context

This process takes the outline Business Case form the Project Brief and the resource requirements from the Project Plan.
From these the sub-process produces a refined Business Case that is later incorporated into the Project Initiation Document.
It also updates the Risk Log with any expansion on risks discovered when writing the Project Initiation Document, plus the addition of any extra risks found since.

Process description

The sub-process refines the Business Case and may reveal extra risks.

The objectives are:

  • Refine the Business Case in the light of what is now known about the project
  • Identify how the achievement of each benefit is to be measured
  • Add to the Risk Log any extra problems or threats identified during this process
  • Modify the Project Plan in the light of any risk management [see ‘The Complete Risk Management package’] activities

To achieve the above certain steps are required:

For the Business Case:

  • Check that programme, corporate or strategic objectives can still be met bearing in mind the information collated during Initiating a Project (IP)
  • Check whether any recent external events have affected any of the benefits quoted in the Business Case held within the Project Brief
  • Establish whether any additional business benefits have become apparent
  • Re-quantify the benefits where appropriate, and identify any non benefits
  • Establish how the achievement of each claimed benefit would be measured and record this for the Post-Project Review Plan
  • Ensure that measurements of the claimed benefits against the current situation are recorded, so that effective comparison can be made at the post-project review
  • Calculate and / or refine the cost elements, based on the Project Plan and the latest information regarding the likely operational and maintenance characteristics of the project’s products
  • Refine or calculate the financial case and recast the investment appraisal where appropriate
  • Summarise any different options considered as part of Defining Project Approach (SU5)

For the Risk Log:

  • Identify any risks that may impact the project
  • Assess the likelihood of each risk occurring within this project
  • Assess the impact on the project if a risk does occur
  • Prepare any appropriate contingency plans for inclusion in the Project Plan
  • Where the project is part of a programme, programme management may need to be informed of any additional risks identified
  • Check whether the summary of key risks included in the Business Case needs refining

For the Project Plan:

  • Evaluate the cost of the resolution actions and contingency plans against their value in reducing the risk
  • Add these to the Project Plan and / or the next Stage Plan. (Note: This will involve an iteration of Planning a Project (IP2) and possibly a revisit to the Business Case elements)

Where there is a serious risk the Project Board may require a contingency plan and approve a budget for it.
This would only be used if the risk occurs.
The decision on project viability will be a balance of risk and identified costs against the agreed benefits.
If any of the steps raise a problem that may affect the Business Case then the Project Board will need to be informed as soon as possible.
The Project Board may need to raise a Project Issues with corporate or programme management.

Responsibilities

The Project Manager is responsible for this sub-process.
There will be assistance from Project Support and advice from Project Assurance as necessary.
The Project Manager should informally discuss the Business Case and risks with the Project Board before presentation in the Project Initiation Document.

Information needs
Management information Usage Explanation
Project Brief Input Contains high-level views of the anticipated business benefits and risks as identified in Starting up a Project (SU).
Project Approach Input Will contain information about the way the work is to be conducted and could provide input to both the Business Case and risk analysis.
Risk Log Update Add any identified new risks. Modify with details of any changed risks.
Project Plan Update Update with any significant extra activities and resource requirements to counter risk exposure.
Business Case Update Extract from the Project Brief and update with the latest (more detailed) information

These are given in tabular form in the file ‘IP3 refining the business case and risks.doc’ in the product package.

Key criteria

  • Are the risk avoidance costs less than the costs implicit in the threats?
  • Is it reasonable that the benefits claimed can be realised by the anticipated final outcome of the project?
  • Has sensitivity analysis been conducted on the Business Case?
  • Is the information in a form that is easily understandable by the Project Board?
  • Are there plans in place by which the user(s) of the product will realise the benefits?
  • Has the Business Case been produced in line with corporate standards?

By the very nature of risks they will in themselves cause another effect in a cause-effect chain. Its up to the Project Manager to know where to cut the chain.

If the project is part of a programme then you must use its risk monitoring mechanism unless there is a valid reason not to.
It would be good practice to combine the maintenance of all Risk Logs at the programme level.

Usually the customer pays for the project but in some cases the supplier may fully or partially fund the project.
In this situation the customer may have less rights to insist on the inclusion of risk avoidance or reduction activities.

The customer and the supplier are likely to have different Business Cases.

Payment methods to suppliers must be considered. It could be:

  • Regular basis throughout the project
  • According to products delivered
  • A lump sum at the end

Non - PRINCE2 information

This product contains EVERYTHING in the publications:

Managing Successful Projects with PRINCE2 - 2005 edition
Managing successful Projects with PRINCE2 – 2009 edition
Directing Projects with PRINCE2.
plus:
The Complete Project Management package.

And much more besides - at a fantastic price.