En mi proyecto sólo hemos detectado un par de riesgos

En la mayoría de los proyectos que inspeccionamos, nos encontramos unas mínimas listas de riesgos (entre dos y cinco, quizás diez). Quitando honrosas excepciones, el Jefe de Proyecto se limita a escoger algunos de entre los disponibles en alguna lista corporativa y a asignarles una probabilidad y un impacto casi al azar.

Agustín, nuestro auditor externo en las normas ISO 20000 e ISO 27001 y ya casi un amigo, me ilustró sobre el error que subyace bajo este planteamiento. Me comentó que cuando hablamos del riesgo alto o bajo en un proyecto, lo hacemos casi siempre de forma errónea.

El riesgo, o mejor el nivel de riesgo, es un simple número arbitrario. Es el producto de la probabilidad de que una amenaza aproveche una vulnerabilidad en nuestros activos por el impacto sobre dichos activos que puede suponer tal amenaza (en FMEA se introduce otro parámetro, la DETECTABILIDAD bastante interesante; hablaré de él un poco al final de este artículo)

La definición es una tanto rebuscada, lo sé. Pero esta frase esconde algunas joyas de conocimiento que intentaré sacar a la luz.

En la norma "ISO 31000 Gestión del Riesgo" aparece una definición mucho más sencilla, pero que va en la misma línea:

"El riesgo es el efecto de la incertidumbre sobre la consecución de los objetivos"

ACTIVOS, AMENAZAS Y VULNERABILIDADES

Para sacar partido a estas dos definiciones debemos considerar siempre tres conceptos cuando hablamos de riesgos: nuestros activos, las posibles vulnerabilidades que pueden presentar, y las amenazas que pueden aprovechar las mencionadas vulnerabilidades para impactar de forma negativa en el proyecto (si el efecto es positivo, estaremos hablando de oportunidades).

Por supuesto, todo proyecto se mueve en un entorno y, por tanto, puede verse afectado por aspectos tales como la seguridad, cambios en la legislación, catástrofes naturales, etc. Son aspectos a considerar pero aquí nos vamos a centrar en los que afectan más directamente a las operaciones.

De la última definición, se infiere que debemos conocer los objetivos de un proyecto para poder evaluar el riesgo. Y estos son, sencillamente, tres:

• Entregar a tiempo
• Entregar con calidad
• Entregar dentro de los costes planificados.

Además de los mencionados sobre cumplir con los requisitos derivados de la legalidad y normativas, de la seguridad, etc.

Por tanto, todos los proyectos tienen 3 activos, al menos tres, que presentan una serie de vulnerabilidades:

• Retrasarnos o adelantarnos en la entrega
• No pasar los procesos de validación internos o del cliente
• No cumplir con el presupuesto

Y estas vulnerabilidades pueden ser aprovechadas para llevar al fracaso a nuestro proyecto. Y aquí es donde aparecen las famosas listas de riesgos que, en realidad, lo son pero de amenazas. Y os doy algunos ejemplos:

• Riesgo de que un proveedor se retrase en la entrega. Es una amenaza sobre la planificación (el tiempo; puede suponer retrasarnos en una entrega) y/o el coste (quizás tengamos parado al equipo de desarrollo a la espera de algún componente)

• Riesgo consecuencia de la rotación o bajas por enfermedad. Es una amenaza sobre la planificación, el coste y, posiblemente, sobre la calidad. Sustituir a un miembro del equipo en mitad del proyecto supone costes de formación, retrasos hasta que se adapta y costes derivados de ellos

• Riesgo de retrasarme en la entrega. Ni es un riesgo, ni una amenaza. Es, como he dicho, una vulnerabilidad de uno de nuestros activos, la planificación

ANÁLISIS DE RIESGO

Aclarados estos conceptos (sé que algunos no estaréis de acuerdo con ellos) toca analizar el nivel de riesgo que presenta un proyecto y decidir si estamos dispuesto a aceptarlo o debemos actuar para mitigarlo.

