Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

PM-5 Risk Management

Download as pptx, pdf, or txt
Download as pptx, pdf, or txt
You are on page 1of 34

Software Project Management

Managing Project Risk

2
Content
 Introduction
 Software Risk
 Project Risk Management Processes
 Identifying Risk
 Performing Qualitative Risk Analysis
 Performing Quantitative Risk Analysis
 Planning Risk Responses
 Monitoring Risks

3
Introduction
 The PMBOK® defines project risk as: an uncertain event or
condition that, if it occurs, has a positive or negative effect on one or
more project objectives such as scope, schedule, cost, and quality
 Anything worth doing has risks. The challenge is not to avoid
them but to manage them.
 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
 It is generally caused due to lack of information, control or
time.
 Risk Management is an attempt to minimize the chances of
failure caused by unplanned events.

4
Software Risk
 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.
 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.
 (2) External risks that are beyond the control of project
manager.
5
Cont’d
 There are basic risks that are generic to almost all
software projects.
 A software project may encounter various types of risks:
 Technical risks
 Include problems with languages, project size, project
functionality, platforms, methods, standards, or processes.
 These risks may result from excessive constraints, lack of
experience, poorly defined parameters, or dependencies on
organizations outside the direct control of the project team.
 Management risks
 Include lack of planning, lack of management experience and
training, communications problems, organizational issues, lack of
authority, and control problems.

6
Cont’d
 Financial risks
 Include cash flow, capital and budgetary issues, and return on
investment constraints.
 Contractual and legal risks
 Include changing requirements, market-driven schedules,
health & safety issues, government regulation, and product
warranty issues.
 Personnel risks
 Include staffing lags, experience and training problems, ethical
and moral issues, staff conflicts, and productivity issues.
 Other resource risks
 Include unavailability or late delivery of equipment and
supplies, inadequate tools, inadequate facilities, distributed
locations, unavailability of computer resources, and slow
response times.
7
Cont’d
 On the other hand, risks can be categorized as:
 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)

 Predictable risks
 Those risks that are extrapolated from past project experience (e.g.,
past turnover)

 Unpredictable risks
 Those risks that can and do occur, but are extremely difficult to
identify in advance

8
Known and Predictable Risks

1-Product size risks associated with overall size of the software to be built

2-Business risks associated with constraints imposed by management or the


impact marketplace

3-Customer risks associated with sophistication of the customer and the developer's
characteristics ability to communicate with the customer in a timely manner

4-Process risks associated with the degree to which the software process has been
definition defined and is followed

5-Development risks associated with availability and quality of the tools to be used to build
environment the project

6-Technology to risks associated with complexity of the system to be built and the "newness"
be built of the technology in the system

7-Staff size and risks associated with overall technical and project experience of the software
experience engineers who will do the work
9
Reasons for Implementing
Software Risk Management
 With risk management the “emphasis is shifted from crisis
management to anticipatory management”.
 Boehm defines four major reasons for implementing SRM
1. Avoiding software project disasters
 Including run away budgets and schedules, defect-ridden software
products, and operational failures.
2. Avoiding rework caused by erroneous, missing, or ambiguous
requirements, design or code,
 Which typically consume 40-50% of the total cost of software
development.
3. Avoiding overkill with detection and prevention techniques in area
of minimal or no risk.
4. Stimulating a win-win software solution where the customer
receives the product they need and the vendor makes the profits
they expect .

10
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.
 Primary objective is to avoid risk and to have a
contingency plan in place to handle unavoidable
risks in a controlled and effective manner.

11
Project risk management processes
 Planning risk management: deciding how to approach and plan the
risk management activities for the project
 Identifying risks: determining which risks are likely to affect a project
and documenting the characteristics of each
 Performing qualitative risk analysis: prioritizing risks based on their
probability and impact of occurrence
 Performing quantitative risk analysis: numerically estimating the
effects of risks on project objectives
 Planning risk responses: taking steps to enhance opportunities and
reduce threats to meeting project objectives
 Implementing risk responses: implementing the risk response plans
 Monitoring risk: monitoring identified and residual risks, identifying
new risks, carrying out risk response plans, and evaluating the
effectiveness of risk strategies throughout the life of the project
12
Planning Risk Management
 Main output of this process is a risk management plan
 Documents the procedures for managing risk throughout a
project
 The project team should review project documents as
well as corporate risk management policies, risk
categories, lessons-learned reports from past
projects, and templates for creating a risk
management plan
 It is also important to review the risk tolerances of various
stakeholders

