Chapter 5

Managing Risk
Risk: is an uncertain condition that, if it occurs has positive or negative
effect on project objectives.
Some potential risk events can be identified before the project starts such
as equipment or change in technical requirements.
Risk Management: attempts to recognize and manage potential and
unforeseen trouble spots that may occur when the project 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
materialize (contingency plans), and provides contingency funds to
cover risk events.

Risk Management’s Benefits

• A proactive rather than reactive approach.
• Reduces surprises and negative consequences.
• Prepares the project manager to take advantage
of appropriate risks.
• Provides better control over the future.
• Improves chances of reaching project performance objectives
within budget and on time.
A graphic model of the risk management challenge. The chances of a
risk event occurring (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.
The 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. The team uses brainstorming
and other problem identifying techniques to identify potential problems.
Organization use risk breakdown structure (RBS) in conjunction with
work breakdown structures (WBS) to help management teams identify
and evaluate risks.
Example of Risk Breakdown Structure (RBS)

The focused at the beginning should be on risks that can affect the whole
project as opposed to a specific section of the project or network.

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.
Example; Risk profile for product development project

For example, building an information system is different from building a

new car.
Risk profiles recognize the unique strengths and weakness of the firm.
Finally, risk profiles address both technical and management risks.
The figure showed asks questions about design and work environment.
The risk identification process should not be limited to just the core
team. Input from customer, sponsors, vendors, and other stockholders .
Step 2: Risk assessment:

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:
1- Probability of the event
2- Impact of the event
Risks need to be evaluated in terms of the likelihood the event is going to
occur and the impact. The risk of a project manager being struck by
lightning at work site would have major negative impact on the project,
but the likelihood is so low it is not worthy of consideration.
The quality and credibility of the risk analysis process requires that
different level of risk probabilities and impacts be defined. These
definitions should be tailored to the specific nature and needs of the
project.

Examples for negative impact only

Because impact untimely 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 , such as ( 1- 10).

Risk Severity Matrix

This figure showed of 5 x 5 array of elements with each

elements representing a different set of impact and likelihood values.
The matrix is divided in to red, yellow, and green zones representing
major, moderate, and minor risks. 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.
Risk Severity matrix provides a basis for prioritizing which risks to
address red zone risks receive first priority followed by yallow zone risks.
Green zone risks are typically considered ignored unless their status
changes.
Failure Mode and Effects Analysis ( FMEA) extends the risk severity
matrix by including ease of detection in the equation:
Impact x probability x Detection = Risk value

Step 3: Risk Response Development

When a risk 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.
Mitigating Risk
Reducing risk is usually the first alternative considered. There are
basically two strategies for mitigating risk:
1- Reduce the likelihood that the event will occur
2- Reduce the impact that the adverse event would have on the
project
Avoiding Risk
Risk avoidance is changing the project plan to eliminate the risk or
condition. Although it is impossible to eliminate all risk events, some
specific risks may be avoided before you launch the project.
Transferring Risk
Passing risk to another party is common; this transfer does not change the
risk. Passing risk to another party almost always results in paying a
premium for this exemption. Fixed price contracts are classic example of
transferring risk from an owner to a contractor. The contractor
understands his or here firm will pay for any risk event that materializes;
therefore, a monetary risk factor is added to contract bid price.
 Retaining Risk
In some case 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 (an earthquake or flood). The project owner
assumes the risk because the chance of such an event occurring is slim.
The risk is retained by developing a contingency plan to implement if the
risk materializes. Control is possible with this structured approach.
- Contingency plan: represents actions that will reduce or mitigate
the negative impact of the risk event. There are different between
response and contingency plan,:
Response: is a part of the actual plan and action is taken before
the risk can materialize.
Contingency plan: is not part of the initial implementation plan
and only goes into effect after the risk is recognized.

Some of the most common methods for handling risk are discussed here

1- Technical Risks: are problematic; they can ofen be the kind that
case the project to be shut down. What if the system or process
does not work? Contingency or backup plans are made for those
possibilities that are foreseen. In addition to backup strategies or
contingency plan, project managers need to develop methods to
quickly assess whether technical uncertainties can be resolved.

2- Schedule Risks: here contingency funds are set aside to crash the
project to get it back on track. Crashing or reducing project
duration, is accomplished by shortening (compressing) one or more
activities on critical path.

3- Cost Risks: projects of the long duration need some contingency

for price changes which are usually upward. The important point to
remember when reviewing price is to avoid the trap of using one
lump- sum to cover price risks. Thus, price risks should be
evaluated item by item. Some contracts will not change over the
life of the project.
Step 4 : Risk Response Control:
The results of the first three steps of the risk management process
are summarized in a formal document often called the risk register.
A risk register details all identified risks, including descriptions,
category and probability of occurring, impact , responses,
contingency plans and current statues. This register is the backbone
for the last step in the risk management process.
Risk control involves executing the risk response strategy,
monitoring events, initiating contingency plans and watching for
new risks. Project managers need to monitor risks just like they
track project progress. In addition to this, risk assessment and
updating needs to be part of every status meeting and progress
report system.

Change Control Management: A major element of the risk control

process is change management. Every detail of a project plan will not
materialize as expected. Changes come from many sources such as the
project customer, owner, project manager, team members and occurrence
of risk event.
Change management systems: involve reporting, controlling, and
recording changes. In practice most change management systems are
designed to accomplish the following:
1. Identify proposed changes.
2. List expected effects of proposed changes
on schedule and budget.
3. Review, evaluate, and approve or disapprove
of changes formally.
4. Negotiate and resolve conflicts of change, condition, and cost.
5. Communicate changes to parties affected.
6. Assign responsibility for implementing change.
7. Adjust master schedule and budget.
8. Track all changes that are to be implemented