Lo primero es que el riesgo debe evaluarse desde las tres perspectivas mencionadas: tiempo, calidad y coste. Y, por tanto, debe realizarse sobre la planificación del proyecto.

Lo ideal es evaluar el riesgo de cada una de las tareas que vamos a realizar. Quizás no una por una, pero sí debemos analizar en detalle las que conforman el camino crítico del proyecto, cierran una fase o constituyen un hito de entrega. Decir que "puede que me retrase en la entrega" no significa nada. ¿En qué entrega?, de la lista de actividades del proyecto, ¿en cuales tienes más riesgo de desviarte?, ¿en todas tienes la misma probabilidad de fracasar?, ¿todas las desviaciones tienen el mismo impacto sobre la planificación?.

Un análisis de riesgos realizado con un cierto nivel de madurez debe partir de la WBS (Workbreak Down Structure) y debe llegar hasta las actividades críticas allí  identificadas. Si hay cien quizás nuestra lista de amenazas tenga el mismo número de elementos o el doble, no pasa nada.

Identificadas las amenazas hay que proceder a analizar el nivel de riesgo que supone cada una de ellas. Evaluar la probabilidad exacta de que una vulnerabilidad sea explotada por una amenaza es un arte más propio de un nigromante que de un ingeniero. De ahí que surjan las escalas para ponderar estos dos factores y convertirlos, en última instancia,l en números que puedan procesarse.

Por ejemplo, en relación con el impacto sobre el coste, podemos considerar el porcentaje del presupuesto que puede verse afectado (1: <5%, 1: 5-10%, etc.). Consideración similares pueden realizarse para el tiempo. En cuanto a la calidad, es más frecuente utilizar escalas relacionadas con los procesos de verificación (interna) o validación (externa). Por ejemplo, la probabilidad de que un producto no supere las pruebas internas, que el cliente no acepte la entrega etc,

ACTUAR SOBRE LOS RIESGOS: PLANES DE MITIGACIÓN Y CONTINGENCIA

Sea como fuere, al final tendremos una lista de amenazas asociadas con las actividades críticas del proyecto y, para cada una de ellas, un nivel de riesgo consecuencia de multiplicar su probabilidad por su impacto. Si utilizamos escalas de 1 a 5 para estos factores tendremos un MAPA de RIESGO de 25 que suele representarse en una matriz con diferentes colores que no hacen sino indicar la relevancia de la amenaza y la necesidad de actuar sobre ella.

En la figura se aprecian tres niveles:

• Rojo: el nivel de riesgo está por encima del NIVEL TOLERABLE o aceptable por la organización. En teoría /y creo que en la práctica), un proyecto con un nivel de riesgo en este rango debería detenerse de forma inmediata hasta conseguir solucionar los problemas detectados. ¿De verdad seguiremos trabajando en un proyecto en el que con seguridad del 90-100% se producirá un problema que afectará al 30 o 40 por ciento de nuestro presupuesto?. No tiene sentido; hay que actuar estableciendo un PLAN DE MITIGACIÓN y ejecutándolo hasta que el nivel de riesgo baje a niveles aceptables. 

• Amarillo: el nivel de riesgo está por encima del NIVEL DE SEGURIDAD fijado por la organización. En este caso existen dos opciones: plantear acciones de mitigación que se ejecutarán mientras el proyecto sigue su curso normal o establecer un PLAN DE CONTINGENCIA que nos servirá para saber cómo actuar (para estar preparados) en caso de que la amenaza sobre nuestro activo se materialice

• Verde: el nivel de riesgo está por debajo del NIVEL DE SEGURIDAD y, por tanto, la organización acepta el riesgo. Nada que hacer más allá de realizar un seguimiento por si las condiciones cambiaran

SEGUIMIENTO DE LAS AMENAZAS

Lo más normal es encontrarse un proyecto que identifica un puñado de amenazas (riesgos) en la fase de arranque y descubrir que todas siguen en los mismos niveles de riesgos o similares en la fase de cierre. Pues bien, es de perogrullo, pero hay que recordarlo:

