Gestin de Riesgos en Proyectos Informticos Jos Onofre

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 GPI-3 C. Gestión de Riesgos en Proyectos Informáticos

Í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-3 C. Gestión de Riesgos en Proyectos Informáticos 1

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-3 C. Gestión de Riesgos en Proyectos Informáticos 2

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-3 C. Gestión de Riesgos en Proyectos Informáticos 3

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-3 C. Gestión de Riesgos en Proyectos Informáticos 4

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-3 C. Gestión de Riesgos en Proyectos Informáticos 5

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-3 C. Gestión de Riesgos en Proyectos Informáticos 6

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-3 C. Gestión de Riesgos en Proyectos Informáticos 7

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-3 C. Gestión de Riesgos en Proyectos Informáticos 8

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 consiste en crear una lista de comprobación. – Gestión ante esta situación. • Estos métodos no son excluyentes. GPI-3 C. Gestión de Riesgos en Proyectos Informáticos 9

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-3 C. Gestión de Riesgos en Proyectos Informáticos 10

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-3 C. Gestión de Riesgos en Proyectos Informáticos 11

• 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-3 C. Gestión de Riesgos en Proyectos Informáticos 12

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-3 C. Gestión de Riesgos en Proyectos Informáticos 13

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-3 C. Gestión de Riesgos en Proyectos Informáticos 14

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-3 C. Gestión de Riesgos en Proyectos Informáticos 15

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-3 C. Gestión de Riesgos en Proyectos Informáticos 16

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-3 C. Gestión de Riesgos en Proyectos Informáticos 17

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-3 C. Gestión de Riesgos en Proyectos Informáticos 18

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-3 C. Gestión de Riesgos en Proyectos Informáticos 19

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-3 C. Gestión de Riesgos en Proyectos Informáticos 20

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-3 C. Gestión de Riesgos en Proyectos Informáticos 21

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-3 C. Gestión de Riesgos en Proyectos Informáticos 22