Guías

Análisis de riesgos del cronograma con Monte Carlo: qué probabilidad tienes de terminar a tiempo

Qué es una simulación de Monte Carlo del cronograma, por qué dos ramas paralelas de 10 días casi nunca terminan en 10 días y cómo leer P50, P80, impulsores de riesgo e índice de criticidad en un cambio de nóminas de 13 días.

por Equipo Planitude18 min de lecturaDatos verificados en noviembre de 2026
En este artículo
  1. Qué es el análisis de riesgos del cronograma con Monte Carlo
  2. Quién necesita una simulación del cronograma, y cuándo
  3. Qué necesita de ti la simulación
  4. Por qué las ramas paralelas terminan más tarde de lo que dice el plan
  5. Un ejemplo práctico: el cambio de sistema de nóminas
  6. Cómo hacer un análisis de riesgos del cronograma, paso a paso
  7. Errores habituales
  8. Los límites de la simulación de Monte Carlo
  9. Cómo hacerlo en Planitude
  10. Preguntas frecuentes

Un cambio de sistema de nóminas tiene dos ramas paralelas de 10 días laborables cada una y después una nómina en paralelo de 3 días, así que el plan fija la puesta en marcha el día 13. Recalcúlalo 5.000 veces con rangos realistas en las dos ramas y el día 13 se cumple en cerca del 17 % de las iteraciones.

La guía para estimar la duración de las tareas presenta las fechas P50 y P80. Esta guía explica de dónde sale la diferencia entre el plan y el P50, y en qué planes merece la pena hacer un análisis de riesgos del cronograma con Monte Carlo. El ejemplo es lo bastante pequeño para recalcularlo a mano; solo las correlaciones de rangos proceden de una ejecución de 5.000 iteraciones.

Qué es el análisis de riesgos del cronograma con Monte Carlo

El análisis de riesgos del cronograma con Monte Carlo es un método que recalcula un cronograma miles de veces con duraciones de tareas extraídas al azar y presenta la fecha de fin como una distribución de fechas, cada una con su probabilidad de cumplirse. Existe porque una única fecha de fin no dice nada sobre lo probable que es, y la Government Accountability Office (GAO) señala en su Schedule Assessment Guide que, si no se hace una simulación estadística, una fecha de finalización calculada a partir de la lógica del cronograma y de las estimaciones de duración tiende a subestimar la duración de la ruta crítica[1]. En el ejemplo de nóminas de más abajo, el día 13 previsto se cumple en el 17 % de las iteraciones, y no llegar al cierre del día 14 supone otro mes con el sistema de nóminas antiguo.

Cada iteración es un cálculo normal del cronograma. Solo cambian las duraciones; las dependencias y los calendarios se quedan como en el plan. Tras 5.000 iteraciones se ordenan las fechas de fin: la fecha que cumple el 80 % de ellas es el P80, y la que cumple la mitad es el P50. La probabilidad de cumplir una fecha límite es la proporción de iteraciones que terminan en ella o antes.

Las estimaciones probabilísticas de duración se remontan a la Program Evaluation and Review Technique (PERT), descrita en 1959 para el programa de misiles balísticos Polaris de la Marina de Estados Unidos, con tiempos de actividad que el personal técnico aportaba en términos probabilísticos[2]. En 1966 Klingel demostró en una red real que el cálculo PERT sobrestimaba la probabilidad de terminar a tiempo, sobre todo cuando varias ramas paralelas tenían duraciones medias parecidas y varianzas grandes, y propuso la simulación para estimar la distribución del tiempo de finalización[3].

Quién necesita una simulación del cronograma, y cuándo

Una simulación del cronograma sirve al jefe de proyecto o al planificador que debe comprometerse con una fecha de fin en un plan donde dos o más ramas inciertas convergen antes del final. La prepara el planificador, y lo que llega al patrocinador o al cliente suele ser un número (el P80) y un gráfico.

