Project Risk

Management
 A risk cannot be
managed unless it is first
identified.

Identify
Risks After risk management
plan has been
developed, the next
process is to identify
all the knowable risks
to project objectives.
 Considers both individual project risks and sources of overall
Identify Risk project risk
 Project Risk
Project Team
Project Manager Specialist (if
Participants Members
assigned)

in Risk Subject Matter

Experts from
Customers End users
identification outside the Project
Team

Stakeholders
Other project Operations Management
managers managers Experts within the
While these personnel are often key participants
organization
for risk identification, all project stakeholders
should be encouraged to identify individual project
Risk Management
risks. It is particularly important to involve the Experts within the
project team so they can develop and maintain a organization.
sense of ownership and responsibility for identified
individual project risks, the level of overall project
risk, and associated risk response actions.
Identify Risk Format

When describing and recording individual project risks, a consistent format

should be used for risk statements to ensure that each risk is understood
clearly and unambiguously in order to support effective analysis and risk
response development.

Risk owners for individual project risks may be nominated as part of the
Identify Risks process and will be confirmed during the Perform Qualitative
Risk Analysis process.

Preliminary risk responses may also be identified and recorded and will be
reviewed and confirmed as part of the Plan Risk Responses process.
 Identify Risks is an iterative process

Since new individual project risks may emerge as

Iterative the project progresses through its life cycle

Process
Level of overall project risk will also change

Frequency of iteration and participation in each

risk identification cycle will vary by situation, and
this will be defined in the risk management plan.
Identifying All the Risk??

Impossible to identify all the risks at the outset of a

project.

Over time, the level of project risk exposure changes as a

result of the decisions and actions taken previously in the
project (internal change) and of externally imposed
change.
Objectives of Identify
Risk

The purpose of risk identification is to identify risks to the

maximum extent that is practicable.

The fact that some risks are unknowable or emergent requires

the Identify Risk process to be iterative, repeating the Identify
Risks process to find new risks which have become knowable
since the previous iteration of the process.
Some Points of Caution for Risk
Management during Identify Risk
Undertake or propose actions which eliminate the
risks before they occur or reduce the effects of risk
or uncertainty.

Recognize the root causes of risks, and not to

consider risks as events that occur almost at
random
 When a risk is first identified,
potential responses may also be
identified at the same time.

Identify & These should be recorded during

the Identify Risks process and
respond considered for immediate action if
such action is appropriate.
Risk
Where such responses are not
implemented immediately, these
should be considered during the
Plan Risk Responses process.
 Early Identification

Risk identification should be performed as early as

possible in the project lifecycle.

Early risk identification enables key project

decisions to take maximum account of risks
inherent in the project, and may result in
changes to the project strategy
Early Identification

MAXIMIZES THE TIME AVAILABLE FOR ENHANCES EFFICIENCY SINCE RESPONSES

DEVELOPMENT AND IMPLEMENTATION OF TAKEN EARLY ARE OFTEN NORMALLY LESS
RISK RESPONSES COSTLY THAN LATER ONES
Iterative Identification

Since not all risks can be identified

at any given point in the project, it
is essential that risk identification is
repeated throughout the project life
cycle.

This should be done periodically, at

a frequency determined during the
Plan Risk Management process.
Emergent Identification

Invokes the Identify Risks process as defined in the project plan

Project Risk Management process should permit risks to be

identified at any time, not limited to formal risk identification
events or regular reviews.
Risks Linked to Project Objectives

Each identified project risk should relate to

at least one project objective
• Time
• Cost,
• Quality
• Scope
 What Long List of Risks (both the opportunities
& threats)
need to
Potential Risk Owners for each risk
be
collected Risk triggers

at this Potential risk response strategies etc.

stage?
 Consult Stakeholder register

Up to 50%more risks were identified, when

stakeholders were consulted on small projects
Who has the
Gain Support for risk identification before you begin
Insight into
Risks? Look through the organization for risk identification
and risk responses

Use published articles

Use involvement with associations

Who has the Insight
into Risks?
Utilize your Include your Ask if who else
competition customers may be involved?

Limit the use of Properly plan risk Meet fact to face

Software (People identification as much as
Process) meetings possible

Risk identification Risk identification

with virtual teams with consultants
Defining Risk
• To differentiate risk from facts, it is advisable to
define risk in “cause – risk – effect” format
Defining Risk

Due to the team not being co-located, communication might take a long time, which may lead to
milestone being missed

The system backup/ disaster recovery mechanism may not work, which could lead to a loss of
programming code or data structures and test data developed to date

