Lecture 2 – Project Risk Management Basics

Project Risk Management

MS (PM)
 Scheme
2

 Importance of PRM
 Basic Terminologies
 Project Assumption, Project Fact and Project Risk
 Risk Appetite and Risk Threshold
 The context of risk
 Project Risk Management Framework
 Sources of risk in projects
 Levels of risk
 Categories of risk (Pure Risk and Speculative Risk)
 Definition of PRM
 Scheme
3

 Uncertainty in Risk Dimensions

 Iterations in PRM

 Scalability and tailoring conditions

 Considerations for Agile/Adaptive environments

 Trends and emerging practices in PRM

 Non-event risks (Variability & Ambiguity)

 Project resilience
 Integrated risk management

 Risk management processes overview

4

Courtesy Mr Tabjeel slides

5

Courtesy Mr Tabjeel slides

6

Courtesy Mr Tabjeel slides

7

Courtesy Mr Tabjeel slides

8

Courtesy Mr Tabjeel slides

9

Courtesy Mr Tabjeel slides

10

Courtesy Mr Tabjeel slides

Basic Terminologies: Risk Project Risk Dimensions of Risk

Project Risk
11

Bilal Atiq PMP & RMP PMI

Basic Terminologies: Project Assumption Project Fact Project Risk

Project Assumption
12

 There may be some external circumstances, conditions or events

that must occur to make the project successful

 If it is believed that such a situation or event is likely to occur, it is

called as assumption.

 It is in contrast to definition of a risk, which may or may not occur.

 By external, we mean that these circumstances, conditions or events

are not in the direct control of project team.

 Example: Budget and resources will be available when needed.

Basic Terminologies: Project Assumption Project Fact Project Risk

Project Fact
13

 If an event that is within control of project team and has 100%

chance of occurring, it is called as fact.

 It is generally part of the approach or work plan.

 For example, to complete pile testing activity by a certain date.

Basic Terminologies: Project Assumptions Project Fact Project Risk

Project Risk
14

 External circumstances or events that if occurs (probability) may:

 Jeopardize the successful completion of project. Or

 Help in the successful completion of the project.

 By external, we mean that these circumstances, conditions or events

are not in the direct control of project team.
Basic Terminologies: Project Assumptions Project Fact Project Risk

Comparative Summary: Assumption, Fact and Risk

15

Project Fact Project Assumption Project Risk

Within control of project Not in the direct control of Not in the direct
team project team control of project team

It is likely to occur It is probable to occur

100% chance of occurring (it is assumed that they (i.e. may or may not
will occur –likelihood) occur – Probability)
Basic Terminologies: Risk Attitude Risk Appetite Risk Threshold

Risk Attitude
16

 A chosen mental disposition towards uncertainty, adopted explicitly or implicitly by

individuals/groups, driven by perception, and evidenced by observable behavior.

 Risk attitudes exists on a continuous spectrum, but common risk attitudes include
risk averse, risk tolerant, risk neutral and risk seeking.

 The attitudes of project stakeholders determine the extent to which an individual

risk or overall project risk matters.

 Risk attitude may differ from one stakeholder to other and from one project to
other.

 A single stakeholder may adopt different risk attitudes at various stages in a single
project.
Basic Terminologies: Risk Attitude Risk Appetite Risk Threshold

Risk Attitude
17

 A wide range of factors influence risk attitude, including:

 Organization’s culture.

 The scale of the project within the range of stakeholder’s overall

activities.

 The strength of public commitments made about the

performance of the project.

 The stakeholders’ sensitivity to issues such as environmental

impacts, industrial relations etc.
Basic Terminologies: Risk Attitude Risk Appetite Risk Threshold

Risk Appetite
18

 The degree of uncertainty a stakeholder, organization or individual is

willing to accept in anticipation of a reward.

 Risk appetite should be expressed as measureable thresholds

around each project objective.

 Risk attitude implies a general approach – preferring one thing over

other, whereas risk appetite shows a degree (a rough quantity) of
risk that an organization or individual can tolerate.
Basic Terminologies: Risk Attitude Risk Appetite Risk Threshold

Risk Threshold
19

 The level of risk exposure above which risks are addressed and below
which risks may be accepted.

 Project team needs to know what level of risk exposure is acceptable in

