MCTs Rajiv Gandhi Institute of Technology

Department of Information Technology

Chapter 6: Risk Analysis and Management Introduction According to Robert Charette risk can be defined as follows: 1. Risk concerns future happenings. 2. Risk involves change, such as change of mind, opinion, actions or places. 3. Risk involves choice, and the uncertainty that choice itself entails. Risk strategies: 1. Reactive risk strategy: a. Software team does nothing about risks until something goes wrong. b. At best, monitors the projects for likely risks. 2. Proactive Risk strategy: a. Begins long before technical work is initiated. b. Identification of potential risks (studies of probability, impact and priorities) c. Objective: AVOID RISK
Although there has been considerable debate about the proper definition of software risk, there is general agreement that risk always involves two characteristics: Uncertainty - The risk may or may not happen. There are no 100% probable risks. Loss - If a 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 of risk are considered. i) Project risks threaten the project plan. If project risks become real, it is likely that the project schedule will slip and that costs will increase. Project risks identify budgetary, schedule, personnel, resource, customer and requirement related problems and their impact on a software project. ii) Technical risk threatens the quality of the software to be produced. If a technical risk becomes a reality, implementation may become difficult or impossible. Technical risks identify design, implementation, interface, verification and maintenance problems. iii) Business risks threaten the viability of the software to be built. Business risk often jeopardizes the project or the product. The most common business risks include: a) Building a product that no one wants (market risk) b) Building a product that no longer fits into the overall business strategy for the company (strategic risk) c) Building a product that the sales force doesnt know how to sell d) Losing the support of management because of a change in focus or change in people (management risk) e) Losing budgetary or personnel commitment (budget risk)

Another general categorization, based on the nature of predictability, is as follows:

i) Known risks: Risks that can be uncovered after a careful evaluation of the project plan, business and technical environment in which the project is being developed and other reliable information sources. For example, unrealistic delivery dates, lack of documented requirements, poor development environment, etc. ii) Predictable risks: These are risks that are derived from past experience. For example, staff turnover, poor communication with the customer, etc.

Created by Prof. Nilesh Patil

-1-

MCTs Rajiv Gandhi Institute of Technology

Department of Information Technology

iii) Unpredictable risks: These are risks that can and do occur, but are extremely difficult to identify in advance.

4.2 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 towards avoiding them when possible and controlling them when necessary. There are two distinct types of risks: i) Generic risks: These are a potential threat to every software project. ii) Product-specific risks: These can be identified only by a clear understanding of the technology, the people and the environment that are specific to the project at hand. One method to identify 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 general categories: Product size: Risks associated with the overall size of the software to be built or modified. Business impact: Risks associated with constraints imposed by the management or the market. Customer characteristics: Risks associated with the sophistication of the customer and the developers 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. Development environment: Risks associated with the availability and the quality of the tools used to build the product. Technology: 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. The risk item checklist can be organized in different ways. Questions relevant to each of the topics can be answered for each software project. The answers to these questions allow the planner to estimate the impact of risk. A different risk item checklist format simply lists characteristics that are relevant to each general subcategory. Finally, a set of risk components and drivers are listed along with their probability of occurrence. Risk components are defined in the following manner: Performance risk - The degree of uncertainty that the product will meet its requirement 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 the product will be delivered on time. The impact of each risk driver on the risk component is divided into one of four impact categories: negligible, marginal, critical or catastrophic.

Created by Prof. Nilesh Patil

-2-

MCTs Rajiv Gandhi Institute of Technology

Department of Information Technology

CATASTR P IC OH

CR ITICAL

S ignificant N onresponsive or degradation to 2 nonachievem of ent unsupportable technical perform ance software F ailure to m the requirem eet ents would ance to a point 1 degrade systemperform where m isssion success is questionable S e reduction in om M inor delays in 2 technical software perform ance m odifications F ailure to m the requirem eet ents would 1 result in degradation of secondary m isssion M al to sm inim all R esponsive reduction in 2 technical perform ance software support F ailure to m the requirem eet ents would 1 create inconvenience or nonoperational im pact N reduction in o 2 technical perform ance