Nuestro umbral, como regla práctica: un plan de unas 15 tareas o más con al menos un punto de convergencia donde se unan dos ramas con estimaciones de tres puntos. Por debajo de 15 tareas, los cálculos de este artículo caben en una hoja de papel. El tamaño del equipo influye poco. El equipo de nóminas de cuatro personas del ejemplo necesita la simulación tanto como un programa de 30 personas, porque la caída del 42 % por rama al 17 % para las dos se debe solo a la forma de la red. El ejemplo se reduce a cuatro líneas para que se pueda comprobar cada probabilidad, y el método es el mismo en un plan de varios cientos de tareas.

Ejecútala cuando el primer plan completo tenga dependencias y estimaciones de tres puntos en las tareas inciertas, antes de que ninguna fecha de fin salga del equipo. Vuelve a ejecutarla cuando guardes una línea base y cada vez que la estimación de una tarea determinante cambie en más de un día. Cada ejecución tarda segundos.

Una cadena única sin punto de convergencia puede prescindir de la simulación, porque un cálculo más corto da la misma respuesta. Suma las medias PERT y las varianzas a lo largo de la cadena, saca la raíz cuadrada de la varianza total y la aproximación normal da los percentiles. Seis tareas seguidas, cada una estimada en 8, 10 y 14 días, muestran cómo funciona: el plan dice 60 días, las medias suman 62,0, la desviación típica PERT clásica es (14 − 8) / 6 = 1 día por tarea, así que la desviación típica de la cadena es √6 ≈ 2,4 días y el P80 ronda 62,0 + 0,84 × 2,4 ≈ 64 días laborables. Los 60 días previstos se cumplen más o menos una vez de cada cinco. Simula la cadena de todos modos cuando tenga restricciones de fecha o tareas con calendarios distintos, o cuando menos de unas cinco tareas concentren toda la incertidumbre con rangos tan asimétricos como estos, porque ahí la aproximación normal es mala. Un sprint de duración fija no le da a la simulación nada que prever: la fecha está fijada y lo que se ajusta es el alcance.

Qué necesita de ti la simulación

La simulación necesita una estimación de tres puntos (optimista, más probable, pesimista) para cada tarea cuya duración sea incierta; el valor más probable es la duración que ya figura en el plan.

El valor pesimista es el que merece más cuidado. En una distribución PERT o triangular es el límite superior: ninguna iteración extrae nunca una duración más larga, así que todo lo que quede por encima falta en todos los percentiles.

Nuestra recomendación: pide a quien hace el trabajo la duración que solo superaría en un caso excepcional, más o menos una vez de cada cien, e introduce ese dato como valor pesimista. Un valor que espera superar una vez de cada diez es un P90. Si se introduce como límite, corta la cola y adelanta el P80 y el P95. Pregunta sin un responsable delante, para que la respuesta no se incline hacia la fecha que quiere ese responsable.

Los datos reales de proyectos anteriores marcan un mínimo. Nuestra regla práctica: si tienes duraciones reales de cinco o más tareas anteriores del mismo tipo, hechas con el mismo proveedor, el valor pesimista no debería ser más corto que la más larga de ellas. El motivo de que sean cinco es aritmético: una tarea nueva dura más que todas las n anteriores más o menos una vez de cada n + 1, así que la más larga de cinco duraciones reales se supera más o menos una vez de cada seis, todavía mucho más a menudo que la vez de cada cien que representa el valor pesimista. Con dos datos reales sería una vez de cada tres, demasiado poco para fijar nada. Los datos de otro proveedor no cuentan.

Hay dos distribuciones de uso habitual. La distribución PERT (Beta) da poco peso a los extremos, mientras que la triangular les da más, de modo que con los mismos tres números la triangular devuelve percentiles más tardíos. El ejemplo de construcción de una vivienda de la GAO usa distribuciones triangulares y señala que hay otras disponibles[1]. Las tareas sin estimación propia reciben un rango por defecto, un porcentaje de la duración prevista como −10 % y +30 %; deja ese valor por defecto para las tareas con poco riesgo.

Por qué las ramas paralelas terminan más tarde de lo que dice el plan

