¿Qué es el método de la ruta crítica?

El método de la ruta crítica, también conocido como Critical Path Method o CPM, es una técnica utilizada para analizar la secuencia de actividades de un proyecto e identificar cuáles determinan su duración. La secuencia resultante es lo que conocemos como ruta crítica y, dependiendo del país o del contexto, también podemos encontrarla con el nombre de camino crítico.

Para identificarla necesitamos conocer las actividades del proyecto, su duración y, sobre todo, las relaciones lógicas que existen entre ellas.

El PMI explica esta construcción de forma bastante clara en sus materiales sobre planificación. En Moving from the WBS to a Critical Path Schedule , por ejemplo, muestra la secuencia lógica que parte de los entregables del proyecto, pasa por la identificación de las actividades, sus dependencias y sus estimaciones de duración, hasta llegar a la ruta crítica.

Esto significa que un cronograma no debería ser simplemente una lista como esta:

• Actividad A — del 1 al 5 de mayo;
• Actividad B — del 6 al 10 de mayo;
• Actividad C — del 11 al 15 de mayo.

Las fechas son importantes, pero cuentan solo una parte de la historia. También necesito saber por qué B está después de A, si B realmente depende de A y qué ocurre con C si B no termina en la fecha prevista.

En otro material, Critical Path Method Calculations , el PMI profundiza en la lógica del CPM y explica cómo las relaciones entre actividades, las duraciones, las fechas de inicio y finalización y los valores de holgura se utilizan para calcular la ruta crítica.

Aquí aparece una de las primeras conclusiones importantes: que una tarea esté retrasada no significa automáticamente que el proyecto esté retrasado. Del mismo modo, que una tarea esté dentro del plazo tampoco significa automáticamente que el proyecto esté en buen estado. Todo depende de la posición que ocupa esa actividad dentro de la red del proyecto y del impacto que una variación en ella pueda provocar sobre las actividades posteriores.

Antes de la ruta crítica, necesitamos entender las dependencias entre tareas

Para identificar una ruta crítica de un proyecto con un mínimo de fiabilidad, primero necesitamos comprender las dependencias entre las actividades. Existe una dependencia cuando el inicio o la finalización de una actividad está relacionado con el inicio o la finalización de otra.

Es un concepto sencillo, pero extremadamente importante. Pensemos, por ejemplo, en un equipo que necesita terminar el desarrollo de una API antes de que otro equipo pueda comenzar una integración. Mientras esa API no esté disponible, la segunda actividad puede simplemente no tener las condiciones necesarias para avanzar.

La guía de Atlassian sobre dependencias de proyectos trata precisamente este tipo de relación y muestra cómo las dependencias pueden afectar la secuencia del trabajo, los recursos y el cronograma. Asana también dispone de una guía completa sobre dependencias en proyectos , incluyendo dependencias lógicas, de recursos, preferenciales y externas.

Aunque las clasificaciones pueden variar dependiendo del contexto, existe una estructura técnica clásica para representar las relaciones de precedencia entre actividades. En ella encontramos cuatro tipos principales: Finish-to-Start, Finish-to-Finish, Start-to-Start y Start-to-Finish.

Los cuatro tipos de dependencia entre actividades

La relación más común es Finish-to-Start — Fin a Inicio. Una actividad debe terminar antes de que la siguiente pueda comenzar. Es, por ejemplo, el caso de un desarrollo que debe finalizar antes de que puedan comenzar determinadas pruebas.

En una relación Finish-to-Finish — Fin a Fin, la finalización de una actividad está relacionada con la finalización de otra. En una relación Start-to-Start — Inicio a Inicio, el comienzo de una actividad depende del comienzo de otra. La cuarta posibilidad, Start-to-Finish — Inicio a Fin, es menos frecuente y ocurre cuando una actividad no puede terminar hasta que otra haya comenzado.

La propia documentación de Asana sobre dependencias entre tareas utiliza estas relaciones para explicar cómo unas tareas pueden bloquear o depender de otras.

Para mí, sin embargo, es más importante comprender el principio que existe detrás de estos cuatro nombres que simplemente memorizarlos: una actividad puede modificar el momento en que otra actividad puede comenzar o terminar. Y cuando varias de estas relaciones están encadenadas, un problema aparentemente pequeño puede propagarse por una parte significativa del proyecto.

