Risk projection, also called risk estimation, attempts to rate each risk in two ways—(1) the likelihood or probability that the risk is real and will occur and (2) the consequences of the problems associated with the risk, should it occur. You work along with other managers and technical staff to perform four risk projec- tion steps: 1. Establish a scale that reflects the perceived likelihood of a risk. 2. Delineate the consequences of the risk.Marginal Failure to meet the requirement would result in mission failure Failure resulis in increased costs and schedule valves in excess ee jo meet the requirement eons system performance to 0 ae nite success Is questional in technical oles | Sarecaae modifications Failure to meet the Seer veld resin in degradation of secanda Failure resus in operational delays and/or increased coats with expected rt | Yale of $100k w $500k Some shortage of = inlOC financial resources, possible overruns, Cast, impocs, and/or recoverable schedule slips with expected val of $1K to $100K Failure to mee! the requirement read | bl inconveniance oF nonoperctionol oa technical Pree is gl Se ey inp pected va of less thon $1K _— “ ee = Note: [1] The potential consequence of undetected sofiwore errors or Fouls. a The potential consequence if the desired outcome is not achieved.3, Estimate the impact of the risk on the project and the product. 4. Assess the overall accuracy of the risk projection so that there will be no misunderstandings. The intent of these steps is to consider risks in a manner that leads to priori- tization. No software team has the resources to address every possible risk with the same degree of rigor. By prioritizing risks, you can allocate resources where they will have the most impact.35.4.1 Developing a Risk Table Arisk table provides you with a simple technique for risk projection? A sample risk table is illustrated in Figure 35.2.Size estimate may be significantly low Larger number of users thon planned Less reuse thon planned End users resist system Delivery deadline will be tightened 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 a z = Impoct values: |—catastrophic 2—critical 3—marginal 4—negligibleYou begin 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 ref- erenced in Section 35.3. Each risk is categorized in the second column (e.g., PS implies a project size risk, BU implies a business risk). The probability of occur- rence 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. One way to accomplish this is to poll individual team members in round-robin fashion until their collective assessment of risk probability begins to converge.reevaluated to accomplish second-order prioritization. Referring to Figure 35.3, risk impact and probability have a distinct influence on management concern. A risk factor that has a high impact but a very low probability of occurrence should not absorb a significant amount of management time. However, high-impact risks with moderate to high probability and low-impact risks with high probabil- ity should be carried forward into the risk analysis steps that follow.35.4.2 Assessing Risk Impact Three factors affect the consequences that are likely if a risk does occur: its na- ture, its scope, and its timing. The nature of the risk indicates the problems that are likely if it occurs. For example, a poorly defined external interface to cus- tomer hardware (a technical risk) will preclude early design and testing and will likely lead to system integration problems late in a project. The scope of a risk combines the severity (just how serious is it?) with its overall distribution (howmuch of the project will be affected or how many stakeholders are harmed?). Fi- nally, the timing of a risk considers when and for how long the impact will be felt. In most cases, you want the “bad news” to occur as soon as possible, but in some cases, the longer the delay, the better.RE=PxC where P is the probability of occurrence for a risk, and C is the cost to the project should the risk occur, For example, assume that the software team defines a project risk tn the fol- lowing manner: Risk identification. Only 70 percent of the software components sched- uled for reuse will, in fact, be integrated into the application. The remain- ing functionality will have to be custom developed. Risk probability. Eighty percent (likely). Risk impact. Sixty reusable software components were planned. If only 70 percent can be used, 18 components would have to be developed from scratch (in addition to other custom software that has been scheduled for development). Since the average component is 100 LOC and local data indicate that the software engineering cost for each LOC is $14.00, the overall cost (impact) to develop the components wauld be 18 x 100 x 14 = $25,200. Risk exposure. RE = 0.80 x 25,200 - $20,200.