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

Mapping the management of risk to the PRINCE2® processes

The requirement for risk management occurs at many stages during the various processes of a project.
It is not a one off activity. The diagram showing the processes where risk management [see ‘The Complete Risk Management package’] is used can be found in file ‘risk flow in the project.doc’ in the product package.

© Crown copyright 2005 Reproduced under licence from OGC

Preparing a Project Brief (SU4)

The Risk Log is required.
The Project Mandate (and the creation of the Project Approach) may have indicated some risks.
Risks such as, legislation change and introduction, cash flow problems and staff changes should be discussed as part of introducing the Project Brief.

Authorising Initiation (DP1)

The Project Board will look at the Risk Log to see if there is nay justification for initiating the project.
The Project Manager should have made Project Board members aware of the risks ahead of the meeting.

Refining the Business Case and Risks (IP3)

The Project Manager, as part of the preparation of the Project Initiation Document should revisit and review any risks.
The initial Project Plan will be created and which should identify many of the risks.

Authorising a Project (DP2)

The Project Board will have seen an updated Risk Log and reviewed the Business Case and hence assessed the status of the risk.
Based upon this they will approve or not the start of the project. Project Board members will own some of the risks.

Analysing risks (PL6)

As any plan progresses new risks may be identified, others modified and others eliminated.
The Risk Log should contain all information on identified risks and their status.
No plan should be updated and approved without first completing a review of the risks.
Naturally, tasks may be modified or added to account for the change in the presence of risk.

Updating the Risk Log (SB4)

This must be updated prior to the approval and start of the next stage.

Authorising a Stage or Exception Plan (DP3)

The Project Board must have the opportunity to assess the risk position prior to approval of the next stage.

Authorising Work Package (CS1)

During this activity the Team Manager might identify additional risks which require plan modification.
This may happen due to the use of new technology or a need to source specialised skills and equipment.

Accepting a Work Package (MP1)

The Team Manager will produce a plan for the implementation of the Work Packages which in turn raise possible risk issues.

Examining Project Issues (CS4)

Assessment of a Project Issue may introduce an new risk of modify an existing one beyond acceptable boundaries.

Reviewing Stage Status (CS5)

Here the Project Manager (with Project Assurance personnel) examines risk changes and other signs. This will be accomplished by reference to a variety of reports, such as, the Stage Plan (containing the latest actual data), the Project Plan, the Business Case, any open Project Issue, the tolerance status and the Risk Log.

Escalating Project Issues (CS8)

Apart from Project Issues, a risk change may cause the Project Manager to raise an Exception Report to the Project Board.

Reporting Highlights (CS6)

This provides an opportunity for the Project Manager to bring key aspects of risk to the attention of the Project Board.
These could be new risks, risks that no longer exist and a reminder of the risks owned by members of the Project Board.

Giving Ad Hoc Direction (DP4)

The Exception Report allows the Project Manager to bring exceptions to the attention of the Project Board.
Based upon this information the Project Board can provide necessary advice to indicate a direction to take.
This might involve project closure, the request of an Exception Plan or the removal of an obstacle.

The Project Manager will usually already be in communication with the Project Board and the meeting will help to ratify any decision making.

Identifying Follow-on Actions (CP2)

When the project is complete the product may still bear certain risk issues, during its operational life, which will be important to those involved in support.
These risks should be recorded in the Follow-on Action Recommendations.