SOFTWARE DEVELOPMENT PROJECT

MANAGEMENT
(CSC4125)

Lecture 8: Risk Management

 Some definitions of Risk
• ‘The chance of exposure to the adverse consequences of
future events’ – PRINCE 2
• ‘An uncertain event or condition that, if it occurs, has a
positive or negative effect on a project’s objectives’
– PM-BOK
• Project plans have to be based on assumptions
• Risk is the possibility that an assumption is wrong
• When the risk happens it becomes a problem or an issue
• Key elements of Risk
– It relates to the future
– It involves cause and effect

2
Categories of risk

3
 Categories of risk
• This is based on Lyytinen’s sociotechnical model of risk
• Actors –relate to all those involved in the project including both developers, users
and managers e.g. a risk could be that high staff turnover leads to information of
importance to the project being lost
• Technology – both that used to implement the project and that embedded in the
project deliverables – risk could be that the technologies selected are not in fact
appropriate.
• Structure – describes the management structures and systems, including those
affecting planning and control. For example, the implementation might need user
participation in some tasks, but the responsibility for managing the users’
contribution might not be clearly allocated.
• Tasks – the work to be carried out. A typical risk is that the amount of effort
needed to carry out the task is underestimated.
• Note: A risk could be well belong to more than one of the four areas – for example,
estimates being wrong could be influenced by problems with actors (e.g. lack of
experience with a technical domain) or the structure (over optimism of managers
keen to win work).
 Overview
• Project risks are those that could prevent the achievements of the
objectives given to the project manager and the project team.
• Risks are potential problems that might affect the successful
completion of a software project.
• Risks involve uncertainty and potential losses.
• Risk analysis and management are intended to help a software
team understand and manage uncertainty during the development
process.
• The important thing is to remember that things can go wrong and
to make plans to minimize their impact when they do.
• The work product is called a Risk Mitigation, Monitoring, and
Management (RMMM) Plan.

5
 Risk Component & Drivers
 The risk components are defined in the following manner:
• Performance risk
– the degree of uncertainty that the product will meet its requirements
and be fit for its intended use
• Cost risk
– the degree of uncertainty that the project budget will be maintained
• Support risk
– the degree of uncertainty that the resultant software will be easy to
correct, adapt, and enhance
• Schedule risk
– the degree of uncertainty that the project schedule will be maintained
and that the product will be delivered on time
• The impact of each risk driver on the risk component is divided into one of
four impact categories—negligible, marginal, critical, or catastrophic

6
Impact Assessment – Table 1

7
 Risk Management: Reactive vs. Proactive
 Reactive  Proactive
• Project team reacts to risks • Formal risk analysis is performed
when they occur • Organization corrects the root
• Mitigation—plan for additional causes of risk
resources in anticipation of fire • TQM concepts and statistical SQA
fighting • Examining risk sources that lie
• Fix on failure—resource are beyond the bounds of the software
found and applied when the risk • Developing the skill to manage
strikes change
• Crisis management—failure
does not respond to applied
resources and project is in
jeopardy

8
 Risk Check List
• Product size (PS) — risks associated with the overall size of the software to be
built or modified.
• Business impact (BU) — risks associated with constraints imposed by
management or the marketplace.
• Customer characteristics (CU) — risks associated with the sophistication of the
customer and the developer's ability to communicate with the customer in a
timely manner.
• Process definition (PR) — risks associated with the degree to which the software
process has been defined and is followed by the development organization.
• Development Environment (DE) — risks associated with the availability and
quality of the tools to be used to build the product.
• Technology to be built (TE) — risks associated with the complexity of the system
to be built and the "newness" of the technology that is packaged by the system.
• Staff size and experience (ST) — risks associated with the overall technical and
project experience of the software engineers who will do the work.

9
Risk Projection & Building a Risk Table
• Risk projection, also called risk estimation, attempts to rate
each risk in two ways
– the likelihood/probability that the risk is real, and
– the consequences of the problems associated with the risk, should it
occur
• The project planner, along with other managers and technical
staff, performs four risk projection activities:
1) Establish a scale that reflects the perceived likelihood of a risk
2) Delineate the consequences of the risk
3) Estimate the impact of the risk on the project and the product
4) Note the overall accuracy of the risk projection so that there will be
no misunderstandings

10
Building Risk Table – Table 2

RMMM = Risk Mitigation, Monitoring and Management Plan

11
 Risk and Management Concern

Risk impact and probability have a distinct influence on management concern

 Assessing Risk Impact
• The following steps are recommended to determine the overall
consequences of a risk:
– Determine the average probability of occurrence value for each risk
component
– Using Table 1 , determine the impact for each component based on the
criteria shown
– Complete the risk table and analyze the results

