Project Risk Management Guide

Project Risk Management Guide
Saudi Aramco
Project Risk Management
Guide
Page 1
Table of Contents
Project Risk Management Corporate Statement .......................................................... 5
1. Introduction ............................................................................................................. 7
1.1 Objectives of Saudi Aramco Risk Management ................................................. 7
1.2 Background to Saudi Aramco Risk Management Development ......................... 8
1.3 Which Projects Require Risk Management? ...................................................... 8
1.4 Document Ownership and update ...................................................................... 8
1.5 Purpose of This Document ................................................................................. 9
1.6 Definitions .......................................................................................................... 9
2. Project Risk and Project Risk Management ....................................................... 14
2.1 Project Risk Basics .......................................................................................... 14
2.2 Project Risk Management Process .................................................................. 20
2.2.1 Risk Management Planning ....................................................................... 21
2.2.2 Risk Identification ...................................................................................... 22
2.2.3 Qualitative Risk Analysis ........................................................................... 23
2.2.4 Quantitative Risk Analysis ......................................................................... 24
2.2.5 Risk Response Planning............................................................................ 25
2.2.6 Risk Monitoring & Control .......................................................................... 26
3. Saudi Aramco PRM Process ................................................................................ 28
3.1 Organizational Assets to support PRM ............................................................ 29
3.2 PRM Process and Project Life Cycle Interface................................................. 31
3.3 Project Risk Process Roadmap........................................................................ 32
3.4 PRM Activities .................................................................................................. 32
3.5 Roles and Responsibilities ............................................................................... 36
4. Project Risk Management Core Tools ................................................................ 40
4.1 Project Risk Management Plan ........................................................................ 40
4.2 Corporate Project Risk Database ..................................................................... 41
4.3 Project Risk Breakdown Structure.................................................................... 42
4.4 Project Risk Statement ..................................................................................... 44
5. Resources ............................................................................................................. 46
5.1 Training ............................................................................................................ 46
Appendix ...................................................................................................................... 48
Appendix A. Project Risk Management Plan – Template........................................... 49
Appendix B. Project Risk Reports – Examples .......................................................... 58
Appendix C. Risk Events Explained ........................................................................... 61
Appendix D. Risk Breakdown Structure ..................................................................... 66
Appendix E. Definitions .............................................................................................. 67
Page 3
This page intentionally left blank
Project Risk Management Corporate Statement

Saudi Aramco is a world leader in delivering energy to satisfy world demand, and is
instrumental in growing the Saudi Arabian economy. To achieve these objectives Saudi
Aramco must adopt best practices in every aspect of its business to ensure it has
control of its business outcomes and to maximize the efficiency of its capital
expenditures. Project Management ‘Best Practice’ requires effective Project Risk
Management; otherwise, the project outcomes can not be predicted or understood.
Project Risk Management delivers sustainable business benefits.
Without exception, Project Risk Management is an essential requirement for all Saudi
Aramco Projects, but projects cannot perform risk management in isolation. Each
project requires the support and active involvement of stakeholders, including the
contractors performing the work. Projects are planned and executed to achieve
corporate objectives and it is the responsibility of every organization to contribute
toward these corporate outcomes.
Without Project Risk Management, the management of projects becomes reactive in
lieu of proactive. The management of projects should be the management of events and
activities necessary to achieve the desired outcome, and should not be simply a
response to uncertain events. Project Risk Management allows the project team to
understand uncertainties in the future and plan for these uncertainties to achieve the
maximum success. Therefore, Project Risk Management is an essential and integral
component in managing projects effectively.
The benefits of Project Risk Management are:
 Saudi Aramco can understand the uncertainty it is exposed to in achieving its
Capital Program.
 Uncertainties that are common across many projects can be identified and
addressed at a corporate level.
 Opportunities for Saudi Aramco Projects to add greater value to the corporation
can be identified, explored and maximized.
 Positive and negative experiences with managing uncertainty can be captured and
shared across projects and can benefit new projects.
 Uncertainties in projects can be collected and analyzed side-by-side with other
corporate uncertainty to take advantage of Enterprise Risk Management (ERM).
Although Saudi Aramco Management has initiated the requirement for Projects to
perform Project Risk Management, it is the requirement of every Capital Program
stakeholder to maximize Saudi Aramco’s opportunities and therefore actively participate
in the management and reduction of risk in the Capital Program.
Page 5
1. Introduction
Project Risk Management (PRM) seeks to anticipate and address uncertainties that
threaten project goals. Uncertainties may include questions of material and parts
quality; delays in delivery of sufficient materials to meet project needs; budgetary and
personnel changes; and, incomplete knowledge or research. These risks lead rapidly to
schedule delays and budget blowouts that can severely undermine confidence in the
project and in the project manager.
This guide sets out a formal process for the effective identification and management of
uncertainty within Saudi Aramco Capital Projects. Risk arises from uncertainties in
which Saudi Aramco capital projects are identified, designed, procured, constructed and
commissioned. These must be identified, assessed, planned and managed proactively
as sources of both threat and opportunity.
The procedure in this guide is to be applied to all capital projects. The process is not
complex nor does it require a tremendous amount of effort; it is a common sense and
structured approach to dealing with uncertainty. Operating in accordance with this
guide demands the management of risk be a core skill of project personnel and project
management. The process must be the cornerstone of the way we manage our projects
and the behavior of teams.
Risk management is part of ‘Best Practice’ for Project Management. Effective risk
management can make the process of project management much easier as it reduces
the workload and burden on projects by reducing the need to ‘fight fires’ and crisis
response to changes in the project environment. Risk Management allows a project
team to manage the way uncertainties affect the project.
1.1 Objectives of Saudi Aramco Risk Management

Engineering and Project Management (E&PM) has initiated the formal implementation
of Risk Management on capital projects. Saudi Aramco’s Business Plan objectives
include Best-in-Class Capital Program Performance and Project Risk Management is
one of the Value Improvement Practices that will be used to achieve this. The PRM
Process provides: the process, the tools/techniques for managing the risk of a single
project, and provides an aggregated or portfolio view of risk for all capital projects.
PRM will only be effective if every project stakeholder is actively involved. Without
complete involvement from all sectors of the organization risks cannot be completely
understood and the response to these risks will not be optimum. Although PRM is
managed by the Project Management Team, the process and the outcomes are owned
by every project stakeholder.
The objectives for Project Risk Management:
 A process that supports the Project Life Cycle and the Capital Procurement
Process.
 A process that is easily used by projects at any stage in the Project Life Cycle
 A process that develops a Risk Register that evolves as the Project evolves.
 Update organizational procedures to ensure all stakeholders (not just PMT) clearly
understand what is required for Project Risk Management
Page 7
 A process that allows the risk visibility to be elevated based on the impact to
corporate KPI’s.
 A process that allows project risks to be directly correlated to corporate KPI’s.
 A process that provides for cross-project sharing of risk information and success.
 A risk focused knowledge database for project and corporate risk learning.
 Ensure the process is adopted and used effectively by projects
 A support structure, including manuals, training, tools and techniques, to allow
projects to rapidly understand and adopt formal Project Risk Management.
 A process that will support the adoption of Enterprise wide Risk Management
(ERM).
1.2 Background to Saudi Aramco Risk Management Development

In 2007 Saudi Aramco completed a study on Enterprise Risk Management (ERM). From
that study it was identified that one of the main areas of risk for the corporation was in
projects. The ERM study recommended a pilot for ERM to understand the processes
and benefits to the organization. In 2008 Senior Management initiated the development
of PRM to pilot ERM for the corporation. This pilot finished in March 2009 and the
process developed is outlined in this guide.
The process used to perform PRM is a generic process that can be adopted by any
Business Unit or department. Although the process described in this document is
anchored to the Project Life Cycle and the Capital Delivery process, the process can
easily be anchored to any other business process that has clear objectives and decision
points. The tools and techniques developed are independent of Projects and can be
adopted ‘as is’ by other business processes. A Corporate Risk Database is the heart of
ERM and this is the foundation on which PRM is built.
1.3 Which Projects Require Risk Management?

All capital projects over $50 M require PRM to be adopted as outlined in Section 3 of
this Guide. For projects under $50 M, the PRM process in Section 3 is performed if
either a complex project environment exists, or if the Project Management Team elects
to use it. For projects that don’t satisfy these two criteria, the principles as outlined in
this Guide should be reviewed and applied as appropriate to the size and complexity of
the project. All projects can benefit from PRM but smaller and less complex projects are
not required to perform the process to the depth of detail outlined in this Guide.
1.4 Document Ownership and update

The PRM Process is managed by Project Support and Control Department (PS&CD).
The tools and techniques used to execute the process will be continuously updated.
The Guide will be updated in January each year. For any suggestions or questions
related to the process, the tools and techniques, or the Guide, please contact
Lachlan Peter - Wk: 874-6633 Mb: 05-3284-6937 email: Lachlan.Peter@aramco.com
or visit the risk website http://pscd.aramco.com.sa/cpod/risk/
Feedback on the Guide and the Process is always gratefully received.
1.5 Purpose of This Document

The primary purpose of this document, (Risk Management Guide, RM Guide, or Guide)
is to provide project teams and project stakeholders with an overview of the Risk
Management Process so they understand how, when and by whom, Risk Management
(RM) is performed within a project. The process described here is based upon the
Project Management Institute’s (PMI) Project Management Body of Knowledge
(PMBOK).
This Guide does not provide in-depth coverage of each aspect of the Project Risk
Management (PRM) process. The Guide sets the context for PRM and is suitable for
project stakeholders, management, subject matter experts, and any other person who
wishes to understand or review Project Risk Management and the way the process is
performed within Saudi Aramco.
In-depth detail of the PRM process is provided in the Saudi Aramco Project Risk
Management Practitioners Handbook (RM Handbook or Handbook). The Handbook is
targeted to the Project Risk Manager, the person who is responsible for managing risk
inside the Project Management Team.
The Guide outlines a process that is performed within the context of Saudi Aramco’s
Engineering Procedures (SAEP). Each SAEP is (will be) updated to articulate the
requirements for PRM at each stage in the Project Life Cycle. Updated SAEP’s will
ensure that corporate processes support the project team to perform effective PRM.
Risks are uncertainties and this implies they could be an opportunity or threat for the
project. The Guide focuses on threats to projects as this is the major area of concern
currently facing projects. As Saudi Aramco becomes proficient in adopting the RM
Process, risk opportunity management will also be covered in the Guide. In the interim,
the management of risk threats and risk opportunities is similar.
1.6 Reference Documents

The key documents for Project risk Management are as follows:
Source Document Notes

Saudi Aramco Project Risk Management Guide This document
Saudi Aramco Project Risk Management Available Q2 2010
Practitioners Handbook
Saudi Aramco Project Risk Management Training From Training course
Manual PMT107
Project Project Management Body of 3rd of 4th Editions
Management Knowledge (PMBOK)
Institute
Page 9
1.7 Definitions
To ensure clarity of understanding, the following table has been developed to provide
PMI definitions for key terminology used in this guidance document.
Contingency See Reserve.

Cross This team is comprised of representative from each stakeholder
Functional Team area as well as appropriate Subject Matter Experts. A core team
will be assigned consisting or PMT and Proponent
representatives, who will provide everyday management of
project risk. The additional team members will be involved when
their skill, knowledge, input, or awareness is required.
Expected Impact The risk impact (cost, schedule, scope, etc) multiplied by
probability of the risk occurring. Also called the probability
weighted impact.
Guide Project Risk Management Guide, or RM Guide. (This document)
Handbook The Project Risk Practitioners Handbook provides a detailed
description of the PRM Process, including the tools, checklists,
templates, etc, used to perform the process. It is the reference
document for the Risk Manager assigned to a project.
Heat Map See Probability &Impact Matrix.
PRM Activity Each PRM Event consists of a number of activities for it to be
achieved. These activities will be meetings, workshops, review
sessions, planning sessions.
PRM Event A combination of meetings and workshops required at key stages
in the project life cycle. A total of 11 events are indentified. Each
event may occur over a period of weeks and consist of meetings
and workshops.
Probability Likelihood of the occurrence of any event.
Probability & A Matrix on which we can plot risks based on their probability
Impact Matrix and impact. Where these plot we can determine if the risk is
critical, important, significant, or unrated. Also called a Heat Map.
The risks that plot in the critical area are called “hot” risks.
Potential Impact The impact of a risk on cost, schedule or scope prior to
calculating probability of its occurrence.
Page 11
Qualitative Risk The process of prioritizing risks for subsequent further analysis.
Analysis The process assigns a probability of the risk occurring and the
impact the risk is expected to have on the project. The
combination of probability and impact is plotted on the Probability
Impact Matrix to determine the priority of the risk.
Quantitative The process of numerically analyzing risk information. This

