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

Risk analysis

[see, risk analysis is tackled in more detail in the 'The Complete Risk Management package‘].

Identify the risks

This step examines all the potential risks or opportunities that might exist.
When generating a list it is a little like a brain storm you must not be judgemental.
At an early stage try not to judge the likelihood of the risk occurring.
This is done more formally later.

All risks are entered into the Risk Log.
This is a complete record of the detail, ownership, assessment and current status.
The full description of a possible Risk Log is given in file ‘risk log.doc’ in the package.
The Risk Log is used by the Project Manager as a quick reference to the status of risks in the project.

Evaluating the risks

You will need to assess the project impact and the likelihood of occurrence.

Not only may a risk actually happen it may happen more than once. So, as well as the probability that a risk may happen you may need to give consideration of its frequency as well. For example, a fire may be unlikely to happen but would have a big impact. Computer breakdowns are mostly just inconvenient but can be quite frequent.

The impact of any risk happening is its effect on the project. This could be a factor of cost and money, delayed completion, a reduction in reputation, quality of the product, detrimental effect on any perceived benefits or an effect on people or resources.

Risk cannot always be judged numerically, for example, costs. Others, like, loss of reputation are harder to define.
Often a simple system is used to ‘rank’ them as ‘High, Medium and Low’.

We have thought about:

• The risk impact
• The risk likelihood of happening
• The risk frequency of occurrence

Another aspect that must be considered is ‘when?’ it is likely to occur.
This will give an idea of ‘urgency’ about the risk.
This is known as the risk ‘proximity’. This would be recorded in the Risk Log along with the evaluation step.

Identifying suitable responses

There are 5 key methods for the control of risk.

Measures are put in place that stop the risk having any potential for occurrence. Activities are carried out differently to remove the risk if this is feasible. The threat is either completely removed or the impact on the project is eliminated should it occur.

The risk is controlled with suitable actions that will either reduce the likelihood of occurrence or minimise the impact should it occur.

The management of the risk is passed to a third party, for example, via an insurance policy or penalty clause which will eliminate the impact on the project. This method cannot be applied to all risks.

The risk is tolerated. This will happen if the costs are too high to put in place any of the other methods or the chance of the risk occurring is considered to be very low.

These are plans that are already in existence and are designed to come into place should the risk occur or if an agreed trigger point is reached.
Generally, all risks could fall into any of the above methods. Acceptance of risk suggests that you have reviewed the options and this is all that is left.
In some cases you will need to consider whether the project is viable baring in mind the level of risk and costs involved.

Select

The overall risk management process requires the identification of risk then evaluating various options before putting plans in place and implementing them at the appropriate time.

The major item to consider is the cost of implementing any plan against the likelihood of the risk occurring.
You need to consider the risk likelihood in the context of what you are prepared to accept (risk tolerances).

Any plan of action may not stand alones and may in fact be a combination of several ideas.
You will need to consider the impact of any plans on various parts of the organisation.

• The Team, Stage and / or Project Plans
• The business or programme
• The Business Case
• Other parts of the project

Risk management

Plan and resource

Following any selection of a method designed to reduce or eliminate the risk, from the types listed above, the next step is to consider how you will actually implement it in practice.
This will require the generation of a plan that takes into account any resource that is required and its impact on the rest of the project.
It is likely that existing plans and their Work Packages will be affected.

Here you will need to identify the type and quantity of resource that is required.
A detailed plan must be generated that will be included in the Project and Stage Plans.
This will appear as extra tasks or as a contingency plan.
Should any additional information come to light any contingency plans should be reviewed for suitability.
Any plans produced must be approved prior to inclusion in the original plans.

This should identify the actual resources required.
They will be reflected in the Project and Stage Plan.

When the actions are based upon ‘prevention, reduction and transference’ they will be actions that we will carry out as part of the budget and as such the money must come out of the project budget.
In the case of a contingency plan resource we are hoping the particular risks do not occur and they are not in the plan to occur.
As such the money for this risk management should not come out of the normal budget but out of a ‘contingency budget’.

Monitor and report

It is pointless putting plans in place to alleviate risk if we don’t monitor whether they are effective or not.
A mechanism must be put in place.

This might include:

• Checking that any actions implemented are having the desired effect
• Keeping an eye on any early signs that a risk occurrence may be imminent. The use of agreed triggers may prove useful here.
• Modelling the trends of outcomes may help in trying to forecast risk issues or possible opportunities
• Checking that the overall management of risk is being implemented effectively

An Exception Report is used should there be any concerns that the risk management process is failing or that risk is beginning to exceed the organisational tolerance.