There have been three instances in this company where the system backup/ disaster recovery
mechanism has not work. Though that system is being investigated, no changes will occur before the
project is completed which means the system backup/ disaster recovery mechanism may not work
which could lead to a loss of programming code or data structures and test data developed to date
Tools for Defining Risks
Forms Checklists Sticky Notes Prompt List Historic Records

• Fast, convenient, • Fast, memory • Easy, excellent • Generic list of • Lists of

don’t allow joggers, generic for anonymity, risk categories, categories, list of
group thought, not specific risk compliment may be risks, probability
don’t allow in- identification, no speaking for dangerous as and impact of
depth analysis detailing on those who are may lead to risks, response
risks, no addition not comfortable elimination of plans, etc.
of risks can be expressing whole category
done, false sense individual
of security that thought, hard
all risks have with virtual
been identified teams, can not
be emailed, too
small to be seen
from distance
Tools for Defining Risks

Brainstorming Conduct a pre-mortem Expert Interviews

• Problem solving meeting, • Meetings, scenario based • Formal Discussions, needs

two scribes, one facilitates future probable questions planning, time taking,
and other writes down, as if project is failed or needs more preparation,
familiar approach, quick success, fun, unusual, experts are hard to reach
method, idea bouncing nonthreatening, story like
mechanism, boring at and hence out of box,
times, some attendees some people find it hard
may be quieter, unequal to imagine failure
contribution, not all
possible risks can be
identified
 Nominal Group Technique

• Group’s opinion on one issue, fast, good for high level

risks, a risk may be identified by a member but may
not be selected by group

Delphi Technique
Tools for • Consensus of experts
Defining • Anonymity
• Time consuming
Risks Cause & effect diagram

Failure mode and effects Analysis, FMEA

• Also known as fault tree analysis, is used to assess the

potential reliability of products
The most serious Project Risks

The most significant Project Risks are those associated with its
Scope.

Identifying Scope Risks reveals whether the project is within ken or

out with the team’s capabilities.

Early decisions to shift the scope or abandon the project are

essential on projects with significant Scope Risks
 Requirements & Risks

Unclear Requirements & Scope of work are a risk to the project

and have cost and schedule Impact
 Unclear
methodology of Changing
requirements Environments
gathering

Reasons for
Difficulty in Inexperienced
project manager
Difference in
language and
Requirements /team cultures

Gathering Determining
First solution is
requirements
the most obvious
seem to take too
solution mind set
much time

Lack of support
from
management
Reasons for Difficulty in Requirements
Gathering
Lack of historic records

Tendency to avoid arguments

Bureaucratic problems required to start the work before finalization of objectives of project

Fast tracking

Stakeholder issues like keeping the option open for them and not considering the consequences of
unclear requirements
 Sources of Scope Risk
While the categories of Scope Risk are many, two important ones are: Change and Defect
 Highest Care should be taken in defining
the Deliverables.

Written documents should be prepared.

Defining
Deliverables The writing (including
Specific
Clear
charts, diagrams, Unambiguous
Accurate
tables) should be: Comprehensive

All stakeholders and project contributors

should agree and sign-on
The Process of Defining the Deliverables

Defining the Deliverables thoroughly is One VERY POWERFUL tool

for uncovering potential Scope Change

Risks Defining the Deliverables for the Project gives the Project
Manager and the team the first indications of the risks in the
proposed project
 Consider the Project over its
Perspectives Entire Life-Cycle

to include in
Defining the
Identifying people who will get
Deliverables involved in the various stages of,
or functions within, the Project
 Design

Procurement

Contracting

Planning
Perspectives
Defect Liability Certificate
to include in
Defining the Documentation

Deliverables Construction

Billing

Acceptance

Handing Over / Taking Over

Topics for the Process of Defining
Deliverables

From the participants collect a list of Topics (or get the list off a
boilerplate).

It helps, if a number of QUESTIONS can be formulated for each

Topic.
Examples: Topics and Questions - 1
Alignment with User and Customer
Compliance
Business Strategy Needs
• How does this • Has the project • Has the team
Project contribute team captured the identified all
to stated high-level ultimate end-user relevant regulatory,
business requirements? environmental, and
objectives? manufacturing
requirements, as
well as relevant
industry standards?
Examples: Topics and Questions - 2

Completion Positioning Decision Criteria

• Has the team • Is there a clear • Does this project

