Risk Analysis and Management

Risk
• Risk is a potential problem. It's an activity or
event that may compromise the success of a
software development project.
Reactive Risk Management
• Project team reacts to risks when they occur.
• More commonly, the software team does
nothing about risks until something goes
wrong.
• Then, the team involved into action in an
attempt to correct the problem rapidly. This is
often called a fire fighting mode.
• When this fails, “crisis management” takes
over and the project is in real jeopardy.
 Proactive 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 ranked by
importance.
• Then, the software 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 and effective manner.
 Software Risks
• Risk always involves two characteristics:
– Uncertainty —the risk may or may not happen; that is, there are no
100% probable risks.
– Loss—if the risk becomes a reality, unwanted consequences or losses
will occur
• When risks are analyzed, it is important to quantify the level of
uncertainty and the degree of loss associated with each risk.
• To accomplish this, different categories or types of risks are considered.
– Project Risks
– Technical Risks
– Business Risks
– Known Risks.
– Predictable Risks
– Unpredictable Risks
 Project Risk

• Project risks make threats the project plan.

• That is, if project risks become real, it is likely that project
schedule will slip and that costs will increase.
• Project risks identify potential budgetary, schedule, personnel
(staffing and organization), resource, customer, and
requirements problems and their impact on a software
project.
• Project complexity, size, and the degree of structural
uncertainty were also defined as project risk factors.
 Technical risks
• Technical risks threaten the quality and timeliness of the
software to be produced.
• If a technical risk becomes a reality, implementation may
become difficult or impossible.
• Technical risks identify potential design, implementation,
interface, verification, and maintenance problems.
• In addition, specification ambiguity, technical uncertainty,
and "leading-edge" technology are also risk factors.
 Business Risk
• Business risks threaten the feasibility of the software to be built.
• Business risks often jeopardize the project or the product.
• Top five business risks are
– Building a excellent product or system that no one really wants
(market risk),
– Building a product that no longer fits into the overall business
strategy for the company (strategic risk)
– Building a product that the sales force doesn't understand how
to sell.
– Losing the support of senior management due to a change in
focus or a change in people (management risk)
– Losing budgetary or personnel commitment (budget risks)
 Known Risk
• Known risks are those that can be uncovered after
careful evaluation of the project plan, the business
and technical environment in which the project is
being developed,
• Other reliable information sources (e.g., unrealistic
delivery date, lack of documented requirements or
software scope, poor development environment).
• Predictable risks are generalized from past
project experience (e.g., staff turnover, poor
communication with the customer, etc).

• Unpredictable risks are the joker in the deck.

They can and do occur, but they are extremely
difficult to identify in advance.
 Risk Identification
• Risk identification is a systematic attempt to specify threats to the
project plan (estimates, schedule, resource loading, etc.).
• By identifying known and predictable risks, the project manager
takes a first step toward avoiding them when possible and
controlling them when necessary.
• Two distinct types of risks
– Generic risks are a potential threat to every software project
– Product-specific risks can be identified only by those with a clear
understanding of the technology, the people, and the
environment that is specific to the project at hand.
 Contd.
• To identify product-specific risks, the project Plan and the software
statement of scope are examined.
• One method for identifying risks is to create a risk item checklist.
• The checklist can be used for risk identification and focuses on
some subset of known and predictable risks in the following generic
subcategories:
• Product size —risks associated with the overall size of the software
to be built or modified.
• Business impact —risks associated with constraints imposed by
management or the marketplace.
 Risk Item Checklist contd.
• Customer characteristics —risks associated with the 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 by the
development organization.
• Development environment —risks associated with the availability
and quality of the tools to be used to build the product.
• Technology to be built —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 —risks associated with the overall
technical and project experience of the software engineers who will
do the work.
 Risk Components
PM identify the risk drivers that affect software 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
 Risk Mitigation, Monitoring,
and Management
• Risk analysis goal - to assist the project team in developing a
strategy for dealing with risk. An effective strategy must
consider three issues:
• Risk avoidance or mitigation.
• Risk monitoring
• Risk management and contingency planning
• Proactive approach to risk, avoidance is always the best
strategy. This is achieved by developing a plan for risk
mitigation.
• For example, assume that high staff turnover (i.e. revenue) is
noted as a project risk.
• To mitigate this risk, project management must
develop a strategy for reducing turnover.
• Steps are:
– Meet with current staff to determine causes for turnover
(e.g., low pay, competitive job market).
– Mitigate those causes that are under our control before
the project starts.
– Organize project teams so that information about each
development activity is widely dispersed.
– Define documentation standards and establish
mechanisms to be sure that documents are developed in a
timely manner.
– Conduct peer reviews of all work
– Assign a backup staff member for every critical
technologist.
• As the project proceeds, risk monitoring activities commence.
• The project manager monitors factors that may provide an
indication of whether the risk is becoming more or less likely.
• In the case of high staff turnover, the following factors can be
monitored:
– General attitude of team members based on project pressures.
– Potential problems with compensation and benefits.
– The availability of jobs within the company and outside it.
• Risk management and contingency planning assumes that
mitigation efforts have failed and that the risk has become a
reality.
• The project is well underway and a number of people
announce that they will be leaving. If the mitigation strategy
has been followed, backup is available, information is
documented, and knowledge has been dispersed across the
team.
• In addition, the project manager may temporarily refocus
resources (and readjust the project schedule) to those
functions that are fully staffed, enabling newcomers who
must be added to the team to “get up to speed.”
• Those individuals who are leaving are asked to stop all work
and spend their last weeks in “knowledge transfer mode.”
• This might include video-based knowledge capture, the
development of “commentary documents,” and/or meeting
with other team members who will remain on the project.
RMMM steps incur additional project cost. For example,
spending the time to "backup" every critical technologist
costs money.
 THE RMMM PLAN
• The RMMM plan documents all work performed as part of
risk analysis and is used by the project manager as part of the
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).
• RIS is maintained using a database system, so that creation
and information entry, priority ordering, searches, and other
analysis may be accomplished easily.
• Once RMMM has been documented and the project has
begun, risk mitigation and monitoring steps commence.