Project Risks
What can go wrong?
What is the likelihood?
What will the damage be?
What can we do about it?
1
Risk Management
• Risk management is carried out to:
– Identify the risk
– Reduce the impact of risk
– Reduce the probability or likelihood of risk
– Risk monitoring
2
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 (see next slide)
– Primary objective is to avoid risk and to have a contingency plan
in place to handle unavoidable risks in a controlled and effective
manner 3
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.
4
Types of software risks
• Software risk exists because the future is
uncertain and there are many known and
unknown things that cannot be incorporated in
the project plan.
• A software risk can be of two types
– (1) internal risks that are within the control of the
project manager and
– (2) external risks that are beyond the control of
project manager.
5
Definition of Risk
• A risk is a potential problem – it might happen and it might not
• 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 or losses occur
6
classifications of risks
• There are 3 main classifications of risks which can affect a
software project:
• 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
• 2) Technical risks
– They threaten the quality and timeliness of the software to be
produced
– If they become real, implementation may become difficult or
impossible
• 3) Business risks
– They threaten the viability of the software to be built
– If they become real, they jeopardize the project or the
product 7
Risk Categorization –(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
8
Risk Categorization
• 4) 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)
• 5) Predictable risks
– Those risks that are extrapolated from past project experience (e.g., past
turnover)
• 6) Unpredictable risks
– Those risks that can and do occur, but are extremely difficult to identify in
advance
9
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
10
Steps for Risk Management
Identify possible risks; recognize what can go wrong
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
Rank the risks by probability and impact
- Impact may be negligible, marginal, critical, and
catastrophic
Develop a contingency plan to manage those risks
having high probability and high impact
11
Risk Identification
• 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
• There are 2 types distinct types of risks
• 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?"
12
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.
• 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.
13
Assessing Overall Project Risk
•The questions are ordered by their related importance to the success of a project.
1.Have top managers committed to supporting the project?
2.Are users excited and committed to the project and its product?
3.Does the team fully understand the project requirements?
4.Were customers involved in defining the requirements?
5.Do users have realistic expectations?
6.Is the project scope clear and stable?
7.Does the team have the right skills for the job?
8.Are project requirements steady and not changing?
9.Does the team have experience with the required technology?
10.Are there enough people on the team to complete the project?
11.Do all customers and users agree on the project’s importance and requirements?
14
Risk Components and Drivers
• Risk components are different types of risks a project might
face, while risk drivers are the factors that cause those risks.
• Here are the key risk components:
• Performance risk: Uncertainty about whether the product will
meet its needs and work as intended.
• Cost risk: Uncertainty about whether the project will stay
within budget.
• Support risk: Uncertainty about whether the software will be
easy to fix, update, and improve.
• Schedule risk: Uncertainty about whether the project will finish
on time.
15
RISK PROJECTION
• Risk projection, also called risk estimation, means evaluating each
risk by looking at how likely it is to happen and what problems it
could cause.
• 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, along with the team, does four things:
1. Create a scale to show how likely the risk is.
2. Define the possible consequences of the risk.
3. Estimate the impact of the risk on the project and product.
4. Clarify the accuracy of the risk projection to avoid
misunderstandings.
16
17
Developing a Risk Table Building a
Risk
• A project team begins by listing all risks (no matter how remote) in the
first column of the table.
• Each risk is categorized in Next; the impact of each risk is assessed.
• The categories for each of the four risk components4performance,
support, cost, and schedule4 are averaged to determine an overall
impact value.
• •High-probability, high-impact risks percolate to the top of the table,
and low probability risks drop to the bottom. This accomplishes first-
order risk prioritization.
18
19
• The project manager reviews the risk list and draws a
cutoff line. Risks above the line are the top priority and get
more focus. Risks below the line are reviewed again to
decide if they need attention later.
20
• Referring to Figure 28.3, risk impact and probability have
a distinct influence on management concern. A risk factor
that has a high impact but a very low probability of
occurrence should not absorb a significant amount of
management time. However, high-impact risks with
moderate to high probability and low-impact risks with
high probability should be carried forward into the risk
analysis steps that follow.
21
Assessing Risk Impact
Assessing Risk Impact means figuring out how much
damage or effect a risk could have on your project if it
actually happens.
Three factors affect the consequences that are likely if a risk
does occur: its nature, its scope, and its timing.
1. Nature – What kind of problems will happen if the risk
occurs?
2. Scope – How serious the risk is and how widely it affects the
project.
3. Timing – When the risk will hit and how long the impact lasts.
The overall risk exposure, RE, is determined using the
following relationship RE = P x C
22
Risk Refinement
• Risk Refinement making something clearer.
• To better understand a risk, we can break it down using the CTC
format:
• Condition – What might go wrong
• Transition – How it could happen
• Consequence – What the result would be
• Example (broken into sub-conditions):
• Components made by third parties don’t follow our design rules.
• Interface design isn’t finalized and may not match existing
components.
• Some components are written in unsupported languages.
23
Example (broken into sub-conditions):
•sub-condition: Components made by third
parties don’t follow our design rules.
•sub-condition: Interface design isn’t
finalized and may not match existing
components.
•sub-condition: Some components are
written in unsupported languages.
24
Risk Mitigation, Monitoring, and Management
•Risk Avoidance – Best way is to avoid the risk completely.
•Risk Monitoring – Keep an eye on warning signs.
•Risk Management – Have backup plans ready.
To reduce risk from team turnover:
•Find out why people leave and fix what you can.
•Be ready in case someone does leave.
•Share knowledge across the team.
•Use good documentation and peer reviews.
•Assign backups for key roles.
25
Risk Monitoring Tips:
•Team’s mood and stress levels
•How well the team works together
•Relationships and team communication
•Salary and benefits concerns
•Job opportunities elsewhere
Software Safety & Hazard Analysis
•Helps find and fix problems early that could cause system failures.
By identifying risks early, we can design safer software from the
start.
26
• RMMM Plan (Risk Mitigation, Monitoring, and Management)
• The RMMM Plan is a part of the software project plan that helps
manage risks.
• It includes:
• Risk Mitigation – Steps to reduce or avoid risks
• Risk Monitoring – Watching for signs of risks
• Risk Management – Having backup plans if risks happen.
Risk Information Sheet (RIS):
• A document that lists and tracks risks
• Often stored in a database for easy updates, searching, and prioritizing
27
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 (see next slide)
(More on next slide) 29
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
30
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
(More on next slide)
31
Background (continued)
• Software safety and hazard analysis
– 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
32
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
33
Seven Principles of Risk
Maintain a global
Management
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 Modify identified risks as more becomes known and add new risks as better
risk management 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 Pool the skills and experience of all stakeholders when conducting risk34
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
35