identified both and compelling team have an
current and benefit-oriented agreed-upon
projected project objective hierarchy of
alternatives to the that supports the measurable
proposed business case for priorities for cost,
deliverables? the project? time, quality and
scope?
Examples: Topics and Questions - 3
Delivery Sponsorship Resources Technical Risk

• Are logistical • Does the • Does the • as the team

requirements management project have, assessed the
understood and hierarchy and will it overall level of
manageable collectively continue to Risk it is taking?
(incl: machinery support the have, the • Are technical
requirement project, and will staffing and and other
and equipment it provide timely funding needed exposures well
availability on decisions and to meet the documented?
time)? ongoing project goals
resources? within the
allocated time?
 Completion Criteria: (project end; acceptance criteria)

Planned Project Start

Required
Staffing Requirements (in terms of skill and experience)
Additional
Information Cost (rough order-of-magnitude)

Detailed Requirements (functionality, usability, reliability,

performance, supportability, other significant issues)

Other data customary and / or appropriate for this project.

Risk Assessment Tools
Several tools are available. Here are three of the more commonly
used ones:

Risk Framework
Tangible Deliverables
Risk Complexity Index

Intangible Deliverables Risk Assessment Grid

Risk Assessment Tools
Sources of Specific Scope Risks include:

• Requirements that seem likely to change

• Mandatory use of new technology
• Requirements to invent or discover new capabilities
• Unfamiliar or untried development tools or methods
• Extreme reliability or quality requirement
• External sourcing for a key subcomponent or tool
• Incomplete or poorly defined acceptance tests or criteria
• Technical Complexity
• Conflicting or inconsistent specifications
• Incomplete Product Definition
• Very Large WBS
• Low Profit Contract
• Client Oriented Contract
Sources of Schedule Risk

DELAY RISKS DEPENDENCY RISKS ESTIMATING RISKS

Sources of
Schedule Risk
Schedule Risk Count Cumulative Average
Impact Impact
(weeks) (weeks)
Delay 46 134 2.9
Dependency 21 102 4.9
Estimates 15 70 4.7
 Among the resources most often discussed are:

• Manpower
• Information
• Machinery, Equipment, Software, Components
Examples of • Money
Resources • Time
• Establishment (Physical and Organizational
Frameworks)
• Services (Communication, Transportation,
Legal)
• Access to Consumables (Power, Fuel, Food,
etc.)
 Sources of Resource
Risk

Resource Type Count Cumulative Average Impact

Impact (weeks) (weeks)
People 45 194 4.3
Outsourcing 17 109 6.4
Money 2 58 29.0
Different Types of People Risks

Staff leaving the project permanently

Staff leaving the project temporarily

Staff joining the project late

Non-dedicated staff

Conflict between simultaneously on-going similar projects.

Low motivation / falling morale

Internal politics
 Different Types of
OUTSOURCING Risks

Late Delivery

Violation of Specified Standards

Protracted Negotiations

Turn over of Service or Product Supplier

Different Types of MONEY Risks

Change in Government

Sudden Change in National Economic / Financial Policy

Displeasure of International Funding Sources e.g. World Bank,

ADB, etc.

This type of risk does not happen often, but when it does, the effects are drastic.
ITTO Model
ITTO Flow
Outputs: Risk Register

The risk register captures details of identified individual project risks

Perform Qualitative Risk Analysis

The results of the following
Plan Risk Responses
processes are recorded in the risk Implement Risk Responses
register Monitor Risks

The risk register may contain limited or extensive risk information

depending on project variables such as size and complexity.
Output: Risk Register
List of identified risks.

• Each individual project risk is given a unique identifier in the risk register. Identified risks are described in as much
detail as required to ensure unambiguous understanding
• A structured risk statement may be used to distinguish risks from their cause(s) and their effect(s).

Potential risk owners

• Where a potential risk owner has been identified during the Identify Risks process, the risk owner is recorded in
the risk register
• This will be confirmed during the Perform Qualitative Risk Analysis process

List of potential risk responses

• Where a potential risk response has been identified during the Identify Risks process, it is recorded in the risk
register
• This will be confirmed during the Plan Risk Responses process.
Output: Risk Register
Additional data may be recorded for each identified risk, depending on
the risk register format specified in the risk management plan
• a short risk title
• risk category
• current risk status
• one or more causes
• one or more effects on objectives
• risk triggers (events or conditions that indicate that a risk is about to occur)
• WBS reference of affected activities
• timing information (when was the risk identified, when might the risk occur, when might it
no longer be relevant, and what is the deadline for taking action).
Risk Register
The risk register captures details of identified individual project risks

