Introduction

• Defintion
• Structure and terminology
• What is a project?

Processes

• The processes
• Management levels
• Starting up a project SU
  • Fundamental principles
  • Appointing an Executive and Project Manager (SU1)
  • Designing a Project Management Team (SU1)
  • Appointing a Project Management Team (SU3)
  • Preparing a Project Brief (SU4)
  • Defining Project Approach (SU5)
  • Planning an Initiation Stage (SU6)
• Initiating a project IP
  • Fundamental principles
  • Planning Quality (IP1)
  • Planning a Project (IP2)
  • Refining a Business Case and Risks (IP3)
  • Setting up Project Controls (IP4)
  • Setting up Project Files (IP5)
  • Assembling a Project Initiation Document (IP6)
• Directing a project DP
  • Fundamental principles
  • Authorising Initiation (DP1)
  • Authorising a Project (DP2)
  • Authorising a Stage or Exception Plan (DP3)
  • Giving Ad Hoc Direction (DP4)
  • Confirming Project Closure (DP5)
• Controlling a stage CS
  • Fundamental principles
  • Authorising Work Package (CS1)
  • Assessing Progress (CS2)
  • Capturing Project Issues (CS3)
  • Examining Project Issues (CS4)
  • Reviewing Stage Status (CS5)
  • Reporting Highlights (CS6)
  • Taking Corrective Action (CS7)
  • Escalating Project Issues (CS8)
  • Receiving Completed Work Package (CS9)
• Managing product delivery MP
  • Fundamental principles
  • Accepting a Work Package (MP1)
  • Executing a Work Package (MP2)
  • Delivering a Work Package (MP3)
• Managing stage boundaries SB
  • Fundamental principles
  • Planning a Stage (SB1)
  • Updating a Project Plan (SB2)
  • Updating a Project Business Case (SB3)
  • Updating the Risk Log (SB4)
  • Reporting Stage End (SB5)
  • Producing an Exception Plan (SB6)
• Closing a project CP
  • Fundamental principles
  • Decommissioning a Project (CP1)
  • Identifying Follow-on Actions (CP2)
  • Evaluating a Project (CP3)
• Planning PL
  • Fundamental principles
  • Designing a Plan (PL1)
  • Defining and Analysing Products (PL2)
  • Identifying Activities and Dependencies (PL3)
  • Estimating (PL4)
  • Scheduling (PL5)
  • Analysing Risks (PL6)
  • Completing a Plan (PL7)

Components

• The components
• Business case
  • What is it?
  • Developing
• Organisation
  • Overview
  • The customer / supplier environment
  • Project Manager
• Plans
  • Benefits
  • Levels of plan
• Controls
  • Purpose
  • Project start-up
  • Tolerance
  • Product Descriptions
  • Exception Report
  • Controlled close
• Management of risk
  • What is it?
  • Risk analysis
  • Risk profile
  • Mapping the management of risk to the PRINCE2® processes
  • Interdependencies
• Quality in a project environment
  • What is quality?
• Configuration management
  • Purpose
  • Configuration control
• Change control
  • Purpose

Techniques

• General
• Product-based planning
  • General
  • Producing a Product Breakdown Structure
  • Writing a Product Description
  • Creating a Product Flow Diagram
• Change control
  • General
• Quality reviews
  • What is it?
  • Steps in a formal quality review procedure

Other

• Risk categories
• Health check
  • Health check – part 1
  • Health check – part 2

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.

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