2. CONTENTS
•
•
•
•
•
•
What is a risk?
What is risk management?
Principles for managing risk?
Types of software risk?
Risk Analysis
How to control risk in project
2
3. What is RISK
•
•
•
•
Risk is the probability of suffering loss (an uncertainty)
Risk exposure = Size (loss) * probability of (loss)
There is difference between problem and risk
Problem is some event which has already occurred but risk is
something that is unpredictable.
• Risk provides opportunity to develop the project better
• Example: developer leaving out from a team which is ongoing
with a project
3
4. RISK MANAGEMENT
• Risk we encounter in a project be reduced so that we
are able to deliver the desired project to customer.
• The project should be managed in such a way that
the risk don’t effect the project in a big way.
• The art of managing the risk effectively so that the
winning situation and friendly situation is established
between team and the customer is called Risk
management
• By using various principles we can manage risk
4
5. PRINCIPLES OF RISK MANAGEMENT
• Global Perspective: In this we look at the larger system
definitions, design and implementation. We look at the
opportunity and the impact the risk is going to have .
• Forward Looking View: Looking at the possible uncertainties
that might creep up. We also think for the possible solutions
for those risks that might occur in the future.
• Open Communication: This is to enable the free flow of
communication between in the customers and the team
members so that they have clarity about the risks.
5
6. PRINCIPLES OF RISK MANAGEMENT contd.
• Integrated management: In this phase risk
management is made an integral part of
project management.
• Continuous process :In this phase the risks are
tracked continuously throughout the risk
management paradigm.
6
7. SOFTWARE RISK
• Project Risks: Threaten the project plan
• Technical Risks: Threaten product quality and the
timeliness of the schedule
• Business Risks: Threaten the viability of the software to
be built (market risks, strategic risks, management
risks, budget risks)
• Known Risks: Predictable from careful evaluation of
current project plan and those extrapolated from past
project experience
• Unknown Risks: Some problems will simply occur
without warning
7
8. RISK ANALYSIS
• Risk identification
• Risk projection-(impact of risks)
• Risk assessment-(what will change if risk
becomes problem)
• Risk management
8
9. RISK IDENTIFICATION
• Product-specific risks
– The project plan and software statement of scope are
examined to identify any special characteristics of the
product that may threaten the project plan
• Generic risks
– are potential threats to every software product
•
•
•
•
product size
customer characteristics
development environment
technology to be built
9
10. RISK PROJECTION
• The risk drivers affecting each risk component
are
– classified according to their impact category
– potential consequences of each undetected
software fault or unachieved project outcome are
described
10
12. RISK ASSESSMENT
• Define referent levels for each project risk that can
cause project termination
–
–
–
–
performance degradation
cost overrun
support difficulty
schedule slippage
• Attempt to develop a relationship between each risk
triple (risk, probability, impact) and each of the
reference levels
12
13. RISK TABLE CONSTRUCTION
• List all risks in the first column of the table
• Classify each risk and enter the category label
in second column
• Determine a probability for each risk and
enter it into column three
• Enter the severity of each risk
(negligible, marginal, critical, catastrophic) in
column four.
13
14. RISK TABLE CONSTRUCTION (contd.)
• Sort the table by probability and impact value
• Determine the criteria for deciding where the
sorted table will be divided into the first
priority concerns and the second priority
concerns
• First priority concerns must be managed (a
fifth column can be added to contain a pointer
into the RMMM document)
14
15. RISK TABLE MODEL
Risks
Category
Probability
Impact
RMMM
PS
80%
2
**
ST
50%
2
**
DE
50%
2
**
DE
35%
3
Components developed separately cannot be integrated
easily, requiring redesign
Development of the wrong software functions requires
redesign and implementation
Development of extra software functions that are not
needed
Strict requirements for compatibility with existing system
require more testing, design, and implementation than
expected
Operation in unfamiliar software environment causes
unforeseen problems
Team members do not work well together
DE
25%
3
DE
25%
3
DE
20%
3
DE
20%
3
EV
25%
4
ST
20%
4
Key personnel are available only part-time
ST
20%
4
Estimated size of project in LOC or FP
Lack of needed specialization increases defects and
reworks
Unfamiliar areas of the product take more time than
expected to design and implement
Does the environment make use of a database
15
18. RISK MANAGEMENT PARADIGM
• Identify: Search for the risks before they create a major problem.
• Analyze: understand the nature , kind of risk and gather information about
the risk.
• Plan: Involves developing actions to address individual risks, prioritizing
• risk actions and creating a Risk Management Plan.
• Track: Monitoring the status of risk.
• Control: Correct the deviation and make any necessary amendments.
• Communicate: Discuss about the emerging risks and the current risks and
the plans to be undertaken.
18
20. CONCLUSION
• To manage the risks we need to establish a strong bond
between the customers and the team members.
• A strong base about risk management would help a great
deal in tackling the risks.
• Software metrics and tools can be developed to manage
the risks.
• Risk necessarily need not be negative and it can be
viewed as an opportunity to develop our projects in a
better way.
20
