Project
Project Risk
Risk Management
Management
1–1
Project
Project Risk
RiskManagement
Management
Processes to decrease the probability and impact of negative events and vice versa . It
includes:
1. Risk management planning
2. Risk identification
3. Risk response planning
4. Risk monitoring and control
1–2
Risk
Risk Management
Management
Risk: Uncertain event or condition, if occurred
has impact on project objectives & may lead to:
• Time overrun
• Cost overrun
• Poor Quality
• Change in scope
Risk Management: A proactive attempt to
recognize and manage internal events and
external threats that affect the likelihood of a
project’s success
Project
Projectrisk
riskmanagement
managementand
andrisk
riskbased
basedestimating
estimating
• It is the policy of the Washington State Department of Transportation (WSDOT) to conduct risk
based estimating workshops for all projects over $10 Million (PE, R/W and Const).
• These workshops provide information to project managers that can help them control scope, cost,
schedule, and manage risks for all projects.
• Construction estimating is a relatively crude process. The absence of any appreciable
standardization together with a myriad of unique site and project conditions make the advance
computation of exact construction expenditures a matter more of accident than design.
4
Steps
Steps of
of Risk
Risk Management
Management
• Identify all the possible risk events that
could affect the project
• Assess each risk in terms of probability,
impact severity and controllability
• Develop a strategy and/or contingency for
responding to each risk
• Monitor and control risks dynamically
1–5
Steps
Steps of
of Risk
Risk Management
Management
1–6
Project
Project life
life stages
stages and
and Risk
Risk management
management
1–7
1–8
1–9
1–10
1–11
Risk
Risk Response
Response
Avoid
Avoid the risks by addressing them before taking
up the project
MITIGATE
Reduction in the probability and/or impact of an
adverse risk event to an acceptable threshold
Examples-adopting less complex processes,
conducting more tests and/or field investigations
Transfer
Try to allocate the responsibility of the risk to the
party that is best able to handle it
ACCEPT
Risks that remain after response actions and/or
for which response is not cost effective are
accepted
- risks that are uncontrollable
1–13
1–14
1–15
1–16
Risk register
1–17
Types
Types of
of Risks
Risks
1–18
Quantitative risk analysis: Cost
Quantitative risk analysis: Schedule
1–20
Types
Types of
of Risks
Risks
Scope Risk
• Scope creep—individuals (generally the Owner) adding tasks to the original scope.
• Hardware or software input defects—mischaracterizations of the true project scope.
• Scope gap—project-necessary activities missing due to an ill-defined scope up-front.
• Dependency change—unexpected and unanticipated regulatory, legal, or political changes.
• Integration defect—change required from unexpected behavior by a project participant.
Schedule Risk
• Project dependency failures—the other party not delivering its work on time.
• Parts delays—equipment and/or materials not being delivered on schedule.
• Estimation errors—poor or improper sources used for estimating project activities.
• Decision delays—untimely decisions causing schedule delay.
• Equipment malfunctions—insufficient attention to quality in the procurement process.
Resources Risk
• Outsource entity delays—project contractors not mobilizing or progressing as planned.
• Insufficient funds—for items (equipment, people, etc.) overlooked in the estimate.
• Attrition of resources—equipment breakdowns, personnel and contractor desertions.
• Late staffing—project workforce buildup falling behind plan.
• Skills scarcity—workforce skill sets not available or trained to match project needs. 1–21
Identifying Project Scope Risk
22
Project
Project Scope
Scope
• Broad definitions use scope to refer to everything in the project, and
• Narrow definitions limit project scope to include only project
deliverables
• The type of scope risk considered here relates primarily to the
project deliverable(s).
Project Scope Risk
1. What is not the scope has come into the picture
2. Project fails to deliver the scope defined
23
Need for Identification of Project Scope
Risk-
– Will reveal either that your project is feasible or that it lies
beyond the state of your art
– Impacts Schedules, Cost
– Scope risks are most numerous in the Project Experience Risk
Information Library (PERIL) database, representing more than
one-third of the data.
24
Types
Types
Project Scope
Risk
scope
Defect Risks
change risks
scope creep scope gaps dependencies Software Hardware Integration
25
Scope
Scope Change
Change Risks
Risks types
types
Scope Scope Scope
Creep Gaps Dependencies
• Are due to
• Scope creep plagues • Scope gaps are the result of
committing to a project external factors
all projects, especially before the project that affect the
technical projects. requirements are complete.
• Scope creep When legitimate needs are project and are the
represents uncovered later in the third category of
project, change is
unanticipated unavoidable change risk.
additional investment • arises coz of- examples, legal
of time and money, 1. in most of the cases these
gaps were due to incomplete or and regulatory
because of both newly
required effort and the
rushed analysis changes do
2. project work breakdown
need to redo work would have revealed the sometimes
already completed missing or poorly defined happen without
portions of the project scope
notice
Defect
Defect Risks
Risks
• Technical projects rely on many complicated things to work as expected.
Unfortunately, new things do not always operate as promised or as
required.
• Even normally reliable things may break down or fail to perform as desired
in a novel application.
• The three categories of defect risks are software, hardware, and integration.
Hardware
Hardware and
and software
software risks
risks
• In several cases, the root cause was new, untried technology that lacked needed
functionality or reliability.
• In other cases, a component created by the project (such as a custom integrated circuit, a
board, or a software module) did not work initially and had to be fixed.
• In still other cases, critical purchased components delivered to the project failed and had
to be replaced.
• Some hardware and software functional failures related to quality or performance
standards.
• Hardware may be too slow, require too much power, or emit excessive electromagnetic
interference.
• Software may be too difficult to operate, have inadequate throughput, or fail to work in
unusual circumstances.
Integration
Integration risks
risks
• These defects related to system problems
above the component level
• For large programs, work is typically
decomposed into smaller, related subprojects
that can progress in parallel.
• Successful integration of the deliverables from
each of the subprojects into a single system
deliverable requires not only that each of the
components delivered operates as specified but
also that the combination of all these parts
functions as a system.
Identifying
Identifying Project
Project
Schedule
Schedule Risk
Risk
Identifying Project Schedule Risk
“Work expands so as to fill the time available for its completion.”
—C. NORTHCOTE PARKINSON, PARKINSON’S LAW
Thoroughly identifying schedule risks requires awareness of this and disciplined use of project
management planning tools to create appropriate schedules that avoid over engineering.
Three categories: delays, estimates, and
dependencies.
Delay risks: Defined as schedule slips
due to factors that are at least nominally
under the control of the project.
Estimate risks: Inadequate durations
assigned to project activities.
Schedule dependency risks: Relate to
project slippage due to factors outside the
project.
Delay Risks
• Types of delay risk: parts, information, hardware, and decisions
Parts Information
• Most frequently reported source of delay • Delay was due to time differences
• Delivery and availability problems were between parts of distributed global
common sources for this delay teams.
• International shipping, including customs, • Poor access to information or delivery
paperwork, and related concerns. of needed reports was interrupted.
• Defective parts.
Slow decisions
• Poor access to the decision
Hardware
• Needed to perform project work, makers, or their lack of interest in
including systems and other equipment, the project.
• Result of extended debates,
that was late.
discussions, or indecision.
Estimating Risks
Due to relatively rapid changes in the work and also environment is in constant flux
hence estimates can’t rely on history
The estimating risk subcategories relate to
learning curves, judgment, and imposed deadlines.
Learning curve
• The quality of the estimates when new technology or new people are involved is not good.
• The portions of project work that require staff to do things they have never done before are
always risky
Judgment
• Overoptimistic estimates
• Requires thorough planning, with appropriate understanding and decomposition of the work,
good record keeping so that the effort and steps required are known.
• Worst-case analysis. It will uncover new potential sources of risk.
Imposed deadlines
• Based on poor estimates
• Unrealistic deadline same objective
• Projects are often doomed from the start
Dependency Risks
There are three dependency risk subcategories: Infrastructure dependencies
other projects, infrastructure factors, and • Includes interruption of technical services,
legal issues. such as computer systems or networks
required and inadequate access to resources
Other projects with shared dependencies such as help desks, system support, and
• Number of smaller projects interact and link people who understood older but necessary
to each other need to be in synchronization . applications.
• Analysis of the connections and interfaces • Maintenance outages
between projects needed
• Many of the risks faced by the projects Legal and regulatory dependencies
become visible through interface • Legal and paperwork requirements for
management techniques. international shipments can cause problems
when they change abruptly.
Key Ideas for Identifying Schedule Risks
• Determine the root causes of all uncertain estimates
• Identify all estimates not based on historical data
• Note dependencies that pose delay risks, including all interfaces
• Identify risky activities and schedule them early in the project
• Ascertain risks associated with multiple critical (or near-critical)
paths
• Recognize the riskiest dependencies at fan-in points in the project
schedule
Identifying
Identifying Project
Project Resource
Resource Risk
Risk
Need
Need of
of Identifying
Identifying Resource
Resource Risk
Risk
• “If you want a track team to win the high jump, you find one person who
can jump seven feet, not several people who can jump six feet.” —
FREDERICKTERMAN, STANFORD UNIVERSITY DEAN AND PROFESSOR
OF ENGINEERING
• A lack of technical skills or access to appropriate staff is a large source
of project risk for complex, technical projects. Risk management on
these projects requires careful assessment of needed skills and
commitment of capable staff.
Sources
Sources of
of Resource
Resource Risk
Risk
• Major categories of Resource Risk
Resource
Risk
People Outsourcing Money
Caused primarily because of
Caused by the services &
Caused by People within the people outside the project insufficient funding & has
project team maximum average Impact .
[Link]
[Link] Risk
Risk
Permanent • People loss due to resignation, promotion health etc.
Loss • It has high probability among people related risk,
• contributes
Temporarytoloss
around onebecause
of staff third. of illness,leave,hot
Temporary
sites, travel& other supports.
Loss • It contributes to 23% by probability in people risk.
People Queuing • Loss because of absence of expertise when
Risk needed in the project.
• It contributes to the 20% in people related risk &
[Link] impact is of 6 weeks.
Late Start
• Full staff not available at the start of the project.
• Impacting good on project delay.
Motivation • Frequency in people risk is around 10 %
• Loss in team cohesion & interest in project.
• Typically happen in large projects
• Probability is very less, roughly 5 %.
Outsourcing
Outsourcing
• Outsourcing was a significant source of resource risk in the
PERIL database.
• Better management of outsourcing and procurement can
uncover many of these problems in advance
• A growing need for specialization underlies the trend
toward increased dependence on project contributors
outside the organization.
• Other reasons for this trend are attempts to lower costs
and a desire in many organizations to reduce the amount
of permanent staff.
Outsourcing
Outsourcing Risk
Risk
• Risk related to outsourcing is subcategorised as :
Poor Output
Outsourcing
Risk
Delayed
Start
Outsourcing
Outsourcing Risk
Risk
Poor Output
– Root causes as other people risks- turnover, queuing problems, staff availability, and other
issues.
Delayed Start
– Delayed starts are also fairly common with outsourced work, causing about one-quarter of
the outsourcing problems.
– Before any external work can begin, contracts must be negotiated, approved, and signed.
All these steps are time consuming.
– Beginning a new, complex relationship with people outside your organization can require
more time than expected.
Outsourcing
Outsourcing Risk
Risk -- Examples
Examples
• Risks in the outsourcing may include
– higher costs,
– potential loss of confidential information,
– an ongoing significant need to maintain core skills (on
future projects or for required support), and
– lack of confidence in the available service providers.
– Some outsourcing decisions are made because all the
current staff is busy.
Project classification frameworks
1–44
Clark and Wright Framework
1–45
NTCP-The
NTCP-The Diamond
Diamond Model
Model
Novelty – How new is the product to customers and
users
Derivative, Platform, Breakthrough
Technology – How much new technology is used
Low-tech, Medium-tech, High-tech, Super High-
tech
Complexity – How complex is the system and its
subsystems
Assembly, System, Array
Pace – How Critical is the Time frame
Regular, Fast/Competitive, Time-Critical, Blitz
(Source: Shehnar and Dvir, 2007)
NTCP model Shenhar et al.(2005)
Technology
Design and development.
Later design freeze
Super-High
Radical Tech
Technological
Innovation
High-Tech
Incremental
Technological Medium-Tech Incremental
Innovation Market
Low-Tech
Innovation
Array System Assembly
Complexity Novelty
Derivative Platform Breakthrough
Regular
Architectural
Innovation Fast/ Radical
Competitive Market
Autonomy Innovation
Modular Time-Critical
Innovation
Blitz
Less market data.
System engineering. Later requirement freeze
System integration Pace
The Project Diamond - Assessing a Project’s Risk/Benefit and Selecting the Right Management Approach
Project
Project type
typeimpact
impact on
onProject
Project Management
Management approach
approach
Design and development.
Technology Later design freeze
System engineering.
System integration
Novelty Formality
Less market data. Complexity
Later requirement freeze
Autonomy
Pace
Detailed
DetailedExplanation
Explanation
It comprises of four dimensions:
1. Novelty: It measures how new is the project’s product to customers,
user or to the market and represents uncertainty in the project goals
and market uncertainty or both.
It helps in making decision about:
The time required to freeze the product requirements.
How much the accuracy and reliability of the market data can be
trusted?
2. Technology: It represents the project’s level of technological
uncertainty and determined by how much new technology is required.
Understanding technology helps us to understand:
The time required to freeze design.
The intensity of technical activities.
The technical skills required by the project managers and team.
Detailed
Detailed Explanation
Explanation
3. Complexity: It measures the complexity of the product, the task
and the project organization.
It helps in decision making about:
The structure of the project organization.
How best to manage it (i.e. finding the right level of bureaucracy and the
project organization)?
4. Pace: It represents the urgency of the project namely how much
time there is to complete the job.
It helps in decision making about:
How to do the planning?
How and When to do reviews?
The most useful degree of autonomy for the project team.
The most useful level of involvement of top management (particularly the
most urgent projects)
Denver
Denver International
InternationalAirport
Airport Project
Project
Technology
Super-High
Tech
Automatic Bag – High-Tech
Handling System
Medium-Tech
Array System Assembly Low-Tech
Novelty
Derivative Platform Breakthrough
Complexity
Regular
Fast/ Airport
Competitive Construction
Project
Time-Critical
Blitz
Pace
Benefits
Benefits of
of NTCP
NTCP model
model
• The model can be used for :
Adaptive planning
Selecting Project Management Style
Communication language
Putting project back on track
Retrospective Analysis