---
title: "Cómo recuperar un proyecto retrasado: fast-tracking, crashing y otras opciones"
description: "Cómo recuperar un proyecto retrasado: mide la desviación, revisa la ruta crítica y compara fast-tracking, crashing, recorte de alcance y nueva fecha."
url: https://planitude.app/es/blog/project-delay-recovery-fast-tracking-crashing
language: es
---

# Cómo recuperar un proyecto retrasado: fast-tracking, crashing y otras opciones

Cómo medir un retraso, saber si de verdad amenaza la fecha de fin y elegir entre solapar tareas, añadir personas, recortar el alcance o mover la fecha límite. Con un ejemplo calculado.

por Equipo Planitude · Publicado el 11 de octubre de 2026

Tarde o temprano todo jefe de proyecto recibe la noticia: un proveedor entrega tarde, una tarea clave se alarga más de lo previsto y la fecha de fin deja de ser creíble. La reacción instintiva es pedir a todo el equipo que vaya más rápido. Casi nunca funciona y, además, esquiva la pregunta de fondo: **¿qué retraso importa, cuánto, y cuál es la forma más barata de recuperar esos días?**

Esta guía propone un método repetible. Primero se mide el retraso y se sitúa respecto a la ruta crítica; después se comparan las cuatro palancas de las que dispone realmente un jefe de proyecto, y se comunica un plan en lugar de una disculpa.

> **En breve**
>
> - Un retraso solo amenaza la fecha de fin si afecta a la **ruta crítica** o supera la **holgura** de la tarea: primero se mide, luego se actúa.
> - El **fast-tracking** solapa tareas planificadas en secuencia. No exige esfuerzo adicional, pero aumenta el riesgo de retrabajo.
> - El **crashing** añade personas u horas a las tareas críticas. Se empieza por la que menos cuesta por día ganado, sabiendo que no todo el trabajo se puede repartir.
> - Recortar el alcance o mover la fecha también son opciones legítimas: hay que presentarlas con cifras, no como una derrota.

## Primero, medir bien el retraso

“Vamos tarde” no es un diagnóstico. Antes de elegir el remedio hay que responder a tres preguntas con datos del cronograma, no con impresiones:

