RISK MANAGEMENT

- INTRODUCTION
- RISK IDENTIFICATION
- RISK PROJECTION (ESTIMATION)
- RISK PLANNING
- RISK MITIGATION, MONITORING, AND MANAGEMENT
SOME DEFINITIONS OF RISK

• risk is an uncertain event or condition that, if it occurs, has a

positive or negative effect on one or more project objectives.
PMBOK
• the chance of exposure to the adverse consequences of future
events’ PRINCE2

• 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 2
 DEFINITION OF RISK
• A risk is a potential problem – it might happen and it might
not
• Risk Management: Series of steps that help a software team
to understand and manage uncertainty.
• Conceptual definition of risk
• Risk concerns future happenings
• Risk involves change in mind, opinion, actions, places, etc.
• Risk involves choice and the uncertainty that choice entails
• Two characteristics of risk
• Uncertainty – the risk may or may not happen, that is, there are no
100% risks (those, instead, are called constraints)
• Loss – the risk becomes a reality and unwanted consequences 3or
losses occur
CATEGORIES OF RISK

4
 CATEGORIES OF RISK -
CONTINUED
• 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 – this includes management procedures, risk here is that a group who need to carry
out a particular project task are not informed of this need because they are not part of the
project communication network
• Tasks – the work to be carried out. A typical risk is that the amount of effort needed to carry out
the task is underestimated.
• 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).
• Exercise 7.2 in the text will be some practice in identifying and categorizing risks 5
RISK CATEGORIZATION –
APPROACH #1
• Project risks
• They threaten the project plan
• If they become real, it is likely that the project schedule will slip
and that costs will increase
• Technical risks
• They threaten the quality and timeliness of the software to be
produced
• If they become real, implementation may become difficult or
impossible
• Business risks
• They threaten the viability of the software to be built
• If they become real, they jeopardize the project or the product
6
RISK CATEGORIZATION – APPROACH #1
(CONTINUED)
• Sub-categories of Business risks
• Market risk – building an excellent product or system that no one
really wants
• Strategic risk – building a product that no longer fits into the
overall business strategy for the company
• Sales risk – building a product that the sales force doesn't
understand how to sell
• Management risk – losing the support of senior management due
to a change in focus or a change in people
• Budget risk – losing budgetary or personnel commitment

7
RISK CATEGORIZATION –
APPROACH #2
• Known risks
• Those risks that can be uncovered after careful evaluation of the
project plan, the business and technical environment in which the
project is being developed, and other reliable information sources
(e.g., unrealistic delivery date)
• Predictable risks
• Those risks that are extrapolated from past project experience (e.g.,
past turnover)
• Unpredictable risks
• Those risks that can and do occur, but are extremely difficult to
identify in advance
8
REACTIVE VS. PROACTIVE RISK
STRATEGIES
• Reactive risk strategies
• "Don't worry, I'll think of something"
• The majority of software teams and managers rely on this
approach
• Nothing is done about risks until something goes wrong
• The team then flies into action in an attempt to correct the problem
rapidly (fire fighting)
• Crisis management is the choice of management techniques
• Proactive risk strategies
• Steps for risk management are followed
• Primary objective is to avoid risk and to have a contingency plan in
place to handle unavoidable risks in a controlled and effective
9
manner
A FRAMEWORK FOR DEALING
WITH RISK

The planning for risk includes these steps:

• Risk identification – what risks might there be?
• Risk analysis and prioritization – which are the most
serious risks?
• Risk planning – what are we going to do about them?
• Risk mitigation – what is the current state of the risk?

10
STEPS FOR RISK
MANAGEMENT

1) Identify possible risks; recognize what can go wrong

