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

2. Example of Risk

3. 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.

4. 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 www.sei.cmu.edu/programs/sepm/risk/

5. Common Problem Sources  Inherent difficulties in estimation Ex – bad historical data  Bad assumptions during planning Ex – our tasks network didn’t expect coding to uncover design problems Ex – we didn’t schedule for time to change the design and code when the specs change Ex – our programmers aren’t as knowledgeable as we thought they were  Unforeseen Events

6. Boehm’s Top Ten - 1991 1.Personnel Shortfalls 2.Unrealistic time and cost estimates 3.Developing the wrong software functions 4.Developing the wrong user interface 5.Gold plating 6.Late changes to requirements 7.Shortfalls in external supplied components 8.Shortfalls in external supplied components 9.Real-time performance shortfalls 10.Development technically too difficult

7. Risk Categories  performance risk does not meet the requirements  cost risk over budget  schedule risk not delivered on time  support risk maintenance problems

8.  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 http://www.processimpact.com/articles/risk_mgmt.html

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

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

11. 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

12. Example Risk 1 Lose of Source Code.  Risk of the server dieing? 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.

13. 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?

14. 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?

15. 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?

16. 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?

17. 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?

18. 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.” www.iceincusa.com/products_tools.htm

20. 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.