¿Cómo identificar la ruta crítica de un proyecto?

No quiero convertir este artículo en una clase sobre cómo calcular la ruta crítica, porque ese no es nuestro objetivo. Pero necesitamos entender mínimamente cómo llegamos a identificarla.

Primero necesitamos conocer las actividades necesarias para producir las entregas del proyecto. Después identificamos las dependencias entre esas actividades y estimamos sus duraciones. Con esta información podemos construir una red lógica, identificar los diferentes caminos que llevan desde el inicio hasta el final del proyecto y calcular cuánto tiempo necesita cada secuencia.

De una forma muy simplificada, imaginemos que tenemos tres posibles rutas:

• A → B → C → entrega = 20 días;
• D → E → entrega = 12 días;
• F → G → H → entrega = 16 días.

Si ningún otro elemento interfiere con la planificación, la secuencia A → B → C merece una atención especial porque es la que está determinando la duración de la entrega. El PMI explica que las actividades de la ruta crítica tienen poca o ninguna holgura para sufrir retrasos sin afectar la finalización del proyecto. En Moving from the WBS to a Critical Path Schedule , esta relación entre dependencias, duración, holgura y ruta crítica se aborda de una forma bastante didáctica.

Esto no significa que podamos simplemente ignorar todas las demás actividades. Una actividad que hoy tiene holgura puede empezar a consumirla y eventualmente convertirse en crítica. Además, los proyectos reales tienen recursos compartidos, proveedores, cambios de alcance, decisiones técnicas, aprobaciones, diferentes equipos y decenas de otras variables capaces de modificar lo que habíamos planificado.

Precisamente por eso no me gusta ver el cronograma como una fotografía. El cronograma es un modelo que necesita ser supervisado durante la ejecución porque la realidad del proyecto continúa cambiando.

Una dependencia no es necesariamente un riesgo

Aquí existe una distinción que considero muy importante: dependencia y riesgo no son lo mismo.

Imaginemos nuevamente que un equipo necesita terminar una API antes de que otro pueda comenzar una integración. Existe una dependencia. Pero si la API avanza normalmente, tiene una estimación fiable, existe suficiente capacidad en el equipo y todavía tenemos holgura antes del inicio de la integración, quizá esa dependencia no represente una amenaza relevante en ese momento.

Ahora imaginemos otra situación. La API debería estar prácticamente terminada, pero su estimación ya se modificó dos veces. Existen subtareas que todavía no han sido estimadas, la persona responsable participa simultáneamente en varias entregas, el sprint está entregando por debajo de lo planificado y la integración que depende de esa API prácticamente no tiene holgura.

La dependencia sigue siendo exactamente la misma. El riesgo asociado a ella ha cambiado completamente.

Este es uno de los puntos en los que la discusión sobre dependencias comienza a acercarse a la gestión de riesgos. Un material del PMI que considero especialmente interesante es Project Interdependency Management . El trabajo presenta una práctica para identificar, validar, analizar, supervisar y comunicar interdependencias externas entre proyectos y las trata dentro del universo de riesgos del proyecto.

Lo que considero más interesante de este enfoque es que una dependencia no se identifica simplemente al comienzo del proyecto para después olvidarla. Necesita seguir siendo supervisada porque aquello de lo que dependemos también cambia con el tiempo.

El problema no es solo la dependencia. Es el efecto en cadena.

Quizá una de las cosas más peligrosas en la gestión de proyectos sea analizar las actividades de forma individual. Imaginemos que A permite comenzar B. B permite comenzar C y D. C necesita terminar para que E pueda comenzar, mientras que D necesita terminar antes de que F pueda iniciarse. Al final, E y F son necesarias para una entrega importante al cliente.

Si A se retrasa, la información “A lleva dos días de retraso” no es suficiente para que yo entienda el problema. Quiero saber hasta dónde pueden propagarse esos dos días. Quiero entender cuánta holgura existe después, qué actividades se verán afectadas, qué equipos dependen de esa entrega y si el retraso tiene capacidad para llegar hasta la fecha final.

Este es uno de los motivos por los que considero peligroso evaluar la salud de un proyecto simplemente contando cuántas tareas están retrasadas. Diez tareas con retraso pueden tener poco impacto sobre una entrega. Una sola actividad crítica retrasada puede comprometer todo el proyecto.

