Risk Management

Introduction Risk Identification Risk Projection Risk Mitigation, Monitoring, and Management Safety Risks and Hazards The RMMM plan SEI Technical Reviews Summary
Chapter 6 ± Risk Management 1

Introduction
Risk management is a process that is used extensively for various purposes Recall earlier questions raised about safety, costs, etc. According to ³Webster¶s Seventh New Collegiate Dictionary´, risk is defined as a: ³possibility of loss or injury´ ³the chance of loss or the perils to the subject matter of an insurance contract´ and ³the degree of probability of such loss.´(1)

Chapter 6 ± Risk Management

2

Introduction
Robert Charette(2) presented the following conceptual definitions of risk: Risk concerns future happenings Risk involves change, such as changes of mind, opinion, action or places Risk involves choice, and the uncertainty that choice itself entails Risk Characteristics : uncertainty: may or may not happen loss: unwanted consequences
Chapter 6 ± Risk Management 3

Introduction
Management is ³the act or art of managing´ and ³judicious use of means to accomplish an end´(1) RISK MANAGEMENT can be defined as: ³A logical process for identifying and analyzing leading to appropriate methods for handling and monitoring exposures to loss´(3) Risk management deals with: Systematic identification of an exposure to the risk of loss, & Making decisions on the best methods for handling these exposures to minimize losses
Chapter 6 ± Risk Management 4

Introduction
Risk Strategies
Reactive Software team does nothing about risks until something goes wrong ³fire fighting mode´ Proactive Begins long before technical work is initiated Identification of potential risks (studies of probability, impact and priorities) Objective: AVOID RISK Responds are in a controlled and effective manner
Our Concern
5

At best, monitors the projects for likely risks

Chapter 6 ± Risk Management

Introduction
‡ Project Risks (budgetary, schedule, personnel, resource, customer) ‡ Technical Risks (design, implementation, interfacing, verification) ‡ Business Risks (market, strategic, management,budget) Software Risk Charette: (2) ‡ Known risks ‡ Predictable ‡ Unpredictable
Chapter 6 ± Risk Management

6

Risk Identification
Risk identification is a systematic attempt to specify threats to the project plan
Identify known and predictable risks

Generic

Product-specific
Product size Business impact Customer characteristics Process definition Development environment Technology to be built Staff size and experience
What characteristics of this product may threaten our project plan?

Risk Item List
Chapter 6 ± Risk Management 7

Risk Identification
Product Size Risk : Estimated size of the product in LOC or FP? Percentage deviation in size of product from average for previous products? Number of users/projected changes to the requirements for the product? Amount of reused software? Business Impact risks: Effect of this product on the company revenue? Visibility of this product to senior management? Amount & quality of product documentation to be produced? Governmental constraints on the construction of the product?
Chapter 6 ± Risk Management 8

Risk Identification
Customer related risks: (needs, personalities, contradictions , associations) Have you worked with the customer in the past? Does the customer have a solid idea of what is required? Will the customer agree to have meetings? Is the customer technically sophisticated in the product area? Does the customer understand the software process? Technology Risks: Is the technology to be built new to your organization? Does the SW interface with new or unproven HW/SW? Do requirements demand creation of new components ? Do requirements impose excessive performance constraints ?
Chapter 6 ± Risk Management 9

Risk Identification
Process Risks : (4) Does senior management support a written policy statement that emphasizes a standard process for software development ? Is there a written description of the software process to be used? Process Is the software process used for other projects ? Issues: Is configuration management used to maintain consistency among system/software requirements, design, code and test? Is a procedure followed for tracking subcontractor performance? Are facilitated application specification techniques used to aid in communication between the customer and developer ? TechAre specific methods used for software analysis? nical Do you use specific method for data and architectural design? Issues: Are software tools used to support the software analysis and design? Are tools used to create software prototypes? Are quality/productivity metrics collected for all software projects?
Chapter 6 ± Risk Management 10

Risk Identification
Development Environment Risks: Is a software project/process management tool available? Are tools for analysis and design available?? Are testing tools available and appropriate for the product? Are all SW tools integrated with one another? Have members of the project team received training in each of the tools? Risk Associated with Staff Size and Experience: Are the best people available? Do the people have the right combination of skills? Are staff committed for entire duration of the project? Do staff have the right expectations about the job at hand? Will turnover among staff be low enough to allow continuity?
Chapter 6 ± Risk Management 11

Risk Identification
Risk Components and Drivers (U.S. Air Force guidelines) 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 software will be easy to correct, adapt, and enhance Schedule risk: the degree of uncertainty that the project schedule will be maintained

Chapter 6 ± Risk Management

12

Risk Identification
COMPONENTS PERFORMANCE CATEGORY
Failure to meet the requirements would 1 CATASTROPHIC result in mission failure Si g n i fi ca n t Non r e s p on s i ve or de g r a da t i on t o un s up p or t a ble n on a ch i e ve m e n t of t e ch n i ca l p e r for m a n ce s oft wa r e Failu o quirements would Failure results in increased costs and schedule delays with expected values in excesss of $500k Si g n i fi ca n t fi n a n ci a l s h or t a g e s , budg e t ove r r un li k e ly de li ve r y da t e Failure results in operational delays and/or increased costs with expected values of $100k to $500k Som e s h or t a g e of Pos s i ble s li p p a g e i n fi n a n ci a l r e s our ce s , p os s i ble ove r r un s de li ve r y da t e Cost, impacts, and/or recoverable schedule slips with expected value of $1 to $100K Suffi ci e n t fi n a n ci a l R e a li s t i c, Un a ch i e va ble