Risk Analysis process provides the detail on the specific effects a risk or risk
response will have on project objectives.
Reserve A provision in the project management plan that can be applied
to risks that arise. Contingency Reserve is used at the discretion
of the Project Manager and is for expected variations from
uncertainties in the project. Management Reserves is outside of
direct project control and is used if completely unforeseen events
occur. The Project Manager will need to request access to
Management reserve.
Risk An uncertain event or condition that, if it occurs, has a positive or
negative effect on a project's objectives.
Risk Acceptance A risk response where the project team has decided not to
actively manage a risk.
Risk Allocation Placing responsibility for a risk to a party through a contract. The
fundamental tenets of risk allocation include allocating risks to
the party best able manage them, allocating risks in alignment
with project goals, and allocating risks to promote team
alignment with customer-oriented performance goals.
Risk A component of risk management that bridges risk identification
Assessment and risk analysis in support of risk allocation.
Risk Avoidance A risk response where the project management plan is altered so
the risk is eliminated. Generally, risk avoidance involves relaxing
the time, cost, scope, or quality objectives.
Risk Database Also called Corporate Risk database. This is the central
coordination point for risk in the company. Each risk in the project
specific Risk Register is mapped to the Risk Database. The Risk
Database is the collection point for all risk information across a
project and is used to understand common risk areas and to
share information between projects facing similar risks. It is also
the starting point for developing the Risk Register for a new
project.
Risk Event A discrete occurrence that may affect the project for better or
worse. Risk Identification Determining which risks might affect
the project and documenting their characteristics. Tools used
include brainstorming and checklists. Risk Management Plan
Documents how the risk processes will be carried out during the
project. This is the output of risk management planning.
Risk Factor Qualitative measure of the relative importance of the risk with 50
being maximum and 1 being minimum
Risk Mitigation A risk response that seeks to reduce the probability of
occurrence or impact of a risk to below an acceptable threshold.
Risk Register Contains all information related to the risks for a specific project.
Each risk has information associated with its ranking, its cause,
its owner, etc. Each risk also has a number of potential risk
response plans, etc. All this information is contained in a central
repository called the Risk Register. The risk Register is used as
the basis for managing risks and responding to them. The risk
register is a component of the project management plan.
Risk A risk response planning technique that shifts the impact of a
Transference threat to a third party, together with ownership of the response.
Triggers Indications that a risk has occurred or is about to occur. Triggers
may be discovered in the risk identification process and watched
in the risk monitoring and control process. Triggers are
sometimes called risk symptoms or warning signs.
Page 13
2. Project Risk and Project Risk Management
Risk is one of the most commonly used terms in the project environment. There is much
awareness of its existence but in a superficial context. This section provides a basic
introduction to Risk and Risk Management. This introduction is generic and not specific
to Saudi Aramco or to Project Management. There are many sources of information on
risk and typically the web can be referred to. For more detailed information on the
methodology for managing risk, refer to the Project Management Institute’s (PMI)
Project Management Body of Knowledge (PMBOK).
2.1 Project Risk Basics

What is Risk and why is it important?
Risk is an uncertain event or
The PMI’s PMBOK defines Project Risk as “an condition that, if it occurs, has
uncertain event or condition that, if it occurs, has a a positive or negative effect
positive or a negative effect on at least one project on a project’s objective.
objective”. The definition highlights three points.
Firstly, it indicates the relationship between causes,
risk events, and effects. Secondly, it points out that risk can be positive or negative.
Finally, it underlines the relationship between risk and project objectives.
A Risk Event is a future uncertain discrete occurrence that has an impact on a project
activity or outcome. The uncertainty that a risk event will occur is described by a
probability from 1% to 99%. The impact can be on any project attribute or project
outcome such as schedule, cost, safety, quality, etc. Risks with negative impact or
adverse effects are termed ‘downside risk’, or threats. Risk with positive impacts or
desirable effects are termed ‘upside risk’, or opportunities.
Risk has three components:
 A root cause.
 A probability of occurrence that the root cause will affect the project
 An Impact or consequence of that root cause on the project.
Understanding and managing risk is important because project outcomes are not
guaranteed. To have control over the project outcomes risk must be understood and
actively managed. Risk implies uncertainty in the future and effective management must
alter these uncertainties to the advantage of the project.
Risk versus Cause versus effect
The statement “because of <cause>, <risk> might occur, which would lead to <effect>”
helps us to identify what is a cause, what is a risk and what is an effect. For example:
“Because the schedule is compressed, construction is required to start prior to
completing engineering design. This creates the risk that some construction may need
to be redone and this will cause project delays and increased costs”. The risk is
“rework”, the cause is the aggressive schedule, and the effect is extra time and cost.
Causes are conditions which exist now or in the future that create risk. The compressed
schedule is a known condition (or fact) which gives rise to whether rework will be
required or not (uncertainty). If rework is required it will affect cost & Schedule (effect or
impact). Facts (causes) about the project or the situation being assessed can be a
prompt to consider areas of risk. Move from cause to risk by asking questions like “as a
result of this fact, what uncertain risk(s) might arise?” Effects are the consequences that
would impact one or more objectives if a risk were to occur; including time, cost, quality,
performance, safety, environmental, etc. Negative effects help determine threats and
positive effects help discover opportunities. By asking “What uncertain events might
happen that would produce this effect”, we can also determine risks. We can therefore
identify risks from causes or effects.
Figure 1 (opposite) indicates that any
Risk Event can have a number of 1st 1st
causes and a number of effects. For Cause Effect
example, the rework considered nd
Risk
2 Even 2nd
above can be caused by the Cause Effect
compressed schedule, poorly trained 3rd t 3rd
labor, or poor design; the effect can Cause Effect
be resource availability, material
availability, or schedule delays. Figure 1
Understanding all causes is vital to
understanding the level of risk, where it will impact the project and possible responses
to the Risk Event. All effects of the risk event must be considered to effectively plan a
response.
The combined effect of different risk events, also called Risk Interaction, needs to be
considered. For example, the market prices of Oil & Gas combined with the continuous
changes in the prices of construction materials can jointly impact the Return on
Investment of the project.
Risk Strategy and Risk Exposure
Each project will have a Risk Strategy or risk attributes that take dominance when
reviewing and comparing risks. The objective on Project A may be to get oil to market
as soon as possible so its risk strategy will be Safety then Schedule. Project B might be
for maintenance and the risk strategy will be Safety then Cost. Each project will have its
own strategy on how to rate risk impacts. A high impact on cost for a $1 MM project
might be $10 M while a high impact on cost for a $20 M project might be $500k. The
risk strategy will define what impacts are/are not acceptable and what types of risk are
less desirable than others.
Risk Exposure is a means of comparing risks to determine which have the greatest
threat or opportunity to the project, and therefore, which risks should receive the most
management. Probability of occurrence and the extent of impact are used to define the
project exposure to a risk.
Risk Exposure = Probability * Impact.
The higher the impact or probability, the more exposed a project is to the effects of the
risk. If impact ratings are selected in accordance with the risk strategy, then risks from
different areas (e.g. cost, schedule, safety, quality) can be compared with each other
Page 15
based on their Risk Exposure. The risks with the highest exposure are the highest
priority for management.
Risk, Issues, Concerns and Assumptions.
A risk is a potential event that may or may not occur. We can plan for and manage risk
to change the probability of occurrence and the potential impact. An issue is an
unpredicted event that has already occurred and now requires a decision. We cannot
plan for issues as they have already occurred. Issue management revolves around
applying resources to solve current issues or problems. Risk Management revolves
around applying resources to alter a future root cause and its impact. Issue
management is crisis management. Risk Management is forward planning to prevent
crisis management. A risk can become and issue but an issue cannot become a risk.
An example risk is: “Our EPC contractor has the committed to too many mega-projects
and has the potential to become financially unviable”. This may or may not occur and
we can develop plans that explore options to reduce our reliance on this contractor. An
example issue is: “Our EPC contractor has become bankrupt and has ceased
operating”. This is an issue as the event has occurred. Our options are related to crisis
management where we try to reduce the negative damage to our project.
An assumption is a statement that is accepted or supposes to be true without proof or
demonstration. Assumptions are made when there is insufficient information or when
there are aspects that reach beyond the scope of the project and are outside project
control. Assumptions are a major source of risk.
Concerns are information that needs to be taken into consideration but are not risks in
themselves. Concerns are general and do not involve a discrete describable event.
Sources of Risk and who should manage risk
The sources of risk are different for each project but one of the most significant sources
of risk are the assumptions that are made at the early stages of the project – the
business case development. Effective risk management must start when the project is
conceived if this major source of risk is to be captured and managed. The capture,
documentation and communication of assumptions made at any project stage are the
largest steps that can be taken towards risk management. Under most circumstances it
is not the Project Management Team that is making these assumptions.
Risk also originates from outside of direct project control. From a Project Management
Team perspective these could be seen as issues because they are outside the control
of the project, but most could be managed as risks if other parts of the organization also
take responsibility for Project Risk Management. Contracting Strategy is outside of the
control of the project and could be seen as an issue so the project must manage the
problems that arise. By including the contracting department in the PRM process, this is
now a risk and can be managed using resources from the contracting department. Early
adoption of PRM in the Project Life Cycle and including key stakeholders in the PRM
team, the management options for risks becomes broader. This results in PMT being
able to control more outcomes and responding less to ‘fires’. Although the PMT takes
core ownership of the process, every stakeholder is responsible for Risk Management
in their discipline, knowledge area, or operational area.
Page 17
Responding to a Risk
For risks to be managed a response plan must be identified. Response plans must have
a level of detail and a scope of response that is commensurate to the level of exposure.
Risk Response plans target the root cause of the risk and help reduce the likelihood of
occurrence or impact to project objectives of activities. Early identification of a risk can
enable some risks to be completely avoided by using a different contracting strategy,
different design, etc. Each response plan will change the probability and/or impact that
risk has on project objectives or activities.
Risk response plans should target the root cause in a timely manner. All risks have a
time window in which they can be managed before they become an issue, and the
earlier this planning occurs the more options exist to manage the risk. Understanding
the time constraints and root causes of the risk will provide guidance on the most
suitable response plans.
A response plan under most circumstances will not eliminate risk; it will just change the
level of risk. Usually there is a cost associated with doing so. Crashing a project
schedule by performing engineering concurrently with construction can help achieve a
project schedule objective but can also introduce new risks, such as rework being
required. Each response will therefore have further risks associated with it, called
secondary risks, which arise directly because of the response plan. Some risks can
not be managed away no matter what is done. These are called residual risks.
To evaluate the effectiveness of a response plan, secondary risks and residual risks
must be understood. The combination of these when added to the change in impact and
probability that arise from the response plan, provide the net benefit of the response
plan. The most appropriate response plan will be the one that gives the maximum
improvement in the time frame available.
The Risk Register
The Risk Register is the central repository of all information related to each specific risk
identified for the project. The Risk Register contains details on the risk itself (such as
cause, effect and risk exposure) and contains all the information related to Response
Plans. Any risk related decision should only be made on information in the Risk
Register. This is to ensure every stakeholder understands the context in which a risk
decision was made, and also ensures the all information is retained when reviewing the
correctness of a risk assessment and the effectiveness of a risk response. If there is
insufficient information in the Risk Register to assess a risk or a risk response, the
information must be obtained and recorded before proceeding.
Because the Risk Register is used as the source of information for assessing and
recording risk decisions the information included must be relevant and accurate, so any
updates must be screened by the Risk Manager. In addition to recording information
related to a risk, the Risk Register records decisions made on how a risk is to be
managed. A decision process must be established for recording risk related decisions
and updating the Risk Register. Decisions must be agreed by all stakeholders and
authorized by the Project Manager before they are recorded in the Risk Register.
The Risk Register records Risk information and decisions over the life of the project.
The relationship between time and information/decisions allows the Risk Register to be
used to track changes related to a risk or risk response plan. The Risk Register
provides both the basis for reporting and also for auditing Risk Management in projects.
For Saudi Aramco the Risk Register will be managed by software. The software used is
Active Risk Manager (ARM) by Strategic Thought (STG). This software manages the
Risk Register, the links to the corporate Risk Database, the reporting, trending over
time, and provides the audit path for risk decisions.
For more Details on the Saudi Aramco Risk Register refer to Section 4.
Page 19
2.2 Project Risk Management Process
Saudi Aramco Project Risk Management (SAPRM or PRM) Process is shown in the
chart below.
Start
1 - Risk Management Planning
Risk Management Plan
2 - Risk Identification
List of Risks / Root