El propio PMI, en Scheduling High-Tech Projects , analiza una limitación importante de una ruta crítica calculada de forma puramente determinista: cuando existe incertidumbre en las estimaciones, diferentes rutas pueden terminar convirtiéndose en críticas. Es decir, aquello que hoy parece ser la secuencia principal del proyecto no debería analizarse sin considerar también el riesgo existente en sus actividades.

El riesgo debería detectarse antes del retraso

Aquí es donde, para mí, la discusión se vuelve todavía más interesante. El PMI publicó un material llamado Risk-Based Scheduling and Analysis , que propone analizar el riesgo a nivel individual de las actividades, ajustar el cronograma teniendo en cuenta estas incertidumbres y después verificar cómo el riesgo puede modificar incluso la propia ruta crítica.

El principio continúa siendo extremadamente actual: no deberíamos esperar a que ocurra el retraso para empezar a analizar el riesgo de una determinada actividad.

Sin embargo, muchas veces hacemos exactamente lo contrario. Primero una tarea se retrasa. Después alguien descubre que otra actividad no pudo comenzar. A continuación aparece una desviación en el cronograma, el proyecto pasa de verde a amarillo, alguien registra un riesgo y entonces empezamos a discutir una mitigación.

Existe un problema evidente en esta secuencia: cuando una actividad que dependía de la anterior ya no ha podido comenzar, quizá ya no estemos hablando únicamente de un riesgo. El problema ya ha comenzado a ocurrir.

Entonces, ¿cómo detectar anticipadamente que una actividad puede retrasarse?

Aquí creo que necesitamos alejarnos un poco de una visión puramente estática del cronograma y empezar a observar el comportamiento real del proyecto. Si una actividad crítica debería terminar dentro de dos semanas, no quiero esperar esas dos semanas para descubrir si tendremos un problema. Quiero buscar señales durante la ejecución.

Puedo comenzar comprobando si la actividad lleva demasiado tiempo detenida, si el esfuerzo consumido ya está muy cerca o por encima de la estimación, si la estimación cambió durante la ejecución o si existen actividades importantes que ni siquiera han sido estimadas. También puedo observar si el volumen de trabajo en curso ha aumentado demasiado, si existen bloqueos, si una sola persona está concentrando demasiado trabajo o si la velocidad del equipo se está deteriorando.

En equipos Agile existen además otras señales interesantes. Lo realmente completado durante el sprint puede estar cada vez más lejos de lo planificado. Actividades similares pueden estar tardando sistemáticamente más de lo previsto. Los bugs y las regresiones pueden aumentar, generando retrabajo. Determinados tipos de actividad pueden empezar a consumir mucho más esfuerzo de lo que consumían anteriormente.

Ninguno de estos indicadores, de forma aislada, demuestra que la actividad necesariamente vaya a retrasarse. Pero varias señales ocurriendo al mismo tiempo pueden empezar a contar una historia.

Es el mismo principio que utilizo cuando hablo de productividad. Como expliqué en el artículo Indicadores de productividad: KPI para medir y mejorar la productividad de tu equipo , observar un único KPI normalmente no es suficiente para entender el comportamiento de un equipo. Necesitamos analizar el contexto y la combinación de los datos.

Algunas dependencias deberían identificarse antes de que la tarea comience

Existe además otro problema: muchas dependencias se descubren demasiado tarde porque la actividad ya ha comenzado sin que nadie haya analizado si realmente estaba preparada para ejecutarse.

Imaginemos descubrir durante el desarrollo que necesitamos una API que todavía no existe, una aprobación que nadie solicitó, una definición del cliente que nunca recibimos o la colaboración de otro equipo que ni siquiera sabía que dependíamos de él. Técnicamente hemos encontrado una dependencia. En la práctica, sin embargo, la hemos encontrado demasiado tarde.

Por eso, cuando trabajo con una Definition of Ready, una de las preguntas que considero importantes es precisamente si ya se han identificado las principales dependencias de la actividad. Es uno de los puntos que desarrollo en el artículo Definition of Done y Definition of Ready en Scrum: qué son, diferencias y ejemplos .

