RISK MANAGEMENT

Contents

• What is a Risk
• Categories of Risk
• Risk Management Approaches
• Framework for Dealing with Risk
• Risk Identification
• Risk Analysis
• Risk Planning
• Risk Monitoring

• Applying the PERT Technique

 What is Risk

• PM-BOK defines Risk as

• “An uncertain event or condition that, if it occurs has a positive
or negative effect on a project’s objectives”.

• Risk can also be defined as

• “The chance of exposure to the adverse consequences of future
events”
 What is Risk

• The key elements of a risk are

• It relates to the future.
• The future is uncertain.
• Some things that seem obvious when the project is over, might not have
appeared obvious during planning (e.g. technology used, project estimation).
• It involves cause and effect.
• A “cost over-run” might be identified as a risk, but it is only the effect, it is not
obvious what causes it.
• Cause can be an inaccurate estimate of effort, use of untrained staff or poor
specification.
 Activity 1

• Match the following causes to their possible effects

• Causes
• Staff inexperience
• Lack of top management commitment
• New technology
• Users uncertain of their requirements

• Effects
• Testing takes longer than planned
• Planned effort and time for activities exceeded
• Project scope increases
• Time delays in getting changes to plan agreed
 Negative Risk
• A dictionary definition of risk is “the possibility
of loss or injury”

• Negative risk involves understanding potential

problems that might occur in the project and
how they might impede project success

• Negative risk management is like a form of

insurance; it is an investment

6
 Risk Can Be Positive
• Positive risks are risks that result in good things
happening; sometimes called opportunities

• A general definition of project risk is an

uncertainty that can have a negative or positive
effect on meeting project objectives

• The goal of project risk management is to

minimize potential negative risks while
maximizing potential positive risks

7
 Residual and Secondary Risks
• It’s also important to identify residual and
secondary risks
• Residual risks are risks that remain after all of
the response strategies have been
implemented
• Secondary risks are a direct result of
implementing a risk response

8
 Risk Categories

• Project Risks are risks that could prevent the

achievement of the objectives given to the project
manager and the project team.
• These objectives are to complete the project
• On time
• Within budget
• Provide required functionality
• Optimum Quality.
 Risk Categories
•A different way to categorize risks is a sociotechnical
model proposed by Kalle Lyytinenand and his colleagues,
presented as
 Continue…

• Actors: Actors refers to all people involved in the

development of the application.
• Example Risk
• A high staff turnover, leads to expertise of value to the project
being lost.
 Continue…

• Technology: It encompasses both the technology

• Used to implement the application
• embedded in the delivered products.
• Example Risks:
• Relating to the appropriateness of the technology
• The possible faults in it especially if it is novel.
 Continue…
• Structure/Process: It describes the management structures and
systems, including those affecting planning and control.
• Example Risk
• Suppose that implementation needs user participation in
some tasks but responsibility for managing the users
contribution might not be clearly allocated.

• Tasks: relates to the planned work.

• Example Risk
The complexity of work might lead to delays because of the
additional time required integrate the large number of
components.
 Continue…

• All boxes are interlinked. HOW?

• Risks often arise from the relationships between factors
• for example between technology and people. If a development technology
is novel then the developers might not be experienced in its use and delay
results. The novelty of the new technology is really a characteristic of the
developers: once they are used to the technology, it is no longer ‘novel’.
 Risk Categories

• Business risk is when an application after successful

implementation proves to be a business failure.
For example: If an e-commerce site is established to sell a product, the site might be
correctly implemented, but customers fail to use the site because of the uncompetitive
prices demanded

• Business risks are likely to be outside the direct responsibilities of

the application implementation team.
 Some other broad categories of
Risks

• Organisational risks.
• Requirements risks.
• Estimation risks/Financial Risk
• Market risk
• Technology risk
• People risk
• Structure/process risk
 Continue….
Risk type Possible risks
Organizational 1. Organization is restructured so that different
management is responsible for the project.
2. Organizational financial problems force reduction
in the budget.

Requirements 1. Changes in requirement that require major

design rework are proposed.
2. Customers fail to understand the impact of
requirement changes.
Estimation 1. The time required to develop software is
underestimated.
2. The rate of defect repair is underestimated.
3. The size of software in underestimated.
Financial 1. The risk of loss due to changes in the value of
stocks or equity investments.
2. The risk that the other party in a financial
transaction may default on its obligations
 Continue….
Risk type Possible risks
Market Market risk includes risks posed from competition,
commodity markets, interest rates, foreign
exchange, and liquidity and credit risks.

Technology 1. The databases used in the system cannot process

