Planificación por olas sucesivas: la elaboración progresiva explicada

Un patrocinador le pide un cronograma totalmente detallado hasta el mes dieciocho de un proyecto que tiene tres semanas, y usted no dispone de la información para entregarlo con honestidad. La planificación por olas sucesivas es la respuesta que no es "me lo inventaré" ni "no puede tener un cronograma". Es una técnica real con reglas reales, y le da un lenguaje que un patrocinador aceptará en lugar de un plan que estará reescribiendo en la sexta semana.

Key Facts

• La Guía del PMBOK, octava edición (PMI, noviembre de 2025) es la Guía del PMBOK vigente, construida en torno a siete dominios de desempeño, entre ellos el alcance y el cronograma, los mismos dos dominios que un plan por olas sucesivas debe mantener sincronizados cada vez que cambia una ola.
• "La planificación por olas sucesivas, si se hace bien, le da al equipo del programa un marco para crear un enfoque de programa equilibrado entre control y flexibilidad", según la propia guía del PMI sobre la gestión de programas con olas sucesivas de Gregory D. Githens, PMP.
• La adopción de la gestión de proyectos híbrida pasó del 20 % de los proyectos en 2020 al 31,5 % en 2023, un aumento del 57,5 %, según la investigación del PMI sobre el cambio hacia el enfoque adecuado al propósito, el cambio que hizo común la planificación por olas sucesivas mucho más allá de su hogar original en la gestión de programas.
• Un paquete de planificación "debe convertirse en paquetes de trabajo antes de que se incurra en cualquier cargo por el esfuerzo", según la guía del PMI sobre el uso de paquetes de planificación para el valor ganado de Timothy J. Pasko, la regla que evita que un plan por olas sucesivas gaste en silencio contra trabajo que nadie ha detallado todavía.

Qué es realmente la planificación por olas sucesivas (y en qué se diferencia de la elaboración progresiva)

La mayoría de las páginas sobre este tema usan estos dos términos como intercambiables, y eso es lo primero que hay que corregir. La elaboración progresiva es el principio: un plan se vuelve más detallado y preciso a medida que llega mejor información, y eso es tan cierto para las secciones de alcance, costo y riesgo de un plan de proyecto como para su cronograma. La planificación por olas sucesivas es la técnica de programación que pone en práctica ese principio con una cadencia definida, y convierte "ya lo resolveremos sobre la marcha" en un horizonte y una fecha de replanificación.

En la práctica, eso significa descomponer el trabajo cercano hasta el nivel de paquete de trabajo o de actividad, el punto en que una tarea tiene un responsable, una duración y una lista de dependencias, mientras que todo lo que está más lejos permanece agrupado en un "paquete de planificación" grueso: una cifra de presupuesto y un hito aproximado, nada más. Cuando llega el límite de la ola, el siguiente bloque recibe su pasada detallada y el horizonte avanza. Esa es la parte "sucesiva", y es lo que distingue a la técnica de una elaboración progresiva que ocurre de manera improvisada.

Tenga presente esta distinción: la mayor parte de lo que sale mal con la planificación por olas sucesivas se remonta a tratar la técnica misma, la ola, la cadencia, la conversión de paquetes de planificación en paquetes de trabajo, como algo opcional, y conservar solo el espíritu vago de "nos adaptaremos más adelante". Los dominios de desempeño de la Guía del PMBOK tratan el alcance y el cronograma como áreas que deben gestionarse de forma integrada, y la planificación por olas sucesivas es una manera concreta de hacerlo cuando el extremo lejano de un proyecto todavía no se puede conocer.

Cómo funciona realmente la planificación por olas sucesivas: la vista ola por ola

Imagine un programa de migración de plataforma de 12 meses, dividido en cuatro fases secuenciales: Descubrimiento, Construcción, Pruebas y Puesta en marcha (Cutover), con un horizonte de ola de 3 meses. Al comienzo, solo el Descubrimiento se descompone hasta el nivel de paquete de trabajo. Todo lo posterior existe como un único paquete de planificación por fase: un presupuesto total y un mes objetivo de finalización, sin lista de tareas.