pursuit of the project objectives.

 This is defined by measurable risk thresholds that reflect the risk appetite
of the organization and project stakeholders.

 Risk thresholds express the degree of acceptable variation around a

project objective.

 They are explicitly stated and communicated to the project team.

Basic Terminologies: Risk Attitude Risk Appetite Risk Threshold

Risk Threshold
20

 Risk thresholds are used to inform the definitions of probability and

impacts to be used when assessing and prioritizing project risks.
 The Context of Risk
21

 Risk is contextual and may arise:

 In context of a person or organization.

 In context of a situation.

 In context of an objective, a task or a commitment.

 One person’s/organization’s risk threat may be another’s risk

opportunity.
PRM Framework Sources Levels Categories Definition

Project Risk Management Framework

22

 Organizations should choose to take project risk in a controlled and intentional

manner in order to create value while balancing risk and reward.

 Project Risk Management aims to identify and manage risks that are not
addressed by the other project management processes.

 When unmanaged, these risks have the potential to cause the project to deviate
from the plan and fail to achieve the defined project objectives.

 Risks exit in relation to objectives, it is, therefore, essential to clearly define the
project objectives right from the beginning of the project.
PRM Framework Sources Levels Categories Definition

Sources of Risk in Projects

23

 All projects are risky because:

 They are unique undertakings with varying degrees of complexity.

 They are based on constraints and assumptions.

 They are aimed at responding to expectations of multiple

stakeholders.

 Stakeholders’ needs may be conflicting.

 Stakeholders’ needs may be changing.

PRM Framework Sources Levels Categories Definition

Levels of Risk
24

▪ An uncertain event or condition ▪ The effect of uncertainty on the project as

that, if it occurs, has a positive or a whole, arising from all sources of
negative effect on one or more uncertainty including individual risks,
project objectives. representing the exposure of stakeholders
to the implications of variations in project
▪ Understanding individual risks can outcome, both positive and negative.
assist in determining how to apply
efforts and resources to enhance the ▪ An important component of strategic
chances of project success. decision-making, program and portfolio
management and project governance
▪ Day-to-day PRM focuses on these where investments are sanctioned or
individual risks. cancelled and priorities are set.
PRM Framework Sources Levels Categories Definition

Categories of Risk
25

▪ Risks that bring only loss but no ▪ Risks that may bring loss and benefit
benefit. as well.

▪ They can occur repeatedly. ▪ They have little probability to repeat.

▪ For example, the risks of an ▪ For example, the risks of stock

accident or earthquake are pure investment or business venture are
risks. speculative risks.
PRM Framework Sources Levels Categories Definition

Project Risk Management (PRM)

26

 Project Risk Management includes the processes of conducting risk

management planning, identification, analysis, response planning, response
implementation, and monitoring risk on a project.

 The objectives of project risk management are to increase the probability

and/or impact of positive risks and to decrease the probability and/or impact
of negative risks, in order to optimize the chances of project success.
Uncertainty in Risk Iterations Scalability Agile/Adaptive Considerations

Uncertainty in Risk
27

 Probability indicates the element of uncertainty.

 This uncertainty may either be in its chance of occurrence (what are

the chances that a risk will occur) or the intensity or span of its impact.

 Risk is usually dynamic.

 For a risk event, probability and impact elements of risk may change
over time.
Uncertainty in Risk Iterations Scalability Agile/Adaptive Considerations

Uncertainty in Risk
28

 For a software development project, the probability of the risk of losing key
data may be constant throughout, but the impact is likely to increase over time.

 For an open-air entertainment event, probability of weather risk may change

over time (seasons), as also will the level and type of impact (winter storms,
extremely hot weather in summer, just a light rain shower or heavy rain).

 Technical risk of accident caused by falling from height may be constant (in
terms of probability and impact) for full period of a pipeline project.

 The probability of same risk might starts as low, then increase sharply and
finally decline again as a multi-storey building project emerges from ground,
structural floors are added. What about impact ?
Uncertainty in Risk Iterations Scalability Agile/Adaptive Considerations

Iterations in PRM
29

 Risk is initially addressed during planning by shaping the project strategy.

 Circumstances change as projects are planned and executed.

 The amount of information available about risks will usually increase as

