Risk management in Software Projects

1. Risk management in Software Projects José Onofre Montesa Andrés Universidad Politécnica de Valencia Escuela Superior de Informática Aplicada 2003-2004

2. Índice • Failure and root causes. • Risk Definition • Formas en las que se afrontan las causas de las desviaciones • Elementos de la Gestión de Riesgos • Identificar los factores de Riesgo • Evaluar la probabilidad y el efecto • Desarrollo de estrategias para mitigar los riesgos • Monitorizar los factores de riesgo GpiI-3C Risk management in Software Projects

3. Failure and root causes. • Software projects fail if: • Software never runs. • Don’t accomplish same expected functions. • Software isn't delivered on time. • Higher cost than expected. • Reasons: • High level of complexity (communications, interrelation with other systems, etc..) • Uncertainty. It wasn’t clear the objective. GpiI-3C Risk management in Software Projects

4. Risk Definition (Fairley) • Risk is a potential problem. • Problem is a risk that has materialized. • By a problem, we mean an undesirable situation that will require time and resources to correct. • (may be uncorrectable). • A risk is characterized by: • The probability that occur (0<P<1) • A loss associated GpiI-3C Risk management in Software Projects

5. Risk factors fall into two categories • Generic risks, common to all software projects, then we tray to improve the organization to overcome this risks or we have a check list. • Project specific risks. • This are complementary points of view we must act on both. GpiI-3C Risk management in Software Projects

6. Most Common Software Risks (1) (Caper Jones) • Ambiguous improvement targets.(4) • Creeping users requirements.(9) • Crowded office conditions.(10) • Excessive schedule pressure.(13) • Excessive time to market.(14) • Inaccurate cost estimating.(19) • Friction between: • Client and software contractors.(16) • Software management and senior executives.(17) GpiI-3C Risk management in Software Projects

7. Most Common Software Risks (2) (Caper Jones) • Inadequate compensation plans.(24) • Inadequate configuration control and project repositories.(25) • Inadequate Curricula (S.E., S.M.)(26, 27). • Inadequate package acquisition methods.(29) • Inadequate software policies and standars.(31) • Inadequate tolls and methods (project management, Quality assurance, software engineering, technical documentation…)(34-37) GpiI-3C Risk management in Software Projects

8. Most Common Software Risks (3) (Caper Jones) • Lack of reusable code, data, test, human interfaces.(41-47) • Lack of specialization (48). • Low user satisfaction(53). • Low productivity.(50) • High maintenance costs.(18) • Partial live cycle definitions.(57) • poor technology investments. • Silver bullet syndrome.(62) GpiI-3C Risk management in Software Projects

9. Specific risk causes. • “When a project is successful, it is not because there are no problems, but because the problems were overcome .” • We can act: • Reactive: we wait problems and then we act on them. • Proactive: We identify potential problems and act in anticipation GpiI-3C Risk management in Software Projects

10. Risk management elements • Different techniques to work whit risk. • The spiral life cycle. • Check lists • Risk management. • This methods can work all together. GpiI-3C Risk management in Software Projects

11. Risk management procedures • Identify risk factors • Asses risk probabilities and effects on the project • Develop strategies to mitigate identify risks • Monitoring Risk factors • Invoke a contingence plan. • Manage the crisis. • Recovery from a crisis. • Fairley, R. IEEE Software Mayo 1994 GpiI-3C Risk management in Software Projects

12. Identify risk factors • You must visualize the project development and identify “wrong” things. • If you have a checklist with problems in other projects you work then revise that list. • “Who don’t know their past is commended to repeat” GpiI-3C Risk management in Software Projects

13. You must difference cause (risk factors), problems and symptoms. • Whether you identify a situation as a risk or an opportunity depends on your point of view. • Is the glass half full or half empty? • Situations with high potential for failure often have the potential for high pay back. GpiI-3C Risk management in Software Projects

14. Asses risk probabilities and effects on the project • Evaluate the probability of this problem. • Evaluate the effect the problem would have on the project desired outcome. • Classify risks with the Risk exposure, calculated as: • Probability * Effect • As a consecuence we will identify more important risks. GpiI-3C Risk management in Software Projects

15. Evaluación de la probabilidad de que se de el problema. • Not all the problems have the same probability. • Some times evaluating the probability is something difficult, use • Similar cases . • Optimist, pessimist and more probable. • Remember the Murphy law: • “if something can go wrong, it will do” • We can use simulation tools. GpiI-3C Risk management in Software Projects

16. Develop strategies to mitigate identify risks • Two types of strategies: • Action planning. • Addresses risks that can be mitigated by immediate response • Contingency planning. • We accept the risk and we plan and control the risk. GpiI-3C Risk management in Software Projects

17. Action planning • We minimize or vanish the risk. • We take action before the problem will materialize. • Example: • Problem: We can have problem using new tolls. • Action: We hire a experienced worker whit this tools GpiI-3C Risk management in Software Projects

18. Contingency planning • We accept the risk and we prepare a plan and we will use this if the risk is materialized. • The actions to take are: • Identify variables to be control in order to detect that the problem is here. • Create an action plan to be used during the crisis, as a consequence of this problem. • Planning the crisis recovery. GpiI-3C Risk management in Software Projects

19. Monitoring Risk factors • We observe identify symptoms, grouped. • We must quantify in a precise manner with objective, timely and accurate metrics. • We must have a clear control limits • We need a tradability between risk factors and risks. GpiI-3C Risk management in Software Projects

20. Invoke a contingence plan • When a quantitative risk indicator crosses a predetermined threshold. • Usually you can have different levels, • At first levels the operative level take action, • If can’t correct the situation then the contingency plan will start. GpiI-3C Risk management in Software Projects

21. Manage the crisis • Despite a team’s best effort, the contingence plan may fail, in which case project enters crisis mode GpiI-3C Risk management in Software Projects

22. Recovery from a crisis • After a crisis certain actions are required: • Reward personnel who have worked in burnout mode, • Reevaluating cost and schedule in light of the drain on resources from managing the crisis. GpiI-3C Risk management in Software Projects

23. Bibliografía • Fairley, R. “Risk Management for Software Development” en Software Engineering editado por Dorffman, M y Thayer, R.H., IEEE Computer Society, 1997 • Fairley, R. “Risk Management for Software Projects”, IEEE Software, Mayo 1994 • Jones, C. Assessment and Control of Software Risks. Yourdon Press, Prentice Hall, 1994. GpiI-3C Risk management in Software Projects