1. Software Engineering Risk Management

2. Steps in Project Planning lScope—understand the problem and the work that must be done. lEstimation—how much effort? how much time? lRisk—what can go wrong? how can we avoid it? what can we do about it? lSchedule—how do we allocate resources along the timeline? what are the milestones? lControl strategy—how do we control quality? how do we control change? Software Project Plan Project Scope Estimates Risks Schedule Control strategy

3. Risk Analysis and Management lDefinition of Software Risk:  Concerns future happenings. What risks might cause the project to go astray?  Involves change. How will changes in customer requirements, development technologies, target computers, and other entities affect timeliness and success?  Requires choice. What methods and tools should be used, how many people should be involved to reduce risk? lQuestions:  What can go wrong?  What is the likelihood?  What will the damage be?  What can we do about it?

4. Reactive Risk Management l “Indiana Jones School of Risk Management” — project team reacts to risks when they occur. lMitigation—plan for additional resources in anticipation of fire fighting. lFix on failure—resources are found and applied when the risk strikes. lCrisis management—if failure does not respond to applied resources then the project is in jeopardy. l“If you don’t actively attack the risks, they will actively attack you.”

5. Proactive Risk Management lFormal risk analysis is performed:  Potential risks are identified  Their probability and impact are assessed  They are ranked by importance  Project team established a plan for managing these risks lOrganization corrects the root causes of risk:  Examine risk sources that lie beyond the bounds of the software  Develop the skill to manage change

6. RISK Risk Management Paradigm control identify analyze plan track

7. Software Risks lProject Risks:  Threaten the project plan. Should identify potential budgetary, schedule, personnel, resource, customer and requirement problems.  Project complexity, size and degree of uncertainty are factors that increase risk. lTechnical Risks:  Threaten the quality. Should identify specification ambiguity, technical uncertainty, technical obsolescence, and “bleeding edge” technology.  Occur because the problem is harder to solve than anticipated. lBusiness Risks:  Threaten the viability of the software. (1) Building an excellent system that no one wants, (2) building a product that no longer fits into the business strategy, (3) a product the sales force don’t understand, (4) losing the support of management, (5) losing budgetary or personnel commitment.

8. Risk Identification lRisk identification is a systematic attempt to specify threats to the project plan. lAlthough generic risks are important to consider, usually the product specific risks cause the most headaches. lAsk a set of questions which will allow an estimate of the impact of risk:  Product Size  Business Impact  Customer  Process Maturity  Technology Risks  Staff/People Risks

9. Risk Due to Product Size lAttributes that affect risk:  Estimated size of product in LOC or FP?  Estimated size of product in number of programs, files, transactions?  Percentage deviation in size of product from average for previous products?  Size of database created or used by the product?  Number of users of this product?  Number of projected changes to the product? Before delivery? After delivery?  Amount of reused software?

10. Risk Due to Business Impact lAttributes that affect risk:  Affect of this product on company revenue?  Visibility of this product to senior management?  How reasonable is the delivery deadline?  Number of customers who will use this product?  Interoperability constraints?  Sophistication of end-users?  Amount and quality of product documentation that must be produced and delivered to the customer?  Governmental constraints.  Costs associated with late delivery?  Costs associated with a defective product?

11. Risks Due to the Customer lQuestions that must be answered:  Have you worked with the customer before?  Does the customer have a solid idea of requirements?  Has the customer agreed to spend time with you?  Is the customer willing to participate in reviews?  Is the customer technically sophisticated?  Is the customer willing to let your people do their job – that is, will the customer resist looking over your shoulder during technically detailed work?  Does the customer understand the software engineering process?

12. Risks Due to Process Maturity lQuestions that must be answered:  Have you established a common process framework?  Is it followed by project teams?  Do you have management support for software engineering?  Do you conduct formal technical reviews?  Are CASE tools used for analysis, design and testing?  Are the tools integrated with one another?  Have document formats been established?

13. Technology Risks lQuestions that must be answered:  Is the technology new to your organization?  Are new algorithms, I/O technology required?  Does the application interface with new software?  Is new or unproven hardware required?  Is a specialized user interface required?  Is the application radically different?  Are you using new software engineering methods?  Are you using unconventional software development methods, such as formal methods, AI-based approaches, artificial neural networks?  Are there significant performance constraints?  Is there doubt that the functionality requested is “do-able”?

14. Staff/People Risks lQuestions that must be answered:  Are the best people available?  Do staff have the right skills?  Are enough people available?  Are staff committed for entire duration?  Will some people work part time?  Do staff have the right expectations?  Have staff received necessary training?  Will turnover among staff be low?

15. Risk Analysis lDeveloping a Risk Table (implemented as a spreadsheet): 1.Identify risks. 2.Estimate the probability of occurrence. Each member of the project team assigns a probability. Continue in round-robin fashion until agreement is reached. 3.Estimate the impact on the project on a scale of 1 to 5:  1 = catastrophic (the failure caused by this risk would result in project failure, or the increase in costs and schedule delays would exceed R500k)  2 = critical (failure leads to questionable project success, or increased costs and delays in the range R100-500k)  3 = marginal (the failure would result in degradation of secondary objectives, or increased costs and delays in the range R1-100k)  4 = negligible (failure to meet requirements would result in inconvenience, or increased costs and delays of less than R1k) 4.sort the table by probability and impact. 5.Calculate risk exposure:

16. A Risk Table RiskProbabilityImpactRMMM Risk Mitigation Monitoring & Management

17. Risk Mitigation, Monitoring, and Management lFor the risks with exposure higher than a certain cutoff:  mitigation—how can we avoid the risk?  monitoring—what factors can we track that will enable us to determine if the risk is becoming more or less likely?  management—what contingency plans do we have if the risk becomes a reality? lExample:  Assume high staff turnover is noted as a project risk with probability = 0.7 and impact = 2.  To mitigate meet with staff about grievances, develop techniques to ensure continuity, conduct peer review so all are up to speed, assign a backup staff member to each critical technologist.  To monitor measure the degree of team “jell”, potential problems with compensation and benefits, general attitude of team members.  To mitigate ensure that critical documents are prepared in a timely and consistent manner.

18. Project: Embedded software for XYZ system Risk type: schedule risk Priority (1 low... 5 critical): 4 Risk factor: Project completion will depend on tests which require hardware component under development. Hardware component delivery may be delayed Probability: 60 % Impact: Project completion will be delayed for each day that hardware is unavailable for use in software testing Monitoring approach: Scheduled milestone reviews with hardware group Scheduled milestone reviews with hardware group Contingency plan: Modification of testing strategy to accommodate delay using Modification of testing strategy to accommodate delay using software simulation software simulation Estimated resources: 6 additional person months beginning 7-1-96 Recording Risk Information