????

• https://www.youtube.com/watch?
v=lrCOIRGpeeM
 Project Risk Management
Plan Risk Identify Risks Perform Perform Plan Risk Monitor and
Management Qualitative Risk Quantitative Responses Control Risk s
Analysis Risk Analysis
• Risk Management is the identification,
assessment, and prioritization of risks
followed by coordinated and economical
application of resources to minimize, monitor,
and control the probability and/or impact of
unfortunate events or to maximize the
realization of opportunities.
• A risk can be assessed using two factors:
impact and probability.
• ‐ If the probability is 1, it is an issue. This
means that risk is already materialized.
• If the probability is zero, this means that risk
will not happen and should be removed from
the risk register.
 Causes of Risk
• The causes of risk can come from various sources,
such as:
• – A requirement, such as legal requirement imposed
by laws or regulations
• – An assumption, such as the conditions in the
market (which may change)
• – A constraint, such as number of personnel
available to work on any given phase of the project
• or – A condition, such as the maturity of the
organization’s project management practices
 Why Do We Manage Risk?
• Project problems can be reduced as much as
90% by using risk analysis
• Positives:
– More info available during planning
– Improved probability of success/optimum project
• Negatives:
– Belief that all risks are accounted for
– Project cut due to risk level
 Project Risk
• Every project manager understands risks are
inherent in projects. No amount of planning
can overcome risk, or the inability to control
chance events.

• In the context of projects, risk is an uncertain

event or condition that, if it occurs, has a
positive or negative effect on project
objectives.
• A risk has a cause and, if it occurs, a consequence. For
example, a cause may be a flu virus or change in scope
requirements. The event is that team members get stricken
with the flu or the product has to be redesigned. If either of
these uncertain events occurs, it will impact the cost,
schedule, and quality of the project.
• Some potential risk events can be identified before the project
starts—such as equipment malfunction or change in technical
requirements. Risks can be anticipated consequences, like
schedule slippages or cost overruns.
• Risks can be beyond imagination like the 2008 financial
meltdown.
 What Risk Management do?
• Risk management attempts to recognize and manage
potential and unforeseen trouble spots that may occur
when the project is implemented.
• Risk management identifies as many risk events as possible
(what can go wrong),
• minimizes their impact (what can be done about the event
before the project begins),
• manages responses to those events that do materialize
(contingency plans),
• and provides contingency funds to cover risk events that
actually materialize.
• It is the normal practice to include a short
summary of project risks in each appraisal
report.
A Project Proposal on Vehicular tracking
 Risk Occurrence
• The chances of a risk event occurring (e.g., an error in time
estimates, cost estimates, or design technology) are greatest
in the concept, planning, and start-up phases of the project.
• The cost impact of a risk event in the project is less if the
event occurs earlier rather than later.
• The early stages of the project represent the period when
the opportunity for minimizing the impact or working around
a potential risk exists.
• Conversely, as the project passes the halfway
implementation mark, the cost of a risk event occurring
increases rapidly.
• For example, the risk event of a design flaw
occurring after a prototype has been made
has a greater cost or time impact than if the
event occurred in the start-up phase of the
project.
• Clearly, identifying project risk events and
deciding a response before the project begins
is a more prudent approach than not
attempting to manage risk.
 Example
• The cost of mismanaged risk control early on in the
project is magnified by the ill-fated 1999 NASA Mars
Climate Orbiter. Investigations revealed that Lockheed
Martin botched the design of critical navigation
software.
• While flight computers on the ground did calculations
based on pounds of thrust per second, the spacecraft’s
computer software used metric units called newtons.
• A check to see if the values were compatible was never
done.
• “Our check and balances processes did not catch an
error like this that should have been caught,” said Ed
Weiler, NASA’s associate administrator for space science.
“That is the bottom line. Processes that were in place
were not followed.” (Orlando Sentinel, 1999.) After the
nine-month journey to the Red Planet the $125 million
probe approached Mars at too low an altitude and
burned up in the planet’s atmosphere
Risk Event Graph
 Why Risk Management
• Risk management is a proactive approach
rather than reactive.
• It is a preventive process designed to ensure
that surprises are reduced and that negative
consequences associated with undesirable
events are minimized. It also prepares the
project manager to take action when a time,
cost, and/or technical advantage is possible.
• Successful management of project risk gives
the project manager better control over the
future and can significantly improve chances
of reaching project objectives on time, within
budget, and meeting required technical
(functional) performance.
• The sources of project risks are unlimited.
• There are sources external to the organization, such as inflation,
market acceptance, exchange rates, and government regulations.
• In practice, these risk events are often referred to as “threats” to
differentiate them from those that are not within the project
manager’s or team’s responsibility area. (Budgets for such risk
events are placed in a “management reserve” contingency budget.)
• Since such external risks are usually considered before the decision
to go ahead with the project, they will be excluded from the
discussion of project risks.
• However, external risks are extremely important and must be
addressed.
Risk Management Process
 Step 1-Risk identification
