CHAPTER - 05

05/21/23 1
 RISK
MANAGEMENT

05/21/23 2
 RISK MANAGEMENT
• Risk is defined as “Possibility of Loss or Injury”.
• “The chance of Loss or the peril to the subject
matters of insurance interact”.
• “Degree of Probability of such Loss”.

05/21/23 3
 INTRODUCTION
• Risk concern future happenings. Today yesterday are
beyond active concern. Now the question is that by
changing our action today, can we create an
opportunity for a different and hopefully better
situation for tomorrow?
• Risk involves change, such that changes of mind,
opinion, actions or places.

05/21/23 4
 • Risk involves choice and uncertainty that choice itself
entails.
• Now when risk is considered in the context of
SWE then 3 conceptual ideas are always in
evidence:
– The future is our concern – what risks might cause
the SW Project to go away.
– The changes are our concern – how will changes in
customer requirements, development technologies,
target computers and all other entities connected to
Project.

05/21/23 5
 – The choices are our concern – what methods &
tools should we use, how many people should be
involved, how much emphasis on quality.
• “While it is futile to try to eliminate risk, & the
question is to minimize it – it is essential that
the risks taken be the right risk”. Before we can
identify the ‘right risks’ to be taken during SW
Projects, it is important to identify all risks that
are obvious to both Managers, & Practitioners.

05/21/23 6
 RISK STRATEGIES
REACTIVE / PROACTIVE RISK
1. Reactive Risk strategies have been laughingly called the “Indiana
Jones School of Risk Management”. It is a name of hero of movies
who have solution for every problem & say “Don’t worry I will
think of something” Means never worrying about any problem
until they happens. But unfortunately, the average SW Project
Managers are not Indiana Jones not the members of SW team are
not his trusty sidekicks.
– Yet… the majority of SW team relies exclusively on Reactive
Risk strategies. At best, a reactive strategy monitors the project
for likely Risks. Resources are set aside to deal with them,
should they became actual problems. More commonly, the SW
team does nothing about Risk until some thing goes wrong.
– Then the team flies into action in an attempt to correct the
problem rapidly. This is often called “Fire fighting Mode”.
When this fails “Crises Management” takes over & the Project is
in real trouble.

05/21/23 7
2. Proactive Risk strategies are more intelligent for
Risk Management. A proactive strategy begins
long before technical work is initiated. Potential
risks are identified, their probability and impact
are assessed, and they are prioritized by
importance.
– SW team establishes a plan for managing risk. The
primary objective is to avoid risk, but because not all
risks can be avoided, the team works to develop a
contingency plan that will enable it to respond in a
controlled & effective manner.

05/21/23 8
 SOFTWARE RISKS
• Although there has been considerable debate about the
proper definition for SW risk, there is general
agreement that risk involves 2 characteristics.
• UNCERTAINTY:
• The event that characterizes the risk may or may not
happen i-e there are no 100% probable risks.
• LOSS:
• If the risk becomes a reality, unwanted consequences or
losses will occur.

05/21/23 9
 CATEGORIES OF RISKS
• When risks are analyzed, it is important to qualify the level of
uncertainty & the degree of loss associated with each risk. To
accomplish, this different categories of risk are considered:
1. Project risk threatens the Project Plan, that is, if Project Risks
became real, it is likely that the project schedule will slip &
that costs will increase. Project risk identifies Potential
budgetary, personnel, resources, customer and requirements
Problems & their impact on software.

05/21/23 10
2. Technical Risk threatens the quality & time lines of SW to be
produced. If a technical risk becomes reality its
implementation may become different or impossible.
 Technical risks identify potential design, implementation
interfacing, and verification & maintenance problems. In
addition of specification, ambiguity, technical
uncertainty. Technical risks occur because the problem is
harder to solve than we thought it would be.
3. Business risk threatens the viability (reasons to develop) of the
SW to be built.

05/21/23 11
4. Known risks are those risks that can be uncovered after careful
evaluation of the Project Plane, the business & technical environment
in which the project is being developed & other reliable resources.

5. Predictable risks are extrapolated from past project

experience i.e. staff turnover poor communication
with customers.

6. Unpredictable Risks are the joker in the deck. They

can do occur, but they are extremely difficult to
identify in advance.

05/21/23 12
 CANDIDATES FOR RISK
IN
BUSSINESS RISK
Candidates for top 5 risks are:
1. MARKET RISK:
• Building an excellent product or system that no one really
wants.
2. STRATEGIC RISK:
• Building a product that no longer fits into overall business
for the company.
3. SALES RISK:
• Building a product that the sales force do not understand
how to sale.

05/21/23 13
05/21/23 14
 RISK IDENTIFICATION
• Risk identification is a systematic attempt to specify threats to the project plan
(Estimation, Scheduling, and Resource Loading).
• By identifying known & predictable risks, the project managers take 1st step
towards avoiding them, when possible & controlling them is necessary.
• There are 2 types of risks for each of the category of Risks explained above.
• GENERIC RISK:
• These are potential threats to every SW project.
• PRODUCT SPECIFIC RISK:
• These are specific to the particular Project. These can be identified by those
with clear understanding of the technology, the people & the environment that
is specific to project at hand.
– Both generic & Product specific Risks should be identified
systematically.
– Tom Gilb drives this point that “If you do not actively attack the risk,
they will actively attack you”.

