Para mí, el verdadero valor de la gestión de proyectos está en notar que algo se está alejando de lo esperado mientras todavía hay tiempo para tomar una decisión. Un estudio académico llamado Dynamic Prediction of Delays in Software Projects using Delay Patterns and Bayesian Modeling, disponible también en una versión abierta en arXiv, parte exactamente de esta idea.

El estudio muestra cómo los modelos actualizados continuamente pueden predecir retrasos durante las primeras fases del proyecto. En lugar de depender únicamente de la estimación realizada al principio, el riesgo se recalcula a medida que aparecen nuevos datos de ejecución y de desempeño del equipo. Este enfoque me parece mucho más cercano a la realidad, porque ningún proyecto permanece exactamente igual después de comenzar.

1. La fecha prevista empieza a alejarse de la línea base del proyecto

La línea base, o baseline, es la referencia que muestra cómo debería avanzar el proyecto. Incluye las fechas, los hitos, las duraciones y los entregables aprobados durante la planificación. Cuando la previsión actual empieza a alejarse de esa referencia, tenemos una de las primeras señales de que la ejecución ya no está siguiendo el plan original.

Esta distancia puede aparecer de distintas maneras. La fecha final proyectada puede retrasarse continuamente, los hitos pueden comenzar a completarse más tarde de lo previsto o el equipo puede entregar menos trabajo del esperado durante un período determinado. En la gestión del valor ganado, Schedule Variance muestra un resultado desfavorable cuando el valor del trabajo realizado es inferior al valor planificado, mientras que un Schedule Performance Index, o SPI, inferior a 1 indica que el proyecto avanza a un ritmo menor del esperado. La guía del Departamento de Energía de Estados Unidos sobre Earned Value Management explica estos indicadores con más detalle.

No considero que un único resultado desfavorable sea suficiente para declarar que un proyecto está retrasado. Lo que me preocupa es la tendencia. Si el SPI se mantiene por debajo de 1, Schedule Variance continúa siendo desfavorable y la previsión de finalización se revisa varias veces, el proyecto está produciendo evidencias de que el plan original ya no representa la realidad de la ejecución.

En Saint Jude, el Módulo de Proyecto compara continuamente lo que se planificó con lo que realmente se entregó. Esta comparación ayuda a identificar qué actividades están contribuyendo a la desviación, qué entregables están quedándose atrás y en qué momento la diferencia entre el plan y la ejecución empieza a amenazar la fecha final.

2. La holgura de la ruta crítica empieza a reducirse

No todas las actividades retrasadas tienen el mismo impacto. Una tarea puede retrasarse algunos días y todavía existir suficiente margen para que el proyecto termine en la fecha prevista. Otra actividad, aparentemente pequeña, puede formar parte de la ruta crítica y determinar directamente cuándo podrá completarse un entregable.

Por eso no me gusta analizar el cronograma simplemente contando cuántas tareas están retrasadas. Diez actividades con retraso pueden tener poco impacto si todavía cuentan con margen. Una única actividad crítica, en cambio, puede bloquear a otros equipos, consumir todo el margen disponible y modificar la fecha final del proyecto.

La Schedule Assessment Guide de la Government Accountability Office explica la importancia de estructurar correctamente las dependencias, las duraciones y las actividades que controlan la finalización del proyecto. También profundicé en este tema en el artículo Ruta crítica: cómo identificar dependencias que pueden retrasar tu proyecto.

Para mí, lo más importante es entender que la ruta crítica no es una fotografía tomada al inicio del proyecto. Una actividad que antes tenía holgura puede empezar a consumirla. Una dependencia puede volverse más arriesgada. Un cambio en la duración puede hacer que otra ruta pase a controlar la entrega. El cronograma tiene que seguir la realidad, porque la realidad continúa cambiando.

En Saint Jude, el Módulo de Cronograma ayuda a seguir las relaciones entre actividades, los hitos y las posibles consecuencias de un retraso. De esta manera, el gerente de proyecto puede concentrar la atención en el trabajo que realmente puede modificar la fecha final, en lugar de tratar todas las tareas como si tuvieran la misma importancia.