Dos cosas hacen que esto funcione en lugar de ser un nombre más bonito para "improvisaremos". Cada paquete de planificación sigue teniendo un presupuesto y una fecha objetivo reales, de modo que el programa tiene una línea base total desde el primer día aunque los detalles internos no estén definidos. Y la conversión de un paquete de planificación en un paquete de trabajo ocurre en una fecha fija, no cuando alguien se acuerda. El texto de Gregory Githens para el PMI lo plantea bien: identifique el trabajo futuro con un marcador de "caja negra" que ocupa el lugar del detalle que añadirá más adelante, y trate el propio límite de la ola como trabajo programado, un entregable que alimenta la misma disciplina de entregables del proyecto que aplicaría a cualquier otra cosa que el proyecto produzca. Los entregables de la ola cercana reciben criterios de aceptación completos; los entregables que están a dos o tres olas de distancia permanecen como marcadores hasta que llega su ola.

Cómo elegir el horizonte y la cadencia de sus olas

No existe una tabla emitida por el PMI que diga que una ola debe durar exactamente seis semanas o exactamente un trimestre. El horizonte es una decisión de criterio, determinada por la rapidez con que sus supuestos quedan obsoletos. Si es demasiado corto, dedica más tiempo a replanificar que a hacer el trabajo; si es demasiado largo, la ola "detallada" a la que se comprometió se habrá alejado de la realidad antes de que llegue a la mitad. Los verdaderos factores: la volatilidad de los requisitos, los plazos de adquisición o de entrega de proveedores, el tipo de contrato y la estabilidad del equipo (un horizonte más largo que la permanencia promedio de un integrante del equipo es buscarse problemas). El propio ejemplo desarrollado de Githens es un buen punto de referencia: un programa de 18 meses con horizontes de 3 meses y un factor de seguridad del 20 por ciento da como resultado aproximadamente siete horizontes de tiempo en la parte superior de la EDT, cada uno un punto de control para revalidar los supuestos antes de comprometer el siguiente bloque de detalle.

Trate esto como un punto de partida, no como una regla. La verdadera prueba es si su ola cercana se mantiene precisa durante toda su ventana. Si no es así, acorte el horizonte; si la replanificación se siente como trabajo burocrático porque nada cambió, alárguelo. La incertidumbre que ya está genuinamente resuelta no necesita una ola en absoluto, una decisión que vale la pena tomar durante la gestión de riesgos del proyecto en lugar de recurrir a un horizonte sugerido por una tabla.

Planificación por olas sucesivas y la estructura de desglose del trabajo

La planificación por olas sucesivas no reemplaza la estructura de desglose del trabajo; cambia el momento en que cada rama se descompone por completo. La regla del 100 % sigue aplicándose a todo el programa en cada momento, pero las ramas lejanas la satisfacen con un único paquete de planificación en lugar de un árbol de paquetes de trabajo. Ese término vale la pena tomarlo prestado de la gestión del valor ganado incluso sin EVM formal: el texto de Timothy Pasko para el PMI lo define como trabajo de plazo lejano dentro de una cuenta de control que puede identificarse, programarse y presupuestarse, pero que aún no está planificado en detalle. La regla que le da fuerza: se convierte en uno o más paquetes de trabajo antes de que se le impute cualquier cargo real. Puede presupuestar contra un marcador. No puede gastar contra uno.

Construir primero la EDT del programa completo a nivel de paquete de planificación es lo que mantiene intacta la regla del 100 % a lo largo de cada ola. Si omite ese paso y comienza la EDT de cada ola desde cero, redescubrirá alcance olvidado tres olas más tarde, una forma mucho más costosa de encontrarlo que verificar contra un marcador que escribió el primer día.

Líneas base y planificación por olas sucesivas: la parte difícil

Esta es la parte que la mayoría de las explicaciones de esta técnica omite, y en la que un gerente de proyecto real se atasca: ¿cómo se mantiene una línea base del proyecto significativa cuando la mitad de la EDT está deliberadamente sin definir?

Usted establece la línea base de elementos distintos con niveles de confianza distintos, y lo dice explícitamente en lugar de fingir que todo el plan tiene el mismo peso. El alcance, el cronograma y el costo de la ola actual se establecen en línea base con detalle de paquete de trabajo, con el mismo rigor que aplicaría a un proyecto totalmente predictivo. Todo lo que está más allá también se establece en línea base, solo que a nivel de paquete de planificación: un presupuesto total y una fecha de hito, no una lista de tareas. La restricción exterior, el presupuesto total del programa y su fecha de finalización, se establece en línea base desde el primer día y se mantiene como aquello dentro de lo cual debe encajar cada ola.