• The overall risk exposure, RE, is determined using the following

relationship:
RE = P x C

where P is the probability of occurrence for a risk, and C is the

cost to the project should the risk occur
13
Example: Calculating Risk Exposure
Assume that the software team defines a project risk in the following manner:
Risk identification.  Only 70 percent of the software components scheduled for
reuse will, in fact, be integrated into the application. The remaining functionality
will have to be custom developed.
Risk probability.  80% (likely).
Risk impact.  60 reusable software components were planned. If only 70 percent
can be used, 18 components would have to be developed from scratch (in addition
to other custom software that has been scheduled for development). Since the
average component is 100 LOC and local data indicate that the software
engineering cost for each LOC is $14.00, the overall cost (impact) to develop the
components would be 18 x 100 x 14 = $25,200.

Risk exposure.  RE = 0.80 x 25,200 ~ $20,200.

14
 Risk Assessment
• For assessment to be useful, a
risk referent level must be
defined.
• In the context of software risk
analysis, a risk referent level has
a single point, called the referent
point or break point, at which
the decision to proceed with the
project or terminate it
(problems are just too great) are
equally weighted.

15
 Risk Assessment (cont.)
In reality, the referent level can rarely be represented as a
smooth line on a graph. In most cases, it is a region in which
there are areas of uncertainty; that is, attempting to predict a
management decision based on the combination of referent
values is often impossible. Therefore, during risk assessment, we
perform the following steps:
1. Define the risk referent levels for the project.
2. Attempt to develop a relationship between each (ri, li, xi) and each of
the referent levels. (where ri = risk, li = probability of the risk, and xi =
impact of the risk)
3. Predict the set of referent points that define a region of termination,
bounded by a curve or areas of uncertainty.
4. Try to predict how compound combinations of risks will affect a
referent level.
16
 Risk Decision Tree
• A technique that can be used to visualize the risks of alternatives is to
build a risk decision tree.
• The top-level branch splits based on the alternatives available. The next
split is based on the probabilities of events happening. Each leaf node
has the risk exposure for that event. The sum of risks exposure for all
leafs under a top-level split gives the total risk exposure for that choice.
 Example – A friend offers to play one of two betting games with you.
Game A is that you toss a coin twice. He pays you $10 if you get two
heads. You pay him $2 for each tail you toss. Game B is that you also
toss a coin twice, but it costs you $2 to play and he pays you $10 if you
get two heads. Which game should you play?

17
 Risk Decision Tree (cont.)
• The risk decision tree is shown below. Both games total to
$0.50. Thus, each time you play, your average gain is 50 cents.
No matter which game you choose.

–
18
 A Framework for Dealing with Risk
• Planning for risk includes four steps:
1) Risk identification – what risks might there be?
2) Risk analysis and prioritization – which are the
most serious risks?
3) Risk planning – what are we going to do about
them?
4) Risk monitoring – what is the current state of
the risk?

19
 Risk identification
• Approaches to identifying risks include:
 Use of checklists – usually based on the
experience of past projects (see previous slides)
 Brainstorming – getting knowledgeable
stakeholders together to pool concerns
 Causal mapping – identifying possible chains of
cause and effect

20
 Causal Mapping
• The idea here is to get the major stakeholders
together and to brainstorm collectively the things
that could go wrong. The causes of the problems
identified are traced back using the mapping
technique which identifies the project factors ( or
‘concept variables’) that people see as being
important and the causal links between them. These
links can be positive or negative.
• Where possible, for each factor, positive and negative
aspects are identified e.g. ‘stable…unstable
requirements’.
21
Causal Mapping
 Causal Mapping - Interventions
• Once a causal map has been drawn up identifying
possible negative outcomes and their causes, the
map can be modified to introduce policies or
interventions which should reduce or mitigate the
effects of the negative outcomes.
• Often a risk reduction activity can actually introduce
new risks. The use of consultants to offset the effects
of skill shortages is an example of this. Causal
mapping can help identify such adverse side-effects.

23
Causal Mapping - Interventions
 Boehm’s Top 10 Development Risks
Risk Risk reduction techniques
Personnel shortfalls Staffing with top talent; job matching;
teambuilding; training and career
development; early scheduling of key
personnel
Unrealistic time and cost Multiple estimation techniques; design to
estimates cost; incremental development; recording
and analysis of past projects;
standardization of methods
Developing the wrong Improved software evaluation; formal
software functions specification methods; user surveys;
prototyping; early user manuals
Developing the wrong user Prototyping; task analysis; user
interface involvement

