Risk Planning

1
 Risk Planning & Management
Some Definitions:
►Risk: An uncertain event or condition that, if occurs, has a positive or negative
effect on the project objectives.

►Risk Management: The systematic process of identifying, analyzing and

responding to project risks.

►Risk Management Planning: Determining how to approach and plan the

project risk management activities, the process of creating a risk management
plan.

2
 What can Possibly Go Wrong?
What risks does a student undertaking a project encounter?
How can we mitigate the damage?
-Computer-related:
► Loss of a file;
► Loss/ damage of a hard drive
► Loss/ damage of a computer

-Human related:
► Sickness
► Incompetence in some project aspect

3
What can Possibly go Wrong?
Consider the “average” project:
► Testing takes longer than planned – cannot resolve bugs
► Supplier cannot deliver product on schedule
► Critical engineer:-
► Has accident;
► Becomes a parent;
► Leaves project/company
► Change of ownership.
► Major downsizing;

4
Software Project Risks
Risk Categories: (Project, technical and organizational)
i) Project management risks – threaten project plan, i.e. affect
the schedule, and costs .
Key: -Identify potential budgetary, schedule, personnel,
resource , stakeholder & requirements problems & their
impact on the software project
Project complexity, i.e. size & the degree of structural
uncertainty contribute towards project risks

5
S/W Project Risk Categories
ii) Technical Risks – Affect quality and performance of the
software
-If it happens, renders implementation difficult or impossible
Key - identify potential design, implementation , interface ,
verification & maintenance problems
-Sources of technical risks are:
► User requirements uncertainty,
► technical obsolescence,
► cutting edge technology,
► unrealistic performance goals

6
 S/W Project Risk Categories
iii/ Organizational Risks – Threaten software viability, can be:-
► Unrealistic scope, cost and schedule objectives
► Resource conflict due to multiple projects running
simultaneously
► Lack of project funding
► Loss of project champion
► Change in management

7
 Seven Principles of Risk Management

[Link] a global perspective—view software risks

within the context of a system
2. Take a forward-looking view—think about the risks
that may arise in the future (e.g., due to changes in
the software)
3. Encourage open communication—if someone states
a potential risk, don’t discount it.

8
Seven Principles of Risk management
4. Integrate— Risk management must be integrated into
the software process.
5. Emphasize a continuous process—the team must be
vigilant throughout the software process, modifying
identified risks as more information is known and adding
new ones as better insight is achieved.
6. Develop a shared product vision—if all stakeholders
share the same vision of the software, it is likely that
better risk identification and assessment will occur.
7. Encourage teamwork—the talents, skills, and
knowledge of all stakeholders should be pooled for
effective risk management.
9

Adapted from SEI

Key Risk Management Processes
► Risk Management Planning: see Definitions slide
► Risk Identification: Deciding which risks can potentially impact the
project
► Qualitative Risk Analysis
► Quantitative Risk analysis
► Risk Response Planning: Developing procedures and techniques to
reduce the threats of risks, while enhancing the likelihood of
opportunities
► Risk Monitoring and Control: Setting up a risk monitoring system, so as
to engage in the risk plan in the event that risk materializes

10
An Example Risk Management Model

11

Source: Nicholas & Steyn, 2011

Risk Management Model Explained
Used for the creation of a risk management plan:-

i) Define objectives – Using the WBS list & define objectives for each activity

ii) Identify risks- Uncertainty & constraints that may impact the project,
limiting objective realization.

iii) Quantify risks- Evaluate & prioritize the level of the risk-based on impact

vi) Develop Response- Define means of responding to risk

v) Monitor and Control Risks- Train team members to implement the risk
management plan

12
 A Project Risk Identification Framework

Adapted from Marchewka, 2015

13
Applying the Project Risk Identification Framework

Working from the outer part of the framework:-

►Go through the project life cycle;
i. Categorize known/unknown-known/ unknown-unknown risks;
Known risks- events that are going to occur and there is no
uncertainty about it.
► Examples: Key personnel leaves the project, Potential Delivery
delay by some vendor
Unknown-known - are identifiable uncertainty,
► Examples: Monthly bill, it comes every month but with varying
amounts.
Unknown-unknown – Events that we may not anticipate to happen,
usually identified after they have happened.
► Examples: Major storm, Power loss, Acts of terrorism
14
ii. Categorize external/internal
External risks – originate from sources outside the project, & project
managers & stakeholders have little control over them
Examples:
• New laws or regulations
• Labor issues
• Weather
• Natural disasters – these require disaster recovery techniques