Aquí es donde la planificación por olas sucesivas se cruza más directamente con un proceso de control de cambios. Convertir un paquete de planificación en paquetes de trabajo, en la fecha prevista, en el límite al que ya se comprometió, no es un cambio, es el plan funcionando como fue diseñado. Lo que sí es un cambio: adelantar alcance de una ola futura sin revisar su presupuesto, o dejar que el detalle de la ola actual se expanda más allá de lo que el paquete se dimensionó para contener. Ambos se ven, desde afuera, exactamente como una expansión del alcance en el vocabulario de olas sucesivas, y lo único que los distingue es si el cambio pasó por la misma aprobación que cualquier otro cambio de línea base. Si convierte paquetes sin que nadie apruebe el resultado, tendrá una línea base que se reinicia sola cada pocos meses sin que nadie responda por lo que cambió.

Estimar en una ola sucesiva

La estimación de la ola actual y la de una ola tres horizontes más adelante no deberían usar el mismo método. El trabajo de la ola cercana se comprende lo suficientemente bien como para merecer una pasada ascendente: dividirlo en tareas y aplicar la estimación de tres puntos para obtener un rango optimista, más probable y pesimista en lugar de una sola cifra disfrazada de certeza. El trabajo de las olas lejanas se apoya en la estimación análoga (comparar el paquete de planificación con uno similar de un programa anterior) o en la estimación paramétrica (una tasa histórica multiplicada por una cantidad aproximada), las técnicas que se tratan en la estimación de costos del proyecto para el presupuesto en etapas iniciales.

Lo que debería ajustarse, ola tras ola, es la estimación de lo que está por entrar en el horizonte actual: la ola anterior era una cifra análoga aproximada, esta ola es una cifra ascendente construida con lo que aprendió al ejecutar la ola previa. Verá esta progresión descrita en otros lugares con un porcentaje de confianza específico asociado a cada clase de estimación, desde el orden de magnitud aproximado en un extremo hasta la estimación definitiva en el otro. Trate cualquier versión que no pueda rastrear hasta una fuente nombrada y accesible como decoración, no como evidencia. Lo que es cierto sin una cifra adjunta: el rango se estrecha porque usted reemplaza supuestos por mediciones una ola a la vez, y ese estrechamiento es el objetivo.

Dónde encaja la planificación por olas sucesivas: predictivo, híbrido y ágil

La planificación por olas sucesivas surgió de la gestión de proyectos predictiva y centrada en programas, el mundo de las cuentas de control y el valor ganado. Está igual de cómoda en la entrega híbrida, donde suele ser el tejido conectivo: el trabajo cercano se ejecuta dentro de sprints ágiles, mientras que todo lo más lejano permanece a nivel de paquete de planificación hasta que está lo suficientemente cerca como para justificar un backlog listo para el sprint. Esa es en buena parte la razón por la que se ha extendido más allá de su hogar original; la propia investigación del PMI sobre el cambio hacia la entrega adecuada al propósito encontró que la adopción híbrida pasó del 20 % de los proyectos en 2020 al 31,5 % en 2023.

Algo que la mayoría de las comparaciones de agile vs waterfall pasan por alto: un equipo ágil que hace refinamiento del backlog hace estructuralmente lo mismo que un programa que aplica planificación por olas sucesivas, solo que con otro vocabulario y un horizonte más corto. La Scrum Guide describe el refinamiento como dividir los elementos del Product Backlog y añadirles detalle, de modo que los elementos se consideran "listos para su selección en un evento de Sprint Planning" solo una vez que han adquirido ese detalle, mientras que los elementos más abajo permanecen gruesos hasta que les llega el turno. Sustituya "sprint" por "ola" y "refinamiento del backlog" por "convertir un paquete de planificación", y estará describiendo la misma disciplina.

El argumento honesto para un patrocinador escéptico del lenguaje que "suena ágil": la planificación por olas sucesivas no es una concesión a la incertidumbre, es una forma más precisa de representar una incertidumbre que ya existe. La planificación completa por adelantado no elimina esa incertidumbre, solo la oculta dentro de cifras que parecen más seguras de lo que son.

