Gestion de Riesgos en Proyectos (II)

Tal como veíamos en el post anterior, la gestión de riesgos es una de las actividades clave de la Dirección de Proyectos, y en muchos casos una de las que menos atención reciben.
Tras plantear cómo se van a gestionar estos riesgos, el primer paso que debemos acometer es su identificación. Anteriormente hablamos de la necesidad de identificar el riesgo, entender las causas que los originan, clasificarlos… pero no profundizamos en el detalle.

Existen varias técnicas para identificar a que riesgos se enfrenta el proyecto, y que serán utilizadas en base al tamaño del proyecto, experiencia previa en proyectos similares, madurez de la organización …etc:

• Tormenta de Ideas (BRAINSTORM):  Técnica clásica, en la que se prentende obtener un número alto de ideas creativas en un entorno más relajado. Su característica más interesante es que el juicio de las ideas emitidas se realiza al final, intentando que éste no condicione a otras posibles ideas relacionadas.
• Análisis DAFO (SWOT): Una técnica heredada del entorno de gestión estratégica y marketing, y cuyo objetivo es plantear el estudio desde los puntos de vista que lo caracterizan: Interno (Debilidades y Fortalezas) y Externo (Amenazas y Oportunidades)
• Técnicas Delphi: Básicamente consiste en consultar de forma anónima a un grupo de expertos en el tema sobre los riesgos que ellos consideran posibles, y con las respuestas se realiza una nueva ronda hasta que los riesgos están perfectamente caracterizados. Útil para entornos donde puede haber reacciones negativas de la interacción de los implicados (por ejemplo, implicando a varias capas organizativas).
• Entrevistas: Método clásico, utilizado sobre todo cuando ya existe cierto conocimiento sobre los riesgos internos del proyecto, pero no sobre los específicos al proyecto a abordar.

Existen otros métodos utilizados en este tipo de análisis (como la identificación de causa raíz, habitual del entorno de la calidad), pero en mi experiencia los anteriores son los más utilizados en el mundo de las TI. En cualquier caso, la identificación debe habernos permitido recopilar al menos la información plasmada en la tabla siguiente (aproximación muy rudimentaria, ojo), y que incluye un ejemplo habitual en los entornos pre-crisis y que se vuelve a dar ahora, aunque por motivos diferentes:

Resulta muy interesante la información anterior… pero no está orientada a la acción: Imaginemos la tabla anterior completamente rellena con todos los riesgos del proyecto… sirve para algo? Para que la respuesta sea afirmativa, deberíamos por un lado decidir qué riesgos se deben tratar y cuáles no, así como encontrar una forma para valorarlos de la forma más objetiva posible… es decir, debemos priorizar los riesgos para poder focalizar esfuerzos.

Hay dos formas no solapadas de hacer esto, en función de lo importante de los riesgos: para la mayoría de los riesgos querremos hacer una valoración menos exhaustiva, con cierto componente subjetivo, denominada Análisis Cualitativo de Riesgos. Para los riesgos que, por su importancia, queramos cuantificar su impacto económico y probabilidad de forma más “objetiva”, realizaremos un Análisis Cuantitativo de Riesgos .

El análisis cualitativo pretende, en base a criterios subjetivos pero tipificados (ahora ampliaremos el significado de este palabro) identificar el impacto de que se produzca un riesgo y su probabilidad. Para ambas variables se definen escalas (Por ejemplo, en el caso de impacto, podemos definir una escala de 1 a 5, siendo 1 que el proyecto incremente su coste en menos de un 5% y siendo 5 que el proyecto incrementa el coste en más de un 50%. En el caso de la probabilidad, 1 podría ser que sucede 1 vez cada 100 proyectos y 5 que pasa en el 100% de proyectos).

Una vez disponemos de todos los riesgos con estas variables rellenas, pasamos a introducirlos en una matriz de riesgos, también conocida como “matriz PxI”, lo que nos da una visión gráfica de su importancia. El último paso (que en realidad deberíamos haber tomado en la fase de planificación) es definir el umbral de tolerancia a riesgos, o umbral de riesgo. Este umbral básicamente define “hasta donde nos preocupan los riesgos”, es decir… para que riesgos debemos preparar ya una estrategia de respuesta (o incluso de contingencia) y cuales simplemente quiero “vigilar”. El siguiente gráfico creo que ilustra bien el concepto: los riesgos que caigan en rojo son aquellos que hay que tratar YA (o al menos plantear una respuesta), los que caigan en amarillo son riesgos “a vigilar de cerca” y los verdes son riesgos residuales, es decir, riesgos para los que asumiremos las consecuencias si suceden.

Para los riesgos “rojos” puede resultar conveniente realizar un análisis más exhaustivo en el que se valore el impacto económico de que el riesgo se materialice, es decir, un Análisis Cuantitativo. Es un proceso laborioso, ya que supone analizar y entender el impacto económico de que cada uno de los riesgos se materialice.

Para ello deberemos asignar un valor económico al impacto (I), que deberíamos asumir en el caso de que ocurriera el riesgo, y una probabilidad (P) de ocurrencia (porcentual, por ejemplo)… con lo que obtendríamos el valor esperado (VE) del riesgo, es decir, VE=PxI.
Tras esto, y en cualquiera de los dos enfoque, deberemos desarrollar para los riesgos que se encuentren por encima del umbral de riesgos un Plan de Respuesta a Riesgos.
Y.. ¿acaban aquí las tareas relacionadas con la gestión de riesgos? Pues no, en realidad es precisamente aquí donde empiezan!! Como comentábamos al principio, es este el aspecto que diferencia a un buen Director de Proyectos de uno malo… pero que trataremos, junto con la respuesta a riesgos, en el futuro