Internal risks - originate from the project, organization, assumption &

technical risks

iii. Classify risks according to people, technology, product, project, etc.

iv. Identify constraint affected, i.e. budget, schedule, quality

15
 Risk Management Plan Structure
Suggested Risk management plan structure:
►RiskManagement method – explains how risk management will be
performed, specifying tools and techniques
►Roles and responsibilities – outlines risk owners
►Risk budget – shows resources allocated to risk handling
►Timing – shows timing and frequency of risk management
►Risk categories – Guide the risk planning stage
►Risk Probability and impact – Documents analysis of all identified risks
►Probability and Impact Matrix – Documents risk probability and impact
►Reporting format – documents format of the risk register
►Tracking – describes how risk activities will be reported and how risk
processes will be audited
16
Risk Identification

17
 Risk Identification Techniques
1. Fact gathering techniques – Document sampling, Brainstorming, Delphi
technique, Interviews.
2. Root-cause analysis – Deep analysis of causes of risk. Suggested to ask
five Whys for each potential risk
Example: Project has identified a database vendor as a potential schedule
risk.
► Why? Vendor has requested additional time to deliver database
► Why? Vendor has not yet completed an intermediate delivery for the
dbase
► Why? Vendor struggled with concurrency ctrl threads
► Why? Vendor is inexperienced in thread programming
► Why? Vendor has new development trainees

18
 Risk Identification Techniques
3. Risk Checklist
►Derived from past projects, list of factors affecting projects
►Provides a meaningful template for understanding risks, may also specify
levels of impacts of the factors
►Checklist is updated as team gains experience
►Checklist may pertain to:
► project as a whole
► specific phases
► work packages or
► tasks within the project

19
 Example Risk Checklist
Risk Sources Risk Level

No of interfaces between modules

[Link] than 5 Very Low
2.5 – 10 Low
3.11 – 20 Medium
4.21 – 30 High
[Link] than 30 Very High

% of System components requiring tests

1.0 – 1 Very Low
2.2 – 10 Low
3.11 – 30 Medium
4.31 – 40 High
[Link] than 40 Very High
20
 Risk Register
• Identified risks are entered into a risk register
• A tool for documenting potential risk events and related information
• Shows both negative and positive risks
• Example negative risks: performance failure, delay in task
• Example positive risks: completing work sooner than planned, collaborating with suppliers
to produce better products

Example risk register headings:-

No. Rank Descr. Category Root Cause Trigger Response Risk Prob. Impact Status
Owner
R44 1 New People Little Realisation of Set up PM Med High Meeting
Cust. investigation lack of meeting planned
knowledge with
customer

R21 2 …. … … … … … … 21 …
R7 3
 Risk Register entry
► No.: R44
► Rank: 1
► Risk: New customer
Description: We have never done a project for this organization before and don’t know too much about them. We might
have trouble working with this customer because they are new to us.
► Category: People risk
► Root cause: We won a contract to work on a project without really getting to know the customer.
► Triggers: The project manager and other senior managers realize that we don’t know much about this customer and could
easily misunderstand their needs or expectations.
► Potential responses: Make sure the project manager is sensitive to the fact that this is a new customer and takes the time
to understand them. Have the PM set up a meeting to get to know the customer and clarify their expectations. Have Cliff
attend the meeting, too.
► Risk owner: Project manager
► Probability: Medium
► Impact: High
► Status: PM will set up the meeting within the week.
22
Risk analysis

23
 Risk Analysis
► Can either be qualitative or quantitative
► Qualitative risk analysis examines and prioritizes the risks based on their probability
of occurring and the impact on the project if the risks did occur.
► Qualitative risk analysis is a broad approach to ranking risks by priority, which then guides the
risk reaction process.
► Easy and fast to conduct, although subjective
► Quantitative risk analysis attempts to numerically assess the probability and impact
of the identified risks.
► Difficult and resource intensive to conduct, but gives a more reliable picture of the risk

24
 Qualitative Risk Analysis