Un punto de convergencia termina más tarde de lo que sugieren sus ramas porque la tarea siguiente solo empieza cuando acaba la última rama, y la más tardía de varias fechas inciertas es, de media, posterior a cualquiera de ellas. La GAO llama sesgo de convergencia (merge bias) a este riesgo añadido en los puntos de convergencia: con dos ramas con un 60 % de probabilidad cada una de terminar a tiempo, el hito de convergencia solo llega a tiempo cuando lo hacen las dos, el 36 % de las veces, y una tercera rama al 60 % lo baja al 22 %[1].

La asimetría lo empeora. Toma una rama prevista en 10 días con un rango de 8 a 14. La distribución PERT sitúa cerca del 42 % de su probabilidad en 10 días o menos, porque la larga cola derecha empuja la mediana por encima del valor más probable, de modo que la duración prevista se cumple menos de una vez de cada dos antes incluso de cualquier convergencia.

Dos ramas independientes con esa forma terminan ambas el día 10 con una probabilidad de 0,417 × 0,417, cerca del 17 %. Tres la bajan al 7 %, cuatro al 3 %.

Un ejemplo práctico: el cambio de sistema de nóminas

Una empresa de 240 empleados cambia de proveedor de nóminas, y el plan fija la puesta en marcha el día 13 frente a un cierre de mes el día 14: un día de margen sobre el papel.

Dos ramas avanzan en paralelo. La rama A configura los conceptos salariales y las tablas fiscales del nuevo sistema, y su caso pesimista es que el proveedor entregue tarde las tablas fiscales de este año. La rama B depura y carga los datos de los empleados; lo que puede alargarla son las altas del mes, cuyos datos bancarios suelen llegar la última semana. Ambas alimentan una nómina en paralelo, en la que el sistema antiguo y el nuevo procesan el mismo mes y las nóminas se comparan línea por línea. El proveedor la ejecuta en una ventana de servicio reservada de 3 días, así que aquí su duración es fija.

El plan de trabajo tiene 26 tareas: 14 en la rama A, que termina con la aprobación de la plantilla de nómina por parte del director financiero, y 12 en la rama B, entre ellas una importación de prueba de 20 fichas de empleados. La tabla resume cada rama en una línea. La estimación de la rama A la dieron el responsable de nóminas y el consultor de implantación del proveedor, y la de la rama B el responsable de datos de RR. HH., cada uno en una sesión de 30 minutos en la que se pidió una estimación de tres puntos de la rama completa, con el valor pesimista fijado en una vez de cada cien. Sumar 14 valores pesimistas por tarea habría descrito una rama en la que todas las tareas salen mal a la vez.

Las duraciones están en días laborables. Todas las dependencias son fin-comienzo.

TareaOptimistaMás probablePesimistaMedia PERT
A. Configurar el nuevo sistema8101410,3
B. Depurar y cargar los datos de empleados9101210,2
Nómina en paralelo (ventana reservada)3333,0
Puesta en marcha (hito, fecha límite día 14)0000

El plan es la columna del más probable. Las dos ramas terminan el día 10, la nómina en paralelo ocupa los días 11 a 13 y la puesta en marcha llega al final del día 13. A y B tienen holgura total cero, así que ambas están en la ruta crítica.

La rama B parece más segura, con un rango de 9 a 12 frente al de 8 a 14 de A, pero cumple los 10 días con la misma frecuencia. Los dos rangos sitúan el valor más probable a un tercio del camino entre el optimista y el pesimista (2 de 6 días en A, 1 de 3 en B), así que las dos distribuciones PERT tienen la misma forma y B es A con la mitad de anchura. La cola de B es más corta en días, y esa diferencia aparece en los impulsores de riesgo.

Las cifras siguientes son valores exactos de la distribución PERT; una simulación de 5.000 iteraciones queda a cerca de un punto porcentual de ellos.

MedidaResultado
Probabilidad de que A termine el día 1042 %
Probabilidad de que B termine el día 1042 %
Probabilidad de que terminen las dos, y por tanto puesta en marcha el día 1317 %
Probabilidad de puesta en marcha el día 14, la fecha límite66 %
Probabilidad de puesta en marcha el día 1592 %
P50, P80, P95 de la puesta en marchacerca de 13,7, 14,4 y 15,3 días laborables