S ignificant financial shortages, budget

U nachievable

overrun likely delivery date F ailure results in operational delays and/or increased costs with expected values of $100k to $500k S e shortage of om P ossible slippage financial resources, in delivery date possible overruns C ost, im pacts, and/or recoverable schedule slips with expected value of $1 to $100K S ufficient financial R ealistic, achievable resources schedule E rror in m inor cost and/or schedule im pact with expected value of less than $1k P ossible budget underrun E arly achievable delivery date

MAR IN G AL

N G IB E LIG LE

E asily supportable software

Figure 6.1: Risk Impacts.

4.3 Risk projection

Risk projection, also called risk estimation, attempts to rate each risk in two ways - the likelihood or probability that the risk is real and the consequences of the problem associated with the risk. The project planner, along with other managers and technical staff, performs four risk projection activities: i) Establish a scale that reflects the perceived probability of a risk ii) Delineate the consequences of the risk iii) Estimate the impact of the risk on the project and the product iv) Note the overall accuracy of the risk projection so that there will be no misunderstandings.

4.3.1 Risk table

A risk table provides a project manager with a simple technique for risk projection. A project team begins by listing all risks (no matter how remote) in the first column of the table. This can be accomplished with the help of the risk item checklists. Each risk is categorized in the second column (e.g., PS implies a project size risk, BU implies a business risk). Team members can estimate the probability of occurrence of each risk individually. Individual team members are polled in round-robin fashion until their assessment of risk probability begins to converge. Next, the impact of each risk is assessed. Each risk component is assessed and an impact category is determined. The categories for each of the four risk components - performance, support, cost and schedule are averaged to determine an overall impact value.

Created by Prof. Nilesh Patil

-3-

MCTs Rajiv Gandhi Institute of Technology

Department of Information Technology

Once the first four columns of the risk table have been completed, the table is sorted by probability and by impact. 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.

Figure 6.3 Risk and Management Concern. The project manager studies the resultant sorted table and defines a cut-off line. The cut-off line will be given further attention. Risks that fall below the line are re-evaluated to accomplish second order prioritization. A risk factor that has a high impact but a very low probability of occurrence should not absorb 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. All risks that lie above the cut-off line must be managed. Making individual estimates and then developing a single consensus value can determine risk probability. Although that approach is workable, more sophisticated techniques for determining risk probability have been developed. Risk drivers can be assessed on a qualitative probability scale that has the following values: impossible, improbable, probable and frequent. Mathematical probability can then be associated with each qualitative value. For example, a probability of 0.7 to 1.0 implies a highly probable risk.

Created by Prof. Nilesh Patil

-4-

MCTs Rajiv Gandhi Institute of Technology

Department of Information Technology

Figure 6.2: Sample risk table prior to sorting

Impact values: 1 . catastrophic 2 . critical 3 . marginal 4 . negligible 4.3.2 Assessing risk impact
Three factors affect the consequences that are likely if a risk does occur: i) Nature of risk: This indicates the problems that are likely if the risk occurs. ii) Scope: This combines the severity of the risk with its overall distribution. iii) Timing: This determines when the impact of the risk will be felt and for how long. The overall risk exposure RE is determined using the following relationship: RE = P X C -------------------Eqn. (4.1) where P is the probability that the risk will occur and C is the cost to the project should the risk occur.

4.4 Risk assessment

At this point in the risk management process, we have established a set of triplets of the form: [ri, ii, xi] where ri is the risk, ii is the probability of the risk, and xi is the impact of the risk. During risk assessment, we further examine the accuracy of the estimates that were made during risk projection, attempt to rank the risks that have been uncovered, and begin thinking about ways to control and /or avert risks that are likely to occur.

Created by Prof. Nilesh Patil

-5-

