Project Risks & Risk Management

Risk:- An uncertain event or condition that, if occurs, has

a positive or negative effect on the project objectives.

Project Risk Management :- The systematic process of

identifying, analyzing and responding to project risks.

1
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 of a memory stick;
 Loss/ damage of a hard drive
 Loss/ damage of a computer

-Human related:

2
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;

3
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

4
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

5
 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

6
 Seven Principles of Risk Management

1.Maintain 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.

7
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.
8

Adapted from SEI

A Risk Management Model

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
on 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) Control Risks- Train team members to implement risk
management plan

10
A Project Risk Identification Framework

11

11 Adapted from Marchewka, 2015

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 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 12

12
 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

Internalrisks - 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
13
Risk Management Plan Structure
Risk planning produces a Risk management plan of the following structure:
Risk Management 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

14
Risk Management Plan Structure

 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

15
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
16
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

17
Example Risk Checklist
Risk Sources Risk Level
Status of implementation
1.No plan required None
2.Standard plan, existing, complete Low
3.Plan being prepared Medium
4.Plan not started High
No of interfaces between modules
1.Less than 5 None
2.5 – 10 Low
3.11 – 20 Medium
4.More than 20 High
% of System components requiring tests
1.0 – 1 None
2.2 – 10 Low
3.11 – 30 Medium
18

4.Over 30 High
Example Risk Checklist
Suppose an upcoming project will use a standard completed
plan, have eight modules, and will test 15 percent of the system
components.
Using the checklist above the risk ratings for the project are:
Status of implementation – Low
Interfaces between modules – Low
% of System components requiring tests – Medium
As team experience grows with completed projects, the
checklists are expanded and updated

19
Risk Identification Techniques
4. Influence Diagrams, - a variation of the Ishikawa diagram
Shows risk factor interdependencies
To construct an influence diagram:
 List all identified risks and space them out
 Identify those risk factors influencing or influenced by
others
 Show risk factor influence by means of arrows
 Keep number of risks minimum (< 15) to avoid clutter
 Risks with the most influences are most important

20
Influence Diagram Example

21
I.2, S.1 and S.2 most significant
 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. Ran Desc Category Root Trigger Response Risk Prob. Impact Status
k r. Cause Owner
R44 1 New People Little Realializ Set up PM Med High Meeting
Cust investiga ation of meeting planne
tion lack of with d
knowled custom
ge er
R21 2 …. … … … … … …
22
…
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 23

 Status: PM will set up the meeting within the week.

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.
 Quantitative risk analysis attempts to numerically assess the
probability and impact of the identified risks.

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.

25
Quantifying Risk Probability
 For most situations, use of a five-point Likert scale is
appropriate:
 Highly unlikely (p < 20%)
 Unlikely (20% < p < 40%)
 About even (40% < p < 60%)
 Likely (60% < p < 80%)
 Highly likely (p > 80%)
 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
Quantifying Impact, Example

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

Risk Probabilit Impact PxI

y 0 - 10 Score
0 – 100%
Key project team member leaves 40% 4 1.6
project
Technology does not integrate with 60% 7 4.2
existing application
Client unable to define scope and 50% 6 3.0
requirements 29

Client experiences financial 10% 9 0.9

Risk Prioritization
 Risk consequences form a basis for risk prioritization

Risk Score Priorit

(Consequence) y
Response time not acceptable to 4.8 1
users
Technology does not integrate 4.2 2
with existing application
Client unable to define scope and 3.0 3
requirements
Key project team member leaves 1.6 4
project
Client experiences financial 0.9 5
problem
30
 Risk Classification
Kittens – low probability & low
Impact, not worth planning for.

Puppies – High probability, low

Impact, need to keep an eye on.

Alligators – Low probability, high

impact, need to be avoided with
Care

Tigers – High probability, high

Impact, need to be dealt with urgently

Tusler’s model - plots risk probability against risk impact in 4 quadrants

31
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.

32
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.

33
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

34
Risk Response
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.

35
Risk Response
Contingency Planning – Involves preparing a plan of action to cope with the risks
Risks 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
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

36