El nivel de riesgo tras la entrega y aceptación de un proyecto es siempre CERO

Esto implica que el nivel de riesgo de cada amenaza debería evolucionar (hacía arriba o hacia abajo) durante toda la vida del proyecto hasta ser cancelado al final del proyecto.

También me encuentro con frecuencia proyectos que se han retrasado en un entrega y siguen manteniendo una amenaza en la planificación. No es una amenaza es un hecho. No hay INCERTIDUMBRE al respecto, ya te has retrasado, no puedes hacer nada más que intentar no retrasarse más. La constatación de un retraso debe suponer el cierre del riesgo asociado (y no me refiero sólo a las entregas sino a cualquier actividad del proyecto) y una re-planificación del proyecto. De nuevo es necesario realizar un análisis del riesgo en el que aparecerá (o no) una nueva amenaza relacionada con el retraso en la planificación (si aparece te estás jugando el cuello, la organización no tiene una paciencia ilimitada)  pero no será la misma que ya se ha materializado.

COMPARTIR EL RIESGO CON EL CLIENTE

Es un tema tabú (más...). ¿Cómo le voy a decir al cliente que estoy casi seguro que me voy a retrasar?, ¿cómo le explico que la rotación en mi empresa es del 20% y que con cierta seguridad alguna de las personas claves del proyecto dejará la empresa antes de que éste finalice?. ¿cómo le justifico la participación de cada vez más juniors en el equipo o mi falta de confianza en las capacidad para entregar a tiempo de un proveedor?.

La respuesta es bien sencilla: se va a enterar. Más tarde o más temprano descubrirá que no les has entregado en la fecha prevista, o comprobará que lo que entregas no vale para nada (mucho peor que entregar tarde) y no les costará mucho suponer que estás incurriendo en costes más allá de los previsto.

Es mucho mejor adelantarle los problemas, las posibles amenazas y demostrarle que estás preparado.

LA DETECTABILIDAD

En la mayoría de los modelos se habla del nivel de riesgo como el producto de la probabilidad por el impacto. Pero no son los únicos factores que pueden considerarse.

Uno de los más complicados de analizar es la DETECTABILIDAD, propuesta en algunas metodologías como FMEA (Failure Mode and Effects Analysis) y en uso desde hace décadas en sectores como la automoción y, en general, la fabricación y que, ahora, se incorpora a las labores de ingeniería.

Básicamente (muy básicamente) se refiere a la capacidad que tenemos para detectar una amenaza cuando esta se materializa. En algunos casos nuestros sistemas de pruebas o nuestra falta de conexión con los procesos de producción hacen imposible detectar los problemas con la suficiente antelación.

Este factor se incorpora al nivel de riesgo de forma que:

Nivel de Riesgo= Impacto x Probabilidad x No-Detectabilidad

Si usamos una escala de 1 a 5, nos ofrece un MAPA DE RIESGOS de 125 valores mucho más refinado.

Establecer una escala para este factor es complicado pero puede emplearse algo similar a los siguiente:

• 5: el producto se entregará al cliente con fallos que no serán detectados en primera instancia
• 4: el producto se entregará al cliente quién detectará el fallo gracias a sus procesos de validación
• 3: el proceso de verificación interna no será capaz de detectar el problema pero sí es posible detectarlo antes de realizar la entrega (por ejemplo en un proceso de pruebas de integración)
• 2: el problema se detectará en la última fase de inspección
• 1: el problema se irá detectando a lo largo de la vida del proyecto y podrá ser corregido a tiempo

[Otras Frases Memorables...]

También te puede interesar:

• Sorprender al cliente, ¿una buena práctica de gestión?
• 17 Herramientas de Software Libre (totalmente gratuitas) para gestionar proyectos
• Aprender de las lecciones aprendidas
• Los clientes valoran la flexibilidad de mi empresa
• Mi proyecto es un tanto peculiar
• Me cuesta más planificarlo que hacerlo
• Cada práctica de CMMI le ha costado el puesto a un Director Técnico