time goes on.

 Some risks will occur while others will not, new risks will arise or
discovered and characteristics of those already identified may change.

 As a result the PRM processes should be repeated and corresponding

plans progressively elaborated throughout the lifetime of the project.
Uncertainty in Risk Iterations Scalability Agile/Adaptive Considerations

Scalability and Tailoring Conditions

30

 Each project is unique and exposed to different levels of risk.

 Every step in the PRM processes should be scalable to meet the varying
degrees of risk.

 PRM (applied to all projects ) activities should be appropriate to the

project.

 A balance needs to be maintained between the level of efforts/resources

applied in the PRM and the expected output gained from these efforts.
Uncertainty in Risk Iterations Scalability Agile/Adaptive Considerations

Scalability and Tailoring Conditions

31

 Considerations for tailoring include but are not limited to:

 Project Size

 Does project’s size in terms of budget, duration, scope, or team require

a detailed approach to risk management or is small enough to justify a
simplified risk process?

 Project Complexity
 Is a robust risk approach demanded by high levels of innovation, new
technology, commercial arrangements, interfaces, or external
dependencies that increase project complexity? Or is the project
simple enough that a reduced risk process will suffice?
Uncertainty in Risk Iterations Scalability Agile/Adaptive Considerations

Scalability and Tailoring Conditions

32

 Project Importance

 How strategically important is the project? Is the level of risk increased

for this project because it aims to produce breakthrough opportunities,
addresses significant blocks to organizational performance, or involves
major product innovation?

 Development Approach

 Is this a waterfall project, where risk processes can be followed

sequentially and iteratively, or does the project follow an agile
approach where risk is addressed at the start of each iteration as well
as during its execution?
Uncertainty in Risk Iterations Scalability Agile/Adaptive Considerations

Scalability and Tailoring Conditions

33

 The main actions to provide the required tailoring are as follows:

 Define those objectives against which risks will be identified.

 Define how the elements of the PRM processes will be scaled for
this project.

 Define risk threshold, appetite and the assessment framework.

Uncertainty in Risk Iterations Scalability Agile/Adaptive Considerations

Scalability and Tailoring Conditions

34

 Tailoring of the Project Risk Management processes to meet these

considerations is part of the Plan Risk Management process.

 Outcomes of tailoring decisions are recorded in risk management plan.

 Scalable elements of PRM processes include, but not limited to:

 Methodology and processes used

 Tools and techniques used
 Supporting infrastructure and resources
 Review and update frequency
 Reporting requirements
Uncertainty in Risk Iterations Scalability Agile/Adaptive Considerations

Considerations for Agile/Adaptive Environments

35

 High-variability environments, by definition, incur more uncertainty and risk.

 Projects managed using adaptive approaches make use of frequent reviews of

incremental work products and cross-functional project teams to accelerate
knowledge sharing and ensure that risk is understood and managed.

 Risk is considered when selecting the content of each iteration, and risks will
also be identified, analyzed, and managed during each iteration.

 Requirements are kept as a living document that is updated regularly, and work
may be reprioritized as the project progresses, based on an improved
understanding of current risk exposure.
36

Trends & Emerging Practices

https://www.pmi.org/learning/library/manage-risks-didnt-know-were-taking-9275

(Hillson, D., 2014; PMI, 2018)

Trends & Emerging Practices: Resilience Integrated RM Non-event Risks

Project Resilience
37

 The existence of emergent risk is becoming clear, with a growing

awareness of so-called unknowable-unknowns.

 These are risks that can only be recognized after they have occurred.

 Emergent risks can be tackled through developing project resilience.

 Resilience can be defined as “the capacity to maintain core purpose

and integrity in the face of external or internal shock and change”,
sometimes known as “bounce-back-ability”.
Trends & Emerging Practices: Resilience Integrated RM Non-event Risks

Project Resilience
38

 This requires each project to have:

 Right level of budget and schedule contingency for emergent risks, in

addition to a specific risk budget for known risks;
 Flexible project processes that can cope with emergent risk while
maintaining direction toward project goals, e.g. strong change management;
 Empowered project team that has clear objectives and that is trusted to get