as many transactions as expected.
2. Old operating system not supporting advanced
features
People 1. It is impossible to recruit staff with skills
required.
2. Key staff is ill and is unavailable at critical times.
E.g if some very innovative project is taken by the
company
 Some common Examples of Software risks

Risk Affects Description

Staff Turnover Project Experienced staff will leave the project during
development
Management Change Project There is a change of Organizational management with
different priorities.
Hardware Project Hardware that is essential for the project will not be
Unavailability delivered in schedule
Requirements change Project and There will be large number of changes to the
product requirements than anticipated.

Specification delays Project and Specification of essential interfaces are not available on
product schedule

Technology change Business The underlying technology in which the system is built is
superseded by new technology

Product Competition Business A competitive product is marketed before the system is

completed.
 Risk Management Approaches

• Risk management approaches can broadly be classified

into reactive and proactive approaches.
• Reactive Approaches take no action until an unfavorable
event occurs.
• Once an unfavorable event occurs these approaches try
to contain the adverse effects associated with the risk and
take steps to prevent future occurrence of the same risk
events.
 Risk Management Approaches

• Proactive Approaches try to anticipate the possible risks

that the project is susceptible to.
• After identifying the possible risks, actions are taken to
avoid the risks.
• If
a risk cannot be avoided, these approaches suggest
making plan to contain the effect of risk.
 Framework for Dealing with Risk

• Planning for risk includes these steps:

Risk Identification

Risk Analysis and

Prioritization

Risk Planning

Risk Monitoring and

management
 Risk Identification

• Main approaches to identify risk are:

• Use of checklists.
• Brainstorming.

• Interviewing

• SWOT analysis
 Risk Identification - Checklists

• Checklists are lists of the risks that have been found to

occur regularly in software development projects.
• These checklists often suggest some potential
countermeasures for each risk.
•A group of representatives for a project examines a
checklist for identifying risks applicable to their project.
 Risk Identification - Checklists
Barry Boehm identified a specialized list of software
development risks

• Personnel shortfalls • Late changes to requirements

• Unrealistic time and cost • Shortfalls in externally supplied
estimates components
• Developing the wrong software • Shortfalls in externally performed
functions tasks
• Developing the wrong user • Real-time performance shortfalls
interface
• Development technically too
• Gold plating difficult
Risk Identification - Brainstorming

• Brainstorming
• Representatives of the main stakeholders of the project, are
brought together , in order to identify the problems that might
occur using their individual knowledge of different parts of the
project.
• This collaborative approach may generate a sense of ownership
in the project.
 Interviewing

• Interviewing is a fact-finding technique for

collecting information in face-to-face, phone,
e-mail, or instant-messaging discussions

• Interviewing people with similar project

experience is an important tool for identifying
potential risks

27
 SWOT Analysis

• SWOT analysis (strengths, weaknesses,

opportunities, and threats) can also be used
during risk identification

• Helps identify the broad negative and positive

risks that apply to a project

28
 Risk Analysis and Prioritization

• Assess probability and seriousness of each risk.

• Probability may be very low, low, moderate, high or
very high.
• Risk effects might be catastrophic, serious, tolerable or
insignificant.
 Risk Analysis and Prioritization
Risk Probability Effect
Organizational financial problems force reduction Low Catastrophic
in the project budget.
It is impossible to recruit staff with skills required High Catastrophic
for the project.
Key staff are ill at critical times in the project. Moderate Serious
Changes in requirement that require major design Moderate Serious
rework are proposed
The organization is restructured so that different High Serious
management are responsible for the project.
 Risk Analysis and Prioritization
Risk Probability Effects
The database used in the project cannot process Moderate Serious
as many transactions per second as expected.
The time required to develop software is High Serious
underestimated.
Customers fail to understand the impact of Moderate Tolerable
requirements change
Required Training for staff is not available Moderate Tolerable
The size of software is underestimated High Tolerable
 Risk Analysis and Prioritization

• A common problem with risk identification is that a list of risks is

potentially endless.
• Therefore a way is needed to prioritize the risks on the basis of
their
• Chances of occurrence
• Damage they can cause

• This can be done by estimating the risk exposure for each risk.
Risk Exposure (RE)= (potential damage) × (probability of
occurrence)
 Risk Analysis and Prioritization

• Example: Lets suppose a project depended on a data center