Llegar a un 80 % de confianza exige unos 14,4 días laborables, que redondeados al alza son el día 15, un día después del cierre. Perder el cierre significa un mes más con el sistema antiguo y una segunda conciliación de 240 nóminas. El cierre no se puede mover, así que tiene que cambiar el plan: o el proyecto empieza un día antes, o se acorta la cola de la rama que concentra el riesgo.

Las mismas iteraciones clasifican las ramas. La rama A está en la ruta que determina el fin en el 53 % de las iteraciones, y B en el 47 % restante. En una ejecución de 5.000 iteraciones, la correlación de rangos entre la duración extraída de cada rama y la fecha de puesta en marcha salió en torno a 0,78 para A y 0,39 para B, porque el rango de A es el doble de ancho.

Recortar el valor pesimista de A de 14 a 12 días, por ejemplo consiguiendo del proveedor las tablas fiscales antes de empezar la configuración, eleva la probabilidad del día 14 del 66 % al 82 %. El mismo recorte de 2 días en B, de 12 a 10, da un 72 %. Si la ventana del proveedor pudiera retrasarse, con un rango de 3 a 5 días, todos los percentiles se moverían hacia más tarde, mientras que el efecto de convergencia entre A y B seguiría siendo el calculado arriba.

Cómo leer los percentiles y la reserva

Comunica fuera del equipo el P80, redondeado al alza al siguiente día entero; en el ejemplo, el día 15. La GAO mide la reserva del cronograma como la diferencia entre la fecha del percentil 80 y el fin determinista, y señala que algunos programas toman el percentil 80 como fecha de compromiso conservadora mientras otros usan el 65 o el 55, que dejan más exposición a retrasos porque las distribuciones de los cronogramas tienden a estar sesgadas a la derecha[1].

En el ejemplo la reserva es de 14,4 − 13 = 1,4 días laborables. Mantenla como una única reserva visible delante del hito de puesta en marcha, donde todos puedan ver cómo se consume.

Nuestra recomendación es el P80 por defecto, porque un cierre como este convierte un final tardío en un mes de retraso. Comunica el P50 solo cuando llegar tarde salga barato, y di claramente que se incumple la mitad de las veces. Lo que llega aquí al patrocinador es la cifra del día 14 de la tabla, junto con las dos formas de mejorarla que salen de la prueba en cada rama.

Impulsores de riesgo e índice de criticidad

Un impulsor de riesgo es una tarea cuya duración extraída mueve más el fin del proyecto, medido aquí como la correlación de rangos de Spearman entre esa duración y la fecha de fin en todas las iteraciones. El índice de criticidad es la proporción de iteraciones en las que una tarea está en la ruta que determina el fin; la guía de la GAO llama a esta misma medida risk criticality[1].

Las dos responden a preguntas distintas. La criticidad cuenta con qué frecuencia una tarea está en esa ruta, y la clasificación de impulsores pondera además la anchura de su rango, de modo que una tarea crítica en el 60 % de las iteraciones con un rango estrecho puede quedar por debajo de otra crítica en el 40 % con un rango amplio. En el cambio de nóminas las ramas están casi igualadas en criticidad, 53 % frente a 47 %, mientras que la correlación de A dobla la de B. La nómina en paralelo y el hito de puesta en marcha son críticos en el 100 % de las iteraciones, porque las dos ramas desembocan en ellos. Para decidir dónde va la siguiente hora de estimación, ordena por correlación y mira la criticidad en segundo lugar.

Cómo hacer un análisis de riesgos del cronograma, paso a paso

