Software Risk Management updated.ppt
- 1. Software Project Management By Dr. Faisal Shafique Butt The information contained in this presentation was obtained from the public domain
- 2. Topic of the Day Software Risk Management
- 3. If you don't invest in risk management, it doesn't matter what business you're in, it's a risky business. Gary Cohn
- 4. It's better to solve the right problem approximately than to solve the wrong problem exactly. John Tukey
- 5. When you gamble with safety, you bet your life.
- 6. Risk Management • Problems that haven’t happened yet • Why is it hard? • Some are wary of bearing bad news – No one wants to be the messenger – Or seen as “a worrier” • You need to define a strategy early in your project
- 7. Risk Management • Identification, Analysis, Control • Goal: avoid a crisis – Proactive vs. reactive
- 8. Project Risk • Characterized by: – Uncertainty (0 < probability < 1) – An associated loss (money, life, reputation, etc) – Manageable – some action can control it
- 9. Types of Risks • Schedule Risks • Schedule compression (customer, marketing, etc.) • Cost Risks • Unreasonable budgets • Requirements Risks • Incorrect • Incomplete • Unclear or inconsistent • Volatile
- 10. Types of Risks • Quality Risks • Operational Risks • Most of the “Classic Mistakes” – Classic mistakes are made more often
- 11. Risk Management Process Risk Management Risk Assesment Risk Control Risk Identification Risk Analysis Risk Prioritization Risk Management Planning Risk Resolution Risk Monitoring “Software Risk Management”, Boehm, 1989
- 12. Risk Identification • Get your team involved in this process – Don’t go it alone • Produce a list of risks with potential to disrupt your project’s schedule • Use a checklist or similar source to brainstorm possible risks
- 13. Risk Analysis • Determine impact of each risk • Risk Exposure (RE) • Also known as “Risk Impact” • RE = Probability of loss * size of loss • Ex: risk is “Facilities not ready on time” – Probability is 25%, size is 4 weeks, RE is 1 week • Ex: risk is “Inadequate design – redesign required” – Probability is 15%, size is 10 weeks, RE is 1.5 weeks • Statistically are “expected values” • Sum all RE’s to get expected overrun
- 14. Risk Prioritization • Often want larger-loss risks higher – Or higher probability items • Possibly group ‘related risks’ • Helps identify which risks to ignore – Those at the bottom
- 15. Risk Management Plan • Example: Employee Turnover. • To mitigate the risk, a project management team must develop a plan for reducing turn over. • Meet with the staff to determine the causes of turnover. • (poor working conditions, low salary etc)
- 16. Risk Mitigation
- 17. Risk Mitigation • Risk Acceptance – Risk acceptance does not reduce any effects. – it is still considered a strategy. This strategy is a common option when the cost of other risk management options such as avoidance or limitation may outweigh the cost of the risk itself. – A company that doesn’t want to spend a lot of money on avoiding risks that do not have a high possibility of occurring will use the risk acceptance strategy.
- 18. Risk Mitigation • Risk Avoidance – Risk avoidance is the opposite of risk acceptance. It is the action that avoids any exposure to the risk whatsoever. – It’s important to note that risk avoidance is usually the most expensive of all risk mitigation options.
- 19. Risk Mitigation • Risk Limitation – Risk limitation is the most common risk management strategy used by businesses. – This strategy limits a company’s exposure by taking some action. – It is a strategy employing a bit of risk acceptance along with a bit of risk avoidance or an average of both.
- 20. Risk Mitigation • Risk Transference – Risk transference is the involvement of handing risk off to a willing third party. – For example, numerous companies outsource certain operations such as customer service, payroll services, etc. – This can be beneficial for a company if a transferred risk is not a core competency of that company. – It can also be used so a company can focus more on their core competencies
- 21. Risk Resolution and Monitoring • The risk-resolution process consists of implementing the risk reduction techniques as identified in the plans. • Risk monitoring ensures that this is a closed-loop process by tracking risk reduction progress and applying whatever corrective action is necessary to keep the risk-resolution process on track
- 22. Risk Management • Monitoring As the project proceeds, risk monitoring activities commence In case of high staff turn over, the following factors can be monitored – General attitude of the teams – Interpersonal relationships – Problems with salary and Compensations – Availability of jobs in the market
- 23. Risk Management • Management When the mitigation plan fails and the risks actually happens then in this case we have contingency plan.
- 24. Risk Register Risk ID Description Probability Project Phase Response Response Plan Contingency Plan Owner
- 25. Categories of Risks • Product size risks 1. Estimated size of the product in LOC 2. Estimated size of the product in number of programs, files etc. 3. Division of work among developers 4. Size of the database created or used by the product 5. Number of users of the product 6. No of changes before and after delivery
- 26. Categories of Risks • Business impact risks 1. Effect of this product on company’s revenue 2. Reasonableness of the delivery date 3. Number of users who will use this product 4. Govt. constraint on the product 5. Costs associated with late delivery
- 27. Categories of Risks • Customer related risks All customers are not equal Some customers will accept the bad product, some will mention the defects in the product and other will always point out the errors/issues, although the product is working fine.
- 28. Categories of Risks • Customer related risks 1. Have you worked with the customer in the past? 2. Does the customer have the solid idea of the product? 3. Will the customer spend time in formal technical reviews? 4. Is the customer willing to let your people do their job or will the customer resist looking over your shoulder?
- 29. Categories of Risks • Process risks 1. Does your senior management support the importance of standard process for software development? 2. Are staff members willing to use the software process? 3. Has the software process used for other projects? 4. Has your organization developed a series of software engineering training courses for the managers?
- 30. Categories of Risks 5. Documentation? 6. Are formal technical reviews after each phase in the organization? 7. Are we working according to Software Engineering standards?
- 31. Categories of Risks • Technical Risks 1. Is there communication between customer and developer? 2. Do you use specific methods for testing? 3. Have software tools used for analysis and design process? 4. Have quality metrics collected for software? 5. Have tools used to create prototypes ?
- 32. Categories of Risks • Technology Risks 1. Is the technology to be built new to the organization? 2. Does the customer demands the creation of new algorithms? 3. Does the software interfaces with new and unproven hardware? 4. Does the software interacts with that database whose performance has not been tested?
- 33. Categories of Risks • Development Environment risks 1. Is Software Project Management tool available (MS project)? 2. Tools for design used? 3. Testing tools used? 4. Is the documentation and help available? 5. Have members of the project received the training on each tool? 6. Code generators (UML)?
- 34. Categories of Risks • Risks associated with staff 1. Is best staff available? 2. Do the people have the right combination skills? 3. Are enough people 4. Have staff received training?