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:
-
Alto
-
Significativo
-
Moderado
-
Menor
-
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.
|
|