Software Engineering. Lecture 6 Risk Management. Reactive vs. Proactive Risk Strategies. Reactive: The software team does nothing about risks until something goes wrong. Proactive: The software team establishes a plan for managing risk. The primary objective is to avoid risk.
Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
Software Engineering Lecture 6 Risk Management
Reactive vs. Proactive Risk Strategies • Reactive: • The software team does nothing about risks until something goes wrong. • Proactive: • The software team establishes a plan for managing risk. • The primary objective is to avoid risk. • The team develop a contingency plan as a respond in case a risk can not be avoided.
Risk Characteristics • Uncertainty: The risk may or may not happen; that is, there are no 100% probable risks. • Loss: If the risk becomes a reality, unwanted consequences or losses will occur. A risk that is 100 percent probable is a constraint on the software project
Categories of risks • Project Risks: threatens project plan e.g. overdue schedule, increased budget. • Technical Risks: threatens software qualitye.g. difficult / impossible implementation. • Business Risks: threatens software viabilitye.g. market risk, strategic risk, management risk, budget risk.
Another categorization of risks (Charette. 1989) • Known risks: uncovered after careful evaluation of the software project (unrealistic delivery date, lack of documented requirements or software scope). • Predictable risks: extrapolated from past project experience (staff turnover, poor customer communication). • Unpredictable risks: risks that are extremely difficult to identify in advance, but they can and do occur.
Stages of Risk Management • Risk Identification • Risk Impact Assessment • Risk Projection • Building a Risk Table • Determine Cutoff Line • Develop RMMM Plan
Risk Identification • Risk identification is a systematic attempt to specify threats to the project plan (estimates, schedule, resource loading, etc.). • There are two distinct types of risks for each of the categories previously presented: • Generic risks: a potential threat to every software project • Product-specific risks: depends on the technology, people, and the environment specific to the project
Risk Item Checklist • Risk Item Checklist is one method for identifying risks. • Generic risk subcategories: • Product Size (PS) • Business Impact (BU) • Customer Characteristics (CU) • Process Definition (PR) • Development Environment (DE) • Technology to be built (TE) • Staff Size and Experience (ST)
Risk Impact Assessment • The impact of risks is divided into one of four impact categories: • Catastrophic: schedule delay, cost increase, project failure. • Critical: schedule delay, cost increase, but not as high as the first one. • Marginal: possible cost increase and schedule delay, but recoverable. • Negligible: no effect to cost and schedule.
Risk Projection • Risk Projection (Risk estimation) attempts to rate each risk in two ways: • The probability that risk is real. • The consequences of the problems associated with the risk, should it occur.
Risk Table Risks Category Probability Impact RMMM Staff turnover ST 60% 2 Lack of training tools DE 80% 3 End-users resist system PS 40% 3 Tightened deadline BU 50% 2 …..
RMMM Plan • 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 are located at the top of the table. • The project manager then defines a cutoff line, indicating that only risks that lie above the line will be given further attention. • All risks that lie above the cutoff line must be managed, by developing the RMMM plan.
Risk Mitigation, Monitoring, and Management • Risk Mitigation / Risk Avoidance • The software team adopts a proactive approach to risk. • Avoidance is always the best strategy. • Risk Monitoring • The project manager monitors factors that may provide an indication of whether a risk is becoming more or less likely. • Risk Management and contingency planning • Assumes that mitigation efforts have failed and that the risk has become reality
An Example of RMMM • Project Risk: High staff turnover • Probability: 70% • Impact: 2 (Critical) • Mitigation: improve working environment, increase salary. • Monitoring: monitor the team member general attitude, member interpersonal relationships. • Management: assign backup team member.
Summary • When a lot is riding on a software project, common sense dictates risk analysis. • Risk Analysis can absorb a significant amount of project planning effort. But the effort is worth it. • Sun Tzu (500 BC) said, “If you know the enemy and know yourself, you need not fear the result of a hundred battles.” For the project manager, the enemy is risk.
References • Pressman, Chapter 6