Tarea: Identificar y valorar los riesgos
En esta tarea se describe cómo identificar, analizar y priorizar los riesgos del proyecto, y cómo determinar las estrategias de gestión de riesgos adecuadas y reflejarlas en la lista de riesgos del proyecto.
Disciplinas: Gestión de proyectos
Objetivo
  • Identificar, analizar y priorizar los riesgos del proyecto
  • Determinar las estrategias de gestión de riesgos adecuadas
  • Actualizar la lista de riesgos para reflejar el estado actual del proyecto
Relaciones
Pasos
Identificar los riesgos potenciales
Objetivo Crear un inventario de 'qué puede salir mal' con el proyecto.  

Para iniciar la lista de riesgos (en la fase inicial):

Reúna al equipo del proyecto (que en este punto debe ser pequeño; si hay más de cinco a siete personas en el equipo del proyecto, limite el proceso de valoración de riesgos a los líderes de las actividades).

Cuando identificamos los riesgos, consideramos 'qué puede salir mal'. Desde luego, llevado al extremo, todo puede salir mal. No obstante, el objetivo es no proyectar una visión pesimista en el proyecto; deseamos identificar las barreras potenciales del éxito para poder así reducirlas o eliminarlas. Para obtener más información, consulte Directriz de producto de trabajo: Lista de riesgos.

Más en concreto, buscamos los sucesos que se pueden hacer que disminuya la probabilidad de entregar el proyecto con las características adecuadas, el nivel de calidad requerido, a tiempo y dentro del presupuesto.

Utilizando técnicas de tormenta de ideas, pida a cada miembro que identifique un riesgo del proyecto. Se permiten preguntas aclaratorias, pero los riesgos no se deben evaluar ni comentar en grupo. Vaya uno a uno hasta que no se puedan identificar más riesgos.

Implique a todas las partes en este proceso, y no se preocupe del formato ni de las repeticiones; la lista se puede pulir más adelante. Utilice grupos homogéneos de personas (clientes, usuarios, técnicos, etc.). Esto facilita el proceso de recopilación de riesgos; las personas se sienten menos cohibidas frente a sus iguales (en especialidad y jerarquía) que en un grupo mixto.

Deje claro a los participantes que proponer un riesgo no significa de ninguna forma ofrecerse como voluntario para solucionarlo. Si existe la impresión de que proponer un riesgo implica ser responsable de su solución, nadie identificará ningún riesgo (o los riesgos que identifiquen serán triviales).

Para empezar, pruebe a comenzar con listas de riesgos genéricos, tal como se describe en Valoración y control de riesgos de software de Capers Jones [JON94] o la Identificación de riesgos basada en taxonomías establecida por el Software Engineering Institute [CAR93]. Haga circular la lista de riesgos: ver qué se ha identificado hasta el momento puede ayudar a identificar nuevos riesgos.

Para actualizar la lista de riesgos (en fases posteriores):

Puede solicitar información tal como se ha identificado anteriormente. Pero, en general, basándose en el ejemplo de la lista existente, los miembros del equipo identificarán nuevos riesgos, que se capturarán en la Valoración de estado del proyecto normal. Consulte Tarea: Valorar iteración.

Analizar y priorizar los riesgos
Objetivo Combinar riesgos parecidos (para reducir el tamaño de la lista de riesgos).
Crear un rango de riesgos según su impacto en el proyecto.  

Cuando no se encuentren más riesgos, observen la lista de riesgos en grupo para ver si existen agrupaciones naturales (apariciones del mismo riesgo), y combinen los riesgos allí donde sea posible para eliminar duplicados. A veces, los riesgos identificados serán síntomas de un riesgo más fundamental; en este caso, agrupe los riesgos relacionados debajo del riesgo más básico.

Las técnicas cuantitativas de gestión de riesgos recomiendan priorizar los riesgos de acuerdo con la exposición general que representa el riesgo para el proyecto. Para determinar la exposición de cada riesgo, el grupo debe calcular la siguiente información:

Impacto del riesgo  Las desviaciones en cuanto a planificación, esfuerzo o costes si se produce el riesgo 
Probabilidad de aparición  La probabilidad de que el riesgo ocurra realmente (normalmente expresada en forma de porcentaje) 
Exposición del riesgo  Se calcula multiplicando el Impacto por la probabilidad de aparición 

En grupo, la exposición de cada riesgo se debe derivar por consenso. Las principales diferencias de opinión se deben debatir más adelante para ver si todos interpretan el riesgo de la misma forma. Normalmente, esta información se incluye en forma de columnas en una Lista de riesgos tabular.

Es humano preocuparse por los riesgos de mayor impacto pero, si no es muy probable que ocurran, realmente son menos importantes que los riesgos moderados que se suelen pasar por alto. Si se considera la magnitud del riesgo y su probabilidad de aparición, este enfoque ayuda a los gestores de proyectos a centrar sus esfuerzos de gestión de riesgos en áreas que tendrán el efecto más significativo en la entrega del proyecto.