Cuanto antes conozcamos una dependencia relevante, más opciones tendremos. Podemos modificar la secuencia de ejecución, hablar con otro equipo, solicitar antes una aprobación, preparar una alternativa técnica o incluso decidir que esa actividad todavía no debería entrar en el sprint.

El dependency mapping ayuda a hacer visible lo que normalmente permanece oculto

Una práctica interesante para hacer más visibles estas relaciones es el dependency mapping. Atlassian dispone de un ejercicio específico de Dependency Mapping cuyo objetivo es identificar factores que pueden impedir el éxito de una iniciativa, entender cómo el trabajo de un equipo afecta a otras partes de la organización y crear acciones antes de que estos problemas ocurran.

La idea es importante porque una dependencia no existe únicamente entre dos tickets. Podemos depender de otro equipo, de una persona específica, de una aprobación, de un proveedor, de una API, de una infraestructura, de una decisión de arquitectura, de una definición del cliente, de otro proyecto o incluso de una decisión ejecutiva.

Asana, en su material sobre dependencias de proyectos , también llama la atención sobre dependencias relacionadas con recursos y factores externos, además de las puramente lógicas. Esto es importante porque no todos los riesgos aparecen simplemente dibujando una flecha entre dos actividades dentro de un board.

Mapear estas relaciones mejora mucho la visibilidad del proyecto, pero todavía deja una segunda pregunta sin respuesta: ¿cómo saber cuáles de esas dependencias están empezando a volverse peligrosas?

Una dependencia puede tratarse como un riesgo antes de convertirse en un problema

Este enfoque aparece también fuera del PMI. En How to Manage Dependencies and Assess Risks , Tempo propone precisamente observar determinadas dependencias como posibles riesgos, permitiendo que el equipo actúe sobre ellas antes de que se conviertan en problemas concretos.

Me gusta esta lógica porque cambia nuestra postura. En lugar de limitarnos a registrar “el Equipo B depende de la entrega del Equipo A”, empezamos a preguntarnos cuál es la situación del Equipo A, cuándo debe estar disponible esa capacidad, qué señales indican una posible dificultad y cuál será el impacto sobre nuestra entrega si aquello de lo que dependemos no ocurre como estaba previsto.

Es un pequeño cambio en la forma de hacer la pregunta, pero enorme en términos de capacidad de gestión. Una dependencia deja de ser simplemente una línea que conecta dos actividades y se convierte en algo cuya salud necesita ser supervisada.

El board conoce las tareas. Pero ¿quién está observando el proyecto?

Jira, Azure DevOps, Asana, Monday.com y ClickUp cumplen una función extremadamente importante. Es en estas plataformas donde los equipos registran actividades, responsables, estimaciones, sprints, estados, fechas, dependencias y gran parte de la información relacionada con la ejecución del trabajo.

El desafío aparece cuando el proyecto crece. Podemos tener cientos o miles de actividades distribuidas entre diferentes equipos, proyectos y tipos de trabajo. En ese escenario, encontrar una tarea que ya está retrasada no es necesariamente difícil. La pregunta difícil es otra:

“¿Qué está ocurriendo hoy que puede hacer que mi entrega se retrase dentro de tres semanas?”

Para responder a esa pregunta no quiero mirar únicamente la fecha final de una tarea. Quiero entender cómo está evolucionando esa actividad, cómo se comportaron actividades similares, si el equipo está entregando lo que había planificado, si existen problemas con las estimaciones, si el trabajo está concentrado en pocas personas, si aparecen señales de retrabajo y si empiezan a producirse desviaciones relevantes de esfuerzo, productividad o coste.

En otras palabras, el board sigue siendo fundamental para organizar el trabajo. Pero existe una diferencia entre hacer seguimiento de tareas e interpretar lo que los datos de esas tareas están diciendo sobre la salud del proyecto.

Aquí es donde entra Saint Jude Project Intelligence

Precisamente este es uno de los motivos por los que creamos el módulo de riesgos de Saint Jude Project Intelligence .

Saint Jude no fue creado para sustituir Jira, Azure DevOps, Asana, Monday.com o ClickUp. Estas plataformas continúan siendo el lugar donde los equipos organizan y ejecutan el trabajo. Saint Jude trabaja en una capa diferente: utiliza los datos de esos proyectos para ayudar a gerentes de proyectos, PMOs y líderes a interpretar lo que está ocurriendo e identificar señales que merecen atención.

