Tu proyecto va atrasado: 6 movimientos antes de pedir plazo

Antes de mover el plan, nombrá la causa dominante. Si mezclás todas, la “solución” será ruido:

Si el atraso es de estimación crónica, el fix de fondo está en cómo estimar tiempos— pero hoy necesitás un plan de recuperación, no un post-mortem eterno.

Mientras el proyecto está rojo, no entran features nuevas salvo que saquen otra del compromiso. Decilo en una frase compartida con el equipo y el stakeholder:

“Hasta el hito del [fecha], solo trabajamos en [lista A]. Todo lo demás va a backlog post-hito o reemplaza algo de A con aprobación explícita.”

Sin freeze, el scope creep se come el rescate. Detalle en alcance de proyecto y scope creep.

Tres palancas (en este orden de preferencia cuando el valor del hito lo permite):

1. Recortar alcance: “debe” → “después del hito”.
2. Resecuenciar: entregar un núcleo usable antes; el resto en una segunda ola.
3. Bajar calidad cosmético (no calidad estructural): menos polish, mismos criterios de “funciona y es seguro”. Nunca recortes testing crítico para “llegar”.

Si gestionás varios frentes, el recorte puede ser de otro proyecto para liberar capacidad — ver el pilar cómo gestionar varios proyectos a la vez.

No todas las tareas atrasadas mueven la fecha de entrega. Identificá la ruta crítica: la cadena de dependencias que define el fin del proyecto.

• Poné a la gente más capaz (o más disponible) en la ruta crítica.
• Sacá de su plato el trabajo que no mueve la fecha.
• Atacá bloqueos de la ruta crítica primero, no los más ruidosos.
• Evitá WIP alto: terminar un eslabón crítico vale más que empezar tres.

Un mensaje útil al stakeholder tiene cuatro bloques, en este orden:

1. Hecho: “Estamos X días / % detrás del plan del hito Y.”
2. Causa en una línea: alcance / capacidad / bloqueo / estimación (sin novela).
3. Qué ya hicimos: freeze, recortes, reasignaciones.
4. Opciones con trade-off: A) misma fecha, menos alcance; B) mismo alcance, nueva fecha; C) más capacidad (si existe).

Plantilla corta: “El hito del 20 queda en riesgo. Causa principal: [Z]. Ya congelamos alcance y sacamos [ítems]. Opciones: (1) entregar núcleo el 20 sin [feature]; (2) entregar completo el 27; (3) sumar [recurso] y mantener fecha. ¿Cuál preferís?”

Pedir tiempo es legítimo cuando el trabajo restante, con alcance ya recortado y ruta crítica desbloqueada, sigue sin caber. Entonces:

• Nueva fecha basada en reestimación de lo que queda (no en optimismo).
• Hitos intermedios visibles (no un “nuevo fin” a 3 meses sin checkpoints).
• Qué se protege y qué queda explícitamente afuera.
• Riesgos residuales y cómo se miran cada semana.

• Esconder el atraso hasta la semana del release.
• Horas heroicas como plan principal — agotan al equipo y no arreglan un alcance imposible.
• Abrir otro proyecto “para distraer” o quedar bien con otro cliente mientras este se hunde.
• Culpar en público a una persona: el diagnóstico es del sistema (alcance, capacidad, proceso).

• Buffer de capacidad en el plan (no al 100%).
• Definition of Ready antes de comprometer (ver sprint planning si usás sprints).
• Check de ruta crítica semanal en proyectos con fecha dura.
• Portafolio con límite de frentes activos — un atraso no debería nacer de tener 8 “prioridades 1”.