2) Analyze each risk to estimate the probability that it will
occur and the impact (i.e., damage) that it will do if it
does occur
3) Rank the risks by probability and impact
- Impact may be negligible, marginal, critical, and catastrophic
4) Develop a contingency plan to manage those risks
having high probability and high impact
11
RISK IDENTIFICATION
BACKGROUND
• Risk identification is a systematic attempt to specify threats to the
project plan
• By identifying known and predictable risks, the project manager takes
a first step toward avoiding them when possible and controlling them
when necessary
• Generic risks
• Risks that are a potential threat to every software project
• Product-specific risks
• Risks that can be identified only by those a with a clear understanding of
the technology, the people, and the environment that is specific to the
software that is to be built
• This requires examination of the project plan and the statement of scope
• "What special characteristics of this product may threaten our project
plan?" 13
RISK IDENTIFICATION -
TECHNIQUES

Approaches to identifying risks include:

• Use of checklists – usually based on the experience

of past projects

• Brainstorming – getting knowledgeable stakeholders

together to pool concerns
14
BOEHM’S TOP 10 DEVELOPMENT RISKS / TYPE
OF 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 cost; incremental
estimates development; recording and analysis of past projects;
standardization of methods

Developing the wrong Improved software evaluation; formal specification methods;

software functions user surveys; prototyping; early user manuals

Developing the wrong user Prototyping; task analysis; user involvement

interface 15
 BOEHM’S TOP TEN RISK -
CONTINUED

Gold plating Requirements scrubbing, prototyping,

design to cost

Late changes to Change control, incremental development

requirements
Shortfalls in externally Benchmarking, inspections, formal
supplied components specifications, contractual agreements, quality
controls

Shortfalls in externally Quality assurance procedures, competitive

performed tasks design etc
Real time performance Simulation, prototyping, tuning
problems
Development Technical analysis, cost-benefit analysis,
technically too difficult prototyping , training

16
RISK ITEM CHECKLIST

• Used as one way to identify risks

• Focuses on known and predictable risks in specific
subcategories (see next slide)
• Can be organized in several ways
• A list of characteristics relevant to each risk subcategory
• Questionnaire that leads to an estimate on the impact of each risk
• A list containing a set of risk component and drivers and their
probability of occurrence

17
KNOWN AND PREDICTABLE RISK
CATEGORIES
• Product size – risks associated with overall size of the software to be built
• Business impact – risks associated with constraints imposed by management
or the marketplace
• Customer characteristics – risks associated with sophistication of the
customer and the developer's ability to communicate with the customer in a
timely manner
• Process definition – risks associated with the degree to which the software
process has been defined and is followed
• Development environment – risks associated with availability and quality of
the tools to be used to build the project
• Technology to be built – risks associated with complexity of the system to be
built and the "newness" of the technology in the system
• Staff size and experience – risks associated with overall technical and project
experience of the software engineers who will do the work
18
QUESTIONNAIRE ON PROJECT RISK
(Questions are ordered by their relative importance to project success)

1) Have top software and customer managers formally committed to

support the project?
2) Are end-users enthusiastically committed to the project and the
system/product to be built?
3) Are requirements fully understood by the software engineering
team and its customers?
4) Have customers been involved fully in the definition of
requirements?
5) Do end-users have realistic expectations?
6) Is the project scope stable?

19
QUESTIONNAIRE ON PROJECT RISK
(CONTINUED)

7) Does the software engineering team have the right mix of skills?
8) Are project requirements stable?
9) Does the project team have experience with the technology to be
implemented?
10) Is the number of people on the project team adequate to do the
job?
11) Do all customer/user constituencies agree on the importance of
the project and on the requirements for the system/product to be
built?

20
 RISK COMPONENTS AND
DRIVERS
• The project manager identifies the risk drivers that affect the
following risk components
• 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 levels
• Negligible, marginal, critical, and catastrophic
• Risk drivers can be assessed as impossible, improbable, probable,
21

and frequent
RISK PROJECTION
(ESTIMATION)
BACKGROUND

• Risk projection (or estimation) attempts to rate each risk in two

ways
• The probability that the risk is real
• The consequence of the problems associated with the risk, should it
occur
• The project planner, managers, and technical staff perform four
risk projection steps (see next slide)
• The intent of these steps is to consider risks in a manner that
leads to prioritization
• Be prioritizing risks, the software team can allocate limited
resources where they will have the most impact
23
RISK PROJECTION/ESTIMATION
STEPS

