Gestion de riesgo en Proyectos

En mi opinión, uno de los grandes olvidados en lo tocante a la Dirección de Proyectos es, sin duda, la Gestión de Riesgos…. y eso a pesar de ser una de las disciplinas que más impacto tienen en el éxito (o fracaso) del proyecto. En mi opinión, su uso es lo que diferencia a un buen Director de Proyectos de uno malo.

La gestión de riesgos se ha asociado históricamente a la Seguridad de la Información, y en este contexto se entiende que el riesgo es la “probabilidad de que una amenaza se materialice sobre un activo explotando una vulnerabilidad y produciendo un impacto”

En la gestión de proyectos, la definición varía ligeramente, dado que se entiende como riesgo cualquier “evento incierto, que de ocurrir afectaría positiva o negativamente al menos un objetivo del proyecto (coste, tiempo, alcance)” es decir, al Triangulo de la Gestión de proyectos o triple restricción. Uno de los primeros aspectos que choca al CIO no iniciado en esta disciplina es el hecho de que un riesgo no es algo necesariamente negativo: puede ser un evento que, de suceder, mejoraría alguno de los objetivos del proyecto.

Por ejemplo, en un proyecto en el que se han comprometido un gran volumen de compras de material en Estados Unidos, uno de los eventos inciertos es el tipo de cambio del dolar. Y su variación puede ser negativa para los efectos del proyecto (sube el precio del dolar) o positiva (baja el tipo del dolar, con lo que nos gastamos menos que lo inicialmente previsto).

El gestionar riesgos involucra maximizar la probabilidad de ocurrencia y efectos de eventos positivos (oportunidades) y minimizar la probabilidad y efectos de eventos negativos (amenazas).

El primer paso que debemos acometer sucede en la fase de Planificación del Proyecto, en la que deberemos plantear cómo se va a abordar la gestión de riesgos en el proyecto (periodicidad, procedimientos estándar…etc.). De igual modo, y siempre antes del comienzo, se debe preparar un listado preliminar de los riesgos (positivos o negativos) que es factible que sucedan en el proyecto, incluyendo al menos:

Definición del riesgo, y posible impacto en el proyecto.
Posibles causas que originan su aparición
Respuestas que pueden ser adoptadas para mitigar su impacto
Categoría a la que pertenecen
Riesgos similares en ese tipo de proyectos
Estos dos últimos puntos son especialmente interesantes, y enlazan con una de mis obsesiones principales: las “lecciones aprendidas”. Cuando se ha abordado un buen número de proyectos, se descubre que en muchos de ellos se repiten invariablemente un número de riesgos (que luego encima se materializan!)… y que se podrían haber evitado si alguien los hubiera recogido, categorizado e incluido en el registro de lecciones aprendidas.

Mi consejo en este sentido es que dispongamos de una serie de riesgos estándar, agrupados por categorías, que se repiten habitualmente en cada tipo de proyectos, de forma que ésta sea la lista a partir de la cual empezar a pensar cuando se aborda un nuevo proyecto, lo que evitará “reinventar la rueda” cada vez.

En la próxima entrada intentaré esbozar la mejor forma de identificar los riesgos y valorarlos… y cómo realizar su seguimiento, autentica “piedra de toque” de la gestión de riesgos. Como dice uno de mis proverbios favoritos:

“Una vaca desconoce lo que vale su rabo hasta que lo pierde”

gestiones
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:
de riesgo

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
en proyectos
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