The results of Perform Qualitative Risk Analysis, Plan Risk Responses, Implement Risk Responses, and Monitor
Risks are recorded in the risk register as those processes are conducted throughout the project

The risk register is updated with new information generated during the Perform Qualitative Risk Analysis
process

Updates to the risk register may include

• Assessments of probability and impacts for each individual project risk

• Its priority level or risk score
• The nominated risk owner
• Risk urgency information or risk categorization
• A watch list for low-priority risks or risks requiring further analysis.
Output: Risk Report

The risk report presents information on sources of overall project risk, together with summary information on
identified individual project risks

The risk report is developed progressively throughout the Project Risk Management process

The results of Perform Qualitative Risk Analysis, Perform Quantitative Risk Analysis, Plan Risk Responses,
Implement Risk Responses, and Monitor Risks are also included in the risk report as those processes are completed

On completion of the Identify Risks process, information in the risk report may include but is not limited to:

• Sources of overall project risk, indicating which are the most important drivers of overall project risk exposure; and
• Summary information on identified individual project risks, such as number of identified threats and opportunities, distribution of risks across risk
categories, metrics and trends, etc.

Additional information may be included in the risk report, depending on the reporting requirements specified in
the risk management plan.
Risk
Report
• Risk Report contains
summary information of
overall project risk,
opportunities exposure
and trends
 Outputs: Project Document Updates

Assumption log Issue log Lessons learned register

• During the Identify Risks • The issue log should be • The lessons learned register
process, new assumptions updated to capture any new can be updated with
may be made, new issues uncovered or changes information on techniques
constraints may be identified, in currently logged issues. that were effective in
and existing assumptions or identifying risks to improve
constraints may be revisited performance in later phases
and changed. or other projects.
• The assumption log should
be updated with this new
information.
 Requirements management plan

• The requirements management plan may indicate project objectives that are
particularly at risk.

Schedule management plan.

• The schedule management plan may identify areas that are subject to uncertainty or
ambiguity.

Input: Project Cost management plan

Management • The cost management plan may identify areas that are subject to uncertainty or
ambiguity.

Plan Quality management plan

• The quality management plan may identify areas that are subject to uncertainty or
ambiguity, or where key assumptions have been made that might give rise to risk.

Resource management plan

• The resource management plan may identify areas that are subject to uncertainty or
ambiguity, or where key assumptions have been made that might give rise to risk.
 Risk management plan.

• The risk management plan provides information on risk-related roles and

responsibilities, indicates how risk management activities are included in the
budget and schedule, and describes categories of risk, which may be expressed
as a risk breakdown structure

Scope baseline

Input: Project • The scope baseline includes deliverables and criteria for their acceptance,
some of which might give rise to risk. It also contains the WBS, which can be
used as a framework to structure risk identification techniques.
Management Schedule baseline
Plan • The schedule baseline may be reviewed to identify milestones and deliverable
due dates that are subject to uncertainty or ambiguity, or where key
assumptions have been made that might give rise to risk.

Cost baseline

• The cost baseline may be reviewed to identify costs or funding requirements

that are subject to uncertainty or ambiguity, or where key assumptions have
been made that might give rise to risk.
 Assumption log

• Assumptions and constraints recorded in the assumption log may give rise to
individual project risks and may also influence the level of overall project risk.

Cost estimates

• Cost estimates provide quantitative assessments of project costs, ideally

Inputs: expressed as a range, indicating the degree of risk, where a structured review
of the documents may indicate that the current estimate is insufficient and
poses a risk to the project.

Project Duration estimates

Documents • Duration estimates provide quantitative assessments of project durations,

ideally expressed as a range, indicating the degree of risk, where a structured
review of the documents may indicate that the current estimate is insufficient
and poses a risk to the project.

Issue log

• Issues recorded in the issue log may give rise to individual project risks and
may also influence the level of overall project risk.
 Lessons learned register

• Lessons learned about risk identified from earlier phases of the project are
reviewed to determine whether similar risks might recur during the remainder
of the project.

Requirement documentation

Inputs: • Requirement documentation lists the project requirements and allows the
team to identify those that could be at risk.

Project Resource requirements

• Resource requirements provide quantitative assessments of project resource

Documents requirements, ideally expressed as a range, indicating the degree of risk, where
a structured review of the documents may indicate that the current estimate is
insufficient and poses a risk to the project.

Stakeholder register

• The stakeholder register indicates which individuals or groups might participate

