Dirección de Proyectos/Planificación de los riesgos del proyecto

Este ámbito de la planificación de riesgos dentro de la dirección de proyectos se compondría de los siguientes apartados:

Identificación de los riesgos del proyecto.
Riesgos a evitar en el software.
Análisis cuantitativo y cualitativo de riesgos.
Elección del modelo de software a desarrollar.
Preparación de un plan de resolución de riesgos.

Una posible definición de riesgo puede indicar que se trata de un evento que puede tener una resolución negativa o positiva. Para la realización de cualquier actividad de riesgo, se debe calcular si la recompensa una vez realizada dicha actividad, suple y sopesa la inversión. Una de las tareas más duras en la gestión de proyectos es precisamente la gestión de riesgos. Los principales supuestos de riesgo en los proyectos de software son los siguientes:

Tiempo inadecuado para completar el proyecto.
Presupuesto inadecuado para completar el proyecto.
Expectativas poco realistas.
Indefinición o ambigüedad de requisitos.

4.3.1 Identificación de riesgos

El riesgo no es necesariamente una cuestión negativa en un proyecto. Además, no es posible considerar todos los imaginables riesgos dentro de un proyecto. Los riesgos positivos han de verse como oportunidades. Se podría hacer una pequeña clasificación que ayude a delimitar los riesgos del negocio:

Riesgos reales o puros. Son aquellos que implican solo riesgos negativos, como la pérdida de una vida, un incendio u otra catástrofe de esta índole.
Riesgos del negocio. Estos son realmente los que se refieren a los riesgos de la dirección de proyectos. Un ejemplo sencillo de riesgo, podría ser contratar a un trabajador con poca experiencia para que ahorre dinero del presupuesto de un proyecto.

4.3.2 Evaluación de riesgos

Los riesgos más comunes dentro de un proyecto software pueden ser los siguientes:

Cese por cualquier causa de algún empleado en el proyecto.
Errores en la toma requisitos.
Software lleno de errores y fallos.
Los requisitos del proyecto crecen pero no su presupuesto.
La expectación acerca del tiempo, el presupuesto y el ámbito que puede alcanzar el proyecto no son realistas.
Los clientes no son capaces de expresar los requisitos del proyecto como es necesario, y se crea una situación confusa.

4.3.3 Riesgos en los proyectos software relativos a la tecnología

Se compondrían de los siguientes tipos:

La velocidad del desarrollo tecnológico.
Un retraso en el calendario acorta la ventana de la necesidad del proyecto que se esté desarrollando.
La adaptabilidad del personal a nuevos lenguajes y metodologías.
Clientes que invierten demasiado tiempo para exponer y dilatar sus requisitos.
Fuga de conocimiento en el capital humano del proyecto.
Proyectos pioneros tienen riesgos intensos en investigación, incluso puede que al borde de la I+D+i, con lo que un desarrollo de este tipo puede implicar en riesgos de presupuesto y adquisición de conocimiento.

4.3.4 Determinación de la tolerancia de riesgo de la organización

La tolerancia al riesgo por parte del cliente va a oscilar en dos ejes como indica el siguiente diagrama, la posibilidad de ocurrencia frente a la dureza que pueda producir en el impacto del desarrollo del proyecto:

4.3.5 Gestión de riesgos

Cada organización tiene su propia forma de gestionar los riesgos. Algunas consideraciones fundamentales para alcanzar una gestión óptima de los riesgos se mantienen determinando los siguientes aspectos:

Identificación de riesgos: La identificación más común en este caso puede ser el análisis cualitativo. Se trataría de crear una escala de riesgos basada en los propios riesgos identificados en el proyecto. Métodos posibles para la identificación de riesgos son los siguientes:
Brainstorming.

Método Delphi.
Creación de una escala de riesgos: Después de identificar los riesgos se trataría de crear una matriz de riesgos. Pueden existir dos tipos:
Ordinal. Se clasificarían sólo como alto, medio o bajo.
Cardinal. Se clasificarían con una calificación numérica.

Para cada riesgo el equipo de proyecto debe andar los siguientes pasos:

Evaluación de la probabilidad del riesgo.
Puntuar cada riesgo.
Multiplicar la probabilidad por el impacto y obtener la matriz de puntuación.

Un ejemplo de matriz de riesgos cualitativa podría ser:

Un ejemplo de matriz de riesgos cuantitativa podría ser:

4.3.6 Elección de modelos de software para la gestión de riesgos

Dentro del desarrollo de software hay modelos que permiten más tolerancia riesgos que otros:

Modelo en cascada. Como podría evidenciar este modelo, a pesar de su simplicidad, mantiene grandes desventajas en el instante en que se rompa un eslabón de este modelo encadenado.
Modelo en espiral. Este modelo es el mejor para la contingencia de riesgos. Está diseñado naturalmente para este propósito entre otros. Aunque es cierto que es más costoso en cuanto a tiempo y presupuesto para llevarlo a cabo, especialmente en proyectos pequeños, incluso en los cuales puede ser contraproducente, ya que puede existir la paradoja de que cueste más implantar el modelo de desarrollo que el propio proyecto y los beneficios de esta adopción.
Modelo en V. El modelo en V presenta una fase de comprobación dentro de cada fase del modelo. Se puede observar en la siguiente figura:

4.3.7 Preparación de un plan de respuesta para los riesgos

A menos que el modelo de desarrollo incluya dicho plan de respuesta, se debe de diseñar un plan de respuesta para éstos. Se pueden utilizar diferentes estrategias:

Evitar los riesgos. Evidentemente sería la estrategia idónea para cualquier caso. Implicaría una planificación creativa, asignación de actividades clave a desarrolladores senior, y múltiples actitudes y recomendaciones óptimas para cada evento y tarea del proyecto. Por tanto, evitar los riesgos consiste en:

 a.	Cambiar el plan de proyecto para evitar las interrupciones de los posibles riesgos.
 b.	Usar un modelo de desarrollo contrastado y establecido preferentemente a innovaciones caseras.
 c.	Consultar a expertos durante el desarrollo del proyecto.
 d.	Invertir tiempo adicional necesario con los clientes para clarificar al máximo los requisitos.

Transferir los riesgos. Consistiría en aprender de la externalización de los riesgos, ya que la organización actualmente no podría atenderlos, al menos si se podría contratar un equipo de expertos que pueda contenerlos, que además podrá servir para aprender convenientemente para nuevos proyectos.
Minimización de riesgos. Se trataría de reducir o mitigar el impacto o la probabilidad del riesgo. Esta estrategia parte de los análisis cualitativos y cuantitativos comentados. La estrategia de minimización implica:

 a.	Añadir comprobación redundante.
 b.	Reducir el número de procesos, actividades, dentro del flujo de un proyecto.
 c.	Desarrollo y prueba de prototipos.

Aceptación de los riesgos. Al menos aceptar un riesgo implica menos impacto que encontrarlo inesperadamente. De hecho, cualquier riesgo no identificado se ha de aceptar automáticamente. Esta estrategia sería correctiva.