Gestión de Riesgos en Proyectos Informáticos

Gestión de Riesgos en Proyectos

Informáticos José Onofre Montesa AndrésUniversidad Politécnica de

ValenciaEscuela Superior de Informática Aplicada

2003-2004

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


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.


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– ...


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


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.



• 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



• 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.


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


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.


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


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”


• 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.


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.


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.


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.


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.


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.


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.


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.


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)


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.


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.

Gestión de Riesgos en Proyectos Informáticos

Documents

Transcript of Gestión de Riesgos en Proyectos Informáticos