13
Risk Identification
 Risk identification deals with identifying and creating a
list of threats and opportunities that may impact the
project’s goal and/or objectives.
 The output of this step is a list of project-specific
risks that have the potential of compromising the
project's success.
 There are many techniques for identifying risks,
including interviewing, reporting, decomposition,
assumption analysis, critical path analysis, and
utilization of risk taxonomies.

14
Risk Identification Techniques
 Interviewing/Brainstorming:
 with project personnel, customers, and vendors.
 Open-ended questions such as the following can help identify
potential areas of risk.
 What new or improved technologies does this project implement?
 What interfaces issues still need to be defined?
 What requirements exist that we aren’t sure how to implement?

 Voluntary Reporting:
 where any individual who identifies a risk is encouraged and
rewarded for bringing that risk to management’s attention.
 Risk Taxonomies:
 Risk taxonomies are lists of problems that have occurred on
other projects and can be used as checklists to help ensure all
potential risks.

15
Cont’d
 Critical Path Analysis:
 As we perform critical path analysis for our project plan, we
must remain on the alert to identify risks.
 Any possibility of schedule slippage on the critical path must
be considered a risk because it directly impacts our ability to
meet schedule.
 Assumption Analysis:
 Process and product assumptions must be analyzed.
 For example, we might assume the hardware would be
available by the system test date or three additional
experienced C++ programmers will be hired by the time
coding starts. If these assumptions prove to be false, we could
have major problem.
 Risk break down structure
 Use some form of risk break down structure
16
Cont’d

Risk break down structure

17
Cont’d
 Boehm's Top 10 Software Risks
1. Schedules, budgets, process
2. Requirements Changes
3. Personnel Shortfalls
4. Requirements Mismatch
5. Rapid change
6. Architecture, performance, quality, distribution/mobility
7. External components
7. Legacy Software
9. Externally-performed tasks
10. User interface mismatch

18
Risk Register
 A risk register is a tool for documenting potential risk events and
related information.
 Risk register contents
 Identification number for each risk event
 Rank for each risk event
 The name of the risk event. E.g. defective server, late completion of
testing, reduced consulting costs
 Description – short description of the risk
 Category under which each risk event falls
 The root cause of the risk. E.g. The root cause of the defective server
might be a defective power supply.
 Triggers for each risk; indicators or symptoms of actual risk events. For
example, cost overruns on early activities may be symptoms of poor cost
estimates.
 Potential responses to each risk: A potential response to the defective
server might be to include a clause in the supplier’s contract to replace
the server within a certain time period at a negotiated cost.
 Risk owner or person who will own or take responsibility for each risk
19
Risk Register(cont’d)
 Probability and impact of each risk occurring. Impact – (4)
catastrophic (3) critical (2) marginal (1) negligible
 The impact to the project if the risk occurs: There might be a high,
medium, or low impact to project success if the risk event actually
occurs.
 Status of each risk: Did the risk event occur? Was the response
strategy completed? Is the risk no longer relevant to the project? For
example, a contract clause may have been completed to address the
risk of a defective server.
No. Rank Risk Description Category Root Cause Triggers Potential Risk Owner Probability Impact Status
Responses

R44 1

R21 2

R7 3

Sample risk register

20
Risk Analysis
 Once the project risks have been identified and their
causes and effects understood, the next step requires that
we analyze these risks.
 Answers to two basic questions are required:
 What is the likelihood of a particular risk occurring?
 What is the impact on the project if it does occur?
 Assessing these risks helps the project manager and other
stakeholders prioritize and formulate responses to those
risks that provide the greatest threat or opportunity to the
project.
 Because there is a cost associated with responding to a
particular risk, risk management must function within the
constraints of the project’s available resources.

21
Performing Qualitative Risk Analysis
 Assess the likelihood and impact of identified risks to
determine their magnitude and priority
 Risk quantification tools and techniques
 Probability/impact matrixes
 The Top Ten Risk Item Tracking
 Expert judgment

22
Probability/impact matrixes
 Lists relative probability of a risk occurring on one side of a
matrix or axis on a chart and the relative impact of the risk
occurring
 List the risks and then label each one as high, medium, or low in
terms of its probability of occurrence and its impact if it did occur
 Calculates risk factors
 Simplest approach: multiplying a numeric score for probability by a
numeric score for impact
 Sophisticated approach: calculate risk factors
 Numbers that represent the overall risk of specific events based on their
probability of occurring and the consequences to the project if they do
occur
 Can be estimated based on several factors.
 E.g. Factors evaluated for potential hardware or software technology risks could