in identifying risks to the project. It also details those individuals who are
available to act as risk owners.
Lessons Learnt Register
When preparing for current projects or for identifying PM process improvements,
we learn from project failures & successes

Input to & updated as an output in many processes throughout the project

Knowledge documented using videos, pictures, audios, or other suitable means

that ensure the efficiency of the lessons captured

At the end of a project or phase, the information is transferred to the lessons

learned knowledge base
Lessons Learnt Register
 If the project requires external
procurement of resources, the
agreements may have information
that can present threats or
Inputs: opportunities such as:
Agreements • milestone dates
• contract type
• acceptance criteria
• Awards and penalties
Inputs: Procurement Documentation
If the project requires external procurement of resources, the initial procurement documentation
should be reviewed as procuring goods and services from outside the organization may increase or
decrease overall project risk and may introduce additional individual project risks.

As the procurement documentation is updated throughout the project, the most up to date
documentation can be reviewed for risks.

For example, seller performance reports, approved change requests and information on inspections.
 Published material, including
commercial risk databases or checklists,

Inputs:
Academic studies,
Enterprise
Environmental
Factors
Benchmarking results

Industry studies of similar projects.

 Project files, including actual data,

Input: Organizational and project process

Organizational controls,
Process
Assets
Risk statement formats

Checklists from previous similar

projects.
Tools and Techniques: Expert Judgment

Expertise should be considered from individuals or groups with specialized

knowledge of similar projects or business areas

Such experts should be identified by the project manager and invited to consider
all aspects of individual project risks as well as sources of overall project risk,
based on their previous experience and areas of expertise

The experts’ bias should be considered in this process.

Tools and Techniques: Data Gathering
(Brainstorming)
The goal of brainstorming is to obtain a comprehensive list of individual project risks and sources of overall
project risk

The project team usually performs brainstorming, often with a multidisciplinary set of experts who are not
part of the team. Ideas are generated under the guidance of a facilitator, either in a free-form brainstorm
session or one that uses more structured techniques.

Categories of risk, such as in a risk breakdown structure, can be used as a framework

Particular attention should be paid to ensuring that risks identified through brainstorming are clearly
described, since the technique can result in ideas that are not fully formed.
 A checklist is a list of items,
actions, or points to be It is often used as a reminder
considered

Tools and Risk checklists are developed

based on historical information
They are an effective way to
capture lessons learned from
similar completed projects, listing

Techniques: and knowledge that has been

accumulated from similar
projects and from other sources
of information.
specific individual project risks
that have occurred previously
and that may be relevant to this
project.

Data The organization may maintain a

While a checklist may be quick
and simple to use, it is impossible

Gathering risk checklist based on its own

completed projects or may use
generic risk checklists from the
industry
to build an exhaustive one, and
care should be taken to ensure
the checklist is not used to avoid
the effort of proper risk

(Checklists) identification

Additionally, the checklist should

The project team should also be reviewed from time to time to
explore items that do not appear update new information as well
on the checklist as remove or archive obsolete
information.
Tools and Techniques: Data Gathering
(Interviews)

Individual project risks and sources of overall project risk can be identified by
interviewing experienced project participants, stakeholders, and subject
matter experts.

Interviews should be conducted in an environment of trust and

confidentiality to encourage honest and unbiased contributions.
Tools and Techniques: Data Analysis (Root
Cause Analysis)

Root cause analysis is typically used to discover the underlying causes that lead to a
problem and develop preventive action.

It can be used to identify threats by starting with a problem statement and exploring
which threats might result in that problem occuring

• for example, the project might be delayed or over budget

The same technique can be used to find opportunities by starting with a benefit
statement (for example, early delivery or under budget) and exploring which
opportunities might result in that benefit being realized.
Tools and Techniques: Data Analysis
(Assumption and Constraint Analysis)

Every project and its project Assumption and constraint

management plan are These are often already analysis explores the validity
conceived and developed incorporated in the scope of assumptions and
based on a set of baseline and project constraints to determine
assumptions and within a estimates. which pose a risk to the
series of constraints. project.

Constraints may give rise to

Threats may be identified
opportunities through
from the inaccuracy,
removing or relaxing a
instability, inconsistency, or
limiting factor that affects
incompleteness of
the execution of a project or
assumptions.
process.
Tools and Techniques: Data Analysis (SWOT
Analysis)

For risk identification, it is used to increase the breadth of identified risks by including
internally generated risks

The technique starts with the identification of strengths and weaknesses of the
organization, focusing on either the project, organization, or the business area in general

