Software Project Management

1. Risk Planning
1

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

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

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

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

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

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

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

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

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

11. An Example Risk Management Model
11
Source: Nicholas & Steyn, 2011

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

13. A Project Risk Identification Framework
13
Adapted from Marchewka, 2015

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

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

16. Risk Management Plan Structure
Suggested Risk management plan 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
►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

17. Risk Identification
17

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

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

20. Example Risk Checklist
Risk Sources Risk Level
No of interfaces between modules
1.Less than 5
2.5 – 10
3.11 – 20
4.21 – 30
5.More than 30
Very Low
Low
Medium
High
Very High
% of System components requiring tests
1.0 – 1
2.2 – 10
3.11 – 30
4.31 – 40
5.More than 40
Very Low
Low
Medium
High
Very High
20

21. Risk Register
No. Rank Descr. Category Root Cause Trigger Response Risk
Owner
Prob. Impact Status
R44 1 New
Cust.
People Little
investigation
Realisation of
lack of
knowledge
Set up
meeting
with
customer
PM Med High Meeting
planned
R21 2 …. … … … … … … …
R7 3
21
• 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:-

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

23. Risk analysis
23

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

25. 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
https://www.pmi.org/learning/library/qualitative-risk-assessment-cheaper-faster-3188
(for more detail and examples on qualitative risk analysis)
25

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

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

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

29. Risk Consequence
► Combined effect of likelihood and impact
► Also known as risk exposure
► Risk consequence can be expressed as - Likelihood x impact
► Example
29
Risk Probability
0 – 100%
Impact
0 - 10
P x I
Score
Key project team member leaves project 40% 4 1.6
Technology does not integrate with existing
application
60% 7 4.2
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 4.8

30. Risk Prioritization
► Risk consequences form a basis for risk prioritization
30
Risk Score
(Consequence)
Priority
Response time not acceptable to users 4.8 1
Technology does not integrate with
existing application
4.2 2
Client unable to define scope and
requirements
3.0 3
Key project team member leaves project 1.6 4
Client experiences financial problem 0.9 5

31. Risk Ranking Matrix
31
Risks at the top right-hand corner
need planning for
Helps to systematically analyze and rank risks, a number of algorithms exist for analysis

32. Risk Response
32

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

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

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

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

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