include the technology not being mature, the technology being too complex, and
an inadequate support base for developing the technology. The impact of a risk
occurring could include factors such as the consequences of not meeting
performance, cost, and schedule estimates.

23
Probability/impact matrixes(cont’d)

Sample probability/impact matrix

24
Performing Quantitative Risk Analysis
 Often follows qualitative risk analysis, but both can be
done together
 The nature of the project and availability of time and
money affect which risk analysis techniques are used
 Large, complex projects involving leading edge
technologies often require extensive quantitative risk
analysis
 Main techniques
 Decision tree analysis
 Sensitivity analysis
 Simulation

25
Decision Trees and Expected
Monetary Value
 A decision tree is a diagramming analysis technique
used to help select the best course of action in
situations in which future outcomes are uncertain
 Expected monetary value (EMV) is the product of a risk event
probability and the risk event’s monetary value
 You can draw a decision tree to help find the EMV

26
Sensitivity Analysis
 Used to show the effects of changing one or more variables on an outcome
 Many people use this approach to determine what the monthly payments for a
loan will be given different interest rates or periods of the loan
 Spreadsheet software, such as Microsoft Excel, is a common tool for
performing sensitivity analysis

Sensitivity analysis
models to estimate
profits by varying
manufacturing cost
per unit or by varying
sales price per unit

27
Planning Risk Responses
 After identifying and quantifying risks, the organization must
decide how to respond to them
 Basic response strategies for negative risks
 Risk avoidance - eliminating a specific threat, usually by eliminating its
causes.
 Risk acceptance - accepting the consequences if a risk occurs. E.g. a
project team planning a big project review meeting could take an active
approach to risk by having a contingency or backup plan and contingency
reserves if the team cannot get approval for a specific meeting site. On the
other hand, the team could take a passive approach and accept whatever
facility the organization provides.
 Risk transference - shifting the consequence of a risk and responsibility
for its management to a third party.
 Risk mitigation - reducing the impact of a risk event by reducing the
probability of its occurrence. E.g. using proven technology, having
competent project personnel, using various analysis and validation
techniques, and buying maintenance or service agreements from
subcontractors

28
Planning Risk Responses(cont’d)
 Basic response strategies for positive risks
 Risk exploitation - doing whatever you can to make sure the
positive risk happens
 Risk sharing - allocating ownership of the risk to another party
 Risk enhancement
 Risk acceptance

29
Planning Risk Responses(cont’d)

Technical Risks Cost Risks Schedule Risks


Emphasize team support Increase the frequency of Increase the frequency of
and avoid stand-alone project monitoring project monitoring
project structure
Increase project manager Use WBS and CPM Use WBS and CPM
authority
Improve problem handling Improve communication, Select the most
and communication understanding of project experienced
goals, and team support project manager
Increase the frequency of Increase project manager
project monitoring authority
Use WBS and CPM

General risk mitigation strategies for technical, cost, and schedule risks

30
Monitoring Risks
 Involves ensuring the appropriate risk responses are
performed, tracking identified risks, identifying and
analyzing new risk, and evaluating effectiveness of
risk management throughout the entire project
 Project risk management does not stop with the initial risk
analysis
 Carrying out individual risk management plans
involves monitoring risks based on defined milestones
and making decisions regarding risks and their
response strategies
 Project teams sometimes use workarounds—unplanned
responses to risk events—when they do not have contingency
plans in place

31
Software Risk Management Plan Template
 Introduction
 Objective
 Definition, acronyms, and abbreviations
 Risk Identification
 Identify and record the risks. Example:
 Risk type: “Shortfalls in personnel”.
 Description: - Key staffs may be unavailable at critical times.
- Lack of experience with C# programming language
 ….

 Risk Analysis and Prioritization


 Specify the probability of occurrence of the risk and the
interpretation(E.g. 1-10- Very unlikely to occur; 91-100: Very likely to
occur)
 Then, determine the impact of the risk. You might categorize the risk in
to five: critical(5), serious(4), moderate(3), minor(2), and negligible(1).
 Finally, calculate the risk exposure(Probability * Impact) and prioritize
based on the result obtained
32
Software Risk Management Plan
Template(cont’d)
 Risk Control
 Resolution/Response
 Specify risk strategy(Reduction, avoidance, etc.) and means to
resolve the identified risk(E.g. for “shortfalls in personnel” risk the
resolution might be “role distributing among team members”)
 Monitoring

33
Assignment
 Prepare risk management plan (RMP)

34

You might also like