Presentation is loading. Please wait.

Presentation is loading. Please wait.

R i s k If you don’t attack risks, they will attack you.

Similar presentations


Presentation on theme: "R i s k If you don’t attack risks, they will attack you."— Presentation transcript:

1 R i s k If you don’t attack risks, they will attack you.

2 An Example of Risk

3 Questions  What risks are there to software projects?  How can we handle those risks?

4 Risk Categories  performance risks does not meet the requirements  cost risks over budget  schedule risks not delivered on time  support risks maintenance problems

5 Common Problem Sources  Inherent difficulties in estimation Ex – bad historical data  Bad assumptions during planning Ex – we thought the customer would take less than two weeks to provide interface feedback Ex – our task network didn’t expect coding to uncover design problems Ex – we didn’t schedule time to change the design and code when the specs change  Unforeseen Events

6 Boehm's Top 10 Software Risks 1.Schedules, budgets, process 2. Requirements Changes 3. Personnel Shortfalls 4. Requirements Mismatch 5. Rapid change 6. Architecture, performance, quality, distribution/mobility 7. External components 7. Legacy Software 9. Externally-performed tasks 10.User interface mismatch USC Center for Systems & Software Engineering

7  customer-furnished items or information  internal and external subcontractor relationships  inter-component or inter-group dependencies  availability of trained, experienced people  reuse from one project to the next  lack of clear product vision  lack of agreement on product requirements  un-prioritized requirements  new market with uncertain needs  new applications with uncertain requirements  rapidly changing requirements  ineffective requirements change management process  inadequate impact analysis of requirements changes  inadequate planning and task identification  inadequate visibility into actual project status  unclear project ownership and decision making  unrealistic commitments made, sometimes for the wrong reasons  managers or customers with unrealistic expectations  staff personality conflicts  poor communication  inadequate training  poor understanding of methods, tools, and techniques  inadequate application domain experience  new technologies or development methods  ineffective, poorly documented, or neglected processes  unavailability of development or testing equipment and facilities  inability to acquire resources with critical skills  turnover of essential personnel  unachievable performance requirements  problems with language translations and product internationalization  technical approaches that may not work

8 IEEE/ISO Std for Recovering from Risks Gone Bad There isn't one!!!!

9 SEI on Risk What does success look like? A successful risk management practice is one in which risks are continuously identified and analyzed for relative importance. Risks are mitigated, tracked, and controlled to effectively use program resources. Problems are prevented before they occur and personnel consciously focus on what could affect product quality and schedules. What will risk management do for my business? There will be a cultural shift from "fire-fighting" and "crisis management" to proactive decision making that avoids problems before they arise. Anticipating what might go wrong will become a part of everyday business, and the management of risks will be as integral to program management as problem or configuration management.

10 SEI Risk Management Principles 1. Global perspective 2. Forward-looking view 3. Open communications 4. Integrated management 5. Continuous process 6. Shared product vision 7. Teamwork

11 Boehm’s Risk Engineering Tasks  Risk Analysis Identification Estimation Evaluation  Risk Management Planning Control Monitoring Directing Staffing

12 Prioritizing Risks RE = likelihood x impact RRL = RE = risk exposure RRL = risk reduction leverage Software Project Management by Hughes and Cotterell RE before – RE after risk reduction cost

13 RRL Example Problem:  We are building a university financial aid application.  There is a 3% chance that an error in the interface will occur and result in a $1 million patch. Solution 1: Requirements Checker: cost = $20K error probability reduced to 1% Solution 2: Interface Testing Tool: cost = $150K error probability reduced to.5% adapted from Software Engineering : Barry Boehm's Lifetime Contributions by Richard Shelby

14 example continued ($1M * 3%) - ($1M * 1%) RRL(Req Checker) = $20K = 1.00 ($1M * 3%) - ($1M *.5%) RRL(Testing Tool) = $150K = 0.197

15 Dealing with Risks  Hazard Prevention  Likelihood Reduction  Risk Avoidance  Risk Transfer  Contingency Planning

16 Example Risk 1 Lose of Source Code.  Risk of the server crashing? cost of automated backups.  Risk of hack attack from outside. cost of firewall software, etc.  Risk of hack attack from inside. cost of off-site backup system.

17 Example Risk 2 Person X is assigned to three tasks on the critical path! How do we deal the risk of them getting sick? How do we deal the risk of them getting sick? Possible Steps: 1. Analyze the possible impact of a delay caused by their absence. 2. Determine cost of training another person to do one or two of those tasks.  What is the risk exposure versus the training costs? 3. Can there be a different task network or assignment of personnel?

18 Example Risk 3 The risk of employee turnover?  What happens if they leave? How dependant is our schedule on people with these exact skills? Will information be lost with the person?  How can we keep them / replace them? How costly would it be to raise salaries? How else could we make them happy? Costs to hire good replacements?

19 Example Risk 4 The Market for our product may change. What is the likelihood of change? How acceptable would our product be?  How risky is it to speed production? Effect of speed on quality? Costs of extra personnel or overtime pay?  What is the risk of making it a more general product? Cost and time of extra features?

20 Example Risk 5 Risk to Functionality based on unknown technology? How likely is it that we don’t know enough to fulfill this particular requirement? How important is this requirement to product acceptance? If someone else knows a lot about this, how much would it cost to get them here? Should we try two approaches at the same time?

21 Example Risk 6 Risks related to Example Data Access.  Who  Who controls access to the database where we are supposed to get our sample data? Is their boss in favor of this project? Are they nice, or do we need to mow their lawn before we can see the data?  When  When can we get the data? If we can’t get data at the beginning, can we use fake data for a while? How long can we use fake data? How will fake data affect quality?

22 Example Risk 7 To generate additional revenue, we will release a new version of a financial analysis product. Since it is currently written in COBOL, the next version should be written in COBOL.  Do you see any potential risks?

23 Risk Analysis Tools “Risk Radar® includes 22 standardized reports that enable project managers to quickly and easily view and track important risk data. It provides the ability to establish standard values for categorizing and prioritizing project risks according to Probability of Occurrence, Risk Impact and Risk Exposure. And, it does this all within the familiar Microsoft Access® graphic interface, which enables most users to immediately apply the benefits of the tool without costly and time-consuming software training.”

24

25 Summary  Be proactive, not reactive.  Assess the cost of failure against the costs of addressing the risk.  Avoid costly risks or limit the effect of the risk.

26 Homework Exercise For the previous homework's web based project:  identify 5 risks  estimate the risk exposure for each risk  how can that team deal with those risks


Download ppt "R i s k If you don’t attack risks, they will attack you."

Similar presentations


Ads by Google