3. El trabajo en curso (WIP) crece por encima de la capacidad del equipo

Hay una situación que veo con frecuencia en los proyectos: el tablero está lleno de actividades en curso, pero muy pocas se están completando. A primera vista, esto puede parecer productividad. Muchas personas están ocupadas y se han iniciado varias tareas. En la práctica, sin embargo, un exceso de trabajo en curso puede indicar que el equipo está sobrecargado y tiene dificultades para terminar lo que empezó.

El WIP, o Work in Progress, representa el volumen de trabajo abierto o en ejecución. Cuando crece por encima de la capacidad real del equipo, aumentan los cambios de contexto, las interrupciones y los tiempos de espera entre las etapas. Las personas comienzan muchas actividades, pero tardan más en completar cada una. La guía de Kanban University presenta la limitación del trabajo en curso como una práctica importante para mejorar el flujo.

Lo que me interesa no es simplemente saber cuántas tareas están abiertas. Quiero entender cuántas están avanzando realmente, cuántas dependen de las mismas personas, cuáles están bloqueadas y si el volumen de trabajo está creciendo más rápido que la capacidad del equipo para completarlo. Cuando empieza a formarse una cola de tareas, el retraso puede no ser visible todavía en el cronograma, pero ya se está formando en el flujo de trabajo. La limitación del trabajo en curso ayuda a reducir esa cola y a recuperar un flujo más previsible.

En Saint Jude, el Módulo de Desempeño y Capacidad del Equipo compara el trabajo en curso con la capacidad de ejecución observada. Este análisis ayuda a identificar la sobrecarga, la concentración de actividades en determinadas personas y las situaciones en las que el equipo parece ocupado, pero no consigue convertir el esfuerzo en entregables completados. Para profundizar en este tema, también puedes consultar nuestro artículo sobre indicadores de productividad para medir y mejorar el desempeño del equipo.

4. El lead time y el tiempo de ciclo se vuelven más largos e imprevisibles

El lead time muestra cuánto tarda una solicitud desde el momento en que entra en el flujo hasta que se completa. El tiempo de ciclo, también conocido como cycle time, mide el período entre el inicio efectivo del trabajo y su finalización. Me gustan estos indicadores porque muestran cómo se comportan realmente las entregas, y no solo lo que se estimó durante la planificación.

Cuando el lead time y el cycle time empiezan a aumentar, el equipo tarda más en completar actividades similares. Cuando además se vuelven menos previsibles, el problema es todavía mayor: aunque el promedio parezca aceptable, algunas tareas empiezan a tardar mucho más que otras. Kanban University presenta el lead time como un indicador importante de previsibilidad.

Un equipo puede seguir entregando y, al mismo tiempo, perder previsibilidad. Los sprints terminan, pero las actividades tardan cada vez más. Las estimaciones deben revisarse con frecuencia y las próximas fechas empiezan a depender de una capacidad que ya no se comporta como antes. Para mí, esta es una señal que aparece antes de que el retraso se vuelva oficialmente visible.

En el Módulo de Proyecto de Saint Jude, validamos la productividad en cada sprint y observamos cómo evoluciona el desempeño de las entregas a lo largo del tiempo. Este análisis ayuda a identificar cuándo el flujo se está ralentizando, cuándo el equipo entrega menos de lo planificado y cuándo las previsiones futuras ya no deberían utilizar las mismas premisas del inicio del proyecto.

5. Los cambios de requisitos y alcance continúan después del inicio

Los cambios de alcance forman parte de la realidad de muchos proyectos. Puede aparecer un nuevo requisito porque el cliente aprendió algo durante la ejecución, porque se descubrió una restricción técnica o porque cambió una prioridad estratégica. El problema no es necesariamente que exista el cambio, sino que no haya visibilidad sobre su impacto.

