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. GpiI-3C Risk management in Software Projects1 Í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

3. GpiI-3C Risk management in Software Projects2 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.

4. GpiI-3C Risk management in Software Projects3 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

5. GpiI-3C Risk management in Software Projects4 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.

6. GpiI-3C Risk management in Software Projects5 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)

7. GpiI-3C Risk management in Software Projects6 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)

8. GpiI-3C Risk management in Software Projects7 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)

9. GpiI-3C Risk management in Software Projects8 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

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

11. GpiI-3C Risk management in Software Projects10 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

12. GpiI-3C Risk management in Software Projects11 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”

13. GpiI-3C Risk management in Software Projects12 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.

14. GpiI-3C Risk management in Software Projects13 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.

15. GpiI-3C Risk management in Software Projects14 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.

16. GpiI-3C Risk management in Software Projects15 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.

17. GpiI-3C Risk management in Software Projects16 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

18. GpiI-3C Risk management in Software Projects17 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.

19. GpiI-3C Risk management in Software Projects18 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.

20. GpiI-3C Risk management in Software Projects19 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.

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

22. GpiI-3C Risk management in Software Projects21 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.

23. GpiI-3C Risk management in Software Projects22 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.