• The risk management process begins by trying to
generate a list of all the possible risks that could affect
the project.
• Typically the project manager pulls together, during the
planning phase, a risk management team consisting of
core team members and other relevant stakeholders.
• The team uses brainstorming and other problem
identifying techniques to identify potential problems.
Participants are encouraged to keep an open mind and
generate as many probable risks as possible.
Risk breakdown structure
 Risk Breakdown Structure
• Lists categories and subcategories where risks
may arise
Project

Project
Technical Organizational
Management

Limited Design
Funding Estimates
Time

Specifications
Prioritization Scheduling
Adherence

Resource
Communication
Availability
• After the macro risks have been identified,
specific areas can be checked. An effective
tool for identifying specific risks is the work
breakdown structure.
• Use of the RBS reduces the chance a risk event
will be missed. On large projects multiple risk
teams are organized around specific
deliverables and submit their risk
management reports to the project manager.
 Risk Profile
• A risk profile is another useful tool. A risk
profile is a list of questions that address
traditional areas of uncertainty on a project.
These questions have been developed and
refined from previous, similar projects.
Partial example of Partial Risk Profile for
Product development project
• Risk profiles are generated and maintained usually by personnel from the
project office.
• They are updated and refined during the post project audit.
• These profiles, when kept up to date, can be a powerful resource in the risk
management process.
• The collective experience of the firm’s past projects resides in their
questions.
• Historical records can complement or be used when formal risk profiles are not
available. Project teams can investigate what happened on similar projects in
the past to identify potential risks.
• For example, a project manager can check the on time performance of
selected vendors to gauge the threat of shipping delays.
• Project managers can access “best practices” papers detailing other
companies’ experiences converting software systems. Inquiries should not be
limited to recorded data.
• The risk identification process should not be limited to
just the core team.
• Input from customers, sponsors, subcontractors,
vendors, and other stakeholders should be solicited.
• Relevant stakeholders can be formally interviewed or
included on the risk management team. Not only do
these players have a valuable perspective, but by
involving them in the risk management process they
also become more committed to project success.
• Step 2: Risk Assessment
• Step 1 produces a list of potential risks.

• Not all of these risks deserve attention.

• Some are trivial and can be ignored, while others pose serious threats to the
welfare of the project.
• Managers have to develop methods for sifting through the list of risks, eliminating
inconsequential or redundant ones and stratifying worthy ones in terms of
importance and need for attention.

• Scenario analysis is the easiest and most commonly used technique for analyzing
risks. Team members assess the significance of each risk event in terms of:

• Probability of the event.

• Impact of the event.
• Simply stated, risks need to be evaluated in terms of the
likelihood the event is going to occur and the impact or
consequences of its occurrence.
• The risk of a project manager being struck by lightning at a
work site would have major negative impact on the project,
but the likelihood is so low it is not worthy of consideration.
• Conversely, people do change jobs, so an event like the loss of
key project personnel would have not only an adverse impact
but also a high likelihood of occurring in some organizations.
• If so, then it would be wise for that organization to be
proactive and mitigate this risk by developing incentive
schemes for retaining specialists and/or engaging in cross-
training to reduce the impact of turnover.
• The quality and credibility of the risk analysis
process requires that different levels of risk
probabilities and impacts be defined. These
definitions vary and should be tailored to the
specific nature and needs of the project.
• For example, a relatively simple scale ranging from
“very unlikely” to “almost certainly” may suffice
for one project, whereas another project may use
more precise numerical probabilities (e.g., 0.1, 0.3,
0.5, . . .).
 Impact analysis