Cuando los requisitos continúan cambiando después de que comienza el trabajo, las actividades pueden perder claridad, las estimaciones dejan de representar el esfuerzo real y el equipo empieza a trabajar en algo diferente de lo que se había planificado originalmente. Una tarea puede parecer pequeña, pero tener que reabrirse varias veces porque su objetivo o sus criterios de aceptación todavía no están claros.

La documentación de la NASA sobre la volatilidad de los requisitos muestra cómo los cambios frecuentes pueden afectar la estabilidad del desarrollo. Según mi experiencia, esta es también una de las señales más difíciles de reconocer, porque el cronograma puede seguir actualizándose mientras el proyecto acumula trabajo que nunca formó parte del plan original.

En el Módulo de Proyecto de Saint Jude, analizamos si las actividades son suficientemente claras y si sus estimaciones están alineadas con tareas similares que ya se han completado. Esta comparación ayuda a identificar actividades genéricas, estimaciones fuera del patrón normal y situaciones en las que los cambios de alcance están aumentando el esfuerzo necesario sin que la gestión lo perciba con claridad.

6. Las dependencias, las tareas bloqueadas y los tiempos de espera empiezan a acumularse

No todas las actividades retrasadas están retrasadas porque el equipo haya dejado de trabajar. Muchas veces están esperando una aprobación, una información, a otro equipo, a un proveedor, a un entorno técnico o a una decisión del cliente. Cuando este tiempo de espera no es visible, puede interpretarse como una baja productividad individual, aunque el problema esté en la forma en que el trabajo está conectado.

Una dependencia, por sí sola, no es necesariamente un riesgo. Si el equipo del que dependemos avanza con normalidad, tiene capacidad suficiente y todavía existe margen en el cronograma, la dependencia puede estar bajo control. El riesgo cambia cuando la estimación se revisa, la actividad se bloquea, la persona responsable está sobrecargada o el siguiente entregable ya no tiene margen suficiente para esperar.

El material de la GAO sobre interdependencias y ruta crítica muestra cómo las relaciones entre actividades pueden afectar al cronograma. Una breve espera en una actividad puede propagarse a varias otras, especialmente cuando existe una secuencia de tareas dependientes o cuando diferentes equipos necesitan trabajar en un orden específico.

Este es también el punto en el que el riesgo de retraso debe reevaluarse continuamente. La estimación inicial pudo ser adecuada cuando comenzó el proyecto, pero los nuevos bloqueos, los cambios en el desempeño y los tiempos de espera acumulados modifican la probabilidad de finalización. No tiene sentido observar el riesgo únicamente porque se registró al principio. Tenemos que observar lo que está ocurriendo ahora.

En el Módulo de Riesgos de Saint Jude, los riesgos son evaluados continuamente de forma proactiva por nuestra Inteligencia Artificial. Cuando se identifica un posible problema, las posibles mitigaciones se asignan automáticamente al usuario responsable en la plataforma. El objetivo es permitir que el equipo trate el riesgo mientras todavía hay tiempo para actuar, antes de que una dependencia se convierta en un retraso concreto.

7. Aumentan el retrabajo, los defectos y los problemas de calidad

Un proyecto puede seguir registrando actividades completadas y, aun así, estar acercándose a un retraso. Esto ocurre cuando parte del trabajo tiene que hacerse de nuevo. Una tarea se cierra, pero vuelve a desarrollo. Un entregable se envía para validación, pero regresa con nuevos problemas. Un cambio provoca una regresión y obliga al equipo a corregir algo que ya debería haberse terminado.

El retrabajo consume una capacidad que no estaba incluida en la estimación original. El equipo sigue ocupado, pero una parte cada vez mayor de su esfuerzo se dirige a correcciones, revisiones y actividades reabiertas. Con el tiempo, las nuevas tareas empiezan a acumularse, el cycle time aumenta y el proyecto entrega menos valor del que podría sugerir el volumen de trabajo realizado.

