Risk
Management
Purpose
This guide provides the rationale and
minimum requirements for project risk management with suggestions,
hints and tips for effective risk management. There is also
additional support material available in the Risk Management
Checklist (Appendix – below).
Rationale
All projects have some level of risk.
Risk cannot be completely eliminated, but it can be managed and
reduced or mitigated in some way. Project risk management involves
the identification, analysis, management and monitoring of project
risk. After potential risks are identified, the purpose of risk
analysis is to determine the relative exposure in terms of time and
cost, to reduce the level of risk to an acceptable level. Risk
management plans then identify both preventive actions and
contingency actions (to mitigate the impact of the risk if it
materialises). The approach should also ensure that the risk
management process:
is proactive, focusing on
prevention rather than cure
is communicated to, and well
understood by, the project team
includes periodic risk assessments
throughout the project lifecycle
is administered and facilitated in
a timely manner by the Project Manager or Project Office.
Experience indicates that many common
project risks can be anticipated at the onset of the project, and
then counteracted. In this case, the tasks to counteract the risk
should be added to the plan. Risk management is a continuous process
beginning with the Vision phase of a project at a high-level,
building on it during Initiation and continuing throughout the life
of the project.
Risk management techniques can be used
at any stage of a project, for example:
prior to project work commencing
when assuming responsibility for a
project already in progress
when recovering a project that is
out of control
during major plan revisions
when significant deviations from
the plan occur
at the beginning of a new project
phase or workstream.
The Project Manager can use the risk
management process as a communication vehicle. High risk areas can be
discussed with project team members and communicated to senior
management to enlist support for risk reduction measures. Risk
management is not intended to be used as an ‘insurance policy’ to
protect the Project Manager in the event risks materialise as
critical delays for the project. Rather, the Project Manager’s risk
management goal is to cultivate support for actions to reduce or
mitigate risks.
This process description addresses the
scope of Risk Management. It should be noted that during the Vision
phase an initial evaluation of the overall project risk may have been
undertaken and hence should be an input to this process.
As an example, SPPP (Sustainable Project Procurement) includes an overall
project risk assessment using the following risk categories; Low,
Medium, High, Very High (see SPPP for further definition of these
categories).
Requirements
At a minimum, the following are
required to implement effective risk management:
Element
|
Description
|
Risk Identifier
|
A unique, sequential reference number
|
Risk Description & Impact
|
Narrative summary of the risk and description of the potential
impact (e.g. budget, schedule, performance etc) on the project if
the risk occurred
|
Likelihood Measure (L)
|
An assessment of the likelihood that the risk would
materialise based on a suitable scale
|
Impact Measure (I)
|
An assessment of the impact on the project based on a suitable
scale
|
Risk Factor (R - weighting)
|
An assessment of the overall risk priority derived from the
impact measure and the likelihood measure (R = L x I).
|
Risk Owner
|
The person responsible for managing the risk
|
Risk Mitigation Actions
|
Modifying the project environment or identifying mitigating
actions to minimise/ eliminate the identified risk
|
Additionally, these elements may be
used to further facilitate risk tracking and resolution:
Risk Movement Indicator
|
Used to indicate whether the risk is increasing, decreasing, or
static
|
Risk Contingency Actions
|
A description of the course of action that would be taken if
the risk materialised
|
Status
|
The current state of the issue, typically ‘opened’ or
‘closed’, but may include ‘deferred’ if issue relates to a
scope change
|
Relative Exposure Cost
|
Cost of impact on the project – in terms of budget, effort,
and/or schedule
|
Cost of preventive action
|
Cost of preventive action – in terms of budget, effort,
and/or schedule
|
Risk
Management
Risk
Identification
At prescribed points in a project and
as part of the progress reporting cycle, the risks to the project
should be reviewed and potential new risks identified. This cycle
starts when the project is first identified during the Vision phase
(for example, preparing the business case for a project via SPPP - Sustainable Project Procurement Portal )
when a very high-level risk analysis is performed. Risk
identification is ongoing and should be performed throughout the
project until the risks have either reduced to zero probability or
the project has completed.
Thinking about ways in which the
project could go wrong or not go to plan is helpful in risk
identification. Refer to the Risk Management Checklist (appendix)
as a guide in identifying many of the common risks associated with
projects. In addition, it is also useful in considering the risks
that may be associated with the particular goals of the project and
any external dependencies as these will be more specific to the
project and are not be covered by the checklist.
For illustrative purposes consider the
following:
If a project goal is to build a house
with 3 bedrooms, a bathroom and 2 reception rooms by June, one thing
that could go wrong is that you may not get planning permission at
your first attempt. This is clearly a risk to the project being able
to deliver on time, and should be logged then evaluated.
Risk
Evaluation
Impact Description
Risks to the project must be evaluated
to see what impact there would be on the project if the risk were to
materialise. To continue the above example, if planning permission
was not achieved on the first attempt, then it could have a
considerable impact upon the goal of the project as stated – in
particular the project would be late (assuming that only 1 cycle of
planning application is anticipated in the plan). Consequently, the
project delivery is threatened (and potentially the project costs if
each planning application needs to be accompanied by an application
fee). But by how much? In order to establish the amount of slippage
that this could cause, you may need to establish further information
such as:-
If possible this impact should be
quantified in some way. This can be in terms of schedule days,
additional cost, additional effort. Then try to establish some
preventive action.
Impact Measure
A subjective impact assessment measure
should be used to be able to compare the impact of different risks.
This should be generated using a suitable scale. This could be a
simple scale such as High, Medium or Low or a more complex scale.
Likelihood Measure
A subjective likelihood assessment
measure should be used to be able to compare the likelihood of
occurrence of different risks. This should be generated using a
suitable scale. This could be a simple scale such as High, Medium or
Low or a more complex scale. .
Risk Mitigation Activities
When potential risk situations are
identified, alternative courses of action should be evaluated to
determine if the undesirable outcome can be eliminated at a
reasonable cost, or whether it can be reduced.
Taking the above example again, this risk to
the project schedule could be eliminated by:
As neither of these is really viable,
the risk could be reduced by:
The relative cost of these reduction
activities should be determined and incorporated into the Risk Log.
The Project Manager should present the Risk Log with these planned
actions to the Project Review Board for approval if the costs and/or
impacts are significant.
Actions described must be appropriate,
depending upon additional project considerations. For example, in
developing systems for the next Olympic Games, any risk whose impact
could cause the system to be unavailable at the start of the games
must have mitigating actions that will cause the risk to be reduced
to minimal level as the deadline is immovable.
Once approved, risk prevention
activities should be incorporated into the Risk section of the
Project Definition document (see the document ‘Skeleton Project
Definition Document’ (SK01)) and appropriate detailed work plans,
with the necessary resources assigned.
Contingency
Action
A contingency action plan should be
developed for addressing significant risks where the impact without
contingency would be unacceptable, preventive action is either
unavailable or the cost of prevention is prohibitive. This plan will
then be put into action in the event that the risk materialises, and
helps to remove the element of “panic” in a serious situation.
The Project Manager must ensure that
the contingency plan is realistic. For the plan to be viable, the
following actions are necessary:
if additional resources will be
required to implement the plan, arrangements must be made for them
to be available at short notice;
members of the project team must
understand the contingency plan, and their role in it; and
testing must be carried out if the
feasibility of the contingency action is in doubt.
Risk
Management
As part of the regular project control
cycle risks should be reviewed to see whether the risks identified
are increasing, reducing or remaining at the same level. A risk that
is increasing should be given additional attention, as there may be
other actions that should be introduced to mitigate the increased
risk.
The mitigation actions identified to
reduce the likelihood of a risk occurring generally provide warning
signs for the project manager and risk owner. If mitigation actions
are having the planned result the risk will be reducing, but if
mitigation action are not being effective there is a clear warning
that additional assessment and risk management planing is required.
Risk is a recommended subject of
regular project progress reports. Significant risks or major movement
in risks that impact project schedule, resources or deliverables,
should be reported to the Project Steering Board via a status report.
Also, new risks can materialise during
the life of a project. For example, during the house building
project, you may find that a particular component can only be
purchased from a single supplier. This gives you a new risk that you
are now reliant upon this supplier to complete the project.
Risk
Closure
Risks can be closed when they are no
longer a threat to the project. This may be due to the mitigation
actions that you have instigated, or may be because the project is
closed, or because the threat is no longer relevant. At this time,
the risk entry should be closed.
Risk
Materialises
If the risk materialises, the impact
must be assessed and the resulting issue (or issues) must be logged
and managed via the issues management process (see the document
‘Issue Management Guide’ (GD1.5)). The Risk Log should be
updated to reflect the fact that it is no longer a risk, but is an
issue and effectively the risk is closed.
Risk Log
There are a variety of tools that can
be used to capture and report risks and can include specific software
solutions or office tools (e.g., Access, Excel, Lotus Notes etc.).
Irrespective of the tool used, it is helpful to remember that while
reports do not have to be overly complex they should:
make full use of automation and if in
lieu of automated tracking mechanisms (e.g., Lotus Notes Database)
be electronic (e.g., Notes forms) and capture all the information
needed to populate a single repository
provide detail-level recording,
tracking and communication of information pertaining to project
issues
include a unique identifier for
each risk to facilitate tracking
include a risk factor/ weighting
for tracking and escalation
provide for communication of risks
and status to the project team and stakeholders
standardise terminology
reference the project plan.
Control
The Risk Log should be controlled by
the Project Manager or delegated authority. The Project Manager
should regularly review the Risk Log, and update the risks adding new
risks and closing existing risks as appropriate. The updated log
will be sorted by priority for inclusion in status reporting and
escalation.
The Project Manager has control to
review the Risk Log, and mitigation actions and determine if they
eliminate the risk and then close the risk and close the
communication loop for the resolution with all interested parties.
Risk Management Checklist (Questions to Consider)
Project Objectives
Is the project large?
Does the project span multiple
divisions/geographic locations?
Is the project of major importance to
the business?
Is the project functionally complex?
Is the design of the project dependent
on very few people?
Is the benefits case and realisation
owned by the business?
Are preceding projects poorly
documented?
Is there an immovable deadline and/or
budget constraint on the project?
Are there external dependencies?
Organisation
Does the project change existing user
procedures/business processes?
Is other organisational change (e.g. reorganizations, mergers/acquisitions) likely to occur during the
project?
Are the key stakeholders distributed
in multiple location and/or geographies?
Are the key stakeholders familiar with
project work?
Do the key stakeholders actively and
openly support the project?
Technology
Is non-standard/untried hardware being
used?
Is non-standard/untried software being
used?
Is bespoke programming a major part of
the project?
Is the project technologically
complex?
Is the quality of existing data poor?
Is there a requirement for interfaces
with legacy applications and/or data?
Approach
Related
Scope and Approach
Are the project scope and critical
requirements poorly defined and/ or not agreed?
Is the project approach poorly defined
and/ or not agreed?
Project Organisation
Are team member roles poorly defined?
Are key stakeholders uncommitted to
the project?
Are team members and/or key
stakeholders unable to commit sufficient time to the project?
Are all full-time team members
reporting to the Project Manager for the duration of the project?
Are any of the required skills
unavailable?
Are some team members indispensable to
the project?
Are political and personal
relationships poor?
Is the project dependent upon third
parties?
Can the design only be achieved by a
large group?
Is a "big bang"
implementation unavoidable?
Is the sponsor taking sufficient
interest in the project?
Experience, training and support
Is the team unfamiliar with the
technology?
Is the team unfamiliar with the
business area(s) and processes?