• A component failure may cause only a slight
delay in project schedule but a major increase
in project cost.
• If controlling cost is a high priority, then the
impact would be severe.
• If, on the other hand, time is more critical than
cost, then the impact would be minor.
• Because impact ultimately needs to be assessed in terms of
project priorities, different kinds of impact scales are used.
Some scales may simply use rank-order descriptors, such as
“low,” “moderate,” “high,” and “very high,” whereas others
use numeric weights (e.g., 1–10). Some may focus on the
project in general while others focus on specific project
objectives.
• The risk management team needs to establish up front what
distinguishes a 1 from a 3 or “moderate” impact from “severe”
impact. Figure on next slide provides an example of how
impact scales could be defined given the project objectives of
cost, time, scope, and quality.
Risk Assessment form
• The risk severity matrix provides a basis for prioritizing which risks to address.
• Red zone risks receive first priority followed by yellow zone risks. Green zone risks
are typically considered inconsequential and ignored unless their status changes.
• Failure Mode and Effects Analysis (FMEA) extends the risk severity matrix by
• including ease of detection in the equation:
• Risk Value = Impact *Probability * Detection
• Each of the three dimensions is rated according to a five-point scale.
• For example, detection is defined as the ability of the project team to discern that
the risk event is imminent.
• A score of 1 would be given if even a chimpanzee could spot the risk
• coming. The highest detection score of 5 would be given to events that could only
• be discovered after it is too late (i.e., system freezing).
• The matrix is divided into red, yellow, and green zones
representing major, moderate, and minor risks, respectively.
• The red zone is centered on the top right corner of the matrix
(high impact/high likelihood), while the green zone is centered
on the bottom left corner (low impact/low likelihood). The
moderate risk, yellow zone extends down the middle of the
matrix.
• Since impact is generally considered more important than
likelihood (a 10 percent chance of losing $1,000,000 is usually
considered a more severe risk than a 90 percent chance of
losing $1,000), the red zone (major risk) extends farther down
the high impact column
Risk Severity matrix
 Probability Analysis
• There are many statistical techniques available to
the project manager that can assist in assessing
project risk.
• Decision trees have been used to assess
alternative courses of action using expected
values. Statistical variations of net present value
(NPV) have been used to assess cash flow risks in
projects.
• Correlations between past projects’ cash flow and
S-curves (cumulative project cost curve—baseline
—over the life of the project) have been used to
• PERT (program evaluation and review technique) and PERT simulation
can be used to review activity and project risk.
• The use of PERT simulation is increasing because it uses the same
data required for PERT, and software to perform the simulation is
readily available.
• Basically PERT simulation assumes a statistical distribution (range
between optimistic and pessimistic) for each activity duration; it then
simulates the network (perhaps over 1,000 simulations) using a
random number generator. The outcome is the relative probability,
called a criticality index, of an activity becoming critical under the
many different, possible activity durations for each activity.
• PERT simulation also provides a list of potential critical paths and
their respective probabilities of occurring. Having this information
available can greatly facilitate identifying and assessing schedule
risk.
• Step 3: Risk Response Development When a
risk event is identified and assessed, a
decision must be made concerning which
response is appropriate for the specific event.
Responses to risk can be classified as
mitigating, avoiding, transferring, sharing, or
retaining
Risk Response Matrix
 Transferring Risk

• Passing risk to another party is common; this transfer does not

change risk.
• Passing risk to another party almost always results in paying a
premium for this exemption.
• Fixed-price contracts are the classic example of transferring risk
from an owner to a contractor.
• The contractor understands his or her firm will pay for any risk event
that materializes; therefore, a monetary risk factor is added to the
contract bid price.
• Before deciding to transfer risk, the owner should decide which party
can best control activities that would lead to the risk occurring.
• Also is the contractor capable of absorbing the risk?
• Clearly identifying and documenting responsibility for
absorbing risk is imperative.
• Another more obvious way to transfer risk is insurance.
However, in most cases this is impractical because defining
the project risk event and conditions to an insurance broker
who is unfamiliar with the project is difficult and usually
expensive.
• Of course, low-probability and high-consequence risk events
such as acts of God are more easily defined and insured.
Performance bonds, warranties, and guarantees are other
financial instruments used to transfer risk.
• On large, international construction projects like
petrochemical plants and oil refineries, host countries
are insisting on contracts that enforce Build-Own-
Operate- Transfer (BOOT) provisions. Here the prime
project organization is expected not only to build the
facility, but also to take over ownership until its operation
capacity has been proven and all the debugging has
occurred before final transfer of ownership to the client.
• In such cases, the host country has transferred financial
risk of ownership until the project has been completed
and capabilities proven.
 Retaining Risk

• In some cases a conscious decision is made to accept the risk of an event

occurring.
• Some risks are so large it is not feasible to consider transferring or
reducing the event (e.g., an earthquake or flood).
• The project owner assumes the risk because the chance of such an event
occurring is slim.
• In other cases risks identified in the budge reserve can simply be absorbed
if they materialize.
• The risk is retained by developing a contingency plan to implement if the
risk materializes.
• In a few cases a risk event can be ignored and a cost
overrun accepted should the risk event occur.
• The more effort given to risk response before the
project begins, the better the chances are for
minimizing project surprises.
• Knowing that the response to a risk event will be
retained, transferred, or mitigated greatly reduces
stress and uncertainty.
• Again, control is possible with this structured
approach
 Next is
• Contingency planning