Causes
4 - Quantitative Risk 3 - Qualitative Risk

Analysis Yes Analysis
Quantitative
List of Quantified Risks Analysis List of Prioritized Risks
needed
No
5 - Risk Response Planning
Risk Response Plan

(Risk Register)
6 - Risk Monitoring and Control
Yes
New Risks
No
Risk Database
Final RM Report
(Risks
Checklist)
End
Figure-2 Risk Management Process

Risk Management is a continuous process that is performed throughout the life cycle of
a project. Saudi Aramco’s process is based on the risk process as defined in the Project
Management Institutes’ (PMI) Project Body of
Knowledge (PMBOK) which describes a series of
6 steps that are cyclic and continuously applied at
each stage in the Project Life Cycle.
The 6 steps defined are:
Identify
 Risk Management Planning
2
MONITOR AND
 Risk Identification CONTROL
 Qualitative Risk Analysis
 Quantitative Risk Analysis
 Risk Response Planning
 Risk Monitoring and Control.
Saudi Aramco depicts these 6 steps as a circle as
illustrated in Figure 3. Each of the 6 steps is Figure 3
completed in each phase of the project and
each step has a defined process and a defined outcome. These 6 steps are explained
below.
For further information refer to PMI’s
Page 1 PMBOK. Introduction to Risk Management
1
PLAN
2.2.1 Risk Management Planning
5 OND
IDENTI
6
RESP
2
MONITORAND
Risk planning is developing and documenting organized, comprehensive,
FY
CONTROL
IFY
QU
AL
and interactive strategies and methods for identifying, understanding and 3
AN
QU
4 TI F
Y
managing risks. To achieve this it is essential to clearly understand and
articulate the fundamental objectives of the project and the Risk Management
requirements. RM planning defines what and when to conduct Risk Management
activities throughout the life cycle of the project. The output of RM Planning is the Project
Risk Management Plan (PRMP). This is the document that communicates to all
stakeholders the approach and process for managing risk on the specific project. The
PRMP is only effective if it is agreed to by all stakeholders. It is used as the basis of
Project Risk Management and it is updated continuously through the Project Life cycle.
For maximum impact, risk planning should start when the project is initiated as this is
where most of the assumptions are made that have the greatest impact on Project Risk.
In PRM planning the following information is collected.
 What should be done and when. Planning of specific risk events (such as risk
assessment) and continuous practices (such as risk monitoring).
 Determine the level of detail required. The level of detail should match the projects
needs
 Roles & Responsibilities. Who are the members of the PRM team and who is
responsible for what? It is not just the project team that has responsibilities.
Organizational departments outside of projects have core knowledge related to
specific risks so they have key responsibilities in the Risk Management Process.
These are project stakeholders.
Page 21
 Risk Tolerance. Risk tolerance defines the level of risk the project is prepared to
tolerate. If a project is time critical then schedule risk has a low tolerance. If cost is
of secondary importance then cost risk has a high tolerance. Although the
corporation gives guidelines in this area, each project must define its own risk
tolerance based on its own project objectives.
 Reporting requirements. Who needs to receive what information? (This will
eventually be standardized for the corporation).
This and other information is captured in the PRM Plan. The plan communicates to all
stakeholders how risk is assessed and managed, what the risk thresholds and tolerances
are, and what risk information will be required. It provides a guideline to the
implementation of later steps in the process.
The PRMP is discussed in further detail in Section 4 and an example PRMP is shown in
the Appendix A.
2.2.2 Risk Identification 1
PLAN
5 OND
IDENTI
6
RESP
Risk identification is where risks are captured. Risk identification is most
2
MONITORAND
FY
CONTROL
effective when it is done in the early stage of the project because the cost IFY
QU
AL
3
AN
QU
4 TI F
Y
of managing the risk is lower as there are more possible ways to address
the risk. Refer to
Figure 4. Business Preliminary
Funding
Detailed
Procurement Construction
Start Up &
Case Engineering Engineering Commissioning
Risk identification is
therefore
recommended to
commence when the
study phase of the
project occurs. This
phase is where the
majority of the Cost
project assumptions
are made that can
introduce risk later in
Uncertainty
the project.
Time
However, risk
identification is an Figure 4
evolutionary process
and as the project proceeds, additional risks will surface and more detail will become
available on those risks already identified.
A Risk Breakdown Structure (RBS) is a hierarchical categorization of sources of risk and
is used in the process of risk identification. During risk identification, the RBS has the
following benefits:
 The categories and subcategories are a catalyst for identifying risks for the project
 The process of categorizing enables the risk to be better understood, thus
enabling a risk owner to be identified, a root cause to be determined, and a project
phase to be determined.
The Risk Breakdown Structure is further discussed in Section 4.2.

Risk identification can be done by various techniques including brainstorming, interviews,
Lessons Learned, and reviews from previous projects. Risks are captured but not
prioritized. This is because a risk may not currently be a priority but may become
important later. Once identified, a risk is easy to monitor for future impact.
When identifying risks certain information is usually captured. Root cause is determined
as this will allow response planning to be more effective. Impact area (such as schedule,
safety, and quality, environmental) is also identified to give focus to the risk assessment
phase. A risk owner is assigned who understands the risk and can take ownership for
preparing information to further asses the risk.
The outcome of this stage is a Risk Statement for each risk. The information in the Risk
Statement is further discussed in section 4.3.
1
PLAN
2.2.3 Qualitative Risk Analysis
5 OND
IDENTI
6
RESP
2
MONITORAND
FY
Qualitative Risk Analysis is the step whereby each risk is analyzed based CONTROL
IFY
QU
3 AL
on the probability of its occurrence and its potential impact on the project.
AN
QU
4 TI F
Y
Impact can be assessed in many areas such as schedule, cost, safety,
quality, and environmental. Impact and probability are assessed on a five level scale from
very low to very high. Each project will have decided in the Project Planning phase the
relationship between the five levels and actual project impact values. For example, a Very
High impact for cost might be $10 M while a Very High impact for safety might be a fatality.
The process of using a five level scale normalizes risks between different areas so they
can be further analyzed side-by-side.
Having assessed each risk for the probability of its occurrence and impact on project
objectives, each risk is plotted on a heat map. An example heat map is shown below. The
risks that fall in the red areas are considered ‘hot’ or critical risks and these become the
highest priority for risk
Impact
management.
Opportunity
Opportunity
Opportunity
opportunity
opportunity
Very High
Very High
Moderate
Moderate
Very Low
Very Low
High
High
Low
Low
Heat Map
Very
High
High
Figure 5
Probability
Moderate
Low
Very
Low
Low Important Significant Critical
Low opportunity Moderate Opportunity High Opportunity
Page 23
The risk heat map in Figure 5 above only indicates ‘downside risk’ that has adverse
consequences or negative impact. Equally there are ‘upside risks’ that have positive
effects or present opportunities should they occur. The process for analyzing upside risk
is identical to downside risk but the heat map has an ‘opportunity side’. The equivalent to
‘critical’ for upside risks are those that have the maximum positive benefit to the project
and are therefore the highest priority for management.
Qualitative Analysis should be conducted by personnel who have good judgment,
experience in the type of project being considered, and should have relevant knowledge
of the risk areas the project is exposed to.
At the completion of Qualitative Risk Analysis all identified risks will have been analyzed
and ranked. The list of prioritized risks will be screened to identify those that need to be
managed and those that require further analysis through Quantitative Risk Analysis.
2.2.4 Quantitative Risk Analysis 1
PLAN
5 OND
IDENTI
6
RESP
For some risk management decisions the need arises for a greater detail of
2
MONITORAND
FY
CONTROL
risk information than was required in the previous step. The risk owner IFY
QU
AL
3
AN
QU
4 TI F
assigned to the risk is knowledgeable in the risk are and is responsible for
Y
gathering the detailed information.
Having collected detailed risk information, Quantitative Analysis proceeds. Tools used to
accomplish this step are usually provided by PRM software. Techniques include
Sensitivity Analysis, Simulation and Decision Trees. This stage of analysis allows the
following types of questions to be answered:
 What degree of confidence do we have for the achievement of a specific
milestone?
 How sensitive are particular milestones to the major risks?
 What are the main risk drivers for the schedule and if we addressed them how
could we change the confidence of specific milestones?
 If we need to bring a project in 6 months earlier, how confident are we that this
could be achieved, what risks work against us, and what actions are required to
make this happen?
 If we decided that project cost was now the prime criteria for project management
and not schedule, what things could we do differently to reduce cost and what
impact would that have on the project?
Quantitative Analysis allows the project to understand the degree of impact from a
particular risk, allows the project to understand what they can influence and what they
cant influence, and allows the project to determine which risks drive the project. It also
allows an understanding of what actions are feasible to manipulate risk.
Quantitative Analysis requires an in-depth understanding of the risk and possible
response plans. The process should only be performed when appropriate subject matter
experts are included.
Quantitative analysis is discussed in more depth in the Handbook. Refer also to Appendix
B for a sample “What-if” report that shows the output from a Monte Carlo simulation that
can be done as part of Quantitative Analysis.
2.2.5 Risk Response Planning 1

PLAN
5 OND
IDENTI
6
RESP
For each opportunity and threat to the project, options and actions are
2
MONITORAND
FY
CONTROL
developed to ensure optimum outcome. For each critical risk a response IFY
QU
3 AL
AN
QU
4 TI F
plan is developed for how the risk is to be managed. The response plan will
Y
alter the probability the risk will occur, or will alter the impact it has on the project. Each
risk may have multiple response plans developed, each with different costs and
benefits. Each Risk Response Plan is assigned to an owner to manage, to ensure the
appropriate information is collected so its suitability can be assessed and the response
enacted.
Each risk considered critical/important will have one or more detailed Risks Response
Plans. As part of the response planning process a preferred risk response will be
selected with trigger points for activating the selected response.
There are a number of different response types that can be taken for a risk. For
downside risk, in order of effect on risk impact, these are:
 Avoid. Change the project plan/design to eliminate the threat entirely.
 Mitigate. Reduce the probability or impact of the risk to be within acceptable limits.
 Transfer. Shift some or all of the impact, along with ownership and management,
to a third party. This party usually has higher expertise in the risk area.
 Accept. It is seldom possible to eliminate all threats. Passive acceptance requires