1) Establish a scale that reflects the perceived likelihood of

a risk (e.g., 1-low, 10-high)
2) Delineate the consequences of the risk
3) Estimate the impact of the risk on the project and
product
4) Note the overall accuracy of the risk projection so that
there will be no misunderstandings

24
 CONTENTS OF A RISK TABLE
• A risk table provides a project manager with a simple technique for
risk projection
• It consists of five columns
• Risk Summary – short description of the risk
• Risk Category – one of seven risk categories (slide 12)
• Probability – estimation of risk occurrence based on group input
• Impact – (1) catastrophic (2) critical (3) marginal (4) negligible
• RMMM – Pointer to a paragraph in the Risk Mitigation, Monitoring, and
Management Plan

Risk Summary Risk Category Probability Impact (1-4) RMMM

25
DEVELOPING A RISK TABLE

• List all risks in the first column (by way of the help of the
risk item checklists)
• Mark the category of each risk
• Estimate the probability of each risk occurring
• Assess the impact of each risk based on an averaging of
the four risk components to determine an overall impact
value (See next slide)
• Sort the rows by probability and impact in descending
order
• Draw a horizontal cutoff line in the table that indicates the
risks that will be given further attention 26
 Risks Category Probability Impact RMMM

Estimated size of project in LOC or FP PS 80% 2 **

Lack of needed specialization increases defects ST 50% 2 **

and reworks
Unfamiliar areas of the product take more time than DE 50% 2 **
expected to design and implement

Does the environment make use of a database DE 35% 3

Components developed separately cannot be DE 25% 3

integrated easily, requiring redesign
Development of the wrong software functions DE 25% 3
requires redesign and implementation
Development of extra software functions that are DE 20% 3
not needed
Strict requirements for compatibility with existing DE 20% 3
system require more testing, design, and implementation
than expected
Operation in unfamiliar software environment causes EV 25% 4
unforeseen problems

Team members do not work well together ST 20% 4

Key personnel are available only part-time ST 20% 4

 ASSESSING RISK IMPACT
• Three factors affect the consequences that are likely if a risk
does occur
• Its nature – This indicates the problems that are likely if the risk occurs
• Its scope – This combines the severity of the risk (how serious was it)
with its overall distribution (how much was affected)
• Its timing – This considers when and for how long the impact will be felt
• The overall risk exposure formula is RE = P x C
• P = the probability of occurrence for a risk
• C = the cost to the project should the risk actually occur
• Example
• P = 80% probability that 18 of 60 software components will have to be
developed
• C = Total cost of developing 18 components is $25,000
28
• RE = .80 x $25,000 = $20,000
 RISK EXPOSURE ASSESSMENT – EXAMPLE

Ref Hazard Likelihood Impact Risk

R1 Changes to requirements specification during coding 8 8 64

R2 Specification takes longer than expected 3 7 21

R3 Significance staff sickness affecting critical path activities 5 7 35

R4 Significance staff sickness affecting non-critical activities 10 3 30

R5 Module coding takes longer than expected 4 5 20

R6 Module testing demonstrates errors or deficiencies in design 4 8 29

32
RISK PROBABILITY: QUALITATIVE
DESCRIPTORS OF RISK
PROBABILITY

Probability level Range

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

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

31
PROBABILITY IMPACT MATRIX

32
RISK PLANNING

Risks can be dealt with by:

• Risk acceptance
• Risk avoidance
• Risk reduction
• Risk mitigation/contingency measures
• Risk transfer
33
RISK PLANNING - CONTINUED

• Risk acceptance – the cost of avoiding the risk may be greater than the
actual cost of the damage that might be inflicted
• 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 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 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. 34
RISK REDUCTION LEVERAGE

Risk reduction leverage =

(REbefore- REafter)/ (cost of risk reduction)
REbeforeis 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
35
USING PERT TO EVALUATE THE
EFFECTS OF UNCERTAINTY

Three estimates are produced for each activity