vulnerable to fire. It might be estimated that if fire occurred a
new computer configuration could be established for $500,000.
• It might also be estimated that there is a 1 in 1000 chance that a
fire will occur.
• risk exposure = (potential damage) x (probability of occurrence
• risk exposure (RE) =500,000 *0.001 = $500

• The higher the RE, the more attention or priority is given to the
risk.
 Risk Analysis and Prioritization

• Another approach is to use qualitative descriptions of the

possible impact and likelihood of each risk.
•A probability matrix is then used to indicate the risk
exposure.
 Risk Analysis and Prioritization
Likelihood of occurrence Range
High Greater than 50% chances of
happening
Significant 30-50% Chances of happening
Moderate 10-29% chances of happening
low Less than 10% chance of happening

Impact Level Range

High More than 30% above budgeted
expenditure
Significant 20-29% above budgeted expenditure
Moderate 10-19% above budgeted expenditure
low Within 10% of budgeted expenditure
Probability Impact Matrix
 Risk Planning

• After the major risks are identified and Prioritized, the

task is now how to deal with them.
• The choices for dealing with them are:
– Risk Acceptance.
– Risk Avoidance.
– Risk Reduction and Mitigation.
– Risk Transfer.
 Risk Planning

• Risk Acceptance is deciding to do nothing about the risk.

This means you will accept its consequences. Why?
• In order to concentrate on the more likely or damaging risks.
• The damage that those risks could cause would be less than the
costs needed to act towards reducing their probability of
occurrence.
 Risk Planning

• Risk Avoidance
• Some activities are so prone to accident that it is best to avoid
them altogether.
• For example to avoid all the problems associated with
developing software solutions from scratch, a solution could be
to
• Retain to existing clerical methods.
• To buy an off-the-shelf solution.
 Risk Planning

Risk Reduction and Mitigation

• Risk Reduction attempts to reduce the likelihood of the
risk occurring. For example consider the following risk:
• Developers leaving a company in the middle of a project for a
better paid job.

• In order to reduce the probability of such a risk occurring:

• The developers could be promised to be paid generous bonuses
on successful completion of the project.
 Risk Planning

• RiskMitigation is the action taken to ensure that the

impact of the risk is reduced when it occurs.
• Taking regular backups of data storage, is it a risk
mitigation measure or a risk reduction measure?
• Since it would reduce the impact of data corruption not
its likelihood of happening, in this sense it is a data
mitigation measure.
 Risk Planning

• Risk Transfer:
• In this case the risk is transferred to another person or
organization.
• For example a software development task is outsourced for a
fixed fee.
Risk Monitoring and management

• Risk management involves

• Contingency
• Deciding on risk actions
• Creating and Maintaining the Risk register
 Continue…
• Contingency Plans:
• Contingency plans are predefined actions that the project team
will take if an identified risk event occurs
• Although risk reduction measures try to reduce the probability or
the likelihood of risks, the risks could still happen.
• These kind of risks need a contingency plan.
• Contingency plan is a planned action to be carried out if a risk
materializes (occurs).
 Fallback Plans and Contingency Reserves

• Fallback plans are developed for risks that have a

high impact on meeting project objectives, and are
put into effect if attempts to reduce the risk are not
effective

• Contingency reserves or allowances are provisions

held by the project sponsor or organization to
reduce the risk of cost or schedule overruns to an
acceptable level

45
 Example

• Consider the following risk:

• Staff absence through illness.

• One risk reduction measure taken:

• Employers will encourage their employees to live a healthy
lifestyle. Still, any of the staff members can get sick by a flu.

• A contingency plan in this case can be:

• To get other team members to cover on urgent tasks.
• Risk reduction’ will usually incur some cost regardless of
the risk materializing or not.
• The cost of a contingency measure will only be incurred if
the risk actually materializes.
• However, there may be some things that have to be done
in order for the contingency action to be feasible.
• An obvious example is that back-ups of a database have to
be taken if the contingency action when the database is
corrupted is to restore it from back-ups. There would be a
cost associated with taking the back-ups.
 Risk Monitoring – Continued….

• Deciding on the risk actions

• For each risk number of different countermeasures can be
considered.
• Whatever countermeasures are adopted, they must be cost-
effective.
 Continued…

• The cost effectiveness of a risk reduction action can be

assessed by the risk reduction leverage (RRL).

• RRL= (RE before – RE after)/cost of risk reduction.

• The risk reduction action with a RRL above 1 is

worthwhile.
 Risk management strategies (i)
Risk Strategy
Organizational Financial Prepare a brief document for senior management
Problems showing how project is making a very important
contribution to goals of the business.
Recruitment problems Alert customer of potential difficulties and the
possibility of delays, investigate buying-in
components.
Staff illness Reorganize team so that there is more overlap of
work and people therefore understand each others
jobs.
Defective components Replace potentially defective components with
bought in components of known reliability
 Risk management strategies (ii)
Risk
Requirements Changes
Organizational restructuring
Database performance
Underestimated
development
Strategy
List information on requirements change impact,
maximize information hiding in the design.
Prepare a brief document for senior management
showing how the project is making a very important
contribution to goals of the business.
Investigate the possibility of higher-performance
database.
Investigate buying in components, investigate use of
program generator.
 Activity 3

• A project is depended on a data center that is vulnerable

to fire. It might be estimated that if fire occurred a new
computer configuration could be established for
$500,000. It might also be estimated that there is a 1%
chance that a fire will occur. Installing fire alarms at a cost
of $500 would reduce the chance of fire to 0.5%. Will the
action of installing alarms be worthwhile.
 Risk Management – Continued…

• Creating and maintaining the risk register

• Project managers, after identifying and examining the most
threatening risks to the project, record their findings in a risk register.
• After work starts on a project more risks can appear and will be added
to the register.
• Risk registers are reviewed and updated regularly.
• Many risks threaten just one or two activities, and when the project
staff have completed these, the risk can then be closed as no longer
relevant.
 Risk Register
• The main output of the risk identification process is a list of identified
risks and other information needed to begin creating a risk register
• A risk register is:
• A document that contains the results of various risk
management processes and that is often displayed in a table or
spreadsheet format
• A tool for documenting potential risk events and related
information
• Risk events refer to specific, uncertain events that may occur to the
detriment or enhancement of the project
54
 Risk Register Contents
• An identification number for each risk event
• A rank for each risk event
• The name of each risk event
• A description of each risk event
• The category under which each risk event
falls
• The root cause of each risk

55
 Risk Register Contents
(continued)
• Triggers for each risk; triggers are indicators or
symptoms of actual risk events
• Potential responses to each risk
• The risk owner or person who will own or take
responsibility for each risk
• The probability and impact of each risk occurring
• The status of each risk

56
Template for a Risk Register
 Risk Mitigation, Monitoring
and Management (RMMM) Plan

• A project manager usually develop an RMMM plan for a project.

• It is a document containing a risk table.
• Each row of the table contains the risk, its probability and its
impact on the project.
• For each risk, the specific conditions required to monitor the
occurrence of risk are mentioned.
• For each risk, avoidance and mitigation plan is also mentioned.
 Applying the PERT Technique

• PERT stands for Program Evaluation and Review

Technique.
• PERT was developed to take account of the uncertainty
surrounding estimates of task durations.
• It is very similar to the CPM but, instead of using a single
estimate of each task, PERT require three estimates
 Applying the PERT Technique

• Three estimates are

• Most Likely Time (m)
• Optimistic Time (a)
• Pessimistic Time (b)

• These estimates are then combined to form a single

expected duration, te using the formula
te = a + 4m + b
6
 Applying the PERT Technique

• The calculated expected durations are then used to carry

out a forward pass through a network using CPM technique.
• In this case, the calculated dates are not the earliest possible
dates, but the dates by which we expect to achieve those
events.
• Unlike CPM approach, the PERT method does not calculate
the earliest date by which we could complete the project,
rather it calculates the expected dates.
 Applying the PERT Technique

• A quantitative measure of the degree of uncertainty of an

activity duration estimate may be obtained by calculating the
standard deviation s of an activity time, using the formula
• The activity standard deviation is proportional to the difference
between the optimistic and pessimistic estimates and can be
used as a ranking measure of the degree of uncertainty or risk
for each activity.
s=b–a
6
 Applying the PERT Technique

• The main advantage of PERT technique is that it provides

a method for estimating the probability of meeting or
missing target dates.
• This probability can be estimated both for
• A single target date i.e. the project completion date
• Additional intermediate target dates
 Applying the PERT Technique

• The PERT technique uses the following three-step

method for calculating the probability of meeting or
missing a target date
• Calculate the standard deviation for project completion date.
• Calculate the z value using a target date
• Convert the z value to estimate the probability of missing the
target date.
 Applying the PERT Technique

• Z value is calculated using the formula

z= T – te
s
• Where T is the target date and t is the expected date.
e

• A z value may be converted to the probability of not

meeting the target date by using the following graph.
Applying the PERT Technique
 Activity 4

• Calculate expected time and standard deviation for each

value. Calculate overall expected completion time of
project and probability of not meeting that target date.
 Reading

[Chapter#7]“Software Project Management by Bob

Hughes and Mike Cotterell, McGraw-Hill Education; 6th
Edition (2009). ISBN-10: 0077122798”