Gestión de Riesgos en Proyectos Informáticos

1. Gestión de Riesgos en Proyectos Informáticos José Onofre Montesa Andrés Universidad Politécnica de Valencia Escuela Superior de Informática Aplicada 2003-2004

2. Índice • El Fracaso y sus Causas. • Definición de Riesgo • 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 GPI-3C. Gestión de Riesgos en Proyectos Informáticos

3. El Fracaso y sus Causas. • Los proyectos Informáticos fracasan por: • El SW nunca llega a funcionar. • No se cumplen los plazos de entrega. • No cumple con las funcionalidades esperadas. • Razones: • La complejidad era muy alta (comunicaciones, interrelación con otros sistemas, etc..) • Incertidumbre. No se tenia una idea clara de lo que se quería obtener. GPI-3C. Gestión de Riesgos en Proyectos Informáticos

4. Definición de Riesgo • Riesgo es un problema potencial. • Un problema es un riesgo materializado. • Por problema entendemos una situación no deseable en la que necesitaremos tiempo o dinero para solucionarla. • Un problema potencial se caracteriza por: • La probabilidad de que ocurra (0<P<1) • Una perdida asociada, cuantificable • ... GPI-3C. Gestión de Riesgos en Proyectos Informáticos

5. Formas en las que se afrontan las causas de las desviaciones • Podemos observar que hay dos puntos de vista respecto a la gestión de riesgos en P.I. • muchas de las causas de fracaso se los P.I. son comunes. • Se identifican e intenta situar a la organización en una situación fuerte. • cada proyecto tiene unos riesgos específicos, • hay que gestionar los riesgos de forma especifica en cada caso. • Realmente son visiones complementarias del problema GPI-3C. Gestión de Riesgos en Proyectos Informáticos

6. Causas comunes de fracaso (1) (Caper Jones) • Ambigüedad del objetivo. • Requerimientos Cambiantes. • Tardó demasiado para el mercado. • Estimaciones inadecuadas. • Oficinas de trabajo muy llenas. • Presión excesiva de la planificación. • Fricciones: • Contratistas y Clientes. • Directores Empresa y SW. • Salarios inadecuados. GPI-3C. Gestión de Riesgos en Proyectos Informáticos

7. Causas comunes de fracaso (2) (Caper Jones) • Falta de especialización. • Inadecuada estimación de la calidad • Sistema de adquisición de paquetes inadecuado • Inadecuada política de estándares • Herramientas y métodos inadecuados • Inadecuado control de configuración. • Documentación inadecuada • Falta de reutilización de código, datos, pruebas, interfaces GPI-3C. Gestión de Riesgos en Proyectos Informáticos

8. Causas comunes de fracaso (3) (Caper Jones) • Bajo nivel de satisfacción de los usuarios. • Curriculum inadecuados en los desarrolladores. • Costes altos de mantenimiento. • Ciclos de vida parciales. • Inversiones pobres en tecnología. • El síndrome de la bala de plata. • Baja productividad. GPI-3C. Gestión de Riesgos en Proyectos Informáticos

9. Causas especificas. Gestión de los Riesgos. • “Cuando un proyecto tienen éxito, no es porque no haya tenido problemas, sino porque se han superado.” • Podemos actuar de dos formas: • Reactivamente: • esperamos que aparezcan los problemas y los solucionamos. • Proactivamente: • Tratamos de identificar problemas potenciales y los atajamos GPI-3C. Gestión de Riesgos en Proyectos Informáticos

10. Elementos de la Gestión de Riesgos • Existen muchas técnicas para abordar este enfoque. • En los primeros temas estudiamos el desarrollo en espiral. • Existe otro enfoque que consiste en crear una lista de comprobación. • Gestión ante esta situación. • Estos métodos no son excluyentes. GPI-3C. Gestión de Riesgos en Proyectos Informáticos

11. Elementos de la Gestión de Riesgos • Identificar los factores de Riesgo. • Evaluar la probabilidad y el efecto sobre el proyecto. • Desarrollo de estrategias para mitigar los riesgos. • Monitorizar los factores de riesgo. • Invocar el plan de contingencias. • Gestionar la crisis. • Recuperarse de la crisis. • Fairley, R. IEEE Software Mayo 1994 GPI-3C. Gestión de Riesgos en Proyectos Informáticos