En el módulo de riesgos, el gerente puede estructurar y supervisar los riesgos del proyecto y mantener un historial de su evolución. Pero existe una parte que considero todavía más interesante: la inteligencia artificial de Saint Jude puede analizar el progreso real del proyecto para generar riesgos y sugerir planes de acción a partir de la información encontrada.

Esto significa que señales como un sprint entregando por debajo de lo planificado, actividades sin estimaciones, problemas en la calidad con la que se han definido las tareas, diferencias relevantes entre esfuerzo y entrega u otros patrones encontrados durante la ejecución pueden dejar de ser información dispersa entre decenas o cientos de tickets y pasar a formar parte de un análisis de riesgos.

El gerente continúa teniendo autonomía para crear sus propios riesgos y planes de acción, porque no todos los riesgos se encuentran dentro de un board. Existen decisiones políticas, cambios estratégicos, información de clientes, negociaciones comerciales y factores externos que ninguna integración puede descubrir completamente por sí sola.

El objetivo no es quitarle la decisión al gerente. Es darle más información y, sobre todo, más tiempo para decidir.

La diferencia entre identificar un riesgo y explicar un retraso

Para mí existe una enorme diferencia entre decir “tu proyecto se retrasó porque la actividad X terminó ocho días después de lo esperado” y decir “la actividad X está mostrando señales de que puede comprometer la próxima entrega”.

La primera frase es útil. Explica el pasado y puede ayudarnos a evitar que el mismo problema vuelva a ocurrir. Precisamente este es el tipo de análisis que abordo en Cómo encontrar la causa raíz de los problemas de tu proyecto .

Pero la segunda frase tiene una característica diferente: todavía permite tomar una decisión antes de que ocurra la consecuencia. Tal vez pueda cambiar una prioridad, reasignar a una persona, dividir el alcance, hablar con otro equipo, renegociar una dependencia o informar al stakeholder antes de que aquello se convierta en una sorpresa.

Project Intelligence no elimina los riesgos. Aumenta el tiempo que tienes para reaccionar.

No creo que exista una plataforma, una metodología o un gerente capaz de eliminar todos los riesgos de un proyecto. Los proyectos implican incertidumbre. Las personas cambian, las estimaciones fallan, los proveedores se retrasan, las prioridades se modifican, los clientes cambian de opinión y la tecnología puede fallar. Las dependencias seguirán existiendo independientemente de la herramienta que utilicemos.

La diferencia está en cuándo descubrimos que algo está empezando a ir en la dirección equivocada.

Si descubro un problema en el momento en que la entrega debería producirse, tengo pocas opciones. Si lo descubro algunas semanas antes, quizá pueda cambiar una prioridad, reasignar profesionales, reducir o dividir el alcance, renegociar una dependencia, modificar la secuencia del trabajo, involucrar a otro equipo o crear un plan de mitigación.

Al final, gestionar riesgos también significa gestionar el tiempo disponible para tomar decisiones.

Y quizá esta sea una de las principales diferencias entre hacer seguimiento de un cronograma y entender realmente un proyecto. El método de la ruta crítica nos ayuda a identificar qué secuencias de actividades determinan nuestras entregas. Las dependencias muestran cómo están conectadas esas actividades. La gestión de riesgos intenta entender qué puede impedir que aquello que planificamos ocurra realmente.

Project Intelligence añade una cuarta capa a esta ecuación: utilizar los datos que el proyecto ya produce para buscar señales de que algo está empezando a desviarse de lo esperado.

Porque el objetivo no debería ser únicamente descubrir por qué una entrega se retrasó. Eso sigue siendo importante, pero en ese momento ya estamos analizando el pasado.

El objetivo debería ser identificar, mientras todavía tenemos tiempo para hacer algo, qué puede hacer que esa entrega se retrase.

Y muchas veces la respuesta comienza en una tarea aparentemente pequeña que otra actividad está esperando para poder comenzar.

¿Y en tu proyecto? ¿Sabes qué actividades pueden realmente comprometer la fecha final o solo lo descubres cuando ya están retrasadas?

¡Hasta la próxima!

Erik Scaranello