05/21/23 15
 RISK ITEM CHECKLIST
• One method for identifying Risks is to recall a Risk Item checklist. The checklist can be
used for Risk identification & focuses on some subset of know & Predictable Risk:
• PRODUCT SIZE (PS):
• Risks associated with the overall size of SW to be built or modified.
• BUSINESS IMPACT (BU):
• Risks associated with constraints imposed by Management.
• CUSTOMER CHARACTERISTICS (CC):
• Risks associated with sophistication of the customer & the developers’ ability to
communicate with the customer in a timely manner.
• PROCESS DEFINITION (PD):
• Risks associated with the degree to which the SW Process has been defined & is followed
by the development organization.
•  
• DEVELOPMENT ENVIRONMENT (DE):
• Risks associated with the availability & quality of the tools to be used to build a product.

05/21/23 16
 • TECHNOLOGY TO BE BUILT (TE):
• Risks associated with the complexity of the system to be
built & the ‘newness’ of the technology that is packaged by
the system.
• STAFF SIZE & EXPERIENCE (ST):
• Risks associated with the overall technical & project
experience of the SWEs, who will do the works.
• This list can be organized in Q & a form. Finally “Risk
Component & drivers” are listed along with probability of
occurrence.

05/21/23 17
 RISK MITIGATION, MONITORING &
MANAGEMENT
• All of risk analysis activities have single goal i-e to
assist the Project team developing a strategy for dealing
with Risk.
• An effective strategy must consider three issues:
– Risk Mitigation (avoidance)
– Risk Monitoring
– Risk Management & Contingency planning
• If the SW team adopts proactive approaches to risk,
avoidance is always the best strategy. This is achieved
by developing a plan for Risk Mitigation.
• Example: High Staff Turnover in Project
05/21/23 18
1. RISK MITIGATE:
• To mitigate this risk, Project Management must develop a strategy for
reducing turnover. Among possible steps to be taken few are:
– Meet with current staff to determine causes for turnover (i-e,
poor working conditions, Low pay, Job Market).
– Act to mitigate those causes.
– Once Project commence assume turnover occur & develop
techniques to ensure continuity when people leave.
– Organize Project teams so that information about each
development activity is widely diapered.
– Define documentation standards in timely manner.
– Conduct peer reviews of all work so that more than one person is
familiar with the work.
– Define back up staff member for every critical situation.

05/21/23 19
2. RISK MONITORING:
• As the project proceeds these activities commence. The Project
Managers monitors factors that may provide an indication that
either the Risk of turnover is becoming more or less likely.
• In case of high (more) following factors can be monitored:
– General attitude of team members are based on Project
Pressures.
– The degree to which team has jelled.
– Interpersonal relationship among team members.
– Potential problems with compensation & benefits.
– The availability of jobs with in company & outsides. In
addition to all above factors Project Manager should also
monitor the effectiveness of Risk Mitigation steps.

05/21/23 20
3. RISK MANAGEMENT & CONTINGENCY PLANNING:

• It assumes that Mitigation efforts have failed & that the Risk has become reality.
Now continuing the same example, suppose that the Project is well underway & a no
of people announce that they will be learning.

– Now if Mitigation policy is followed, then backup is here, information is

documented & knowledge has been dispersed across the team.

– In addition, managers may temporarily refocus resources to those functions

that are fully stepped, enabling newcomers who must be added to the team
to ‘get up speed’.

– Those individuals, who are learning are asked to stop all work & spend their
last weeks in ‘knowledge transfer mode’.

– It is important that RMMM steps incur additional project cost, but it will be
evaluated when benefits occurred by RMMM steps.

05/21/23 21
 THE RMMM PLAN
• A risk management strategy can be included in the SW Project
Plan or the Risk Management steps can be organized into separate
RMMM plan.
• The RMMM plan documents all work performed as part of Risk
Analysis & are used by the Project Manager in a part of overall
‘Project Plan’.
• An outline for RMMM plan is:
• INTRODUCTION
• Scope & purpose of document
• Overview of major risks.
• Responsibilities
– Management
– Technical Staff

05/21/23 22
 • PROJECT RISK TABLE
• :Description of all risks above critoff.
• Factors influencing probability & Impact
• RISK MITIGATION, MONITORING, MANAGEMENT:
• Mitigation
• n. Risk #n
– General Strategy
– Specific steps to mitigate the Risk.
• Monitoring
• Factors to be monitored
• Monitoring Approach
• Management
• Contingency Plan
• Special Consideration
• RMMM PLAN ITERATION SCHEDULE:
• SUMMARY

05/21/23 23
 • Once the RMMM plan has been developed & Project has begun, Risk Mitigation &
Monitoring steps will be commenced. As we have discussed that:

– Mitigation is a problem avoidance Policy

– Monitoring is a Project tracking activity with 3 primary objectives.

• To access that whether predicted risk occurs.

• To ensure that risk avoidance steps are being properly applied.

• The collection of information that can be used for future analysis.

– In many cases, the problem that occurs during a Project can be traced to more
than one risk.

• Another job of risk monitoring into attempts to determine the ‘Origin’ throughout the
Project.

05/21/23 24