2. Risks  All projects have some degree of risk  Risks are issues that can cause problems  Delay in schedule  Increased project costs  Technical risk example 1.We intend to use Web services, but no team member has experience with them 2.The team may not have the required Java skills to execute the job on time because several have not used Java in a business environment

3. What is Risk Management?  The total process to identify, control, and minimize the impact of uncertain events.  In IT, the focus is on availability, reliability, maintainability & security  In SE, the focus is on quality & productivity  One time, on budget & works  Realistic expectations  Try to confront risks early in the process rather than waiting for them to confront us when building the application

4. Risk Management  Usually performed 1. at the start of a project, 2. at the beginning of major project phases (such as requirements, design, coding and deployment), and 3. when there are significant changes (for example, feature changes, target platform changes and technology changes). Other Processes 4

5. Risk Analysis Methods 1. Identify potential sources of risk  Imagine all wost-case scenarios 2. Analyze each risk  Understand its potential impact on the project 3. Prioritize risks  Focus on the most serious 4. Mitigation strategies  Conquer it (investigate & take action)  Avoid it (change plans so the issue doesn’t occur 5. Develop a plan to retire the risk 6. Review your risk management plan periodically  Progress on plan?  Change to the risk?  New risks?

6. Identification  How are risks to the project’s success identified ?  Can be tricky  Requires imagination – looking at parts of the process that at first glance do not seem risky  Brainstorming

7. Brainstorming  Have a brainstorming session, consider :  Weak areas, such as unknown technology.  Aspects that are critical to project success, such as the timely delivery of a vendor's database software, creation of translators or a user interface that meets the customer's needs.  Problems that have plagued past projects, such as loss of key staff, missed deadlines or error-prone software Other Processes 7

8. Expressing Risks  Need to describe in as much detail as possible  Vague: “Team member may get sick”  Better: “Sick time will exceed the company norm by 50% due to high number of young parents on team”

9. Mitigation  Do you conquer the risk?  Take an action  Fire young parent employees?  Or avoid the risk?  Change a plan  Budget more time in the schedule?

10. Mitigating Risk by planning  The team should develop a plan to address each risk  Assign an individual to carry out the plan  Make plans concrete  Vague: “we will all learn Java”  Concrete: “Tom & Sue will pass level 2 Java Certification by Dec. 4 th by attending SuperJava Course”  Avoidance: “Use C++ instead of Java”

11. Prioritizing Risks  Create a table of identified risks and prioritize  What is the estimated likelihood that the risk will occur?  L: 1-10 with 1 lowest likelihood  What is the estimated impact of the risk?  I:1-10 with 1 lowest impact  What is the estimated cost of managing it?  M:1-10 with 1 lowest cost  Priority number  (11-L)*(11-1)*M  Retirement plan  Responsible person  Target completion date

12. Risk prioritization  Describe the risks fully  Priority depends on factors such as likelihood and seriousness of impact on project  A high priority task has a low priority number because people usually refer to their “highest priority” as number 1  The more expensive it is to deal with a risk, the lower its priority  If it’s a lot of work, may be better off not working on it in advance  Construct an expensive simulation? Or deal with it when it arises?  Sometimes have to just accept the risk

13. # Title Likelihood Impact Management Cost Priority # Retirement Plan Responsible Person Target Completion 1Lack of Java skills (see note 1) 8993 * 2 * 9 = 54 See note 3 JaredOct 15. 2Web services immature (see note 2) 3728 * 4 * 2 = 64 See note 4 JenAug 3. Note 1: The risk is that the team does not have enough skills in Java to handle the programming required by this project in the time allowed Note 2: The risk is that although a Web Service technology is a good choice, it is a new technology and its immaturity may create difficulties Note 3: Jen, Oscar, and Alf will all pass their level 2 Java cert by X date by taking Y course Note 4: Jen will install 3 Web services typical of DVD inventory management and run 1,000 typical transactions against these, gathering timing data

14. Just deal with it?  Not every risk can be dealt with earlier than its natural occurrence.  Suppose the team has a week to add significant functionality to the app  Goal: add the capability to show future investment growth graphically for a financial app  Little to gain from performing risk analysis and retirement in this case  With such short lead time, the resource of work time is better spent just getting to it  The chance that it won’t get done exists, but the time required for risk analysis my not leave enough time to do the job

15. Risk Review  review your risks periodically,  check how well mitigation is progressing.  change risk priorities, as required  Identify new risks.  rerun the complete risk process if the project has experienced significant changes.  incorporate risk review into other regularly scheduled project reviews Other Processes 15

16. In your projects  Risk management should be part of your discussions in your weekly meetings  Identify & mitigate (where possible)