Una vez determinada la exposición de cada riesgo, puede ordenar los riesgos en orden de exposición decreciente para crear la Lista de los 10 primeros riesgos.

Como el cálculo de la probabilidad y el coste es caro y arriesgado en sí mismo, generalmente sólo se recomienda medir el impacto de los 10-20 primeros riesgos. Los proyectos más pequeños pueden considerar menos riesgos, mientras que los proyectos más grandes presentan un 'destino de riesgos' mayor y, como resultado, tienen un mayor número de riesgos relevantes.

Además de crear un rango de los riesgos en orden de exposición descendente, también se recomienda agrupar los riesgos en categorías, basándose en la magnitud de su impacto en el proyecto (magnitud del riesgo). En la mayoría de casos, cinco categorías es suficiente:

  1. Alto
  2. Significativo
  3. Moderado
  4. Menor
  5. Bajo

Documente los riesgos y distribúyalos entre los miembros del equipo del proyecto.

Identificar estrategias de elusión
Objetivo Reorganizar el proyecto para eliminar riesgos 

Aunque no siempre sea posible, a veces se pueden evitar los riesgos. A menudo, los riesgos vienen provocados por un ámbito del sistema mal definido; si puede reducir el ámbito del sistema (eliminando los requisitos no fundamentales), secciones completas de la lista de riesgos se vienen abajo con los requisitos eliminados. Un riesgo no menos importante es no tener suficientes recursos (incluido el tiempo) para hacer el trabajo.

En otros casos, se puede adquirir la tecnología para reducir el riesgo de crear una determinada funcionalidad, una forma de elusión de riesgos en la que un conjunto de riesgos (crear la tecnología) se intercambia por otro (depender de fuerzas que están fuera de su control).

Por último, los riesgos se pueden transferir a otras organizaciones.

Identificar estrategias de mitigación de riesgos
Objetivo Desarrollar planes para mitigar los riesgos, esto es, para reducir el impacto de los riesgos.  

Para los riesgos directos, esto es,  los riesgos en los que el proyecto tiene algún grado de control, identifique qué acciones se deben llevar a cabo para reducir la probabilidad del riesgo, o para reducir su impacto en el proyecto (las estrategias de mitigación). Normalmente, el riesgo se deriva de la falta de información; a menudo, la propia estrategia de mitigación consisten en investigar el tema más a fondo para reducir la incertidumbre.

Existen riesgos en los que se puede realizar alguna acción para materializarlos o retirarlos. En un proceso de desarrollo iterativo, asigne esas acciones a las primeras iteraciones para mitigar el riesgo lo antes posible. Confronte los riesgos lo antes posible. Si un riesgo tiene la forma "¿puede que X no funcione según lo previsto?", intente X lo antes posible.

Ejemplos:

  • Para reducir el riesgo de que los productos X e Y no se puedan integrar, se creará un prototipo para investigar la dificultad de la integración. Las siguientes características (enumerar en una lista) se probarán para garantizar que la integración es satisfactoria.
  • Para reducir el riesgo de que la Base de datos A no funcione correctamente, se ejecutará un estándar de comparación utilizando un conjunto de pruebas que modelen la carga de trabajo de la aplicación de destino.
  • Para reducir el riesgo de que la herramienta de prueba Z no pueda realizar una prueba de regresión eficaz en la aplicación, se adquirirá y se utilizará durante la próxima iteración.

El resultado de estas acciones debe ser reducir la probabilidad de que se produzcan determinados riesgos, quizás a un valor próximo a cero. En aquellos casos en los que se confirme el riesgo, se debe responder a él con un plan de contingencia (Consulte Identificar estrategias de contingencia).

Identificar estrategias de contingencia
Objetivo Desarrollar planes alternativos 

Para cada riesgo, tanto si tiene un plan para mitigarlo como si no, debe decidir qué acciones se deben realizar y cuándo, o si el riesgo se materializa, esto es, si se convierte en un problema, un 'evento de pérdidas', como se denomina en la jerga de seguros. Esto se denomina normalmente "un plan 'B'" o plan de contingencia. El plan de contingencia es necesario cuando la elusión de riesgos y la transferencia de riesgos han fallado, la mitigación no ha sido satisfactoria, y ahora el riesgo debe afrontarse directamente. Muchas veces este es el caso con los riesgos indirectos, es decir, los riesgos para los que el proyecto no tiene ningún control, o cuando las estrategias de mitigación son demasiado costosas de implementar.

El plan de contingencia debe considerar:

Riesgo 

Indicador 

Acción 

¿Cuál es el riesgo?  ¿Cómo sabrá que el riesgo se ha convertido en una realidad? ¿Cómo se reconoce el 'evento de pérdidas'?  ¿Qué debe hacer para solucionar el 'evento de pérdidas' (¿cómo puede detener la "brecha"?) 

Identificar indicadores de riesgos