Cuándo la planificación por olas sucesivas es la opción equivocada

La técnica justifica su lugar cuando el extremo lejano del proyecto es genuinamente incognoscible. Es la opción equivocada cuando eso no es cierto, o cuando quien paga necesita una certeza que estructuralmente no puede darle.

Githens hace un comentario relacionado que vale la pena repetir porque corta en sentido contrario: las olas sucesivas están pensadas para el trabajo de desarrollo, donde el extremo lejano está genuinamente sin resolver, y aplicarlas a un proyecto de despliegue (una implementación, una migración, una puesta en marcha ya bien comprendida antes de comenzar) puede hacer que ese proyecto sea más lento y menos eficiente que planificarlo todo por adelantado. Es una respuesta específica a un tipo específico de incertidumbre, y debería retirarse una vez que esa incertidumbre desaparece.

Cómo se abusa de la planificación por olas sucesivas

Esta es la sección que la mayoría de las explicaciones omite, y la que más importa cuando usted defiende la técnica ante una PMO escéptica. Las "olas sucesivas" son un método legítimo, y también una frase que sirve de coartada a equipos que nunca tuvieron la intención de planificar.

Ninguna de estas es exótica. Son el resultado previsible de adoptar el vocabulario de las olas sucesivas sin su disciplina, y todas se pueden corregir poniendo una fecha, un responsable y un paso de aprobación donde antes había una vaga intención.

Cómo implementar la planificación por olas sucesivas: paso a paso

Paso 1: confirme que esta es realmente la técnica adecuada

Verifique que la incertidumbre sea real, no solo que no se ha abordado. Si las fases posteriores se comprenden bien pero nadie ha programado el trabajo para planificarlas, eso es una brecha de planificación, no un caso para las olas sucesivas. La incertidumbre genuina suele remontarse a dependencias sin resolver, o a un ciclo de vida del proyecto en el que las fases posteriores dependen de resultados que aún no tiene.

Paso 2: defina el horizonte y la cadencia de las olas

Use los factores anteriores: volatilidad de los requisitos, plazo de adquisición, tipo de contrato, estabilidad del equipo. Escriba el horizonte y las fechas de replanificación en el propio cronograma, no en una conversación aparte.

Paso 3: construya la EDT del programa completo a nivel de paquete de planificación

Cada fase y cada entregable recibe al menos un paquete de planificación, una cifra de presupuesto y una fecha de hito, antes de descomponer cualquier cosa más. Esto protege la regla del 100 % en cada ola desde el primer día.

Paso 4: descomponga la ola actual hasta el nivel de paquete de trabajo

Aplique la regla 8/80 solo a la ola actual. Estímela con la estimación de tres puntos, ahora que el trabajo se comprende lo suficientemente bien como para sustentar un rango real.

Paso 5: establezca la línea base de la ola actual y de la restricción exterior del programa

Establezca la línea base de la ola actual con detalle completo, y la del presupuesto total del programa y su fecha de finalización como la restricción dentro de la cual debe encajar cada ola futura.

Paso 6: ejecute, haga seguimiento y proteja la fecha del límite de la ola

Ejecute la ola actual como cualquier otra pieza de trabajo bien gestionada, haciendo seguimiento de los valores reales frente a la línea base que acaba de establecer.

Paso 7: replanifique en el límite y trátelo como un entregable real

Cuando llegue el límite, convierta el siguiente paquete de planificación en paquetes de trabajo usando lo que aprendió al ejecutar la ola anterior, haga pasar cualquier cambio de línea base resultante por el control formal de cambios y haga avanzar el horizonte.

Errores comunes con la planificación por olas sucesivas

La planificación por olas sucesivas no es una forma de evitar comprometerse. Es una manera más honesta de comprometerse: detalle completo para lo que usted sabe, un presupuesto y una fecha reales para lo que aún no sabe, y un punto fijo en el que esa brecha se cierra. Defina el horizonte con criterio, ponga una fecha al trabajo de replanificación de cada ola y mantenga estable la línea base exterior mientras el detalle interno avanza, y tendrá un plan en el que un patrocinador puede confiar en el mes uno y seguir confiando en el mes doce.