Administración de riesgos

Un riesgo es un evento potencial que puede o no ocurrir pero si sucede, tendrá un impacto en el proyecto ya sea causando demoras, sobre costos y/o afectando la calidad del producto. El objetivo de la administración de riesgos es tener en cuenta los aspectos inciertos de un proyecto para mitigarlos y que no se conviertan en problemas graves. Es un enfoque pro activo: evitar que el riesgo se presente o prepararse para disminuir las consecuencias si se llega a presentar.

Las actividades relacionadas con la Administración de Riesgos se pueden organizar en dos grandes grupos: 1) Identificar y estimar los riesgos, y 2) Controlar los riesgos.

Identificar y estimar los riesgos

Producir una lista de riesgos capaces de romper la planificación del proyecto. Algunos ejemplos clásicos son:

• Planificaciones demasiado optimistas
• Planificación con tareas innecesarias
• Presupuestos bajos
• El ciclo de revisión/decisión de las directivas es mas lento de lo esperado
• Cambio de requerimientos
• Mal funcionamiento de las herramientas de desarrollo
• Espacios de trabajo inadecuados
• Curva de aprendizaje de las nuevas tecnologías es más larga de lo esperado
• Escatimar en la calidad
• Diseño inadecuado
• Personal no adecuado o no bien capacitado
• Pérdida de motivación del personal
• Falta de trabajo en equipo
• Error en la contratación
• Diferencias entre el personal de desarrollo y el cliente
• Falta de participación de los usuarios finales

Son muchos los riesgos potenciales que se pueden presentar en un proyecto de desarrollo de software. Para poder hacer una gestión adecuada, los riesgos se deben priorizar y seleccionar los más críticos para hacerles seguimiento y control. La criticidad de un riesgo depende de dos factores que hay que estimar: la probabilidad del evento y el impacto que pueda causar si el evento ocurre. De manera general cada riesgo debe definirse con el siguiente esquema:

Si evento entonces impacto. Por ejemplo:

Si la Curva de aprendizaje de las nuevas tecnologías es más larga de lo esperado entonces se tendrá retrasos importantes en el cronograma del proyecto.

Probabilidad del evento

Es difícil medir cuantitativamente la probabilidad del evento. Por esta razón, la probabilidad es una percepción subjetiva que debe ser contrastada entre los integrantes del grupo para obtener un valor de consenso. La probabilidad del evento la mediremos en: Alta, Media y Baja.

para entender la probabilidad asignada al evento de un riesgo es importante definir claramente el contexto en el que puede ocurrir y las razones para esa probabilidad. Por ejemplo, supongamos que al riesgo anterior le asignamos una probabilidad baja:

Ejemplo 1

Ejemplo 2

Impacto del riesgo

Si el riesgo se materializa, es decir, el evento se cumple, habrá un impacto sobre el proyecto. El valor de este impacto también es subjetivo y puede clasificarse en: Catastrófico, Moderado y Leve.

La valoración del impacto, tiene que considerarse en el contexto particular del proyecto. Por ejemplo, un riesgo asociado con la calidad del producto, el impacto es distinto si se trata de un software del que dependen vidas humanas a si se trata de un software más de apoyo a algún proceso de negocio. En el primer caso el impacto se puede considerar catastrófico mientras que en le segundo podría ser moderado.

Priorización de los riesgos

La cantidad de riesgos que pueden surgir en una lluvia de ideas del equipo de desarrollo puede ser alta. Clasificarlos y priorizarlos permite enfocarse en los que el equipo encontró como los más importantes. De esta manera el esfuerzo se invierte a conciencia de la importancia de cada riesgo, de manera que el equipo se compromete activamente en evitar que el riesgo se materialice en un problema, o en estar listo para enfrentarlo.

La importancia de un riesgo está en la combinación entre probabilidad del evento e impacto. Claramente un riesgo de probabilidad alta e impacto catastrófico debe ser manejado por el equipo de desarrollo. La lista de los riesgos que se van a manejar puede variar a lo largo del proyecto ya que no todos los riesgos se pueden identificar al comienzo del proyecto. Algunos pueden surgir por el camino.

El grupo de desarrollo decidirá cuántos riesgos podrá controlar y hacer seguimiento.

Controlar los riesgos

Para cada riesgo que se decida controlar se debe definir un conjunto de planes o acciones de mitigación. El objetivo puede ser disminuir la probabilidad del evento asociado con el riesgo o de disminuir el impacto que tendrá en ele proyecto si el evento se vuelve realidad.

Las acciones de mitigación deben incluirse en el plan del ciclo del proyecto. Para cada acción se debe tener claro cuál es el resultado esperado, debe tener responsables, participantes, estimaciones, etc. Por ejemplo, ante el riesgo de que el desconocimiento de la tecnología tarase el proyecto, el plan de mitigación puede ser estudiar la tecnología. sin embargo esto es muy abstracto y no se puede medir avance, así que se deben buscar acciones más concretas del estilo:

1. Cada desarrollado realiza el tutorial xyz (1h de trabajo)
2. Juan y José definen un modelo de arquitectura con la nueva tecnología para validar con el grupo (2h de trabajo)
3. etc.

Adicional a los planes de mitigación se debe hacer seguimiento a los riesgos. Esta es la actividad más importante de la administración de riesgos. Realizar un seguimiento permite darse cuenta de la efectividad de los planes de mitigación, y del acierto en la identificación y clasificación que se realizó de los riesgos del proyecto. El seguimiento debe ser corto de manera que los recursos invertidos sean mínimos. Ante proyectos complejos o con más probabilidad de riesgos el equipo debe invertir más cantidad de tiempo en hacer seguimiento.

Esta actividad se evalúa continuamente los siguientes puntos:

1. Los planes de mitigación puestos en marcha, junto con su efectividad.
2. Los posibles nuevos riesgos que aparecen.
3. Los riesgos que de manera positiva desaparecen.

Durante cada ciclo de desarrollo se hace una rápida revisión del avance de los planes de mitigación y se recogen impresiones de riesgos que acechan el proyecto. Los integrantes del equipo a través de las iteraciones desarrollan habilidades para estar atentos a posibles nuevos riesgos.