El Software Engineering Institute destaca la importancia de utilizar los datos del flujo de desarrollo para comprender la calidad y la eficiencia de las entregas. Las investigaciones sobre los factores que influyen en la entrega dentro del plazo, como el estudio publicado por la IEEE, también refuerzan que los problemas de calidad y el retrabajo pueden comprometer la previsibilidad.

Para mí, la señal principal no es un defecto aislado. Lo que merece atención es que tareas similares comiencen a reabrirse con mayor frecuencia, que aumente el número de correcciones o que crezca el esfuerzo necesario para completar un entregable aunque el alcance no haya cambiado. En ese momento, el equipo puede estar generando mucho movimiento, pero muy poco progreso real.

En Saint Jude, los indicadores de desempeño pueden analizarse junto con los datos del proyecto para identificar cuándo el esfuerzo está siendo consumido por retrabajos, revisiones o actividades que no avanzan hacia una conclusión definitiva. Esta visión ayuda a entender no solo cuánto se hizo, sino cuánto trabajo se convirtió realmente en un entregable aceptado.

El problema está en la combinación de las señales

Ninguna de estas señales, por sí sola, demuestra que un proyecto sufrirá un retraso. Un SPI inferior a 1 puede representar una variación temporal. Un aumento del lead time puede estar relacionado con una tarea excepcionalmente compleja. Un cambio de alcance puede ser necesario para proteger el resultado del proyecto. Lo que me preocupa es cuando varias de estas señales empiezan a aparecer al mismo tiempo.

Cuando la fecha prevista se aleja de la línea base, el margen de la ruta crítica disminuye, el WIP crece, las entregas se vuelven más lentas, los requisitos siguen cambiando y los bloqueos se acumulan, el proyecto está contando una historia. El retraso quizá todavía no haya ocurrido oficialmente, pero los datos ya muestran que la forma actual de trabajar puede no ser suficiente para cumplir el plan.

Por eso no creo en una gestión de proyectos basada únicamente en informes estáticos o reuniones de seguimiento. Un informe muestra lo que ha ocurrido. Una reunión puede ayudar a discutir lo que está ocurriendo. Pero también tenemos que interpretar lo que los datos indican sobre lo que podría ocurrir dentro de unas semanas. La gestión de riesgos en proyectos necesita actualizarse con la realidad de la ejecución, no quedarse atada a la estimación inicial.

Cómo la inteligencia artificial para gestión de proyectos aumenta el tiempo para reaccionar

No creo que exista una plataforma capaz de eliminar todos los riesgos de un proyecto. Las personas cambian, los proveedores se retrasan, las estimaciones fallan, los clientes modifican sus prioridades y las decisiones importantes pueden tardar más de lo esperado. La incertidumbre siempre formará parte del trabajo de gestión.

La diferencia está en cuándo nos damos cuenta de que algo se está alejando de la dirección planificada. Si descubrimos el problema el día en que debería entregarse el resultado, nuestras opciones son pocas. Si identificamos el riesgo unas semanas antes, quizá todavía podamos redistribuir capacidad, ajustar una prioridad, dividir el alcance, negociar una dependencia o crear un plan de mitigación.

Saint Jude no sustituye herramientas como Jira, Azure DevOps, ClickUp, Monday.com o Asana. Estas plataformas siguen siendo fundamentales para organizar y ejecutar el trabajo. Saint Jude trabaja en una capa diferente: utiliza los datos que los proyectos ya producen para ayudar a gerentes de proyecto, PMO y líderes a comprender la salud de los proyectos, identificar patrones y tomar decisiones con mayor anticipación.

Al final, predecir retrasos no significa adivinar el futuro. Significa observar el presente con suficiente atención para reconocer cuándo el comportamiento del proyecto empieza a alejarse de lo esperado. Significa entender que una actividad retrasada puede ser una simple variación o el inicio de una reacción en cadena.

Y quizá esta sea la pregunta más importante: en tu proyecto, ¿estás esperando a que se pierda la fecha para actuar o ya puedes identificar las señales que indican que podría perderse?

¡Hasta pronto!

Erik Scaranello