25
Boehm’s Top 10 Development Risks (cont.)
Risk Risk reduction techniques
Gold plating Requirements scrubbing, prototyping,
design to cost
Late changes to requirements Change control, incremental
development
Shortfalls in externally supplied Benchmarking, inspections, formal
components specifications, contractual agreements,
quality controls
Shortfalls in externally performed Quality assurance procedures,
tasks competitive design etc.
Real time performance problems Simulation, prototyping, tuning
Development technically too Technical analysis, cost-benefit analysis,
difficult prototyping , training

26
 Risk Exposure
Risk Exposure (RE) = (potential damage) x (probability of occurrence)
• Ideally
– Potential damage: a money value
• e.g. a flood would cause $0.5 millions of damage
– Probability 0.00 (absolutely no chance) to 1.00 (absolutely
certain)
• e.g. 0.01 (one in hundred chance)
RE = $0.5m x 0.01 = $5,000
• Crudely analogous to the amount needed for an insurance premium
• Note: In practice, with project risks, the quantitative
approaches are usually impractical and more qualitative
approaches are used instead. See the next slide...

27
 Risk Exposure Example
Ref Hazard Likelihood Impact Risk
Exposure

R1 Changes to requirements specification during 8 8 64

coding

R2 Specification takes longer than expected 3 7 21

R3 Significant staff sickness affecting critical path 5 7 35

activities

R4 Significant staff sickness affecting non-critical 10 3 30

activities

R5 Module coding takes longer than expected 4 5 20

R6 Module testing demonstrates errors or deficiencies 4 8 32

in design

28
Qualitative descriptors of Risk probability and
associated range values
Probability Range
level
High Greater than 50% chance of happening

Significant 30-50% chance of happening

Moderate 10-29% chance of happening

Low Less than 10% chance of happening

Managers would be happier identifying an approximate range rather than a

precise probability.
29
Qualitative descriptors of Impact on cost
and associated range values

Impact level Range

High Greater than 30% above budgeted expenditure

Significant 20 to 29% above budgeted expenditure

Moderate 10 to 19% above budgeted expenditure

Low Within 10% of budgeted expenditure

30
 Problem with Qualitative Approach
• Similar tables can be produced for the impact
on project duration and on the quality of
project deliverables.
• The problem with the qualitative approach is
how do you combine the judgements about
probability and impact – you can’t multiply
them together.
Probability Impact Matrix

32
 Probability Impact Matrix
• R1, R2 etc. refer to particular risks. They are
located on the grid according to the likelihood
and impact ratings that have been allocated to
them. A zone around the top right hand
corner of the grid can be designated and risks
falling within that zone are treated as
requiring urgent action.
 Risk Planning
• Having identified the major risks and allocated
priorities, the task is to decide how to deal
with them. Risks can be dealt with by:
– Risk acceptance
– Risk avoidance
– Risk reduction
– Risk transfer
– Risk mitigation/contingency measures

34
 Risk planning
• Risk Acceptance – the cost of avoiding the risk may be greater than the
actual cost of the damage that might be inflicted. This is the do-nothing
option.
• Risk Avoidance – avoid the environment in which the risk occurs e.g. buying
an OTS application would avoid a lot of the risks associated with software
development e.g. poor estimates of effort.
• Risk Reduction – the risk is accepted but actions are taken to reduce its
likelihood e.g. prototypes ought to reduce the risk of incorrect requirements
• Risk Transfer – the risk is transferred to another person or organization. The
risk of incorrect development estimates can be transferred by negotiating a
fixed price contract with an outside software supplier.
• Risk Mitigation – tries to reduce the impact if the risk does occur e.g. taking
backups to allow rapid recovery in the case of data corruption
 Risk Reduction Leverage (RRL)
Risk Reduction Leverage (RRL) = (REbefore- REafter)/ (cost of risk reduction)
– REbefore is risk exposure before risk reduction e.g. 1% chance of a fire causing
$200k damage
– REafter is risk exposure after risk reduction e.g. fire alarm costing $500 reduces
probability of fire damage to 0.5%
RRL = { (1% of $200k) – (0.5% of $200k) } / $500 = 2
RRL > 1.00, therefore worth doing
Note: If you think in terms of the analogy to insurance. An insurance company might
reduce the fire insurance premium from $2k to $1k on condition that a fire alarm
is installed. The insured would save $1k a year by investing $500 so it would be
worth doing.
Note: Cost-effectiveness of a risk reduction action can be assessed by RRL
Using PERT to evaluate the effects of uncertainty

• Three estimates are produced for each activity

 Most likely time (m) –the time we would expect
the task to take normally
 Optimistic time (a) –the shortest time could be
realistically be expected
 Pessimistic time (b) –worst possible time
 ‘Expected time’ te = (a + 4m +b) / 6
 ‘Activity standard deviation’ s = (b – a)/6

37
 A chain of activities
Task A Task B Task C