Siete pasos llevan un plan de una única fecha a un P80 comprometido, y la mayor parte del tiempo se va en el paso 2.

  1. Revisa las dependencias. Todas las tareas salvo la primera necesitan un predecesor, y solo la última puede no tener sucesor. Una tarea sin predecesor empieza el primer día en todas las iteraciones, así que los retrasos del trabajo del que depende en realidad nunca le llegan y la simulación termina demasiado pronto. La guía de dependencias entre tareas explica los tipos de dependencia.
  2. Estima las tareas con riesgo. Elige las 5 a 10 tareas con más probabilidad de retrasarse y consigue una estimación de tres puntos de cada una de quien vaya a hacer el trabajo. Cada estimación es una conversación, y el valor pesimista puede necesitar una segunda pregunta si la primera respuesta resulta ser un P90. El resto mantiene el rango por defecto.
  3. Elige la distribución. Escoge PERT o triangular una sola vez y mantenla en todas las versiones del plan.
  4. Ejecuta 5.000 iteraciones y lee el histograma, la curva S, los percentiles y la probabilidad de cumplir la fecha límite.
  5. Clasifica los impulsores. Toma las tres primeras tareas por correlación de rangos y pon al lado su índice de criticidad.
  6. Prueba un cambio en el primer impulsor con la misma semilla, para que la diferencia se deba solo al cambio, como con el recorte de la cola de la rama A en el ejemplo.
  7. Guarda el P80 y la reserva con la línea base.

Errores habituales

El error con más efecto en el resultado es un rango uniforme en todas las tareas, que convierte el resultado en el plan más un margen fijo. Un −10 % / +30 % uniforme oculta las tareas realmente inciertas y atribuye al resto un riesgo que no tiene; en el ejemplo daría a A y B el mismo rango cuando el de A es el doble de ancho.

  • Un P90 introducido como valor pesimista. La cola se corta y el P80 sale demasiado pronto.
  • Comunicar el P50 como previsión. La mitad de las iteraciones terminan más tarde.
  • Dos versiones del plan comparadas con semillas distintas, de modo que parte de la diferencia es ruido de muestreo.
  • Recortar estimaciones hasta que cuadre la fecha. La GAO advierte que cambiar duraciones solo porque se prefiere una fecha de fin más temprana probablemente aumenta el riesgo de retrasar el proyecto[1]. Cuando la fecha no cuadra, cambia la lógica o el alcance, y toca una estimación solo cuando haya información nueva sobre esa tarea.
  • Una simulación ejecutada antes de que las dependencias estén bien (paso 1).

Los límites de la simulación de Monte Carlo

Una simulación vale lo que valen sus rangos y su hipótesis de independencia. Unos valores pesimistas recortados para contentar a un patrocinador dan un P80 anterior al que el proyecto puede cumplir.

Las simulaciones estándar extraen cada duración de forma independiente. Cuando una misma causa frena varias tareas a la vez, la cola real es más larga que la simulada. El ejemplo de construcción de una vivienda de la GAO muestra la magnitud del efecto: al añadir una correlación del 90 % entre actividades de oficios relacionados, el P50 apenas se movió (25 de febrero sin correlación, 24 de febrero con ella), mientras que el P80 pasó del 4 al 9 de marzo, una semana laboral más tarde[1]. En el cambio de nóminas, un proveedor que configura la rama A y además suministra la plantilla de importación de la rama B une las dos ramas, y entonces el 82 % de la prueba resulta demasiado generoso.

Los rangos de duración tampoco recogen los eventos de riesgo. Un riesgo que puede producirse o no, como que la administración tributaria rechace el nuevo registro del empleador, añade semanas o no añade nada, y una estimación de tres puntos lo diluye en un rango continuo que no corresponde a ninguno de los dos casos. Cuando un evento puede añadir semanas, ponlo en una tarea aparte con esas semanas en su valor pesimista, o trátalo al margen de los percentiles.

Cómo hacerlo en Planitude

Abre la pestaña Riesgo y activa la simulación. Planitude recalcula el plan 5.000 veces por defecto, con duraciones PERT o triangulares, respetando las dependencias y restricciones del plan; en planes muy grandes se reduce el número de iteraciones, nunca por debajo de 1.000. Introduce las duraciones optimista y pesimista en los detalles de las tareas que las necesiten. Para mantener fija una tarea, como la nómina en paralelo, ponle la duración prevista en los dos campos; las tareas que se dejen vacías usan el rango por defecto del proyecto.