Algunos riesgos se pueden supervisar utilizando la métrica del proyecto, observando las tendencias y el umbral; por ejemplo:

  • La revisión permanece muy alta
  • La ruptura permanece muy alta
  • El gasto real sobrepasa los planes

Algunos riesgos se pueden supervisar basándose en los requisitos del proyecto y los resultados de las pruebas; por ejemplo:

  • Los tiempos de respuesta están un orden de magnitud por encima del requisito.

Algunos riesgos se asocian con el suceso específico; por ejemplo:

  • Componente de software no entregado a tiempo por terceros.

Existen muchos otros indicadores "más sutiles", ninguno de los cuales diagnosticará completamente el problema. Por ejemplo, existe siempre el riesgo que la moral decaiga (de hecho, en determinados puntos del proyecto, esto es prácticamente previsible). Los indicadores son varios: quejas, "humor negro", horas límite incumplidas, baja calidad, etc. Ninguna de estas "medidas" es un indicador seguro; bromear sobre la inutilidad de un determinado entregable puede ser una forma saludable de liberar la tensión, pero si continúa, puede ser un indicador de que el equipo tiene latente una sensación de desastre cada vez mayor.

Atienda a todos los indicadores sin emitir ningún juicio. Es fácil etiquetar al portador de 'malas noticias' como alguien que tiene una actitud incorrecta; detrás del cinismo hay bastante de cierto. A menudo, el 'portador de las malas noticias' actúa como la 'conciencia del proyecto'. Todos desean que el proyecto sea un éxito y se sienten frustrados si la tendencia lo lleva en la otra dirección.

Identifique las acciones de "pérdida", o el "Plan B"

En los casos más simples, el plan de contingencia enumera soluciones alternativas. El impacto suele ser de costes y retardos para descartar la solución actual e implementar una nueva.

Para otros riesgos "más sutiles", el plan no supone la realización una acción cuando se ha producido una pérdida, sino de varias. Por ejemplo, cuando la moral decae, es mejor reconocer la condición y reunirse en grupo para debatir las actitudes que prevalecen en el proyecto. Escuche las preocupaciones, identifique los problemas y en general deje que las personas se desfoguen. Eso sí, después de desfogarse, empiece a centrarse en las causas de los problemas. Utilice la lista de riesgos para centrar el debate. Traduzca las preocupaciones en un plan de acción concreto; para ello, vuelva a priorizar los riesgos y a formular los planes de iteración para enfocar de forma sistemática los principales riesgos. Una acción positiva tiene un mayor efecto que las palabras positivas (pero vacías).

A pesar del ánimo del momento, la aparición de una pérdida tiene un lado positivo: obliga a la acción. A menudo, es fácil posponer los riesgos, ignorándolos, adormecidos en la complacencia de la tranquilidad aparente. Cuando se produce un evento de pérdidas, se necesita una acción. El riesgo ya no es un riesgo, no existe ninguna incertidumbre sobre su aparición.

No obstante, la aparición de una pérdida también es un error de elusión o mitigación del riesgo. Debe forzar un repaso de la lista de riesgos para determinar si el equipo del proyecto tiene algunos puntos ciegos sistemáticos. Aunque la autovaloración sincera es difícil, puede impedir la aparición de otros problemas en el futuro.

Revisar los riesgos durante la iteración
Objetivo Garantizar que la lista de riesgos se mantenga actualizada durante todo el proyecto.  

La valoración de riesgos es realmente un proceso continuo, no es un proceso que se realice sólo en intervalos específicos durante el proyecto. Como mínimo, debe:

  • Revisar la lista semanalmente para ver qué ha cambiado.
  • Hacer que estén visibles los primeros diez elementos para todo el proyecto, e insistir en las acciones que se deben realizar para ellos. A menudo, deberá adjuntar la lista de riesgos actual a los informes de Valoración de estado.
Revisar los riesgos al final de la iteración
Objetivo Garantizar que la lista de riesgos se mantenga actualizada durante todo el proyecto.  

Al final de una iteración, vuelva a centrarse en los objetivos de la misma en cuanto a la lista de riesgos. Específicamente:

  • Elimine los riesgos que se hayan mitigado totalmente.
  • Introduzca nuevos riesgos que se hayan descubierto recientemente.
  • Vuelva a valorar la magnitud y a ordenar la lista de riesgos (consulte Analizar y priorizar riesgos).

No se preocupe demasiado si descubre que la lista de riesgos aumenta durante las fases inicial y de elaboración. A medida que los miembros del proyecto realizan su trabajo, descubren que algo que consideraban trivial realmente implica algunos riesgos. Cuando empiece a realizar la integración, encontrará algunas dificultades ocultas. No obstante, los riesgos deben empezar a disminuir regularmente cuando el proyecto alcance el final de la elaboración y durante la construcción. De lo contrario, puede que no esté manejando los riesgos correctamente o que el sistema sea demasiado complejo, o que sea imposible crearlo de forma sistemática y previsible. Para obtener más información, consulte Directriz de producto de trabajo: Lista de riesgos.