UNIT V 5.1. RISK MANAGEMENT • • • Risk is an undesired event or circumstance that occur while a project is underway It is essential that the risks taken be the "right risks" It is necessary for the project manager to anticipate and identify different risks that a project may be susceptible to. • Risk Management aims at reducing the impact of all kinds of risk that may affect a project by identifying, analyzing and managing them Reactive vs Proactive Risk Strategies • Reactive Risks: project team reacts to risks when they occur. The team flies into action in an attempt to correct the problem rapidly. • This is often called a fire fighting mode. When this fails, “crisis management” takes over and the project is in real jeopardy. Proactive Risks • Potential risks are identified, their probability and impact are assessed, and they are ranked by importance. • It is more intelligent strategy for risk management is to be proactive • It begins long before technical work is initiated • The software team establishes a plan for managing risk. • The primary objective is to avoid risk, but because not all risks can be avoided, the team works to develop a contingency plan that will enable it to respond in a controlled and effective manner. 5.1.1. Software Risks • Risk always involves two characteristics Uncertainty the risk may or may not happen; Loss if the 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 • The type of risks that we likely encounter as software is built? • Project risk: Threaten the project plan and affect schedule and resultant cost • Technical risk: Threaten the quality and timeliness of software to be produced • Business risk: Threaten the viability of software to be built • Known risk: These risks can be recovered from careful evaluation • Predictable risk: Risks are identified by past project experience • Unpredictable risk: Risks that occur and may be difficult to identify 5.1.2. Risk Identification • Risk identification is a systematic attempt to specify threats to the project plan (estimates, schedule, resource loading, etc.). • By identifying known and predictable risks, the project manager takes a first step toward avoiding them when possible and controlling them when necessary.
• Two distinct types of risks for each category of risks specified above Generic risks are a potential threat to every software project. Product-specific risks can be identified only by those with a clear understanding of the technology, the people, and the environment that is specific to the project at hand. • One method for identifying 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 generic subcategories: o Product size risks associated with the overall size of the software to be built or modified. o Business impact risks associated with constraints imposed by management or the marketplace. o Customer characteristics risks associated with the sophistication of the customer and the developer's ability to communicate with the customer in a timely manner. o Process definition risks associated with the degree to which the software process has been defined o Development environment risks associated with the availability and quality of the tools to be used to build the product. o 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. o Staff size and experience risks associated with the overall technical and project experience of the software engineers who will do the work. • Risk item check list can be organized in different ways • Questions relevant each topics can be answered • The answers can be used to estimate impact of risk • Different risk item checklist lists characteristics relevant to each generic subcategory • Finally, set of "risk components and drivers are listed • Short list of questions can be used to provide a preliminary indication of whether a project is "at risk" 18.104.22.168. Assessing overall Project Risk • The following questions are derived from risk data obtained by surveying experienced software project managers in different parts of the world • The questions are ordered by their relative importance to the success of a project 1. Have top software and customer managers formally committed to support the project? 2. Are end-users enthusiastically committed to the project and the system/product to be built? 3. Are requirements fully understood by the software engineering team and their customers? 4. Have customers been involved fully in the definition of requirements? 5. Do end-users have realistic expectations? 6. Is project scope stable? 7. Does the software engineering team have the right mix of skills? 8. Are project requirements stable?
9. Does the project team have experience with the technology to be implemented? 10. Is the number of people on the project team adequate to do the job? 11. Do all customer/user constituencies agree on the importance of the project and on the requirements for the system/product to be built? • If any of these questions is answered negatively, it indicates the degree to which the project is at risk is directly proportional to the number of negative responses to these questions 22.214.171.124. Risk Components and Drivers • The project manager need to identify the risk drivers that affect software risk components - performance, cost, support and schedule • In the context, the risk components are defined in the following manner. • 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 resultant software will be easy to correct, adapt, and enhance. • Schedule risk—the degree of uncertainty that the project schedule will be maintained and that 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. • Ref. to fig., a characterization of the potential consequences of errors(rows labeled 1) or a failure to achieve a desired outcome (rows labeled 2) are described • The impact of category is chosen based on the characterization that best fits the description in the table 1. The potential consequence of undetected software errors or failures 2. The potential consequence if the desired outcome is not achieved 5.1.3. Risk Projection • It estimates the impact of risk on the project and the product • Risk projection, also called risk estimation, attempts to rate each risk in two ways o the likelihood or probability that the risk is real o the consequences of the problems associated with the risk, should it occur. • The project planner, along with other managers and technical staff, performs four risk projection activities • establish a scale that reflects the perceived likelihood of a risk • delineate the consequences of the risk • estimate the impact of the risk on the project and the product, • note the overall accuracy of the risk projection so that there will be no misunderstandings • These steps lead to prioritization
• By prioritizing risks, the team can allocate resources where they will have the most impact 126.96.36.199. Developing a Risk Table • A risk table provides a project manager with a simple technique for risk projection • Impact values Catastrophic-1 Critical-2 Marginal-3 Negligible-4 • • • • • • • • • • • • • A project team begins by listing all risks 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) The probability of occurrence of each risk is entered in the next column of the table. The probability value for each risk can be estimated by team members individually. Next, the impact of each risk is assessed. 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 lowprobability risks drop to the bottom. This accomplishes first-order risk prioritization. The project manager studies the resultant sorted table and defines a cutoff line. The cutoff line (drawn horizontally at some point in the table) implies that only risks that lie above the line will be given further attention. Risks that fall below the line are re-evaluated to accomplish second-order prioritization. Referring to Figure 6.3, risk impact and probability have a distinct influence on management concern.