• Most likely time (m)
• Optimistic time (a)
• Pessimistic (b)
• ‘expected time’ te = (a + 4m +b) / 6
• ‘activity standard deviation’ S = (b-a)/6

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

37
 A CHAIN OF ACTIVITIES

• What would be the expected duration of the chain A

+ B + C?
• Answer: 12.66 + 10.33 + 25.66 i.e. 48.65
• What would be the standard deviation for A + B+ C?
• Answer: square root of (12 + 12 + 32) i.e.
3.32

38
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.33)/3.32 i.e. 1.01
• Look up in table of z values

39
RISK MITIGATION, MONITORING,
AND MANAGEMENT
BACKGROUND
• An effective strategy for dealing with risk must consider
three issues
(Note: these are not mutually exclusive)
• Risk mitigation (i.e., avoidance)
• Risk monitoring
• Risk management and contingency planning
• Risk mitigation (avoidance) is the primary strategy and is
achieved through a plan
• Example: Risk of high staff turnover

41
 BACKGROUND (CONTINUED)
Strategy for Reducing Staff Turnover
 Meet with current staff to determine causes for turnover (e.g., poor working
conditions, low pay, competitive job market)
 Mitigate those causes that are under our control before the project starts
 Once the project commences, assume turnover will occur and develop techniques
to ensure continuity when people leave
 Organize project teams so that information about each development activity is
widely dispersed
 Define documentation standards and establish mechanisms to ensure that
documents are developed in a timely manner
 Conduct peer reviews of all work (so that more than one person is "up to speed")
 Assign a backup staff member for every critical technologist
42
BACKGROUND (CONTINUED)
• During risk monitoring, the project manager monitors
factors that may provide an indication of whether a risk is
becoming more or less likely
• Risk management and contingency planning assume that
mitigation efforts have failed and that the risk has become
a reality
• RMMM steps incur additional project cost
• Large projects may have identified 30 – 40 risks
• Risk is not limited to the software project itself
• Risks can occur after the software has been delivered to the user
43
SOFTWARE SAFETY AND
HAZARD ANALYSIS
• Risks are also associated with software failures that occur
in the field after the development project has ended.
• Computers control many mission critical applications today
(weapons systems, flight control, industrial processes,
etc.).
• These are software quality assurance activities that focus
on the identification and assessment of potential hazards
that may affect software negatively and cause an entire
system to fail
• If hazards can be identified early in the software process,
software design features can be specified that will either
eliminate or control potential hazards
44
THE RMMM PLAN
• The RMMM plan may be a part of the software development plan or
may be a separate document
• Once RMMM has been documented and the project has begun, the risk
mitigation, and monitoring steps begin
• Risk mitigation is a problem avoidance activity
• Risk monitoring is a project tracking activity
• Risk monitoring has three objectives
• To assess whether predicted risks do, in fact, occur
• To ensure that risk aversion steps defined for the risk are being properly
applied
• To collect information that can be used for future risk analysis
• The findings from risk monitoring may allow the project manager to
ascertain what risks caused which problems throughout the project
45
46
47
SEVEN PRINCIPLES OF RISK
MANAGEMENT
• Maintain a global perspective
• View software risks within the context of a system and the business problem that is intended
to solve
• Take a forward-looking view
• Think about risks that may arise in the future; establish contingency plans
• Encourage open communication
• Encourage all stakeholders and users to point out risks at any time
• Integrate risk management
• Integrate the consideration of risk into the software process
• Emphasize a continuous process of risk management
• Modify identified risks as more becomes known and add new risks as better insight is achieved
• Develop a shared product vision
• A shared vision by all stakeholders facilitates better risk identification and assessment
• Encourage teamwork when managing risk
48
• Pool the skills and experience of all stakeholders when conducting risk management activities
SUMMARY

• Whenever much is riding on a software project, common sense

dictates risk analysis
• Yet, most project managers do it informally and superficially, if at all
• However, the time spent in risk management results in
• Less upheaval during the project
• A greater ability to track and control a project
• The confidence that comes with planning for problems before they occur
• Risk management can absorb a significant amount of the project
planning effort…but the effort is worth it
49