no action. Active acceptance would be to have a contingency reserve for the risk.
For upside risk, in order of impact, these are 'exploit, enhance, share, and accept'. The
table below shows the four levels of downside risk and the four risk response strategies.
The higher the risk level, the more appropriate are the strategies to avoid or mitigate the
risk. Only with Low risks is ‘acceptance’ a suitable response strategy. Therefore the risk
response must be appropriate to the level of the risk. Refer to Figure 6 below.
Risk Level Response Comments
Do things Differently to
Critical Avoid
avoid the risk.
Reduce the probability or
Significant Mitigate
impact of the risk
Pass ownership to a 3rd
Important Transfer
party (insurance)
Live with the risk. Set
Low Accept
contingency.
Figure 6
Once a risk trigger is activated, the Risk Manager will propose a Risk Response plan to
be enacted. Tasks within the response plan will be submitted through standard Project
Management Change Control to be adopted into the project base line. The Response
Plan will have altered the probability or impact of the risk and may have given rise to a
further, or secondary, risk. The risk Register must be updated to reflect these changes.
The impact from secondary risks must be considered when evaluating the optimum
Page 25
response to the primary risk, as they will reduce the effectiveness of the risk response.
All risk response plans must have secondary risks fully documented and considered.
2.2.6 Risk Monitoring & Control 1
PLAN
5 OND
IDENTI
6
RESP
2
MONITORAND
Risk Monitoring & Control covers those activities that are performed on a
FY
CONTROL
continuing basis for the management of the risks and response plans IFY
QU
AL
3
AN
QU
4 TI F
Y
throughout the Project life Cycle.
Monitoring
Monitoring involves the process of reviewing the information related to a risk and
identify if the risk has changed over time. As well as monitoring and tracking individual
risks, project assumptions are revalidated and new or emerging risks are identified for
further evaluation. Each risk is reassessed as to its probability of occurrence and
impact on the project in light of new information or changing project needs.
In addition to understanding the change in risk, contingency reserves are evaluated and
predicted to ensure sufficient reserves are available for the life of the project. An
essential task in monitoring is also ensuring the risk management policies and
procedures are being correctly followed, and the project is conforming to the PRM Plan.
During the process of Monitoring, the available information is analyzed as to its impact
on the project and where there is a possibility to improve project outcomes. Trend
analysis and variance analysis will identify emerging risks. What-if analysis and
sensitivity analysis will help identify those risks that have the greatest impact on the
project and, if they are satisfactorily addressed, what the opportunity is to improve the
project outcomes. Although some of this analysis can be performed manually, they are
usually performed using Risk Management software. However, risk management
software is only effective if the Risk Register is sufficiently and appropriately populated.
Risk Monitoring, including sensitivity Analysis, trend analysis and what-if analysis, is
further discussed during Risk Software training.
Controlling
The monitoring process will identify risks that have reached their trigger point or identify
risk responses where project outcomes can be improved. These risks must be correctly
controlled. Controlling is the process of acting on risk information to change the Risk
Exposure. In some instances controlling a risk could simply be gathering information to
understand if the level of the risk has been correctly determined. In other circumstances
changes in the Risk Exposure are achieved by enacting a Risk Response Plan.
To enact a Risk Response Plan the tasks it describes must be included in the project
baseline via a change order. The decision to enact a plan therefore can only occur if the
risk response information is complete and accurate. The guidelines of enacting a risk
response plan will be governed by the Project Change Management process.
Once a Risk Response Plan is enacted and its tasks incorporated in the project
baseline, the Risk Exposure may be lowered such that it no longer needs to be tracked.
However, any secondary risks that are identified must now be included in the Risk
Register and actively managed.
Risk Monitoring and Control is a continuous process and should part of standard Project
Management practices.
Page 27
3. Saudi Aramco PRM Process
This section describes how Project Risk Management is executed within Saudi Aramco.
This is referred to as the Saudi Aramco Project Risk Management (SAPRM or PRM)
Process. This section is an overview of the process; for more detail refer to the
Handbook.
The key principles of PRM are:
 Applicable to all projects
 Centered on a corporate Risk Database to which all project specific risks are
linked. This provides the benefits of
 Visibility of risk exposure up and down the management chain to help the
project obtain support from key stakeholders, to ensure risk information is
communicated effectively, and to ensure that all stakeholders understand
what risk decisions the project is or is not making.
 Corporate can understand the level of risk exposure across all projects.
 Sharing of risk information/planning between projects facing similar risks.
 Create a repository for learning based on specific risks where not only
lessons learnt are captured, but where a project can access information on
what has worked or not worked in the past related to the specific risk.
 Maximum effectiveness if initiated early. PRM should be initiated when the
project is initiated.
 An evolutionary process where the information related to a specific risk becomes
more detailed as the project moves closer to that risk event.
 Can commence at any stage in the project life cycle.
 Integral to Saudi Aramco Capital Process and stage gate decision points.
 Requires explicit engagement of all key stakeholders.
All of the above key principles must be satisfied if Saudi Aramco is able to achieve best
practices in project management and to effectively achieve its corporate objectives. The
failure of any one of the key principles will significantly reduce the value Project Risk
Management can add to the project and the corporation.
PRM can only be effective if all Saudi Aramco stakeholders are explicitly involved. In
addition, the process is only effective if EPC contractors are forced to use the process
and actively manage risk as part of their project responsibilities. It is expected that
future EPC contracts will have this provision. Involvement of stakeholders occurs
through participation in Cross-functional PRM team activities, and taking ownership of
risks and response plans in their area of knowledge or operation.
3.1 Organizational Assets to support PRM

There are six major organizational assets available to support projects performing PRM:
Project Risk Support Team, Engineering Practices, Project Risk Practitioners
Handbook, Risk Database, Active Risk Manager (ARM) software, and the training.
3.1.1 Project Risk Support Team
Project Support and Control Department (PS&CD) has developed resources to help
projects understand risk, start risk management in their project, and provide ongoing
support to projects for Risk Management. The Project Risk Support Team provides the
following support and services:
 Champions and manages the process at the early stage of the project life cycle
before a Risk Manager has been identified for the project.
 Provides information, education and training across the corporation to ensure all
prospective stakeholders understand the process and understand their role and
requirements.
 Provide documentation, tools, checklists, etc to enable RM to be performed by
projects. This includes the update and revision of this Guide and the Handbook.
 Collect information and feedback on the process and tools and update these on a
regular basis to ensure they continually meet the needs of the project and the
corporation.
 Provides resources and guidance for the establishment and practice of RM in
projects.
The following website will contain key links to project risk assets
http://pscd.aramco.com.sa/cpod/risk
3.1.2 Engineering Practices
Saudi Aramco Engineering Practices (SAEP) and General Instructions (GI) will be
modified to ensure all contributors to the PRM Process and its successful outcome have
full awareness of their responsibilities. The SAEP’s define risk processes and
responsibilities at each stage of design, engineering and construction, etc. of the
project. For more information on PRM tasks that are defined in SAEP’s and GI’s, refer
to the Handbook.
3.1.3 Project Risk Management Practitioners Handbook (Handbook)
The Handbook provides more detail regarding the Saudi Aramco PRM Process. The
Handbook describes in detail the processes and how the processes are executed. The
Handbook provides details on tools and techniques to perform the individual steps in the
process but does not discuss or educate the reader on risk management. The PRM
Process is discussed in further detail in the PMI PMBOK.
Page 29
3.1.4 Corporate Risk Database
The Corporate Risk Database (or Risk Database) is a central repository for information
relating to Risk. Each risk in the Project specific Risk Register is linked to a risk in the
Risk Database. This is discussed in further detail in Section 4.2. In brief, the Risk
Database provides the following advantages:
 Risks common to a number of projects can be understood at the corporate level:
 Senior management understanding on where the corporation is most
exposed, or most uncertain, across the project portfolio.
 Corporate response to be made if necessary to maximize risk response
effectiveness.
 Corporate understanding of major areas of risk exposure.
 Risks common to a number of projects can be indentified at the project level:
 Projects to combine their knowledge and experience to tackle a risk issue.
 Develop joint Risk response plans.
 Risks that are not managed are made visible to the corporate level:
 Understanding what risks are beyond the project to control.
 If a project has been waiting for external support to mange a risk, the lack of
support is transparent.
 The decision to manage a risk in a certain manner is made transparent to
ensure management understands the response decision. Management can
request different action to be taken if required. Project actions cannot be
questioned at a later stage.
 All learning and risk history for all projects are stored in the risk database:
 Projects can review past actions and the effectiveness of the actions.
 Projects can understand the probability of a risk occurring and the potential
impact.
 Projects have an instant source to populate their project specific Risk
Register.
 All information is risk specific and not of a general nature.
 Benchmark information can be developed to understand distinguish good or
poor risk performance.
 Project specific risk management can be compared by management across
different projects, both current and past.
3.1.5 Project Risk Software
Active Risk Manager (ARM) has been chosen as the software for Project Risk
Management. The major attributes of this software include:
 Manages all types of risk including schedule, cost, safety, quality, environment.
 Can be used at any project stage even if a schedule is unavailable
 Facilitates the process of identifying and analyzing risk
 Manages how risks change with time so that trends and variances can be
analyzed and project risk performance can be tracked.
 Facilitates proactive planning rather than static reporting.
 Can perform “what-if” analysis and Monte Carlo simulation to understand possible
outcomes of risk responses.
3.1.6 Project Risk Training

Training will be provided at three levels that relate to the needs of the individual.
 Awareness training will be brief and targeted to personnel who are not directly
involved in Project risk Management but need a brief understanding of what it is.
 Overview training will be targeted to any Project Risk stakeholder who needs to
understand the process but is not required to understand the detail.
 Detailed training will be targeted at Project risk Managers or other personnel that
require a detailed understanding of the process, the tools and techniques.
3.2 PRM Process and Project Life Cycle Interface

The PRM Process is mapped onto the Project Life Cycle (the Capital Process). The
PRM Process is a series of eight repetitive activities that occur at each stage of the
project life cycle. Refer to the Figure 7 below.
EARLY DBSP PROJECT FUNDING DETAILED

PLANNING PROPOSAL DESIGN
PROCUREMENT
CONSTRUCTION
STARTUP
Figure 7
The PRM Process defines two types of activities – discrete events and continuous
practice. The events are indicated in Figure 7 by the risk circle (described in Section 2),
and the continuous practice is represented by the blue arrow. These are shown at the
bottom of the figure. The blue arrow is analogous to the centre (dark blue) of the risk
circle being spread over the life cycle of the project. This dark blue is the practice of
Monitoring and Control. This implies that planning, identification, qualify, quantify and
response planning, all happen as events, and monitoring and control is practiced
continuously. This is how the PRM Process is structured.
Risk process events are mapped to specific stage gates in the capital process and start
when the project itself is initiated. If the risk process is not initiated at this early stage in
the process then the effectiveness of the process is limited.
Page 31
3.3 Project Risk Process Roadmap
PRM is achieved through eight events as well as the continuous practice of Monitoring
& Control as shown in Figure 7. The first four events are mapped to specific stage gates
during the Project Planning Phase.
An additional event occurs during project close-out is to ensure the Corporate Risk
Database is updated and to capture Lessons Learnt. Note that the structure of the
Corporate Risk Database is such that managing the Project specific Risk Register will
automatically update the Corporate Risk Database.
The risk events are weighted towards the front of the process as this is where the major
assumptions are made, and any changes made to the project that arise from the PRM,
have the most impact and the least cost on the project.
Facilities planning (FPD) owns the process during the initial stage of the project life
cycle so FPD has the major responsibility to commence the PRM process for a specific
Project.
Project Risk Management is an industry Best Practices and as such it is mandated on
all projects. SAEP’s will be modified to include the requirements for PRM. This allows
all project stakeholders to contribute to PRM and not rely solely on the Project
Management Team. For more detail on the PRM process or a description of which
SAEP’s reference the PRM process, refer to the Handbook.
3.4 PRM Activities

