Unit –4

Risk Management

BE Sem – 7 SPM – 3171609

Risk Analysis and Management
What is Software Risk?
• Risk is an expectation of loss, a potential problem that may
or may not occur in the future.
• It is generally caused due to lack of information, control or
time.
• A possibility of suffering from loss in software
development process is called a software risk.
• Loss can be anything, increase in production cost,
development of poor quality software, not being able to
complete the project on time.
Definition of Risk
• A risk is a potential problem – it might happens & it might
not
• Conceptual definition of risk
o Risk concerns future happenings
o Risk involves change in mind, opinion, actions,
places, etc.
o Risk involves choice & the uncertainty that choice
requires.
• Two characteristics of risk
o Uncertainty – the risk may or may not happen, that
is, there are no 100% risks (those, instead, are called
constraints)
o Loss – the risk becomes a reality & unwanted
consequences or losses occur
Risk Management Activities
Risk Categorization – Approach #1
• Project risks
o They threaten the project plan
o If project risk become real, it is likely that the project
schedule will slip & that costs will increase
o Identifies problems related to budgetary, schedule, personnel &
resource
• Technical risks
o They threaten the quality & timeliness of the software to be
produced
o If they become real, implementation may become difficult or
impossible
o Identifies problems related to design, implementation,
maintenance etc.
• Business risks
o They threaten the viability of the software to be built
o If they become real, they risk the project or the product
Risk Categorization – Approach #1 cont.
• Sub-categories of Business risks

o Market risk – building an excellent product or system that no

one really wants
o Strategic risk – building a product that no longer fits into the
overall business strategy for the company
o Sales risk – building a product that the sales force doesn’t
understand how to sell
o Management risk – losing the support of senior management
due to a change in focus or a change in people
o Budget risk – losing budgetary or personnel commitment
 Risk Categorization – Approach #2
• Known risks
o Those risks that can be uncovered after careful evaluation of
the project plan, the business & technical environment in
which the project is being developed, & other reliable
information sources (e.g. unrealistic delivery date, lack of
documented requirements, poor development environment)
• Predictable risks
o Those risks that are extrapolated from past project experience
(e.g. past turnover, poor communication with the customer)
• Unpredictable risks
o Those risks that can & do occur, but are extremely difficult to
identify in advance (e.g. certain changes in government
policies may affect the business project)
Reactive vs. Proactive Risk Strategies
Reactive risk strategies
• “Don’t worry, I’ll think of something”
• The majority of software teams & managers rely on this approach
• Nothing is done about risks until something goes wrong
o The team then files 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 :
o Identify possible risks; recognize what can go wrong
o Analyze each risk to estimate the probability that it will occur & the
impact (i.e., damage) that it will do if it does occur
o Rank the risks by probability & impact. Impact may be negligible,
marginal, critical, & catastrophic.
o Develop a contingency plan to manage those risks having high probability
& high impact
• Primary objective is to avoid risk & to have a contingency plan in place
to handle unavoidable risks in a controlled & effective manner
Risk Identification
• Risk identification is a systematic attempt to specify
threats to the project plan
• By identifying known & predictable risks, the project
manager takes a first step toward avoiding them when
possible & controlling them when necessary
• Generic Risks
o Risks that are a potential threat to every software project
• Product-specific Risks
o Risks that can be identified only by those with a clear
understanding of the technology, the people & the environment,
that is specific to the software that is to be built
o This requires examination of the project plan & the statement of
scope
o “What special characteristics of this product may threaten our
project plan?”
Risk Item Checklist
• One method for identifying risks is to create a risk item
checklist
• Checklist can be used for risk identification which focuses
on some subset of known & predictable risks in the specific
subcategories
• Can be organized in several ways
Known & 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 & 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 & is followed
• Development Environment: risks associated with availability &
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 & the “newness” of the technology in the
system
• Staff Size & Experience: risks associated with overall technical &
project experience of the software engineers who will do the work
Risk Components & Drivers
• The project manager identifies the risk drivers that affect
the following risk components
o Performance risk - the degree of uncertainty that the product will
meet its requirements and be fit for its intended use
o Cost risk - the degree of uncertainty that the project budget will be
maintained
o Support risk - the degree of uncertainty that the resultant software
will be easy to correct, adapt, and enhance
o 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
o Negligible, marginal, critical, and catastrophic
• Risk drivers can be assessed as impossible, improbable,
probable, and frequent
Risk Projection (Estimation)
• Risk projection (or estimation) attempts to rate each risk in
two ways
o The probability that the risk is real
o The consequence of the problems associated with the risk,
should it occur
• The project planner, managers, and technical staff perform
four risk projection steps
• The intent of these steps is to consider risks in a manner
that leads to prioritization
• By prioritizing risks, the software team can allocate limited
resources where they will have the most impact
Risk Projection/Estimation steps
• Establish a scale that reflects the perceived likelihood of a
risk (e.g., 1-low, 10-high)
• Delineate the consequences of the risk
• Estimate the impact of the risk on the project and product
• Note the overall accuracy of the risk projection so that
there will be no misunderstandings
Contents of a Risk Table
• A risk table provides a project manager with a simple
technique for risk projection
• It consists of five columns
o Risk Summary – short description of the risk
o Risk Category – one of seven risk categories
o Probability – estimation of risk occurrence based on group
input
o Impact – (1) catastrophic (2) critical (3) marginal (4)
negligible
o RMMM – Pointer to a paragraph in the Risk Mitigation,
Monitoring, and Management Plan
Risk Summary Risk Category Probability Impact (1-4) RMMM
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
Assessing Risk Impact
• Three factors affect the consequences that are likely if a
risk does occur
o Its nature – This indicates the problems that are likely if the
risk occurs
o Its scope – This combines the severity of the risk (how serious
was it) with its overall distribution (how much was affected)
o Its timing – This considers when and for how long the impact
will be felt
• The overall risk exposure formula is RE = P x C
o P = the probability of occurrence for a risk
o C = the cost to the project should the risk actually occur
• Example
o P = 80% probability that 18 of 60 software components will
have to be developed
o C = Total cost of developing 18 components is $25,000
o RE = .80 x $25,000 = $20,000
 Risk Refinement
