Análisis de Riesgo de Cronograma: ¿Qué es y por qué lo hace?

«En estos asuntos la única certeza es que nada es seguro.» (Plinio el Viejo)

Los planes de proyecto son, por supuesto, sobre el futuro, y todo lo relacionado con el futuro tiene cierta incertidumbre asociada. Cuando se estima que la duración de una tarea es de 5 días, se acepta que esto probablemente no será precisamente cierto. Puede haber una pequeña cantidad de incertidumbre o una gran cantidad, pero definitivamente hay algo.

Como resultado de esta incertidumbre sobre la duración de las tareas, cualquier estimación de la finalización del proyecto es sólo eso, una estimación. Sólo será válido en la medida en que las estimaciones de la duración de las tareas resulten ser ciertas. Dado que generalmente hay muchas tareas, es casi seguro que muchas de ellas llevarán menos tiempo del estimado, mientras que otras tomarán más tiempo del estimado.

Por lo tanto, en realidad, es probable que el final del proyecto no sea el proyectado por un CPM o PERT determinista, sino que se encuentre en algún lugar dentro de un rango de fechas que podrían estar distribuidas simétricamente en torno a esa estimación. (En realidad es peor que eso. Como se discutirá más adelante, el uso de estimaciones deterministas también introduce sesgos, de manera que estas estimaciones tienden a ser sistemáticamente optimistas.)

El Análisis de Riesgo de Cronograma es una técnica que reconoce esta incertidumbre reemplazando la duración determinista para cada tarea por una distribución que representa el rango de duraciones probables. Existen métodos analíticos para procesar distribuciones de probabilidad en casos sencillos, pero las redes de proyecto suelen ser demasiado complicadas para que sean aplicables.

La solución es utilizar la simulación de Monte Carlo. Esto es un poco como simular un evento de la vida real lanzando dados, excepto que se hace en una computadora. Las computadoras pueden generar lo que se llama números pseudo-aleatorios. Estos no son verdaderamente aleatorios, en el sentido de que pueden ser reproducidos si se conoce el mecanismo generador, pero en ausencia de ese conocimiento pasan sofisticadas pruebas estadísticas diseñadas para identificar cualquier no-aleatoriedad. Utilizando estos números pseudo-aleatorios, se pueden generar muestras de cualquier distribución deseada, y éstas se utilizan en la simulación de Monte Carlo para simular sistemas físicos sobre un gran número de escenarios generados aleatoriamente.

La simulación Monte Carlo tiene aplicaciones en muchas áreas. En el contexto de una red de proyectos, la simulación de Monte Carlo:

1. toma una muestra de la distribución definida por el usuario para cada duración de la tarea;
2. realiza un análisis de la RPC basado en estas duraciones muestreadas;
3. almacena los resultados de este análisis de tiempo (generalmente en forma de resumen como un histograma); y
4. repite los pasos 1 a 3 varios cientos o miles de veces.

Al final de este proceso puede producir histogramas que representen las distribuciones de probabilidad de cualquier resultado de interés calculado, que generalmente incluyen fechas de inicio y fin anticipadas y tardías, holguras libres y totales y coste de cada tarea.

Como resultado, la fecha estimada de finalización del proyecto y otros hitos importantes están representados por distribuciones de probabilidad en lugar de estimaciones de punto único. En lugar de predecir que el proyecto se completará en una fecha determinada -una predicción que casi con toda seguridad se demostrará que es errónea-, se pueden hacer predicciones más realistas como «hay un 90% de posibilidades de que el proyecto se complete para el 31 de mayo».

Pero quizás la razón más importante para hacer el análisis de riesgo es el sesgo mencionado anteriormente, lo que significa que la estimación de un solo punto de finalización del proyecto realizada por CPM o PERT determinista a menudo ni siquiera está dentro del rango representado por la distribución de probabilidad producida por el análisis de riesgo. La razón de esto es un fenómeno llamado sesgo de fusión.

El sesgo de fusión ocurre cuando dos o más rutas convergen en una red y la incertidumbre sobre su duración es tal que cualquiera de ellas puede resultar crítica. Para ilustrar el sesgo de fusión, considere una tarea que sólo tiene dos predecesores que funcionan en paralelo. Suponga que cada uno de ellos puede tardar de 1 a 6 días con la misma probabilidad. Y supongamos además que no tomarán fracciones de un día. (Esto puede sonar bastante artificioso, y lo es. Sin embargo, permite que el punto se haga por analogía con el lanzamiento de dados y sin involucrarse en mucho cálculo.)

La duración esperada de cada una de las tareas individuales es, por supuesto, de 3,5 (1+2+3+4+4+5+6 dividido por 6). Pero, ¿cuál es el tiempo esperado para que ambos estén completos? La siguiente tabla muestra los 36 resultados posibles para el par de tareas, que se pueden simular lanzando dos dados. (Así, por ejemplo, si la primera tarea toma 5 días y la segunda sólo 3 días, el tiempo necesario para que ambas se completen, 5 días, puede consultarse en la tabla.

1

2

3

4

5

6

1 1 2 3 4 5 6 2 2 2 3 4 5 6 3 3 3 5 6 4 4 4 4 4 5 6 5 5 5 5 5 5 6 6 6 6 6 6 6 6

De las 36 posibilidades, sólo una tiene 1 como máximo mientras que no menos de 11 tienen 6 como máximo. Así que con sólo dos trayectorias paralelas se puede ver que el tiempo que tardan ambas tareas en completarse es probable que sea más largo que el estimado determinista de 3,5 días. Si hacemos los cálculos nos damos cuenta de que el valor esperado es en realidad de casi 4,5 días. Con 3 tareas paralelas, el valor esperado es de casi 5 días, y con 5 tareas es de unos 5,4 días. Y con 10 son 5,8 días. (Es evidente que convergerá en 6 días, ya que el número de caminos paralelos se vuelve muy grande.)

Otra manera de ver esto es reformular la ley de Murphy, menos pesimista que Murphy:

Si hay muchas cosas que podrían salir mal entonces al menos una de ellas lo hará.

Y en una red de proyectos con trayectorias paralelas, sólo es necesario que una de ellas «salga mal» para retrasar la finalización del proyecto. (En este contexto, «salir mal» significa simplemente tardar más de lo esperado. Esto no implica necesariamente que se haya cometido un error, sino que podría ser el resultado de la inevitable incertidumbre que implica la estimación original.) Esto es un sesgo de fusión.