Each Risk event or risk continuous practice in the Project life cycle is achieved through
six PRM Project activities: Risk Planning Session, Risk Workshop, Risk Action Review,
Risk Quantitative Assessment, Risk Monitoring Session and Risk Control Session.
These activities occur at every stage in the project Life cycle but differ in scope, detail,
structure and objectives. Additional activities managed by PS&CD occur to ensure the
PRM Process is adopted correctly and to capture feedback.
In the early stages of the project the Project Risk Support Team will manage these
activities on behalf of the Project. When a Project Risk Manager is identified these
activities will be managed by the Project Risk Manager with the support of the Project
Risk Support Team.
The PRM effort is loaded towards the front of the Project Life cycle. Activities related to
Event 1 and Event 2 encompasses more work effort as it involves the creation of the
Risk Register and creation of the Risk Management Plan. Later events are orientated
towards reviewing and updating these and therefore require less effort to achieve. If a
project commencing PRM partway through the Project Life Cycle, Event 1 & 2 will
need to be conducted at the point the project commences Risk Management. The
events between Event 2 and the current life cycle position would then not be required.
3.4.1 Risk Planning Session

The Risk Planning session is a session with the Core Risk Management team to
develop and revise the Project Risk Management Plan. This activity is initially led by the
Risk Support Team until a Project Risk Manager is assigned to the project, and then it is
led by the Project Risk Manager.
Risk planning is best accomplished with a core group of around 4 people. Much of this
process is the collection and recording of information related to the project and can be
conducted informally. Once the majority of the information is collected then a meeting or
roundtable is scheduled to step through the PRM Plan to ensure it is complete and
accurately represents the information as viewed by the core team.
A key part of the PRM plan is identifying the Cross Functional Risk Team. This team
consists of the members of the Core Risk Team and additional stakeholders and
Subject Matter experts (SME’s) related to the project. The Core Risk Team is the PMT
and Proponent representatives who are involved in PRM on a regular basis and who
have responsibility for the RPM Process within the project. It is important that all project
stakeholders are member of the cross functional team as they will be required to take
ownership of risks identified in their area of operation, responsibility, or expertise. For
this reason, once the initial draft of the PRM Plan has been developed, it must be
presented to and agreed on by all stakeholders. This ensures they all understand and
agree to the risk strategy and decision making criteria, and helps them to buy-in and
take ownership of issues and activities.
The planning session accomplishes the requirement of the Planning step in the PMI six-
step risk cycle. The outcome is the Project Management Risk Plan. The initial planning
session prepares the Risk Management Plan and subsequent sessions review and
update the PRM Plan. The PRM Plan is discussed further in Section 4 and an example
is shown in Appendix A.
The discussion and agreement to the PRM Plan is performed in the Risk Workshop as
outlined below as this is when all the stakeholders will be present. Ratifying an updated
PRM Plan can also occur in workshops later in the project life cycle.
3.4.2 Risk Workshop
The Risk Workshop is performed with the Cross Functional Risk Team where the Risk
Register is developed or updated through the process of risk identification, qualification
and response planning. For these workshops to be effective it is vital to have good
representation from the entire cross functional team.
The Risk Workshop is typically a one day facilitated session. This ensures input from all
workshop participants is captured and sufficient time is allocated. A one day workshop
is an exhaustive session but is required to achieve focus on the workshop objective.
Depending on the complexity of the project and the stage in the Project Life Cycle, a
number or workshops may be required. To maintain focus and to prevent revisiting the
same information, each workshop should have a specific focus (e.g. identification and/or
qualification or response planning).
At each workshop the PRM Plan should be presented to ensure each participant is
aware of the Risk Strategy, the Risk Criteria, and their role related to outcomes of the
Page 33
workshop. In addition, a presentation by the Project Team on the background and life
cycle stage of the project is a valuable aid to ensure all the participants are ‘on the
same page’.
It is recommended that these workshops are facilitated by a third party to ensure that no
bias is seen by the participants during the brainstorming and evaluation phase. PS&CD
can provide facilitators or can provide information on suitable contractors who know how
to facilitate the process to Saudi Aramco standards. The detailed process of
identification, qualification and Response planning is documented in the Handbook and
a Facilitators Guide is available from PS&CD to guide the facilitator in workshop
process.
The main outcome of the Risk Workshop is to update the Risk Register, but in many
circumstances insufficient information is available to make some judgments related to
risks. Therefore, a secondary outcome of the workshop is to define actions (and dates)
that are required before further evaluation of the risks.
The appointed facilitator will manage the workshop scheduling, preparation, invitations,
facilitation, and reporting. The reporting consists of the Updated Risk Register and the
list of actions arising from the Workshop.
3.4.3 Risk Action Review
The Risk Action Review is performed by the Core Risk Management Team. This
session is to Review outcomes and actions from workshops or other sessions and the
information that has been collected as a result of actions. The Risk Manager controls
this process. A Risk Action Review needs to be scheduled (at least) as a follow-up of
every workshop, Monitoring Session and Control Session.
3.4.4 Risk Quantitative Analysis
To fully understand a Risk and the appropriate Risk Response Plan, a more detailed
analysis must sometimes be performed. Quantitative Analysis is a time consuming
process and is only performed on those risk identified with the highest Risk Exposure.
The essential key to this step is to ensure accurate and detailed information is collected
on the risk and the potential Risk Response Plans.
The process is software centric and requires the person performing the analysis to
understand the operation of the software. Training is available on the software that is
used to perform this process. Alternatively, PS&CD can provide support to the Risk
Manager to perform this analysis.
Quantitative Analysis must be performed either by, or under the direct guidance of the
Risk Manager. The What-if analysis provided by this step is only useful if the output is
analyzed. Analysis may require the process to be run again with a different set of
criteria. Only an experienced risk practitioner who understands the Project Risk Strategy
can perform this analysis process.
The output of this Analysis is an understanding of what is possible and what is not
possible in managing risks. It allows the Risk Manager to recommend response plans
based on feasibility and response effectiveness. Refer to the Handbook for more
information related to this activity.
3.4.5 Risk Monitoring Session

The Risk Monitoring session must occur prior to Project Review Meetings so that Risk
Control Actions can be evaluated and agreed upon. Risk Monitoring is the process of:
 Collect and update risk data. What information is required and who will supply it.
 Evaluating the data. Is the information appropriate and valid? What has changed?
 Reporting the status or changes in the data.
 Recommending control actions.
Collecting risk data and generating reports is an administrative process and is a task
that can be assigned to a Risk Coordinator. Determining if the data collected is valid
and appropriate requires a degree of understanding of the risk, but may be delegated to
a suitable knowledgeable person. Evaluating the data and recommending control
actions requires a detailed understanding of the Risk and the Risk Response Plans and
is the responsibility of the Project Risk Manager.
The level of evaluation is dependent upon what has changed. Under most
circumstances the Risk Register will provide key trigger information and the Risk
Manager will be alerted to the need to either evaluate a Risk or Risk Response further,
or recommend a control action. The Risk Register should contain the information
required for the Risk Manager to evaluate and recommend as this ensures that all
stakeholders understand the criteria and information on which a risk decision was
made. An auditor can later examine the reason behind a specific risk decision.
The process of Monitoring may require a Quantitative Analysis session to occur. For this
reason the Monitoring session should be done sufficiently in advance of the Project
Management Review Meeting to ensure appropriate information is collected to conduct
the Quantitative Analysis.
The PRM plan will define what information is required and the process used to
recommendation a control action (Risk Response Plan).
3.4.6 Risk Control Session
The Risk Control session is the process of enacting a Risk Response Plan or alternative
control action, such as obtaining further information. A Risk Response Plan is enacted
by including in the project baseline the tasks defined in the Response Plan. Risk Control
actions will be analyzed and agreed upon during the Project Management Review,
unless the nature of the risk and/or actions requires special attention or additional
management approval.
Each risk Control Action recommended by the Risk Manager will have a process that
outlines the recommendation and the authorization required to enact the control. The
Project Manager is responsible for deciding what control actions will occur and for final
signoff. Once the signoff for the control action has occurred, the Risk is updated in the
Risk Register and the control is executed. If a Risk Response Plan is enacted the Risk
has now changed and the Risk Register is updated. Secondary risks resulting from the
Risk Response are now included in the Risk Register.
Page 35
3.4.7 External Review
External Reviews occur where additional control sessions are hosted by parties external
to the PRM team, such as PS&CD and Auditing, to review the effectiveness of PRM
Process and how it has been applied by the project team.
3.4.8 Example Events and Activity Description
Refer to Appendix C for an example description of the Events and Activities that occur
during the typical project lifecycle.
3.5 Roles and Responsibilities

The Project Risk Management Team comprises a “core team” and additional
participants. Together they make up the cross-functional team. The core team members
are involved in all risk activities. The cross-functional team is assembled during specific
risk events and representation will depend on the project stage in which the event is
occurring.
The core risk team should consist of the Project Risk Manager, the Project Manager (or
representative), the proponent (or representative), and a maximum of three other
representatives that are closely linked to the project throughout the project life cycle.
The cross-functional team will include members from all stakeholder groups and subject
matter experts that are appropriate for the type of project.
Roles and responsibilities are explained below.
Project Risk Manager (PMT role)
Roles & Responsibilities
 Manages the PRM process from beginning-to-end from within the Project
Management Team
 Produces and updates the PRM Plan
 Owns the PRM tools and templates
 Initiates and organizes PRM Activities
 Ensures that risk information is gathered in a consistent way and recorded to the
required quality
 Owns the Risk Register and manages the process for regular updates
 Provides training and ongoing guidance to the project on the PRM process
 Administrates the quantitative risk analysis process.
 Interprets the results Monitoring and Quantitative Analysis activities and provides
recommendations for Control Actions.
 Request support services for risk management.
Role Profile
 A good understanding of project management gained through a minimum of five
years experience in Project delivery.
 Well organized and a good facilitator and communicator
 Understanding of quantitative techniques associated to risk (e.g. Monte Carlo
analysis).
Risk Coordinator (PMT role)

 Provides administrative support to the Risk Manager to organize communication,
workshops, meetings etc.
Role Profile
 Well organized and good IT skills
 Planning skills.
Project Manager (PMT role)

 Regularly monitors risks
 Review the completeness of risk information and Risk response plans.
 Analyses the effectiveness of risk response plans
 Makes decision to activate Risk control actions including recommendations for risk
Response Plans to be incorporated in project Baseline.
Proponent Representative
 In conjunction with FPD, the initiator of the Project Risk Register during the
Planning Phase
 The acceptance of both ongoing operational risk and residual project risk on
completion and acceptance of the project.
Role Profile
 A clear understanding of the principles of PRM and reporting.
PRM Champion/Specialist (PS&CD role)
 Subject matter expert for PRM within Saudi Aramco PS&CD
 Champions the PRM process
 Provides risk management input during the early stages of Project initiation and
study
 Updates the overall PRM approach by gathering feedback from risk managers
 Reviews best PRM practice from other sectors and industries and considers
suitability of adopting or adapting this for SA.
Role Profile
 A comprehensive understanding of Project Management gained from managing
projects for a minimum of 10 years.
 A comprehensive understanding of Project Risk Management gained from
managing the PRM process for a minimum of 5 years.
Page 37
Cross-Functional Team member (refer to Project Risk Management Plan)
 Represent key stakeholder groups within the project
 Attend PRM workshops and forums to input and provide collective expertise in
undertaking the PRM process
 Single point of contact for the PRM issues for their key stakeholder group
 Gather input from their group to feed into the PRM process
 Manage and monitor risks and risk response plans that impact their stakeholder
group.
Role Profile
 A good understanding of the project area that they are representing, gained
through delivery of similar functionality on previous projects or through specialist
subject knowledge
 Team players
 Strong analysis and problem solving skills.
Page 39
4. Project Risk Management Core Tools
4.1 Project Risk Management Plan
The Project Risk Management Plan defines how and when to conduct risk management
activities and defines the information used in conducting those activities. It should be
established at the same time the project is conceived and completed during the project
planning phase. It is initially developed using a template and populated with information
supplied by the PRM Core Team. It is reviewed with stakeholders during the workshop
process and is reviewed throughout the project life cycle.
The PRMP is a communications tool to ensure that every stakeholder has the same
understanding and expectations regarding risk and its management. The PRM plan is
part of the overall Project Management Execution Plan and risk management activities
are integral with PM activities.
An example PRM Plan appears in Appendix A.
Each Project Risk Management Plan should have the following sections:
 Project Description. This ensures all stakeholders, particularly those without full