La pestaña muestra las fechas P50, P80 y P95, la probabilidad de cumplir la fecha límite o cualquier fecha que elijas, un histograma, una curva S, los impulsores de riesgo y el índice de criticidad. La misma semilla en el mismo plan da las mismas cifras, así que una prueba como la de la rama A se compara limpiamente. Las tareas terminadas se mantienen fijas y las tareas en curso solo simulan el trabajo pendiente, de modo que una nueva ejecución a mitad de proyecto parte del punto en que está el plan.

Las duraciones se extraen de forma independiente, así que un riesgo compartido por muchas tareas ensancha las colas más de lo que muestra la pestaña. No se modelan ni los eventos de riesgo ni los costes.

Prueba Planitude con tu propio plan

Prueba Planitude gratis

Preguntas frecuentes

¿Se puede hacer una simulación de Monte Carlo del cronograma en Excel?

Sí, para una red tan pequeña como la del ejemplo de nóminas. La función DISTR.BETA.INV de Excel (BETA.INV en la versión inglesa) devuelve el valor de una distribución beta para una probabilidad acumulada dada, entre un límite inferior A y un límite superior B[4]; si le pasas como probabilidad un número aleatorio uniforme entre 0 y 1, extrae una duración. Para la forma PERT, alfa = 1 + 4 × (más probable − optimista) / (pesimista − optimista) y beta = 1 + 4 × (pesimista − más probable) / (pesimista − optimista), lo que da 2,33 y 3,67 para las dos ramas de este ejemplo. La puesta en marcha es la mayor de las dos extracciones más 3 días; copia esa fila 5.000 veces. A partir de unas pocas decenas de tareas enlazadas, rehacer el cálculo hacia delante con fórmulas es el punto en que la hoja de cálculo deja de ser práctica.

¿Cuántas iteraciones de Monte Carlo hacen falta?

Unos pocos miles. En el ejemplo, 5.000 iteraciones quedan a cerca de un punto porcentual de los valores exactos. Mantén la misma semilla al comparar dos versiones del plan, para que el ruido de muestreo no entre en la comparación.

¿Por qué mi P50 de Monte Carlo sale antes que el fin previsto?

Normalmente por las estimaciones. Un P50 anterior al plan aparece cuando, en las tareas que determinan el fin, el valor optimista queda más por debajo del más probable de lo que el pesimista queda por encima. Revisa primero esas estimaciones: un valor pesimista que en realidad es un P90, o un valor optimista copiado del mejor caso de la historia, produce exactamente este resultado.

¿Uso la distribución PERT o la triangular?

PERT, salvo que quieras un resultado deliberadamente conservador. Con los mismos tres números, la triangular da más peso a los extremos y percentiles más tardíos. Para la rama A, de 8 a 14 días con 10 como más probable, la media triangular es de 10,67 días frente a una media PERT de 10,33.

¿El P80 es lo mismo que añadir un 20 % al cronograma?

No. El P80 depende de la red. La cadena de seis tareas de este artículo tiene un P80 de unos 64 días frente a un plan de 60, un margen de cerca del 7 %, mientras que el cambio de nóminas necesita 14,4 días frente a 13, cerca del 11 %, porque convergen dos ramas. Un porcentaje fijo ignora tanto la anchura de cada rango como el número de ramas que convergen.

Compartir

Fuentes

Las páginas oficiales citadas en el artículo, consultadas en noviembre de 2026.

  1. GAO-16-89G, Schedule Assessment Guide: Best Practices for Project Schedules (December 2015), Best Practice 8: Conducting a Schedule Risk Analysis, pp. 99-117gao.gov
  2. Malcolm, Roseboom, Clark & Fazar (1959): Application of a Technique for Research and Development Program Evaluationdoi.org
  3. Klingel (1966): Bias in PERT Project Completion Time Calculations for a Real Network, Management Science 13(4)doi.org
  4. Microsoft Support: BETA.INV functionsupport.microsoft.com

Prueba Planitude con tu propio plan

Crea una cuenta gratuita, importa tu archivo .mpp o empieza con una plantilla: en pocos minutos verás el diagrama de Gantt con dependencias, calendarios y ruta crítica.

La publicidad mantiene Planitude gratis