Project Risk Management

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:-

• How frequently does the planning committee sit?
• What is the average number of planning applications that need to be put in before permission is granted?

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:

• bribing a committee member!

• not getting planning permission and building anyway.

As neither of these is really viable, the risk could be reduced by:

• submitting multiple applications with variations on plans to one planning session
• ensuring that you use an Architect known to the Planning Committee who has experience in this kind of building.

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?