time involvement in the project, understand the project context. Minimum
information includes:
 Project Scope
 Project Schedule
 Project Objectives
 Risk Decision-Making context. This ensures that each stakeholder fully
understand the criteria by which risk decisions are made. This section defines the
risk strategy and the risk tolerance for the project and must be ratified by
management. Minimum information includes:
 Unique aspects of the project or environment in which the project is
executed.
 Risk Strategy or objectives that need to be considered when making risk
decisions
 Risk Tolerance. How is probability of risk occurrence and risk impact
assessed?
 Risk Escalation. What is the procedure for escalating a risk?
 Roles and Responsibilities. This indicates who is involved in Project Risk
Management, how and when they are involved, what their skill/knowledge is and
what their responsibilities are.
 Activity scheduling. The risk process requires a number of activities to be
scheduled throughout the life of the project. The frequency and format of the
continuous practices must be defined.
 Risk Detail. This should indicate what level of detail is required for each risk at a
given risk exposure and what level of detail is required for each risk response
plans. Information on risk owner and response owner should also be defined. The
framework for reporting risk trends and variations should be defined. The process
of proposing and signoff for enacting Risk Response plans should be documented.
The process for authorizing updates to the Risk Register should be documented.
 Reporting. This defines what information should be generated, in what detail, how
often, distributed to whom and in what form. It should prescribe the process for
information feedback to the project. Risk reporting ensures that the degree, type
and visibility or risk Management is appropriate to the risks and the importance the
project is to the corporation.
 Training. This should define the training requirements of the stakeholders and
members of the PRM Team.
4.2 Corporate Project Risk Database

The Corporate Risk Database (Risk Database) is the key link that relates Project Risk
Management to Enterprise Risk Management. It provides the link between projects and
senior management and the link between projects and other departments or business
lines. The Risk Database allows a specific business line or skill area to understand and
take ownership of risks related to its business; these would normally be difficult to see
because they are wrapped in the Project umbrella.
The Risk Database is the central repository of all identified risks faced by the
corporation. This database captures the risks for all projects but is not a substitute for a
project specific Risk Register. Project specific risks are captured through brainstorming
and analyzing the project life cycle and environment, but the Risk Database can be
used as a catalyst for identification and prioritization. Standard Risk Registers for
specific project types can be built from the Risk Database to provide an initial Risk
Register when a project of a specific type is first initiated.
Each risk in a project Risk Register is linked to a risk in the Risk Database. This
achieves the following objectives:
 Risks common across many projects can be identified at the corporate level to
allow the corporation to manage some risks strategically and remove the
specific risk burden from individual projects.
 The rollup of risks for all projects allows the corporation to understand what areas
of the business are uncertain and what these uncertainties mean. This allows
the corporation to proactively manage the outcome of uncertainties related to
achieving its objectives.
 Each project can see whether other projects are facing the same risk, what
response plans they have identified, whether the risk manifested, what response
plans were enacted, and how effective they were. Alternatively this could be the
catalyst to develop a cross-project team to manage the risk for a number of
projects. It can also be used to understand the effect a response could have on
other projects, and vice versa.
 Risk issues can be given visibility to higher management. If a project is having
difficulty finding the resources to address a specific risk, the Risk Database gives
visibility of this higher up the management chain. If a project needs support from
another department outside its control for it to manage the risk, should that support
not be provided, visibility of this is raised through the Risk Database and Risk
Register. It also allows for capturing information on specific risks and becomes the
lessons learnt database for specific risks. The Risk Database becomes the central
repository for all risk information and all risk learning for all projects.
Page 41
 Risks that require specific knowledge or skills can be assigned to the business
area that is best equipped to manage that risk. This allows the business area to
proactively get involved in those projects that are exposed to risk in its business
area.
The Risk Database defines eight risk categories. These are discussed in the Risk
Breakdown Structure.
To ensure risks exposure can be compared across projects and can be accumulated at
a corporate level, the risk tolerance for a specific project must be stated. Initially this will
be based on corporate recommendations for risk tolerance and then modified by the
project. This normalizes risks within projects and between projects. The corporate
standard risk tolerance is shown in the example PRM Plan in appendix A.
4.3 Project Risk Breakdown Structure

A Risk Breakdown Structure (RBS) is a source orientated grouping of project risks
where each level represents an increasing level of detail defining the source of the risk.
The RBS facilitates understanding, communications and management or risk. The RBS
is primary tool used to identify risks as it focuses on the primary causes of risk.
Reoccurring themes can be easily identified. It allows us to ask “is this a source of risk
to our project”. The RBS is the basis of the Corporate Risk Database which allows the
corporation to understand the major sources of risk to the corporation. The Corporate
Risk Database is discussed in Section 4.2
The RBS is defined as eight major categories, with each major category containing a
number of subcategories. This provides the following benefits:
 Provides a catalyst for identifying risks for a specific project.
 Allows a project to review learning from previous projects on a specific types of
risk.
 Allows a project to identify other projects that are exposed to the same risk types
and take advantage of developing joint strategies with the other projects.
 Accumulate risk exposure across projects to identify areas of high uncertainty at
corporate level.
 Enables a department or business area to understand the level of uncertainty
related to that business or knowledge area, so they can proactively manage root
cause to relieve projects of risk in those areas.
 Allow for corporate risk response strategies to be developed and made available to
projects.
The eight major categories of Risk (top level) for the RBS are as follows:
 Project Delivery. Includes all areas relating to the planning, development,
scheduling and execution of project activities. Specifically this contains risks over
which the Project Team has the majority of control on outcomes. Risk in this
category will typically manifest between Expenditure Request Approval (ERA) and
Mechanical Completion (MCC).
 Financial. Includes financial activities such as budgets, estimating, and
contingency. Specifically this contains risks over which the finance departments
have the majority of control. Risks in this area that are related to the project have
the potential to manifest at any stage in the project life cycle.
 Engineering & Technical. Risks in this area can typically be combated through by
the commencement of Project Risk Management early. If identified early, these
risks can be avoided.
 Operational. Risks to the project in this category are those that occur when
interacting with existing operations. This area of risk is predominantly associated
with Brown Field sites and the risk usually manifests in construction or Mechanical
Completion and hand-over.
 Markets. This relates to risk outside the direct control of the project and arise from
the management structure, organization structure or organizational processes in
the organization.
 People. This relates to risk outside the direct control of the project and arise from
the management structure, organizational structure or processes.
 Legal. This includes contracting strategies and other legal frameworks that have a
direct impact on the project. It also includes economic and environmental
constraints imposed from outside the organization.
 Strategic. These relate to corporate direction and requirements.
Under each of the major categories there are a number of sub-categories. Using the
RBS enables Risk Management to be assigned to the correct risk owner who has the
capability/ knowledge/ authority to have the greatest impact on the risk. The RBS also
enables the corporate management to understand the areas of the organization that
cause the greatest exposure to risk or uncertainty.
Refer to Appendix D for the top two levels of the RBS for projects.
Page 43
4.4 Project Risk Statement
The Risk Statement is the information in the Risk Register that describes the Risk and
the Response plans. The information that relates to the risk is described below.
Field Description
ID Numerical ID of the Risk
Name Brief Name to identify the risk
Category Risk Category (refer to Risk Breakdown Structure)
Class Risk Sub-Category (refer to Risk breakdown Structure)
Schedule Impact Impact on Schedule – if appropriate
Cost Impact Impact on cost – if appropriate
Safety Impact Impact on safety – if appropriate
Quality Impact Impact on Quality – if appropriate
Probability Probability the risk will manifest
Heat Probability weighted Impact from the highest Impact area
Phase Managed Project phase where management actions are required for maximum effect on the
risk
Phase Affected Project phase that will be affected by the risk
Owner Risk Owner (Risk Category helps define this)
Description Description of the risk
Root Cause Root cause of the risk
Effects Effect if risk manifests
Raised By The person who first raised the risk
Identified Date the risk was identified
Risk Type Critical, Significant, Important, Low, closed, associated, issue, concern
Target Resolution Date the risk needs to be resolved by
Target Risk Level Level of risk required when risk resolved
Trigger Type Date, probability level, etc
Trigger Value Probability/ date etc which will initiate a Risk Response Plan.
Assessment Date Date the risk needs to be re-assessed
Complete Date The date the risk was considered finished
Comments Comments that help understand the risk
Last reviewed Date
Next Review Date
Previous Impact Impact level at the last report
Previous Probability Probability level at the last report
Previous Heat Probability weighted impact at the last report
Previous Date Date of last report
Status Current status – approved, tracked, mitigated.
Strategic Priority Link to corporate business objective
Link The ID of which risk to which it is linked in the Risk Database
The information below relates to the Risk Response Plans:

Field Description
ID Numerical ID of the Risk Response
Risk ID The ID of the risk to which the response is linked
Description Description of the Risk Response
Owner Risk Response Owner (The person who has the most knowledge about the response).
Strategy Risk Response Strategy (Accept, Mitigate, Transfer, Remove)
Status Current status (Data collection, analysis, proposed, Activated)
Actions Actions required to enact the selected response strategy
Action Date Dates that actions must be completed
Due Date the risk response information is to be updated
Priority Priority Ranking of preferred strategy
Post mitigation
schedule impact
Post Mitigation
Cost impact
Post mitigation
Safety Impact
Post mitigation
Quality Impact
Post mitigation
Probability
Secondary Risk What further risks will arise if this response is used?
Response
Comments
Start Date Date the response strategy commenced
Completion date Date the response strategy was completed
Performance Effectiveness of Response after Risk has manifested
Page 45
5. Resources
5.1 Training
The following Training options are available from Saudi Aramco for Project Risk
Management. In addition to these options, PMI has a training course for generic Project
Risk Management and a certification for Project Risk Professional.
Risk 01
Name: PRM in the context of Saudi Aramco Enterprise Risk Management.
Duration: 1 hour.
Audience: Management.
Prerequisites: None.
Contents: This presentation outlines the Project Risk Management process and
where it fits in the context of Saudi Aramco’s corporate objectives and
the Enterprise wide Risk Management.
Risk 02
Name: Overview of PRM and Saudi Aramco Project Risk Management Process.
Duration: 1 hour.
Audience: Anyone who wants to understand the basics of the Saudi Aramco Project
Risk Management Process.
Contents: Brief overview of PMI Risk Process as outlined in PMBOK - what to do in
Project risk Management. Brief overview of the Saudi Aramco PRM
Process: how to perform PRM in relation to the Project Life Cycle. The
main reference document for this session is the RM Guide.
Risk 03
Name: Introduction to PRM and the Saudi Aramco Project Risk Management
Process.
Duration: 3 hours.
Audience: Project Stakeholders.
Contents: Introduction to the PMI Risk Process as outlined in PMBOK which
explains the 6 steps of the Project Risk Management Process and what
is included in each step. Introduction to the Saudi Aramco Project Risk
Management Process which explains the tasks and activities required to
perform each of the 6 steps of the RM process and how these steps are
integrated to the Project life Cycle. The main reference document for this
session is the RM Guide and introduces sections of the RM Handbook.
Note: It is expected that during 2010 this course will be PMI accredited.
Risk 04
Name: Practicing PRM in Saudi Aramco
Duration: 2 days
Audience: Project risk managers and other professionals who are actively involved
in Risk Management on a daily basis.
Prerequisites: None
Contents: An in-depth explanation of the Saudi Aramco PRM Process. Discuss the
activities that must be completed at each stage in the process. Discuss
the tools and techniques used within the process. Discuss how to
develop a PRM Plan. The main reference document for this session is
the RM Handbook.
Risk 05
Name: Active Risk Manager (ARM) Software Basic Training
Duration: 1 day
Audience: Personnel who enter data into the software or who generate reports from
the data.
Prerequisites: None
Contents: Basic understanding of the software and introduction to software
operation and basic features.
Risk 06
Name: Active Risk Manager (ARM) Software Advanced Training
Duration: 2 days
Audience: Project risk Managers of risk practitioners who need to use the advanced
analysis tools provided by the software.
Prerequisites: Risk 04 and Risk 05 training.
Contents: software configuration, Report setup, training on software analytical
functions, Risk Register setup requirements.
Page 47
Appendix