• During early stages of project planning, a risk may be stated
quite generally.
• As time passes & more is learned about risk, it may be possible
to refine the risk into a set of more detailed risks each
somewhere easy to monitor & manage.
• One way to do this is to represent the risk in Condition
Transition Consequence format :
Given that<condition>then there is concern that(possibly)<consequence>.
• Refinement helps to isolate the underlying risks & lead to easier
analysis & response.
• Case - Only 70% of software components are reusable & the remaining 30%
need to be custom built
• Subcondition 1 - Certain reusable components were developed by a third
party with no knowledge of internal design standards.
• Subcondition 2. Certain reusable components have been implemented in a
language that is not supported on the target environment.
RMMM
• Risk Mitigation, Monitoring, & Management
• An effective strategy for dealing with risk must consider
three issues (Note: these are not mutually exclusive)
o Risk mitigation (i.e., avoidance)
o Risk monitoring
o Risk management and contingency planning

• Risk Mitigation is a problem avoidance activity

• Risk Monitoring is a project tracking activity
• Risk Management includes contingency plans that risk will
occur
 Risk Mitigation
• Risk mitigation (avoidance) is the primary strategy & is
achieved through a plan
• Example: Risk of high staff turnover
• To mitigate this risk, Strategy for reducing staff turnover :
o Meet with current staff to determine causes for turnover (e.g., poor
working conditions, low pay, and competitive job market)
o Mitigate those causes that are under your control before the project
starts
o Once the project commences, assume turnover will occur and
develop techniques to ensure continuity when people leave
o Organize project teams so that information about each development
activity is widely dispersed
o Define work product standards and establish mechanisms to be sure
that all models and documents are developed in a timely manner
o Conduct peer reviews of all work (so that more than one person is
“up to speed”).
o Assign a backup staff member for every critical technologist
Risk Monitoring
• During risk monitoring, the project manager monitors
factors that may provide an indication of whether a risk is
becoming more or less likely
• The objective of risk monitoring is
• To check whether the predicted risks really occur or not
• To ensure the steps defined to avoid the risk are applied
properly or not.
• To gather the information which can be useful for
analyzing the risk.
Risk Management
• Risk management and contingency planning assume that
mitigation efforts have failed and that the risk has become a
reality
• Project manager performs this task
• If project manager is successful in applying the project
mitigation effectively then it becomes very much easy to
manage the risks.

• RMMM steps incur additional project cost

o Large projects may have identified 30 – 40 risks
• Risk is not limited to the software project itself
o Risks can occur after the software has been delivered to the
user
Risk Plan
• The RMMM Plan is a document in which all the risk analysis
activities are described.
• Sometimes project manager includes this document as a
part of overall project plan.
• Some software teams do not develop a formal RMMM
document, rather each risk is documented individually using
a Risk information sheet (RIS)
• In most cases, RIS is maintained using a database system.
• So Creation and information entry, priority ordering,
searches and other analysis may be accomplished easily.
Risk information sheet (RIS)
Risk Prioritization
• Risk prioritization is the process of determining which risk
you should act upon first.
• This should be based on the likelihood of a risk & the impact
that it would make.
• It can be achieved by evaluating the risks against your
business to determine which are more likely to occur &
which will have a higher impact.
• A risk prioritization matrix can be used for evaluation.