SUPPORT

COST

SCHEDULE

1 degrade system performance to a point CRITICAL w ere misssion success is questionable Som e r e duct i on i n M i n or de la ys i n

t e ch n i ca l p e r for m a n ce m odi fi ca t i on s Failure to meet the requirements would 1 result in degradation of secondary MARGINAL misssion M i n i m a l t o s m a ll R e s p on s i ve r e duct i on i n t e ch n i ca l p e r for m a n ce s oft wa r e s up p or t Failure to meet the requirements would

1 create inconvenience or nonoperational NEGLIGIBLE impact No r e duct i on i n t e ch n i ca l p e r for m a n ce

¢¡ ¢¥ £ £¢¢¤ £ ¢¡

¥

       

s oft wa r e

r e s our ce s a ch i e va ble s ch e dule Error in minor cost and/or schedule impact with expected value of less than $1k Pos s i ble budg e t un de r r un Ea r ly a ch i e va ble de li ve r y da t e

Ea s i ly s up p or t a ble s oft wa r e

Chapter 6 ± Risk Management

13

Risk Projection
Also called risk estimation, attempts to rate each risk in two ways: Likelihood (probability) Consequences Develop a risk table: A risk table provides a project manager with a simple technique for risk projection For each identified risk, list likelihood, consequence and impact Risk Assessment: Examine the accuracy of the estimates that were made during risk projection. A risk referent level must be defined and the referent point or break point should be established
Chapter 6 ± Risk Management 14

Risk Projection
Risks
Siz i i ii r r an planned Lar r Less reuse than planned End users resist system Deli ery deadline will be ti htened Funding will be lost Customer will change requirements Technology will not meet expectations Lack of training on tools Staff inexperienced Staff turnover will be high

Category Probability Impact RMMM
S PS PS BU BU CU PS TE DE ST ST

. . .

60% 30% 70% 40% 50% 40% 80% 30% 80% 30% 60%

2 3 2 3 2 1 2 1 2 2 2

Chapter 6 ± Risk Management

15

Risk Matrix
L I k e l I h o o d 5 4 3 2 1 1 2 3 4 Consequences
Chapter 6 ± Risk Management

5
16

Risk Mitigation, Monitoring, and Management
An effective strategy must consider three issues: risk avoidance, risk monitoring, and risk management and contingency planning. A proactive approach to risk avoidance is the best strategy. Develop a plan for risk mitigation. For example: assume that high staff turnover is noted as a project risk r1, some of the possible steps to be taken are these: meet with current staff to determine causes for turnover assume turnover will occur and develop techniques to ensure continuity when people leave. define a backup staff member for every critical technologies.
Chapter 6 ± Risk Management 17

Risk Mitigation, Monitoring, and Management
As the project proceeds, the following factors can be monitored: general attitude of team members based on project pressures, the degree to which the team has jelled, interpersonal relationship among team members, availability of jobs within the company and outside it In addition of these factors, the project manager should monitor the effectiveness of risk mitigation steps. Risk management and contingency planning assumes that mitigation efforts have failed and that the risk has become reality.
Chapter 6 ± Risk Management 18

Safety Risks and Hazards
Software safety and hazard analysis are software quality assurance activities that focus on the identification and assessment of potential hazard that may impact software negatively and cause an entire system to fail. If hazards can be identified early in the software engineering process, software design features can be specified that will either eliminate or control potential hazards.

Chapter 6 ± Risk Management

19

The RMMM plan
1. Introduction 1.1. Scope and Purpose of Document 1.2. Overview of major risks 1.3. Responsibilities 1.3.1. Management 1.3.2. Technical staff 2. Project Risk Table 2.1. Description of all risks above cut-off 2.2. Factors influencing probability and impact
Chapter 6 ± Risk Management

An outline for the Risk Mitigation, Monitoring, and Management plan.

20

The RMMM plan
3. Risk Mitigation, Monitoring, Management
3.n Risk #n (for each risk above cut-off) 3.1.1. Mitigation 3.1.1.1. General strategy 3.1.1.2. Specific steps to mitigate the risk 3.1.2. Monitoring 3.1.2.1. Factors to be monitored 3.1.2.2. Monitoring approach 3.1.3.Management 3.1.3.1. Contingency plan 3.1.3.2. Special considerations 4. RMMM Plan Iteration Schedule 5. Summary
Chapter 6 ± Risk Management

An outline for the Risk Mitigation, Monitoring, and Management plan.

21

SEI Risk Management Paradigm
a) Identify b) Analyze c) Plan d) Track e) Control f) Communicate

Chapter 6 ± Risk Management

22

SEI Software Development Risk

Chapter 6 ± Risk Management

23

SEI Technical Reviews
Software Risk Management Ronald P. Higuera, Yacov Y. Haimes; June 1996 An Introduction To Team Management (Version 1.0) Ronald P. Higuera, David P. Gluch, Richard L. Murphy ; May 1994 Software Development Risk: Opportunity Not Problem Roger L. Van Scoy; September 1992 Taxonomy-Based Risk Identification Marvin J. Carr, Surresh L. Konda, Ira Monarch, F. Carol Ulrich; June 1993
Chapter 6 ± Risk Management 24

www.sei.cmu.edu/products/publications.info.html

Summary
Risk analysis is an important part of most software projects. Risk analysis requires a significant amount of project planning effort. Understanding risk helps you know where to commit your resources. If you don¶t actively attack the risks, they will actively attack you. Major projects should all have a risk management plan..

Chapter 6 ± Risk Management

25