Gestión del cronograma: ruta crítica, holgura y compresión del cronograma

Un cronograma no es una lista de fechas. Es un modelo de cómo el trabajo depende de otro trabajo, y su verdadero resultado es la respuesta a una sola pregunta: ¿qué actividades, si se retrasan un día, mueven un día la fecha de fin? Todo lo demás (el diagrama de barras, el informe de hitos, el histograma de recursos) es presentación sobre ese modelo.

Esta guía construye el modelo desde cero con un ejemplo pequeño que puedes seguir con lápiz y papel, y después explica qué hacer una vez que lo tienes: nivelar recursos, comprimir un cronograma demasiado largo y mantener una línea base con sentido cuando la realidad se aparta de ella. Da por hecho que ya tienes una descomposición del trabajo, tema que cubre la guía de fundamentos de la gestión de proyectos.

De los paquetes de trabajo a la secuencia

La programación empieza convirtiendo cada paquete de trabajo en una o más actividades (los verbos, donde la estructura de desglose contenía los sustantivos) y decidiendo después qué debe ir antes de qué. Dos disciplinas dan fruto de inmediato: cada actividad tiene exactamente un responsable y cada actividad tiene un criterio de finalización claro, para que un «en curso» no pueda durar semanas.

Las dependencias son de cuatro tipos, y usar el adecuado evita mucha serialización artificial.

FS cubre la inmensa mayoría de los casos. SS y FF son las que permiten modelar con honestidad el trabajo que se solapa en lugar de forzar una secuencia falsa. SF es rara y aparece sobre todo en los cambios de sistema.

El adelanto es una espera negativa: empezar una sucesora antes de que termine su predecesora, por ejemplo iniciar las pruebas de integración dos días antes de que esté completo el último componente. El retraso es una espera impuesta que no consume esfuerzo: el fraguado del hormigón, un periodo de preaviso regulatorio de dos semanas, una reindexación de la base de datos que se ejecuta de noche. Modela los retrasos de forma explícita en lugar de inflar la duración de una actividad, porque un retraso no tiene coste y no se puede acortar con más recursos, y esconderlo dentro de una duración hace que el cronograma mienta sobre ambas cosas.

Distingue las dependencias obligatorias, inherentes al trabajo, de las discrecionales, que reflejan una preferencia o una costumbre. En las discrecionales es donde la compresión del cronograma suele encontrar margen, así que márcalas al crearlas.

Estimar duraciones

Tres técnicas cubren casi todas las necesidades, y lo normal es combinarlas.

La estimación análoga escala a partir de una actividad pasada comparable: la última migración de tamaño parecido llevó nueve días, esta es algo mayor, pongamos doce. Rápida, barata y tan buena como lo sea la comparación.

La estimación paramétrica usa un ritmo medido: 40 pantallas a 1,5 días por pantalla son 60 días. Es la técnica más defendible cuando ese ritmo existe de verdad, y peligrosa cuando el parámetro se inventa para justificar una cifra.

La estimación por tres valores recoge la incertidumbre de forma explícita con un valor optimista, uno más probable y uno pesimista. La forma ponderada con la distribución beta, asociada a PERT, es:

Expected duration   te = (O + 4M + P) / 6
Standard deviation  sd = (P - O) / 6

Backend build:  O = 6 days, M = 9 days, P = 18 days
   te = (6 + 36 + 18) / 6 = 10 days
   sd = (18 - 6) / 6 = 2 days

Interpretation: ~10 days expected; roughly 95% confidence
of finishing within te + 2sd = 14 days.

Fíjate en cómo la cola larga empuja el valor esperado por encima del más probable: esa asimetría es la realidad de las actividades de software, donde las cosas salen mal más a menudo de lo que salen inusualmente bien. El dimensionamiento relativo a nivel de equipo es otra herramienta para otra pregunta, y se trata en estimación y planificación.

Una ruta crítica resuelta paso a paso

Piensa en una entrega pequeña con nueve actividades. Las duraciones están en días laborables.

La pasada hacia delante avanza de izquierda a derecha y calcula el inicio y el fin más tempranos de cada actividad. Una actividad empieza en cuanto han terminado todas sus predecesoras, así que, cuando confluyen varias, se toma el fin más tardío. La pasada hacia atrás recorre después la red de derecha a izquierda desde el final del proyecto y calcula el inicio y el fin más tardíos de cada actividad sin empujar esa fecha de fin; cuando una actividad tiene varias sucesoras, se toma el inicio tardío más temprano.

El proyecto dura 29 días y hay dos rutas críticas: A–B–D–G–H–I y A–C–E–G–H–I suman 29 las dos. Solo F tiene holgura, nueve días, porque aunque los scripts están listos el día 15, el ensayo de la migración no puede empezar hasta que terminen las pruebas de integración el día 24. La holgura libre de F también es de nueve días, ya que retrasarla hasta ese punto no afecta al inicio temprano de ninguna sucesora.

De aquí salen dos lecturas prácticas. Primera: los scripts de migración no son urgentes, así que tomar prestado a ese desarrollador durante una semana no cuesta nada; el cronograma te dice dónde hay margen de verdad, algo que la intuición rara vez consigue. Segunda: como hay dos rutas críticas, acortar solo el desarrollo del backend no cambia absolutamente nada, porque la ruta del frontend sigue llegando al día 19. Es el error más común al comprimir un cronograma, y solo se ve si calculas la red en lugar de juzgar a ojo el diagrama de barras.

Presentar y nivelar