the job done within agreed upon limits;
 Frequent review of early warning signs to identify emergent risks a.s.a.p.;
 Clear input from stakeholders to clarify areas where the project scope or
strategy can be adjusted in response to emergent risks.
Trends & Emerging Practices: Resilience Integrated RM Non-event Risks

Integrated Risk Management

39

 Projects exist in an organizational context, and they may form part of a

program or portfolio.

 Risk exists at each of these levels, and risks should be owned and
managed at the appropriate level.

 Some risks identified at higher levels will be delegated to the project

team for management, and some project risks may be escalated to higher
levels if they are best managed outside the project.

 A coordinated approach to enterprise-wide risk management ensures

alignment and coherence in the way risk is managed across all levels.
Trends & Emerging Practices: Resilience Integrated RM Non-event Risks

Non-event Risks
40

 Most projects focus only on risks that are uncertain future events that
may or may not occur, i.e. event-based risks, such as:

 A key seller may go out of business during the project

 The customer may change the requirement after design is complete

 The focus of PRM, however, is broadening to ensure that all types of risk
are considered, and that project risks are understood in a wider context.

 There is an increasing recognition that apart from event-based risks, the

non-event risks also need to be identified and managed.
Trends & Emerging Practices: Resilience Integrated RM Non-event Risks

Non-event Risks
41

Variability Risk (also called “aleatoric uncertainty”)

 Name taken from Latin word alea, which is a game played using a dice with a set
number of possible outcomes but we don’t know which one will actually occur.

 Some aspect of a planned task or situation is uncertain.

 For example, we plan to run a 15-day trial, but the actual duration could in fact
be anywhere between 10–25 days.

 The probability of running the trial is 100%, but its duration is uncertain.

 Other variable parameters include cost, resource requirement, productivity,

defect rate, performance, etc.
Trends & Emerging Practices: Resilience Integrated RM Non-event Risks

Non-event Risks
42

 The best way to analyze variability risks is in a quantitative risk analysis model
using Monte Carlo simulation.

 The standard probability distributions used in these models (triangular,

lognormal, beta etc.) are all built using a range of values from a credible min to
a credible max, with various intermediate values such as mean or most-likely.

 These ranges are specifically designed to reflect the degree of uncertainty in key
parameters such as time, cost etc., which makes them ideal for describing
variability risks.
Trends & Emerging Practices: Resilience Integrated RM Non-event Risks

Non-event Risks
43

Ambiguity Risks (also known as “epistemic uncertainty”)

 Name taken from the Greek word episteme meaning knowledge.

 These describe uncertainties arising from lack of knowledge or understanding.

 Examples of project areas where imperfect knowledge might affect our ability to
achieve project objectives include:

 Elements of the requirement or technical solution

 Use of new technology
 Competitor capability or intentions
 Inherent systemic complexity in the project
Trends & Emerging Practices: Resilience Integrated RM Non-event Risks

Non-event Risks
44

 Ambiguity risks are addressed through exploration and

experimentation, seeking first to define the scope and boundaries of
those areas where we have a deficit of knowledge or understanding.

 The aim is to transform ambiguity risks into “known-unknowns.”

 Having understood where lack of knowledge might cause a problem,

we can then take action to fill the gap, perhaps by obtaining expert
external input, or by benchmarking our approach against best-
practice, so that we can learn from the experience of others.
Trends & Emerging Practices: Resilience Integrated RM Non-event Risks

Non-event Risks
45

 A second strategy to tackle ambiguity risks is through incremental

development, prototyping or simulation.

 These allow us to take small steps within the scope of our existing limited
knowledge, gradually extending the boundaries of our understanding.
 Development Approach or Project Lifecycle
46

 The project lifecycle is what you need to do to do the work, and the project
management process is what you need to do to manage the work.

 Project lifecycle is progression of phases through a series of developmental

stages, i.e. within a project lifecycle, there are generally one or more phases.

 An example of a development lifecycle for a software project might include

the lifecycle phases of research, design, code, test and implement.

 These phases are collectively referred to as development lifecycle of a

project.
 Risk Management Processes
47

 Plan Risk Management

 Identify Risk Management

 Perform Qualitative Risk Analysis

 Perform Quantitative Risk Analysis

 Plan Risk Response

 Implement Risk Responses

 Monitor Risk
48