Appendix A. Project Risk Management Plan – Template
Risk Plan Version

Version Date Life Cycle Stage
1.0 08-June-09 50% Engineering, 17% Procurement, 0% Construction.
Project Scope Statement

BI-10-xxxx provides for xxx. Project cost is xxx. Project duration is xxx.
Project Schedule
Attach project schedule.
Project Objectives and Milestones

Description Start Finish
DBSP Approval
Project Proposal
ERA
Detail Design IK (PMC)
Develop and Issue LSPB Contract
Saudi Aramco Procurement
Construction
MCC
Commission
Risk Management Context

The Risk Management Plan is where all information for Risk Management is defined.
This will include any background information and criteria for risk analysis and reporting.
The Risk Management Process is defined in the Saudi Aramco Project Risk
Management Guide. This Project Risk Management Plan contains information that is
critical to implementing the process on this project.
- Major justification for this project
- Feasibility of alternatives
- Background information on risk for the project e.g. other risk reports
- Significant issues relating to the project
- Significance of major milestones or targets
- Pertinent sources of information or supporting documents
- Project Dependencies
- Key success factors
- Do we need to break the project into the WBS or sub-projects for risk analysis
The major justification for this BI is the ongoing reliability of production. The major
assumption is that alternative options are not economically feasible. Therefore the major
risk driver is the project schedule because delays to the schedule could jeopardize the
reliability of crude supply. Risk strategy is therefore focused on Schedule and safety.
Project Key Objectives

The key objectives will justify the selected risk strategy and risk tolerance.
Page 49
Project Uniqueness
Any aspect of the project that makes it unique or different from other projects or
common practice.
Major Assumptions
Major assumptions are usually made early in project development. Some assumptions
become invalid during the life of the project and this may affect project outcomes.
Risk Strategy
A Risk strategy is identified to ensure all stakeholders understand the context and
priority by which risks are prioritized. When evaluating which risks are the most
important, the risk drivers should be considered in the order of their importance.
- Major justification for the project
- Main risk drivers
- Project constraints
Risk drivers in order of importance are therefore: (example)
1. Safety to personnel and equipment
2. Reliability of xxxx.
3. Construction (Schedule) milestones.
4. Net Cost of project
Each risk level must have the following minimum information:
 Risks categorized as ‘Critical’ must have risk response plans identified and a risk
owner, trigger points and a preferred response plan identified.
 Risks categorized as ‘Significant’ must have risk response plans, an identified
owner, and a risk review date defined.
 Risks identified as ‘’Low’ must have a risk owner and a review date.
 All risks except ‘unrated’ must be reported at the detail level.
Risk Tolerance
Risk tolerance is defined so that different risks can be qualitatively assessed based on
the probability the risk will occur and the impact the risk has on the project. Each type of
risk including schedule, cost, etc, uses the same ranking to normalize the risks. Each
risk is then plotted on a heat map based on the probability and impact. Those risks that
plot in the red are the ‘hot’ or critical risks and these need to be managed before all
others.
Risk tolerance for this project is defined in the following Impact and Probability Matrix.
Probability Matrix
Rank Description Probability
Very High Even chance > 50%
High One in every 4 projects > 25%
Moderate One in every 10 projects > 10%
Low One in every 20 projects > 5%
Very Low Less than 1 in every 20 projects < 5%
At present the Risk Impact matrix is as follows:

Impact Matrix
Rank Schedule Cost Safety Quality
Very High > 3 month >$5m Fatality >10%
High < 3 month < $5m Severe Injury <10%
Moderate < 1 month < $2.5m Medical Treatment <5%
Low < 2 weeks < $1m First Aid <3%
Very Low < 1 week < $500k No injury <1%
The heat map used to define heat tolerance is as indicated below:

Impact
Opportunity
Opportunity
Opportunity
opportunity
opportunity
Very High
Very High
Moderate
Moderate
Very Low
Very Low
High
High
Low
Low
Heat Map
Very
High
High
Probability
Moderate
Low
Very
Low
Low Important Significant Critical
Low opportunity Moderate Opportunity High Opportunity
Page 51
Roles and Responsibilities – Cross Functional Team
Dept Name Job Role ID Type Supervisor
PMT Project Manager DM Part
PMT Lead Project Eng. RM Full
PMT Project Eng. RC Part
PMT Snr. Project Eng. RC Part
Proponent Proponent Eng. RC Full
PID Snr. Insp Eng. RC
LPD Eng. RC
FPD Eng.
CSD Eng.
EED Eng.
PS&CD Scheduler SME Part
PS&CD Cost Estimator SME Part
Contracting SME Part
PS&CD Risk Support Team RSS Part
Contractor
RM Risk Manager Coordinates risk activities within project

RSS Risk Support Specialist Provides support and Risk knowledge to projects
SME Subject Matter Expert
RC Risk contributor Contributes to Project Specific Risk Information
Stakeholder involvement matrix.

Stage PMT Proponent FPD PID LPD PS&CD EPC
Business Case C R
DBSP Planning C R C C C
Project Proposal R C C C C C
ER Approval R C
Detailed Engineering A C C C C R
Construction A C C C R
Startup & Commission A C C C R
Project Closeout R C I I
For above:
 (R) Responsible - those who work to achieve the task
 (A) Accountable – those who are ultimately accountable or final approving
authority
 (C) Consulted – those who must be consulted for opinions
 (I) Informed – Those who must be informed on progress or changes.
Risk Activity Scheduling

Activity Target Date Representation
Risk Planning and Review
Risk Workshops
Risk Activity review
Risk Management Outcomes
Review
Monitoring and Control are continuous activities and are therefore not scheduled as
events. When defining these activities we should consider information as outlined
below.
Monitoring
Monitoring includes Data collection, Quantitative Analysis, trend and variance analysis,
reserve analysis, generation of what if scenarios, generation of reports.
 Define How often this is done
 Who to will manage and be involved in the process
 Who to notify if risks change and by how much
 Who requires software; what type of access
Controlling
Control includes the discussion on risk and deciding actions that need to occur.
Response plans that need to be activated must be approved and incorporated in the
baseline. The risk register is updated.
 When to perform control activities
 What is to be addressed in the Control activity
 Who to include in the control activities to make decisions
 Who to approve changes to the risk register and where to submit changes to the
baseline.
 Who has ultimate authority?
Risk Training Requirements

 Who needs to be trained (Risk Manager, Proponent, SME, etc)
 What training do they need (Overview of Process, Understanding of the detailed
process, ability to manager and control the process)?
 When should this training occur (Risk Manager before DBSP is finalized,
Proponent before Preliminary engineering is complete, EPC contractor before
procurement commences)
Risk Reporting
Risk reporting should define what types of risk reports are required, who should get
them, and how often. Individuals should be identified. Such a table is shown below.
Group Level of Report Frequency Media /

Reporting Forum
Executive Summary Dashboard monthly Email
committee status
Page 53
Management Detailed Risk Stage Gates/
committee Report Management quarterly
Study
Finance / Detailed Risk Audit Report Quarterly
Audit Status
Proponent Summary Risk Status In accordance with
Report Report Project Review
Meetings
Project Team Summary Risk Status
Report Report
Project Analysis Risk situation and 1 week prior to
Manager recommendations Project review
meeting
Risk
Contributors
Risk Owners
Risk
Response
Owners
The detail of each type of report should also be defined. An example is:
Risk Management Report

 Risk Management Status Detailed
 Risk ID, Risk, Owner, status, Significance, Overdue, Qualified, Response
Plans, tracked.
 Risk Management status summary
 # Risks identified, # risks with response plans, # of significant risks, # of
significant risks without response plans?
 # Critical risks, # risks with increasing significance this period, # risks with
decreasing significance this period, # risks maturing this period.
 Risk Tracking Summary
 The change in the top 10 risks over time.
 Risk Heat Map Summary
 Plot of risks on heat map from comparing one time period to another.
 Risk number by owner
 Pie chart
 Risk number by category
 Pie Chart
 Risk Cost Management Summary
 Contingency status, contingency expectations, contingency
recommendations
Risk Status Report

An example Risk status report is shown below.
Page 55
Risk Management Status Report for BI-xxx
This Report Previous Report Next Report

12 Jun 09 10% Project Completion 1 Jul 09 12% Project Completion
Summary
The risk situation is high as:
 There are 13 critical and 4 significant risks.
 Schedule risk is 27% giving an estimated project delay of 11.6 months.
 Cost risk is 9% giving an estimated cost overrun of $xxMM
 Two critical and one significant risk have no response plans.
 Two critical safety risks and 4 critical quality risks have been identified.
The risk situation is expected to improve if the identified risk response plans are effective.
(Over the next reporting period all response plans will not be completed so risk will remain high
in the interim).
 Cost risk is expected to reduce to $xxMM.
 Schedule risk is expected to reduce to 3.3 months.
 All response plans are management actions and no additional cost is expected.
 It is expected that the risk situation will reduce to 4 critical and 6 significant risks using the
identified response plans.
 It is expected that no critical safety risks Impact
and 2 critical quality risks will still exist
Very High
Moderate
Very Low
Risk Management Activities to be performed:
High
Low
Heat Map
 Status Report to Management in June.
 Risk awareness session with contractors Very
prior to commencing construction. High 2 2 3
Heat Map High 1 1 1 3 1
Probability
Moderate 1 2 1
Low 2 1
Very
Low 1 1 1
Current # of Critical Risks 13
Expected # of critical risks 3
Current Total # of Risks 24

Expected # of risks 22
Project Impacts
Current Cost Risk 9% 100%
Prev
Expected Cost Risk 1% Cost Now 9% ($xxMM)
Current Schedule Risk 27% Expected 1% ($xxMM)
Expected Schedule Risk 8% Prev

Schedule Now 27% (11.7 month)
Current Average Risk 52% Expected 8% (3.3 months)
Factor
Prev
Expected Ave Risk Factor 30% Risk
Now 52% (13.1)
Factor
Expected 30% (7.6)
Page 57
Appendix B. Project Risk Reports – Examples
Risk Tracking Report
The Chart tracks the change in the risk exposure over time and as risk response
strategies are enacted. A risk exposure that reduces is being managed, one that stays
unchanged is not being managed, and one that increases is out of control.
Pre and Post Mitigation Heat Map

This chart shows the number of risks at each level of risk exposure before Risk
Mitigation plans are enacted and after they are enacted.
Residual Risks
This chart shows what risks are being managed and what changes to the risk exposure
have occurred over time.
Risk Dashboard
This is an example management dashboard that provides a summary of the risks of a
project or portfolio. At a glance can be seen the number of risks at each level of risk
exposure, Risks by area of responsibility, and the percentage of risks that have been
managed to different levels.
Page 59
Risk Performance
This table summarizes risks over many areas and enables an understanding of who is
managing risk and who is not.
What-If Analysis
What-if analysis can help understand the level of confidence in a project milestone or
other project attribute. The chart shown plots the Handover date assuming no risk
events mature (yellow), assuming the expected risks occur (red), and assuming we
manage the major risks and instigate suitable response plans (green). Many other what-
if scenarios can be performed.
Appendix C. Risk Events Explained