SWOT analysis then identifies any opportunities for the project that may arise from
strengths, and any threats resulting from weaknesses

The analysis also examines the degree to which organizational strengths may offset
threats and determines if weaknesses might hinder opportunities.
SWOT
 Risks may be identified from a structured review
of project documents, including, but not limited
to, plans, assumptions, constraints, previous
Tools and project files, contracts, agreements, and
technical documentation.
Techniques:
Data
Analysis
(Document Uncertainty or ambiguity in project documents,
Analysis) as well as inconsistencies within a document or
between different documents, may be indicators
of risk on the project.
 Interpersonal and team skills that can be used for this
process includes but are not limited to facilitation

Tools and Facilitation improves the effectiveness of many of the

techniques used to identify individual project risks and
Techniques: sources of overall project risk
Interpersonal
and Team A skilled facilitator can help participants

Skills • remain focused on the risk identification task

• follow the method associated with the technique accurately
• ensure clear risk descriptions
• identify and overcome sources of bias
• resolve any disagreements that may arise.
Tools and Techniques: Prompt List

A prompt list is a predetermined list of risk categories that might give rise to individual project risks and that could
also

act as sources of overall project risk

The prompt list can be used as a framework to aid the project team in idea generation when using risk
identification techniques

The risk categories in the lowest level of the risk breakdown structure can be used as a prompt list for individual
project risks

Some common strategic frameworks are more suitable for identifying sources of overall project risk, for example:

• PESTLE (political, economic, social, technological, legal, environmental)

• TECOP (technical, environmental, commercial, operational, political)
• VUCA (volatility, uncertainty, complexity, ambiguity).
 • Political - how will you respond to changes in governments
and their agendas?

• Economic - what external and internal factors may affect

PESTLE the viability of your project?

• Social - does your business consider local demographics?

• Technological - how will you adapt to changes in

technology?

• Legal - are you able to comply with laws and regulations

that apply to your project?

• Environmental - is your project environmentally

sustainable?
 • Tax policy, trade restrictions, employment laws, political

• stability

PESTLE • Interest rates, economic growth, inflation, and exchange

EXAMPLE rates, viability and soundness of the project, financial

resourcing required

• Demographics, culture, lifestyle, wealth, and social class

• New technology, access to technology.

• Legislation, regulatory bodies, employment law, health &

safety regulations

• Adverse weather, laws regarding pollution and recycling,

use of green or eco-friendly products, and sustainability
 RISK
BREAKDOWN
STRUCTURE
 To undertake risk identification, the project team may conduct a
specialized meeting (often called a risk workshop)

Most risk workshops include some form of brainstorming, but other risk
identification techniques may be included depending on the level of the
risk process defined in the risk management plan

Tools and
Techniques: Use of a skilled facilitator will increase the effectiveness of the meeting

Meetings It is also essential to ensure that the right people participate in the risk
workshop

On larger projects, it may be appropriate to invite the project sponsor,

subject matter experts, sellers, representatives of the customer, or
other project stakeholders

Risk workshops for smaller projects may be restricted to a subset of the

project team.
Typical Risks in Construction Industry

Physical Organizational Act of God

Design Political Environmental

Labor and Site Financial and

Stakeholder
Related Economic
Risks due to Act of God

Floods

Earthquake

Landslide

Fire

Wind damage
Physical Risks

Accident on Site

Damage to Equipment

Damages to Machinery

Human injuries

Damages to Infrastructure

Fire eruption

Theft
Engineering Design Risks

Incomplete design

Inexperience Designer

Defective design

Poor Scope understanding

Errors & omissions

Inadequate specifications
Political Risks

Disowner-ship of Project

Changes in laws and regulations

Requirement for permits

Law & order Situation

New Legislation
Environmental Risks

Pollution and Safety Rules

Over activation of Environmental Agencies & NGOs

Poor EIA report at design stage

Local’s emotions hike due to damages to graveyards

Climatic risks like rain, snow

Site Related Risks

Labor disputes

Stakeholder’s interventions

Labor efficiency

Extreme site conditions

Design changes during currency of project

Machinery/equipment failure
Financial & Economical Risks

Inflation

Rise in Salaries

Change in Interest Rates

Escalation in Materials Costs

Cash flows

Exchange rate fluctuations

Stakeholders Risks

Withdrawal of Acceptance

Lobbying for Rejection

Protests

Strikes

Denying access to site

Organizational Risks

Demotivation of Project Team

Leaving of Team Member

Organization's Ability to keep the project

Financial health

Policies
Thank you