► Rates project risks according to their probability (likelihood) and
impact.
► Risk probability - likelihood that a risk event may happen,
► Risk impact - consequence the result of the risk event will have on the
project objectives.
► Each risk is measured based on its likelihood and its impact.

► Visit
[Link]
(for more detail and examples on qualitative risk analysis)
25
Estimating Risk Probability
► For most situations, use of a five-point Likert scale is appropriate:
► Highly unlikely (p < 20%) or 1
► Unlikely (20% < p < 40%) or 2
► About even (40% < p < 60%) or 3
► Likely (60% < p < 80%) or 4
► Highly likely (p > 80%) or 5

► For less well-defined situations, use a three-point scale:

► High (p > 75%) ; Moderate (35% < p < 75%) ; Low (p < 35%)

26
Risk Impact
► Risk impact is the result of a risk hazard materializing.
► Specified in terms of time, cost, and quality
► Risk impact can be expressed as a qualitative rating such
as high, medium, or low
► Measures are subjective, dependent on team.

27
Estimating Risk Impact, Example
Can also use the
Values 1 to 5 for
Very lo to Very High

28
 Risk Consequence
► Combined effect of likelihood and impact
► Also known as risk exposure
► Risk consequence can be expressed as - Likelihood x impact
► Example

Risk Probability Impact PxI

0 – 100% 0 - 10 Score
Key project team member leaves project 40% 4 1.6

Technology does not integrate with existing 60% 7 4.2

application
Client unable to define scope and requirements 50% 6 3.0

Client experiences financial problem 10% 9 0.9

Response time not acceptable to users 80% 6 29

4.8
 Risk Prioritization
► Risk consequences form a basis for risk prioritization

Risk Score Priority

(Consequence)
Response time not acceptable to users 4.8 1

Technology does not integrate with 4.2 2

existing application
Client unable to define scope and 3.0 3
requirements
Key project team member leaves project 1.6 4

Client experiences financial problem 0.9 5

30
Risk Ranking Matrix
Helps to systematically analyze and rank risks, a number of algorithms exist for analysis

Risks at the top right-hand corner

need planning for

31
Risk Response

32
Risk Response
● Once risks are identified, quantified & prioritized, then a response plan needs
to be developed defining means to address the risks
● Risks can be dealt with as follows:
− Eliminate/Avoid the risk
− Mitigate/Reduce the risk
− Risk Transfer
− Formulate a risk contingency plan
− Accept the risk
● Response selection for a given risk should be based on the results of a
cost-benefit analysis performed for each candidate response for the risk

33
 Risk Response
I/ Risk Elimination / Avoidance– Seeks to identify means to completely avoid the risk
or taking an alternative course of action
Examples of avoidance include:
► Changing the project plan to eliminate the risk.
► Clarifying project requirements to avoid discrepancies.
► Hiring additional project team members that have experience with the technology
that the project deals with.
► Using a proven methodology rather than a new approach
►Reducing the scope of the work by removing from the project the work package that
causes the risk.
This may result in diminished pay-off opportunities, better reduce the risk, than to
completely avoid it.

34
 Risk Response
II/ Mitigating/Reducing the risk - Effort to reduce the probability and/or impact of an
identified risk in the project.
The following are recommended for reducing the risk's likelihood & impact:-
• Simplifying the processes within the project
• Completing more tests on the project work before implementation
•Developing prototypes, simulations, and limited releases

35
Risk Response

III/ Deflecting the risk – Transfers the risk to another party

May involve contracting & insurance.
Contracts can be of the following forms:-
Fixed price contract-A detailed scope of work showing costs for
labour, equipment, inflation & risk is created for the
contract.
Cost plus contract-Flexible contract that allows for changes in
costs as project progresses.
Turnkey contract -Contractor takes over project from design to
finish, similar to off the shelf software products.
36
Risk Response
IV/ Contingency Planning – Involves preparing a plan of action to cope with
the risks
Risks are closely monitored so that if a trigger symptom is detected,
the contingency course of action is adopted
Several contingency plans can be developed based on the what-if
analysis
V/ Risk Acceptance/ Do nothing – For impacts that are not severe or those
whose cost is estimated to exceed the benefit, the response might be to
ignore
Note: Risk responses might trigger other risks

37