Effective Risk Management in Software Engineering

1. Risk Management in software engineering

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 • We intend to use Web services, but no team member has experience with them • 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 • at the start of a project, • at the beginning of major project phases (such as requirements, design, coding and deployment), and • when there are significant changes (for example, feature changes, target platform changes and technology changes). Other Processes

5. Risk Analysis Methods • Identify potential sources of risk • Imagine all wost-case scenarios • Analyze each risk • Understand its potential impact on the project • Prioritize risks • Focus on the most serious • Mitigation strategies • Conquer it (investigate & take action) • Avoid it (change plans so the issue doesn’t occur • Develop a plan to retire the risk • 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

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. 4th 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. 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

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