MCTs Rajiv Gandhi Institute of Technology

Department of Information Technology

For assessment to be useful, a risk referent level must be defined. For most software projects, the risk component discussed earlier : performance, cost, support and schedule also represent risk referent levels. That is, there is a level for performance degradation, cost overrun, support difficulty, or schedule slippage (or any combination of the four) that will cause the project to be terminated. If a combination of the problems cause one or more of these reference levels to be exceeded, work will stop. In the context of software risk analysis, a risk referent level has a single point, called the reference point or break point, at which the decision to proceed with the project or terminate it, are equally weighed. Figure 4.2 represents this situation graphically. In reality, the referent level can be rarely be represented as a smooth line on a graph. In most cases it is a region in which there are areas of uncertainty; that is, attempting to predict a management decision based on the combination of referent values is often impossible. Therefore, during risk assessment, we perform the following steps: Define the risk referent levels for the project Attempt to develop a relationship between ri , ii, xi and each of the referent levels Predict the set of referent points that define a region of termination, bounded by a curve or areas of uncertainty Try to predict how compound combinations of risks will affect a referent level

4.5 Risk mitigation, monitoring and management (RMMM)

All the risk analysis activities presented to this point have a single goal - to assist the project team in developing a strategy for dealing with the risk. An effective strategy must consider three issues: Risk avoidance Risk monitoring Risk management and contingency planning If a software team adopts a 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 is noted as a project risk, ri. Based on past history and management intuition, the likelihood, ii, of

Created by Prof. Nilesh Patil

-6-

MCTs Rajiv Gandhi Institute of Technology

Department of Information Technology

high turnover is estimated to be 0.7 (70%, rather high) and the impact, xi, is projected at level 2 . That is, high turnover will have a critical impact on project cost and schedule. To mitigate this risk, project management must develop a strategy for reducing turnover. Among the possible steps to be taken are: i) Meet with current staff to determine causes for turnover. (e.g. poor working conditions, low pay, competitive job market, etc.) ii) Mitigate those causes that are under our control before the project starts. iii) Once the project commences, assume turnover will occur and develop techniques to ensure continuity when people leave. iv) Organize project teams so that information about each development activity is widely dispersed. v) Define documentation standards and establish mechanisms to be sure that documents are developed in a timely manner. vi) Conduct peer reviews of all work so that more than one person is up to speed. vii) 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 case of high staff turnover, the following factors can be monitored: General attitude of team members based on project pressures. The degree to which the team has jelled. Interpersonal relationships among team members. Potential problems with compensation and benefits. The availability of jobs within the company and outside it. In addition to monitoring these factors, the project manager should monitor the effectiveness of risk mitigation steps. For example, risk mitigation steps are mechanisms to be sure that documents are developed in a timely manner. This is one mechanism for ensuring continuity, should a critical individual leave the project. The project manager should monitor documents carefully to ensure that each can stand on its own and that each imparts information that would be necessary if a newcomer were forced to join the software team somewhere in the middle of the project. Risk management and contingency planning assumes that mitigation efforts have failed and that the risk has become a reality. Continuing the example, 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. It is important to note that RMMM steps incur additional project cost. For example, spending time to backup every critical technologist costs money. Part of risk management, therefore, is to evaluate when the benefits accrued by the RMMM steps are outweighed by the costs associated with implementing them. In essence, the project planner performs a classic cost benefit analysis. If risk aversion steps for high turnover will increase both project cost and duration by an estimated 15 percent, but this predominant cost factor is backup, management may decide not to

Created by Prof. Nilesh Patil

-7-

MCTs Rajiv Gandhi Institute of Technology

Department of Information Technology

implement this step. On the other hand, if the risk aversion steps are projected to increase costs by 5 percent and duration by only 3 percent management will likely implement it all. For a large project, 30 to 40 days of risk may be identified. If between three and seven risk management steps are identified for each, risk management may become a project in itself.

Created by Prof. Nilesh Patil

-8-