1. **¿Cuánto?** La desviación en días laborables entre la fecha de fin prevista hoy y la del plan aprobado. Sin una línea base guardada no se puede responder con precisión, y es uno de los motivos para tenerla (consulta la guía sobre [línea base y desviaciones](https://planitude.app/es/blog/project-baseline-variance-guide)).
2. **¿Dónde?** Qué tarea ha provocado el retraso y si ya ha terminado, está en curso o aún no ha empezado. Un retraso que ya se ha producido solo se puede absorber aguas abajo.
3. **¿Sigue creciendo?** No es lo mismo una tarea que se retrasó una vez por una aprobación pendiente que una tarea cuyo trabajo restante aumenta semana tras semana.

Lo primero es actualizar el avance. Un plan de recuperación basado en porcentajes desactualizados recupera días que nunca se perdieron, o ignora días que ya no vuelven.

## ¿Está el retraso en la ruta crítica?

La fecha de fin depende de la **ruta crítica**, la cadena de tareas vinculadas sin holgura. Un retraso en una tarea crítica desplaza la fecha de fin día por día. Un retraso en una tarea no crítica no mueve nada hasta que consume su holgura total; a partir de ahí la tarea se vuelve crítica y cada día adicional empuja la fecha de fin. La [guía de la ruta crítica](https://planitude.app/es/blog/critical-path-method-guide) explica cómo se calcula la holgura.

De ahí sale una clasificación sencilla:

| Dónde está el retraso | Efecto en la fecha de fin | Qué hacer |
| --- | --- | --- |
| Tarea no crítica, retraso menor que su holgura | Ninguno | Vigilarla, no hace falta recuperar |
| Tarea no crítica, retraso mayor que su holgura | El exceso mueve la fecha de fin | Tratar el exceso como un retraso crítico |
| Tarea crítica | Día por día | Recuperar en las tareas críticas pendientes |

Hay dos consecuencias que se suelen pasar por alto. La primera: solo se puede recuperar tiempo en tareas que **todavía están por delante**, porque comprimir una tarea ya terminada es imposible. La segunda: tras cada cambio la ruta crítica puede moverse, y una rama que tenía cinco días de holgura puede convertirse en la nueva ruta crítica una vez comprimida la anterior.

## Las opciones de recuperación

Términos como fast tracking y crashing forman parte del vocabulario estándar de la programación de proyectos, recogido en el léxico de términos de dirección de proyectos del PMI[^1]. En la práctica, las palancas son cuatro.

### Fast-tracking: solapar el trabajo

Hacer fast-tracking consiste en empezar una tarea antes de que termine su predecesora, aunque el plan las tuviera en secuencia. En términos de programación, un vínculo fin-comienzo se sustituye por uno comienzo-comienzo con un retardo, o el retardo del vínculo existente pasa a ser negativo (un adelanto). Las pruebas arrancan con los primeros módulos terminados en lugar de esperar al desarrollo completo; los acabados empiezan en las plantas que ya están listas.

No exige esfuerzo adicional, pero tampoco es gratis: el trabajo solapado se apoya en información que todavía puede cambiar, y el precio habitual es el **retrabajo**. Conviene solapar solo cuando el resultado de la tarea anterior es suficientemente estable, y con solapes cortos. La guía de [dependencias y retardos](https://planitude.app/es/blog/task-dependencies-fs-ss-ff-sf-lag) muestra cómo modelarlos correctamente.

### Crashing: más recursos en las tareas críticas

El crashing acorta las tareas críticas añadiendo personas, horas extra o medios. La regla es económica: se comparan las opciones por **esfuerzo adicional por día ganado**, se empieza por la más barata y solo se pasa a la siguiente si todavía faltan días.

No todas las tareas se pueden comprimir. Fred Brooks, en *The Mythical Man-Month* (1975), formuló lo que se conoce como ley de Brooks: añadir personas a un proyecto de software retrasado lo retrasa aún más. Quien se incorpora necesita tiempo para entender el contexto, y cada persona adicional aumenta la coordinación. El crashing funciona con trabajo que se divide limpiamente (sesiones de formación en paralelo, guiones de prueba independientes, zonas de obra separadas) y mal con trabajo que una persona o un equipo pequeño y compenetrado tiene que pensar de principio a fin.

### Recortar el alcance

Entregar menos a tiempo suele valer más que entregarlo todo tarde. Se pasa una funcionalidad, un informe o un entregable secundario a una fase posterior, con el acuerdo explícito de quien es responsable de los requisitos. Es una decisión de negocio, no un truco de planificación: hay que dejarla por escrito.

### Mover la fecha límite

A veces la respuesta honesta es una fecha nueva. Si las demás opciones cuestan más que el retraso, o introducen riesgos inaceptables, se propone una nueva fecha de fin, se aprueba y se guarda una nueva línea base. Lo que no se debe hacer es dejar que la fecha se deslice en silencio.

## Un ejemplo calculado

Un equipo está implantando un nuevo sistema interno. La cadena crítica pendiente es: **Desarrollo**, luego **Pruebas** (10 días, un probador), luego **Formación** (5 días, un formador) y, por último, el hito **Puesta en marcha**. La **Documentación** (6 días) también empieza tras el desarrollo y debe estar lista para la puesta en marcha; avanza en paralelo a pruebas y formación, por lo que tiene 9 días de holgura.

Un problema de integración ha alargado el desarrollo 6 días laborables. El desarrollo es crítico, así que la puesta en marcha se retrasa 6 días y supera la fecha comprometida con la dirección. Los 9 días de holgura de la documentación no sirven de nada: el retraso no está ahí.

Las opciones sobre las tareas críticas pendientes:

| Opción | Días recuperados | Esfuerzo adicional | Riesgo principal |
| --- | --- | --- | --- |
| Crashing de la formación: dos formadores en sesiones paralelas, de 5 a 3 días | 2 | 1 jornada-persona (de 5 a 6) | Disponibilidad del segundo formador |
| Crashing de las pruebas: un segundo probador, de 10 a 7 días | 3 | 4 jornadas-persona (de 10 a 14) | Tiempo de incorporación del nuevo probador |
| Fast-tracking: las pruebas empiezan 1 día antes de que acabe el desarrollo | 1 | Ninguno | Retrabajo si cambia el último código |
| Recorte de alcance: el módulo de informes (4 días de desarrollo) pasa a la versión 2 | 4 | Ninguno | Aceptación de los interesados |
| Nueva fecha de puesta en marcha | 0 | Ninguno | Credibilidad, condiciones del contrato |

Ordenadas por coste por día ganado, primero va la formación (0,5 jornadas-persona por día) y después las pruebas (unas 1,3 jornadas-persona por día). Juntas recuperan 5 días con 5 jornadas-persona adicionales. El sexto día sale de un día de solape entre desarrollo y pruebas, aceptable porque la última jornada de desarrollo está reservada a documentar el código, no a nuevas funcionalidades.

La comprobación: después del desarrollo, la cadena crítica necesita ahora 7 + 3 − 1 = 9 días laborables en lugar de 15, así que los 6 días quedan recuperados. La documentación sigue necesitando 6 días y termina holgadamente dentro de esos 9: continúa sin ser crítica, con 3 días de holgura en lugar de 9. Si se hubiera comprimido más, podría haberse convertido en la nueva ruta crítica.

El recorte de alcance queda como plan B por si las pruebas sacan a la luz más defectos de los previstos.

## Elegir y comunicar el plan de recuperación

Un plan de recuperación es una propuesta dirigida a quienes aprobaron el plan original, y hay que presentarlo como tal:

- el retraso en días laborables y su causa, en una frase;
- las opciones analizadas, con días recuperados, esfuerzo adicional y riesgos;
- la combinación recomendada y la fecha de fin resultante;
- lo que se necesita de los interesados: aprobación, presupuesto para el esfuerzo adicional, una decisión sobre el alcance;
- la fecha del próximo punto de control.

Antes de enviarlo, conviene comprobar que:

- el avance está actualizado a hoy;
- la recuperación actúa solo sobre tareas que aún no han terminado;
- la ruta crítica se ha recalculado tras los cambios y ninguna otra rama se ha vuelto crítica sin que nadie lo note;
- las personas añadidas están realmente disponibles en esas fechas y no están ya sobreasignadas en otro proyecto;
- cada solape tiene un responsable que vigila el retrabajo.

## Errores frecuentes

- **Recuperar en la rama equivocada.** Comprimir tareas con holgura cuesta esfuerzo y no mueve la fecha de fin.
- **Comprimirlo todo.** Añadir personas en todas partes dispara el coste y la coordinación; solo se comprime lo necesario, empezando por lo más barato.
- **Solapar sin red.** Un solape sobre información inestable convierte un retraso en retrabajo, es decir, en un retraso mayor.
- **Ignorar la ley de Brooks.** En el trabajo que no se puede repartir, las personas nuevas frenan al equipo durante semanas.
- **Rehacer la línea base para que desaparezca el retraso.** Una línea base nueva es el resultado de una decisión aprobada, no una forma de poner la desviación a cero.
- **Comunicar tarde.** Los interesados aceptan mucho mejor un retraso acompañado de un plan que una sorpresa en la fecha de fin.

## Cómo hacerlo en Planitude

Las [funciones de seguimiento](https://planitude.app/es/features#tracking) de Planitude cubren el diagnóstico. La línea base se guarda automáticamente con la primera actualización de avance y cada barra muestra su desviación en días laborables. Se señalan las tareas vencidas, las que van por detrás del plan y las que se han movido desde tu última visita, y los vínculos se vuelven rojos cuando un retraso supera la holgura y se propaga por la cadena; al pasar el ratón se ve cuánto se desplaza cada tarea. Con la [ruta crítica y la holgura total](https://planitude.app/es/features#planning) visibles se ve al instante si el retraso afecta a la fecha de fin.

Para probar una recuperación, se cambia el plan y el motor recalcula: un vínculo FS pasa a ser SS con retardo, una tarea se acorta tras añadir a una segunda persona, la [vista de Carga de trabajo](https://planitude.app/es/features#views) avisa de las sobreasignaciones. El historial de versiones y la opción de deshacer permiten volver atrás si una opción no funciona. El [análisis Monte Carlo](https://planitude.app/es/features#risk) indica la probabilidad de la nueva fecha de fin (P50, P80, P95), y la estimación con IA del riesgo de retraso marca las tareas abiertas que merecen atención.

También se le pueden pedir los cambios al [asistente de IA](https://planitude.app/es/features#ai): cada propuesta se muestra en vista previa y se revisa antes de aplicarse. Cuando la recuperación esté aprobada, guarda una nueva línea base.

**Prueba Planitude con tu propio plan** [Prueba Planitude gratis](https://planitude.app/es/signup)

## Preguntas frecuentes

### ¿Qué diferencia hay entre fast-tracking y crashing?

El fast-tracking solapa tareas planificadas en secuencia: no exige esfuerzo adicional, pero aumenta el riesgo de retrabajo. El crashing añade personas, horas o medios a las tareas críticas: cuesta esfuerzo adicional, pero mantiene el orden del trabajo.

### ¿Qué tareas conviene comprimir primero?

Solo las de la ruta crítica que aún no han terminado, empezando por la que menos cuesta por día ganado. Tras cada cambio hay que recalcular: la ruta crítica puede haberse desplazado.

### ¿Añadir personas acorta siempre una tarea?

No. El trabajo que se divide en partes independientes se acelera; el que exige una comprensión compartida suele frenarse al principio, porque quien llega necesita tiempo y la coordinación aumenta. Es el sentido de la ley de Brooks.

### ¿Cuándo es mejor mover la fecha límite?

Cuando recuperar los días costaría más que el propio retraso, o añadiría riesgos que el proyecto no se puede permitir. La nueva fecha se propone con las cifras que la justifican, se aprueba y se registra en una nueva línea base.

### ¿Cómo sé si un retraso afecta a la fecha de fin?

Se compara el retraso con la holgura total de la tarea. Si la tarea es crítica, o el retraso supera su holgura, la fecha de fin se mueve; si no, el retraso se absorbe.

## Fuentes

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

[^1]: [PMI Lexicon of Project Management Terms](https://www.pmi.org/standards/lexicon)

## 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.

[Prueba Planitude gratis](https://planitude.app/es/signup)