This section describes in more detail the major risk events described in Section 3.3, and
the activities that are required for those events.
Event 1: Preliminary Economic Evaluation
At this stage of the project life cycle much of the information is developed, and many
assumptions and approximations are made. These are major sources of risk and the
information must be captured and evaluated for the impact they will have on later stages
of the project. Project decisions at later project stages may make some of the earlier
assumptions invalid which may have project consequences.
At this stage it is essential to ensure all members of the project planning team clearly
understand their responsibilities towards risk management. If 3 point estimates are used
these should be captured for later risk quantification. If the normal practice for estimates
is to include some element of contingency in each project task, then a decision could be
made to mange this separately in order to understand risk effects later in the project.
A Project Team may not yet be assigned. Responsibility for risk lies with FPD with
PS&CD providing the guidance. The Activities that occur are as follows:
Activity Format Duration Event Purpose
Awareness Presentation 2 hrs To ensure all members of the Project Planning team
clearly understand their responsibilities relating to
capturing and evaluating project risk information.
Planning Roundtable 4 hrs Prepare the Preliminary Project Risk Management Plan
Workshop Workshop 1 day Introduce the Project Risk Process to the cross functional
team. Preliminary Risk Identification and Qualification
Action Meeting(s) Follow up Actions
Review
Outputs
 Risk Management Plan
 Roles and Responsibilities
 Risk Register
Event 2: DBSP/Scope Definition
During this stage of the project life cycle the project team may be assigned and more
members of the planning group are assembled. More detailed information is gathered
regarding the project allowing more risks to be identified and providing information on
risks identified previously. The Activities that occur at this stage are:
Awareness Presentation 2 hrs Ensure all members of the risk team understand the
process and their responsibilities.
Planning Roundtable 4 hrs Identify additional members of cross functions risk team
and update the PRM Plan
Awareness Presentation Management from different functional areas may need to
understand the process sufficiently to release their staff to
attend Risk Workshops
Workshop Workshop 2 days Overview of the PRM Process, Risk Identification,
Qualification and preliminary Response planning
Page 61
Action Meeting Summarize & assign Risk Activities, Review the Risk
Review Management Plan
Outputs
 Project Risk Manager identified (if appropriate).
 Updated Risk Register
 Updated Risk Management Plan
 Updated Cross Functional Team
Event 3: Project Proposal
During Project Proposal the Project Management Team exists. The Project Risk
Manager is identified and is in control of the PRM process. Subject matter experts
(SME) are involved in this stage and their specialist knowledge can contribute to better
Risk Management. Risks are further assessed based on new information available.
Because SME’s are available, risk areas requiring additional understanding can be
further evaluated. The Activities that occur at this stage are:
Preplanning Meeting 3 hr Transfer control to Project Risk Manager. Brief Risk
Manager on Responsibilities. Review the PRM Plan with
Risk Manager.
Planning Roundtable 1 hr Review PRM Plan.
Workshop Workshop 2 day Overview of PRM Process, Revisit Risk Identification,
qualification, and response planning. Assign risk owners.
Assign risk activities to gather more information for more in-
depth evaluation.
Quantitative Roundtable Risk Quantification for critical risks
Analysis
Action Meeting Review actions
Review
Outputs
 Risk Assignments
 Risk Quantification
 Update Risk Register
Event 4: Expenditure Request Approval
This event is to ensure the selected scope and the business case is justified based on
the uncertainty in the PRM Plan. The PRM Study ensures the Management Committee
clearly understands the risks associated with the project scope. This will enable a good
understanding of the proposed contract strategy and the contingency allowance for the
project. The Activities that occur at this stage are:
Meeting(s) Review Risk Register
Roundtable Prepare Risk Management Study for inclusion in ER
proposal.
Output
 Risk Management Study Report.
Event 5: Contract Establishment

When contracts are let the contractor must be included in the Risk Management
Process or must take ownership of it. It is expected that contracts will require the
contractor to manage risk in accordance with the Saudi Aramco PRM Process. The
contractor, PMT and Proponent representatives would then form the Core Risk Team
for the project. The Activities that occur at this stage are:
Awareness Presentation 3 hrs Briefing for all parties now involved in Risk Management
Roundtable 1 day Revisit the Risk Management Plan. Review Roles and
Responsibilities and reporting requirements. Ensure
contractor understands risk obligations. Update
Reporting requirements.
Workshop 2days Overview of the PRM Process, Revisit Risk
identification, qualification, response planning
Roundtable Risk Quantitative session
Monitoring Sessions as required
Control Sessions as required
Outputs
 Updated Risk Management Plan
 Update roles and Responsibilities
 Update Reporting Requirements
 Update Risk Register
Event 6: Detailed Engineering
Most risks would have been identified and managed prior to this. Construction and
Start-up risks will still exist. This phase of the project provides sufficient information for
the detailed quantification of risks. The Activities that occur at this stage are:
Planning Meeting 1 hr Review the PRM Plan.
Workshop Workshop 1 day Overview of PRM Process, Risk Identification,
qualification, response planning
Activity Meeting Risk Monitoring and control Activities to run concurrently
Review with Project review meetings.
Quantitative Meeting(s) Quantitative analysis
Analysis
Audit Meeting Risk Audit. How effectively is the Project managing risk
and what additional support is required.
Outputs
 What-if analysis
 Risk Management Process – audit and review
Page 63
Event 7: Procurement
Procurement presents a major area of risk. The Activities that occur at this stage are:
Awareness Presentation 1 hr Ensure all personnel involved in procurement are aware
of their requirements.
Workshop Workshop 1 day Risk Identification, qualification, response planning
Output
 Regular monitoring and control sessions
Event 8: Construction
Construction occurs over a sustained period. The majority of activities during this phase
are orientated on the practice of monitoring and control. An event should occur when all
of the contractors are on board to ensure they are all aware of their responsibilities for
Risk Management. A review of the contractor’s methods for Risk Management should
occur. The Activities that occur at this stage are:
Awareness Presentation 1 hr Ensure all contractors and PMT staff aware of
requirements.
Review Meeting 4 hr Review Contractor PRM process
Output
 Regular monitoring and control sessions
Event 9: Start-up
Start-up and handover are a major source of risk for the effective finalization of the
project. The Activities that occur at this stage are:
Awareness Presentation 1 hr Ensure all stakeholders are aware of risk requirements.
Planning Meeting 3 hr Review PRM Plan to incorporate stakeholders and
reporting needs related to handover.
Workshop 1 day Risk Identification, qualification, response planning
Action Meeting Review Actions from Risk Workshop.
Review
Outputs
 Updated PRM Plan
Event 10: Project Close Out

Project Risk Management will be reviewed by PS&CD during the Project Life cycle and
any improvements will be adopted on an annual basis. In addition, the structure of the
Corporate Risk Database allows all learning on specific risks to be collected and
attached to the risk entry in the database. It is important at Project Closeout to ensure
the Project Risk register is up-to-date and complete as this will be the basis of capturing
all of the risk learning from the Project. A completed Risk Register will ensure little effort
is required to achieve this activity.
The Lessons Learned process will also cover PRM. The Risk Register captures learning
related to specific risks and the Lessons Learnt sessions covers learning related to the
risk process and its interaction with Project Management. The Activities that occur at
this stage are:

Meeting 4 hrs Review the Risk Register and PRM plan fro
completeness.
Audit Meeting Risk Audit. Review effectiveness of the Risk
Management Process as applied to the project.
Output
 Finalized Risk Register
 Finalized PRM Plan
Page 65
Appendix D. Risk Breakdown Structure
The Risk Breakdown Structure provided below is based on the needs of the project.
Although this RBS is shown as a top-down view, it does not aim to represent the
complete RBS for the entire corporation. ERM initiatives will bring this RBS to comply
with corporate requirements.
Financial Technical and Engineering

 Product Market Basis  Engineering Design
 Cost/Benefit Estimation Accuracy  Constructability
 Business Case Analysis  Information & Documentation
- Cash flow Modeling  Technology & R&D
- Asset Lifecycle Analysis  Operability
- Operations/Maintenance Modeling  Reliability
 Project Viability and Selection Criteria  Conformance to Standards
Project Delivery Operational

 Aramco / EPC Capability  Operations Acceptance
 Project Scope  Interruption/disruption
 Resource Availability – Quality/  Resource Availability
Quantity  Commissioning Knowledge transfer
 Communications & Reporting  IT Management
 Design and Construction Planning  Security
 Availability of Utility Services
 Quality
 Interface to Existing Equipment
People Strategic
 Project Portfolio Interdependence &  Planning & Resource Management
coordination  Risk Management appetite
 Stakeholder Management  Project Governance
 Project Sponsorship  Social Responsibility
 Project Manager Resource Pool  Organizational structure
 Succession Planning
 Health & Safety
Legal Markets/ External

 Regulatory environment  Financial/Capital Market dynamics
 Environmental requirements  Supply/Production Market dynamics
 Contract Management  Supply Chain dynamics
 Visa Requirements  Contractor Viability
 Community
Appendix E. Definitions
Abbreviation Description
Guide (or RM Guide) Project Risk Management Guide (This
Guide)
Handbook Project risk Management Practitioners
Handbook
PMI Project Management Institute
PMBOK PMI Project Management body of
Knowledge
CPDP Saudi Aramco Capital Projects Delivery
Process
RM Risk Management
PRM Project Risk Management
PS&CD Project Support & Control Department
ERA Expenditure Request Approval
RBS Risk Breakdown Structure
PMT Project Management Team
SARD (RD) Saudi Aramco Risk Database
WBS Work Breakdown Structure
SME Subject Matter Expert
PM Project Management
SAEP Saudi Aramco Engineering Procedures
VE Value Engineering
SWOT Strength, Weaknesses, Opportunities and
Threats
PC PRM Champion
Page 67

Project Risk Management Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Project Risk Management Guide

Uploaded by

Copyright:

Available Formats

Project Risk Management Guide

Project Risk Management Corporate Statement

1.1 Objectives of Saudi Aramco Risk Management

1.2 Background to Saudi Aramco Risk Management Development

1.3 Which Projects Require Risk Management?

1.4 Document Ownership and update

1.5 Purpose of This Document

1.6 Reference Documents

Source Document Notes

Contingency See Reserve.

Quantitative The process of numerically analyzing risk information. This

2.1 Project Risk Basics

1 - Risk Management Planning

Risk Management Plan

List of Risks / Root

4 - Quantitative Risk 3 - Qualitative Risk

5 - Risk Response Planning

Risk Response Plan

6 - Risk Monitoring and Control

Figure-2 Risk Management Process

Risk planning is developing and documenting organized, comprehensive,

The Risk Breakdown Structure is further discussed in Section 4.2.

2.2.3 Qualitative Risk Analysis

Low Important Significant Critical

Low opportunity Moderate Opportunity High Opportunity

2.2.5 Risk Response Planning 1

3.1 Organizational Assets to support PRM

3.1.6 Project Risk Training

3.2 PRM Process and Project Life Cycle Interface

EARLY DBSP PROJECT FUNDING DETAILED

3.4 PRM Activities

3.4.1 Risk Planning Session

3.4.5 Risk Monitoring Session

3.5 Roles and Responsibilities

Risk Coordinator (PMT role)

Project Manager (PMT role)

4.2 Corporate Project Risk Database

4.3 Project Risk Breakdown Structure

The information below relates to the Risk Response Plans:

This page intentionally left blank

Appendix A. Project Risk Management Plan – Template

Risk Plan Version

Project Scope Statement

Project Objectives and Milestones

Risk Management Context

Project Key Objectives

At present the Risk Impact matrix is as follows:

The heat map used to define heat tolerance is as indicated below:

Low Important Significant Critical

Low opportunity Moderate Opportunity High Opportunity

RM Risk Manager Coordinates risk activities within project

Stakeholder involvement matrix.

Risk Activity Scheduling

Risk Training Requirements

Group Level of Report Frequency Media /

Risk Management Report

Risk Status Report

This Report Previous Report Next Report

Current # of Critical Risks 13

Expected # of critical risks 3

Current Total # of Risks 24

Expected Schedule Risk 8% Prev

Pre and Post Mitigation Heat Map

Appendix C. Risk Events Explained