Task a m b te s

A 10 12 16 ? ?

B 8 10 14 ? ?

C 20 24 38 ? ?

Can you fill the missing gaps?

38
 A chain of activities
• For Task A, te = (10+ (12 x 4) + 16)/ 6 = 12.66, s = (16-10)/6 i.e. 1
• For Task B, te = (8 + (10 x 4) + 14)/ 6 = 10.33, s = (14-8)/6 i.e. 1
• For Task C, te = (20 + (24 x 4) + 38)/6 = 25.66, s = (38-20)/6 i.e. 3
 A chain of activities (cont.)
• What would be the expected duration of the
chain A + B + C?
 Answer: 12.66 + 10.33 + 25.66 = 48.65

• What would be the standard deviation for

A + B+ C?
 Answer: Square root of (12 + 12 + 32) = 3.32

40
Expected Times and Standard Deviation
Activity Durations in (weeks)
Activity Optimistic Most likely Pessimistic Expected Standard
deviation

(a) (m) (b) ( te ) (s)

A 5 6 8 6.17 0.50

B 3 4 5 4.00 0.33

C 2 3 3 2.83 0.17

D 3.5 4 5 4.08 0.25

E 1 3 4 2.83 0.50

F 8 10 15 10.50 1.17

G 2 3 4 3.00 0.33

H 2 2 2.5 2.08 0.08

41
PERT Network

X t = 2.83

42
 Assessing the likelihood of meeting a target

• Say the target for completing A+B+C was 52 days (T)

• Calculate the z value, thus
z = (T – te )/s
• In this example z = (52 – 48.65)/3.32 i.e. 1.01
• Look up in table of z values  see next slide

43
 Graph of z values

There is about a 17% chance of not meeting the target of 52 days.

44
 Critical chain approach
• One problem with estimates of task duration:
– Estimators add a safety zone to estimate to take account of
possible difficulties
– Developers work to the estimate + safety zone, so time is
lost
– No advantage is taken of opportunities where tasks can
finish early – and provide a buffer for later activities

• Note: Developers will tend to start activities as late as is

compatible with meeting the target date as they often have
other urgent work to be getting on with in the mean time.

45
 Critical chain approach (cont.)
• One answer to this:
– Base targets on midpoints (i.e. te)
– Accumulate 50% of the safety zones (between te and b) into a buffer at the end
of the project
– Work backwards and start all activities at their latest start dates
– During project execution use ‘relay race’ model
• Note:
– This approach means that the ‘safety buffer’ in the estimate for an activity is
moved from the individual developer to the project as a whole.
– The ‘relay race’ principle is that the project manager makes sure that team
members are ready to immediately start dependent activities as soon as the
preceding activity is finished.

46
 Risk Due to Product Size
• Attributes that affect risk:
– estimated size of the product in LOC or FP?
– estimated size of product in number of programs, files,
transactions?
– percentage deviation in size of product from average for
previous products?
– size of database created or used by the product?
– number of users of the product?
– number of projected changes to the requirements for
the product? before delivery? after delivery?
– amount of reused software?
47
 Risk Due to Business Impact
• Attributes that affect risk:
– effect of this product on company revenue?
– visibility of this product by senior management?
– reasonableness of delivery deadline?
– number of customers who will use this product
– interoperability constraints
– sophistication of end users?
– amount and quality of product documentation that must be produced
and delivered to the customer?
– governmental constraints
– costs associated with late delivery?
– costs associated with a defective product?
48
 Risks Due to the Customer
• Questions that must be answered:
– Have you worked with the customer in the past?
– Does the customer have a solid idea of requirements?
– Has the customer agreed to spend time with you?
– Is the customer willing to participate in reviews?
– Is the customer technically sophisticated?
– Is the customer willing to let your people do their job—
that is, will the customer resist looking over your
shoulder during technically detailed work?
– Does the customer understand the software
engineering process?
49
 Risks Due to Process Maturity
• Questions that must be answered:
– Have you established a common process framework?
– Is it followed by project teams?
– Do you have management support for software
engineering
– Do you have a proactive approach to SQA?
– Do you conduct formal technical reviews?
– Are CASE tools used for analysis, design and testing?
– Are the tools integrated with one another?
– Have document formats been established?

50
 Technology Risks
• Questions that must be answered:
– Is the technology new to your organization?
– Are new algorithms, I/O technology required?
– Is new or unproven hardware involved?
– Does the application interface with new software?
– Is a specialized user interface required?
– Is the application radically different?
– Are you using new software engineering methods?
– Are you using unconventional software development methods, such
as formal methods, AI-based approaches, artificial neural networks?
– Are there significant performance constraints?
– Is there doubt the functionality requested is "do-able?"

51