11/29/2012 Risk Analysis 1 Assessing Risk • The potential consequences of not assessing and managing risks can include the following: – Failure to attain expected benefits from the project, – Inaccurate project cost estimates, – Inaccurate project duration estimates, – Failure to achieve adequate system performance levels, and – Failure to adequately integrate the new system with existing hardware, software, or organizational procedures. 2 Chapter 5 1
11/29/2012 Project Risk Factors • Project size – Team size, organizational departments, project duration, programming effort • Project structure – New vs. renovated system, resulting organizational changes, management commitment, user perceptions • Development group – Familiarity with platform, software, development method, application area, development of similar systems • User group – Familiarity with IS development process, application area, use of similar systems 3 Chapter 5 Assessing Risk(Cont.) • Risk can be managed on a project by: – Changing the project plan to avoid risky factors. – Assigning project team members to carefully manage the risky aspects. – Setting up monitoring methods to determine whether or not potential risk is, in fact, materializing. 4 Chapter 5 2
11/29/2012 Assessing Risk(Cont.) • The four primary factors associated with the amount of technical risk on a given project are: – Project size, – Project structure, – The development group’s experience with the application and technology area, and – The user group’s experience with systems development projects and the application area (see also Kirsch, 2000). 5 Chapter 5 Assessing Risk(Cont.) • Four general rules emerged as technical risk assessments: – Larger projects are riskier than smaller projects. – A system in which the requirements are easily obtained and highly structured will be less risky than one in which requirements are messy, ill structured, ill defined, or subject to the judgment of an individual. 6 Chapter 5 3
11/29/2012 Assessing Risk (Cont.) – The development of a system employing commonly used or standard technology will be less risky than one employing novel or nonstandard technology. – A project is less risky when the user group is familiar with the systems development process and application area than if unfamiliar. 7 Chapter 5 Assessing Risk(Cont.) Effects of degree of project structure, project size, and familiarity with application area on project implementation risk (Source: Based on 7th Applegate, Austin, and McFarlan. 2007; Tech Republic, 2005.) 8 Chapter 5 4
11/29/2012 Risks and Their Implications in the Requirements Process • Insufficient user Unacceptable product involvement Overruns and degraded • Creeping user quality requirements • Ambiguous requirements Rework and wasted time • Gold-plating Unnecessary features • Minimal requirements Missing features • Overlooking user classes Dissatisfied customers • Incompletely defined All of the above requirements 9 Controlling Risk • Project Management • Application of knowledge, skills, tools, and techniques to achieve targets within specified budget and time constraints • Scope • Time • Cost • Quality • Risk 5
11/29/2012 Kaiser Permanente Botches Its Kidney Transplant Center Project • Read the case study and then discuss the following questions: • Classify and describe the problems Kaiser faced in setting up the transplant center. What was the role of information systems and information management in these problems? • What were the people, organization, and technology factors responsible for those problems? • What steps would you have taken to increase the project’s chances for success? • Were there any ethical problems created by this failed project? Explain your answer. Quantifying Risk • For each risk event we’d like to estimate two factors • Probability – What are the chances the event will occur? • Impact – What is the cost if it does occur? • Together, these allow us to compute our exposure for the risk event 12 6
11/29/2012 Risk Event Exposure Exposure = Probability x Cost Note that the exposure is never the actual cost incurred. If the risk event occurs, the total impact is absorbed; if it doesn’t occur, there is no impact. The exposure is a measure of what to expect “on the average.” It is useful primarily for assessing the potential cost of an aggregate of risk events. 13 Risk Exposure: An Example • Suppose the risk event we’re considering is that we miss a delivery deadline • We estimate the probability that this will occur to be 25% • Suppose further that our assessment of what missing the delivery deadline will cost us is $100,000 • The exposure is then = . 25 X 100,000 = $25,000 • Will this risk event ever cost us $25,000? No. – the cost will be $0 if we deliver on time – the cost will be $100,000 if we miss the deadline 14 7
11/29/2012 Risk Exposure: An Example (cont’d) • Suppose now that we have identified 4 main risk events for our project, each with these same characteristics: 25% probability and $100,000 cost if the event occurs. • So our exposure on each risk is $25,000. • We add these to get our total exposure on the project which is $100,000. 15 Qualitative Risk Assessment • Sometimes it is very difficult to make confident estimates of probabilities and impacts associated with risk events • In these cases, a qualitative assessment of these two factors may make more sense • Ranking each of the two factors (low-high, low- medium-high, or similar) in a two dimensional table will still provide a basis for prioritizing risks • Prioritization is crucial to planning and creating risk management strategies 16 8
11/29/2012 Qualitative Risk Assessment High L H H H Probability L L H L Low Low High Impact 17 Question: Prioritizing Using Qualitative Assessments How would you prioritize risk events based on assessments done using the chart on the previous slide? HH HH HL or LH LH HL LL LL 18 9
11/29/2012 Some other sources of risk – Scope incorrectly defined – Incomplete or incorrect requirements – Poor estimates – Team turnover – Changing scope and requirements – Poor project management and planning – New technologies (already mentioned) • Risks should be assessed and “managed” even though they are unpredictable 19 Risk Response Strategies • Perform contingency planning , including: – a contingency budget – schedule alternatives, to include some built-in float – complete emergency responses designed to deal with major areas of risk • Develop workarounds designed to avoid or minimize selected risks • Mitigate risks – mitigation involves adding activities/deliverables to a project to offset the possible effect of a potential risk event – mitigation occurs before the risk event materializes – therefore mitigation costs are incurred whether the risk event occurs or not – a kind of insurance policy against selected risk events • Evade risk (Hope for the Best) 20 10
11/29/2012 Risk Avoidance and Mitigation • Risks should be identified early in the project • Stakeholders should be aware of potential risks and their impacts • They should help devise strategies for either avoiding them or minimizing their impact • Requires planning • Formulate contingency plans for mitigation • Track risk event potential and revise plan accordingly 21 Group Exercise #1 1) What do you consider to be the risks in the BEC project as you currently understand it?. 2) Is this a low, medium, or high risk project? 3) How would you propose dealing with the risks? 22 11
11/29/2012 Software Risk: A Recent Example On the following several slides, a recent highly publicized software failure is described. Read this case study and we will then discuss its implications for our study. 23 Errant Trades Reveal a Risk Few Expected Downloaded and adapted from NY Times Online, August 2, 2012 Errant trades from the Knight Capital Group began hitting the New York Stock Exchange almost as soon as the opening bell rang on Wednesday. The trading firm Knight Capital recently rushed to develop a computer program so it could take advantage of a new Wall Street venue for trading stocks. But the firm ran up against its deadline and failed to fully work out the kinks in its system, according to people briefed on the matter. In its debut Wednesday, the software went awry, swamping the stock market with errant trades and putting Knight’s future in jeopardy. Knight, founded in 1995, is a leading matchmaker for buyers and sellers of stocks, handling 11 percent of all trading in the first half of 2012. Knight lost three-quarters of its market value in two days, in addition to losing $440 million from the errant trades, and was scrambling to find financing or a new owner. 24 12
Recommend
More recommend