12. Identificar los factores de Riesgo • Se trata de visualizar el desarrollo y tomar notas de las cosas “malas” que podrían ocurrirnos. • Es aconsejable el disponer de una lista con los problemas acaecidos en otros proyectos y revisarla. • “Quien no conoce su pasado esta condenado a repetirlo” GPI-3C. Gestión de Riesgos en Proyectos Informáticos

13. Hay que diferenciar entre causa (factores de riesgo), problema y síntomas. • Todos los problemas potenciales no son malos, realmente son los que hacen que este proyecto no se haya realizado anteriormente. • El mismo problema puede se visto como un reto, una oportunidad o algo indeseable. GPI-3C. Gestión de Riesgos en Proyectos Informáticos

14. Evaluar la probabilidad y el efecto sobre el proyecto • Evaluar la probabilidad de tener el problema. • Evaluar los efectos sobre el proyecto. • Clasificar los riesgos en base a la EXPOSICIÓN AL RIESGO, que se calcula como: • Probabilidad * Efecto • Como consecuencia de esta clasificación habrán riesgos importantes y otros menores. GPI-3C. Gestión de Riesgos en Proyectos Informáticos

15. Evaluación de la probabilidad de que se de el problema. • No todos tienen la misma probabilidad. • Aveces es difícil asignar una probabilidad a un problema en concreto, • Casos similares. • Optimista, pesimista y lo mas probable. • Recordar la ley de Murphy: • “Si algo puede salir mal, saldrá mal.” • Existen herramientas de simulación. GPI-3C. Gestión de Riesgos en Proyectos Informáticos

16. Desarrollo de estrategias para mitigar los riesgos • Las estrategias pueden ser de dos tipos: • Plan de Acción. • minimizamos o hacemos desaparecer el riesgo. • Plan de Contingencia. • aceptamos el riesgo y preparamos el plan por si el problema se materializa. GPI-3C. Gestión de Riesgos en Proyectos Informáticos

17. Plan de Acción • Minimizamos o hacemos desaparecer el riesgo. • La acción se realiza antes de que pueda darse el problema. • Por ejemplo: • Problema: Pueden aparecer dificultades al utilizar nuevas herramientas. • Acción: Contratamos a personas experimentadas con estas herramientas. GPI-3C. Gestión de Riesgos en Proyectos Informáticos

18. Plan de Contingencia • Aceptamos el riesgo y preparamos el plan por si el problema se materializa. • Las actividades a realizar son las siguientes: • Identificar las variables a monitorizar (factores de riesgo) para detectar que el problema se ha materializado. • Crear un plan de acción para la Crisis, consecuencia de este problema. • Planificar la recuperación de esta crisis. GPI-3C. Gestión de Riesgos en Proyectos Informáticos

19. Monitorizar los factores de riesgo • Se trata de los síntomas que hemos identificado en el caso anterior, agrupados. • Deberán de cuantificarse de forma precisa mediante medidas objetivas y puntuales. • Hay que disponer de un sistema de trazabilidad entre los factores de riesgo y los problemas asociados, así como los limites de control. GPI-3C. Gestión de Riesgos en Proyectos Informáticos

20. Invocar el plan de contingencias • Sí algún factor de riesgo excede los limites de control habrá de tomarse las medidas previstas. • Es habitual varios niveles limites, • ante los primeros excesos se notifique el problema a nivel operativo, • si este no se corrige, se excede el siguiente limite, se pondrá en marcha el plan de contingencia previsto. GPI-3C. Gestión de Riesgos en Proyectos Informáticos

21. Gestionar la crisis • El que la situación de crisis este prevista no quiere decir que podamos relajarnos, más bien al contrario. Deberemos estar más atentos al control de la crisis y del resto. • Puedes suceder que el plan de contingencia: • funcione de acuerdo a lo previsto. • fracase. En este caso pasaremos a una situación de crisis (vista en el tema anterior) GPI-3C. Gestión de Riesgos en Proyectos Informáticos

22. Recuperarse de la crisis • Si el plan de contingencia ha ido de acuerdo a lo previsto como si no, deberemos: • Recompensar a las personas a las que se ha forzado a trabajar más duro (ver tema anterior), • Replanificar el proyecto con los retrasos y los costes que esa situación hayan provocado. GPI-3C. Gestión de Riesgos en Proyectos Informáticos

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. Assesment and Control of Software Risks. Yourdon Press, Prentice Hall, 1994. GPI-3C. Gestión de Riesgos en Proyectos Informáticos