Un diagrama de Gantt representa la red como barras sobre un calendario. Es excelente para comunicar y pésimo como herramienta de planificación por sí solo, porque un diagrama de barras dibujado a mano codifica fechas sin dependencias: cuando una barra se mueve, ninguna otra lo hace, y el plan se convierte sin que nadie lo note en ficción. Genera siempre el diagrama a partir de la red. Muestra la ruta crítica en un color distinto, marca los hitos con rombos y resiste la tentación de enseñarle cuatrocientas filas a un comité de dirección cuando nueve barras de resumen bastan para transmitir el mensaje.

Los hitos son marcadores de duración cero de un estado significativo: diseño aprobado, entorno de integración disponible, aceptación de usuario firmada. Sirven mejor para informar que los porcentajes porque son binarios. Un gráfico de tendencia de hitos, que traza la fecha prevista de cada hito en cada periodo de seguimiento, es el informe de cronograma más revelador que existe, ya que una línea que deriva poco a poco hacia la derecha muestra un problema meses antes de que se incumpla el hito.

Luego los recursos chocan con el plan. La nivelación de recursos ajusta el cronograma para que la demanda nunca supere la disponibilidad; como puede retrasar actividades, puede alargar la fecha de fin del proyecto y cambiar qué ruta es crítica. El alisamiento de recursos solo ajusta las actividades dentro de su holgura disponible, de modo que la fecha de fin se conserva, pero la demanda solo se aplana hasta donde la holgura lo permite. Si un mismo especialista aparece en las dos rutas críticas del ejemplo anterior, la nivelación alargará el proyecto y ningún informe lo va a cambiar.

Comprimir un cronograma

Cuando la fecha de fin calculada es posterior a la exigida, hay exactamente dos técnicas legítimas y una alternativa honesta.

El crashing añade recursos a las actividades críticas para acortarlas, lo que cuesta dinero y no escala de forma lineal: duplicar el equipo rara vez reduce la duración a la mitad, y sumar personas a un trabajo ya en marcha suele ralentizarlo. Aplícalo primero a la actividad crítica cuyo día ahorrado salga más barato, y recalcula la red después de cada paso, porque la compresión cambia qué ruta es crítica.

Siguiendo con el ejemplo, supón que el plazo es de 25 días en lugar de 29:

Acelerar H ahorra un día en ambas rutas por 2.000: claramente, lo primero. Acelerar G ahorra otro día en ambas por 6.000. Acelerar D o E no ahorra nada salvo que se aceleren las dos, lo que cuesta 13.000 en total y ahorra dos días. Así que llegar a 25 días cuesta 21.000 y afecta a cuatro actividades, mientras que el intuitivo «aceleremos el backend» habría gastado 8.000 sin ahorrar nada.

El fast tracking solapa actividades que estaban en serie, normalmente convirtiendo una dependencia fin a inicio en una inicio a inicio con adelanto. No cuesta dinero, pero compra riesgo de retrabajo: empezar el frontend antes de terminar el diseño de interfaces significa que una parte se construirá dos veces. Aplícalo primero a las dependencias discrecionales, nunca a las obligatorias, y anota el riesgo añadido en el registro de riesgos.

La alternativa honesta es reducir el alcance. Suele ser más barata y más segura que cualquiera de las dos técnicas, y es la opción que se plantea en último lugar.

Línea base, cambios y seguimiento

Una vez acordado el cronograma, congela una copia como línea base. Todo lo que venga después se mide contra ella, y solo cambia mediante un control de cambios aprobado; de lo contrario, el plan se reescribe discretamente cada mes para cuadrar con la realidad y el proyecto parece estar en plazo hasta el día en que ya no lo está.

Un proceso de cambios que funciona: una evaluación del impacto en plazo, coste y riesgo; una decisión de quien tenga la autoridad para ese umbral; una nueva línea base solo si el cambio se aprueba; y un registro conservado de la línea base anterior. Rehacer la línea base es legítimo tras un cambio de alcance real e ilegítimo como forma de borrar una desviación.

Haz el seguimiento midiendo el avance contra la red, no contra el tiempo de calendario transcurrido. Las preguntas que vale la pena hacerse cada semana son si alguna actividad crítica va con retraso, cuánta holgura se ha consumido en las rutas casi críticas, si las previsiones de los hitos están derivando y si alguna hipótesis de dependencia ha dejado de ser válida. La desviación del cronograma en términos de coste se trata en gestión del valor ganado, que convierte la misma información en dinero y te da un índice cuya tendencia puedes seguir.

Ideas clave

• Un modelo de cronograma sirve para identificar qué actividades no pueden retrasarse; el diagrama de barras es presentación, y dibujarlo sin una red de dependencias produce un plan incapaz de reaccionar.
• Usa los cuatro tipos de dependencia y modela los retrasos de forma explícita en lugar de inflar duraciones, y marca las dependencias discrecionales, porque ahí es donde la compresión encuentra margen.
• Calcula la holgura con una pasada hacia delante y otra hacia atrás; la holgura total es margen frente a la fecha de fin, y la holgura libre es el margen que no afecta a ninguna sucesora.
• Una red puede tener varias rutas críticas, y comprimir solo una no sirve de nada: recalcula siempre después de cada paso de compresión.
• La nivelación puede alargar la fecha de fin; el alisamiento, no. Si un especialista está en dos rutas críticas, el cronograma se alargará.
• Establece una línea base del cronograma y cámbiala solo mediante decisiones que queden registradas; rehacer la línea base para borrar una desviación destruye la única referencia que tenías.