Rolling Wave Planning: Elaboração Progressiva Explicada

Um patrocinador pede um cronograma totalmente detalhado até o décimo oitavo mês de um projeto que tem três semanas de vida, e você não tem as informações para entregá-lo com honestidade. O rolling wave planning é a resposta que não é "vou inventar alguma coisa" nem "você não pode ter um cronograma". É uma técnica real, com regras reais, e ela lhe dá uma linguagem que um patrocinador aceita, em vez de um plano que você estará reescrevendo na sexta semana.

Fatos principais

• O PMBOK Guide, Oitava Edição (PMI, novembro de 2025) é o PMBOK Guide atual, estruturado em torno de sete domínios de desempenho, entre eles escopo e cronograma, os mesmos dois domínios que um plano de rolling wave precisa manter sincronizados toda vez que uma onda se renova.
• "O rolling wave, quando bem feito, dá à equipe do programa uma estrutura para criar uma abordagem equilibrada de programa, com controle e flexibilidade", segundo a orientação do próprio PMI sobre gerenciamento de programas com rolling wave, de Gregory D. Githens, PMP.
• A adoção do gerenciamento de projetos híbrido cresceu de 20% dos projetos em 2020 para 31,5% em 2023, um aumento de 57,5%, segundo a pesquisa do PMI sobre a mudança para abordagens adequadas ao propósito, a mudança que tornou o rolling wave planning comum muito além de seu lar original, o gerenciamento de programas.
• Um pacote de planejamento "deve ser convertido em pacotes de trabalho antes que qualquer custo seja lançado para o esforço", segundo a orientação do PMI sobre o uso de pacotes de planejamento no gerenciamento de valor agregado, de Timothy J. Pasko, a regra que impede um plano de rolling wave de gastar silenciosamente com trabalho que ninguém detalhou ainda.

O que o rolling wave planning realmente é (e como ele difere da elaboração progressiva)

A maioria das páginas sobre este tema usa os dois termos como sinônimos, e essa é a primeira coisa a corrigir. A elaboração progressiva é o princípio: um plano fica mais detalhado e preciso à medida que chegam informações melhores, e isso vale tanto para as seções de escopo, custo e risco de um plano de projeto quanto para o cronograma. O rolling wave planning é a técnica de cronograma que coloca esse princípio em prática em uma cadência definida, transformando "vamos descobrir ao longo do caminho" em um horizonte e uma data de replanejamento.

Na prática, isso significa decompor o trabalho de curto prazo até o nível de pacote de trabalho ou atividade, o ponto em que uma tarefa tem responsável, duração e lista de dependências, enquanto tudo o que está mais distante fica agrupado em um "pacote de planejamento" grosseiro: um valor de orçamento e um marco aproximado, nada além disso. Quando o limite da onda chega, o bloco seguinte recebe sua passada detalhada, e o horizonte avança. Essa é a parte "rolling" (contínua), e é o que separa a técnica da elaboração progressiva acontecendo de forma ad hoc.

Guarde essa distinção: a maior parte do que dá errado no rolling wave planning remonta a tratar a própria técnica, a onda, a cadência, a conversão de pacotes de planejamento em pacotes de trabalho, como opcional, mantendo apenas o espírito vago do "nos adaptamos depois". Os domínios de desempenho do PMBOK Guide tratam escopo e cronograma como áreas a serem gerenciadas de forma integrada, e o rolling wave planning é uma maneira concreta de fazer isso quando o fim do projeto ainda não é conhecível.

Como o rolling wave planning realmente funciona: a visão onda por onda

Imagine um programa de migração de plataforma de 12 meses, dividido em quatro fases sequenciais: Discovery, Build, Test e Cutover, com um horizonte de onda de 3 meses. No kickoff, apenas o Discovery é decomposto até o nível de pacote de trabalho. Todo o resto existe como um único pacote de planejamento por fase: um orçamento total e um mês-alvo de conclusão, sem lista de tarefas.

Duas coisas fazem isso funcionar em vez de ser um nome mais bonito para "vamos improvisar". Todo pacote de planejamento ainda carrega um orçamento e uma data-alvo reais, de modo que o programa tem uma linha de base total desde o primeiro dia, mesmo sem detalhar os componentes internos. E a conversão de um pacote de planejamento em pacote de trabalho acontece em uma data fixa, não quando alguém se lembra. O texto de Gregory Githens no PMI enquadra bem: identifique o trabalho futuro com um marcador de "caixa-preta" no lugar do detalhe que você acrescentará depois, e trate o próprio limite da onda como trabalho agendado, um entregável que entra na mesma disciplina de entregáveis do projeto que você aplicaria a qualquer outra coisa que o projeto produza. Os entregáveis da onda próxima recebem critérios de aceitação completos; os entregáveis a duas ou três ondas de distância permanecem como marcadores até sua onda chegar.

Escolhendo o horizonte e a cadência da onda

Não existe uma tabela emitida pelo PMI dizendo que uma onda deve ter exatamente seis semanas ou exatamente um trimestre. O horizonte é uma decisão de julgamento, determinada pela velocidade com que suas premissas ficam obsoletas. Se for curto demais, você gasta mais tempo replanejando do que trabalhando; se for longo demais, a onda "detalhada" com que você se comprometeu terá se afastado da realidade antes de você chegar à metade dela. Os fatores reais: volatilidade dos requisitos, prazos de aquisição ou de fornecedores, tipo de contrato e estabilidade da equipe (um horizonte maior que o tempo médio de permanência de um membro da equipe é pedir problemas). O exemplo prático do próprio Githens é um bom ponto de referência: um programa de 18 meses usando horizontes de 3 meses e um fator de segurança de 20 por cento resulta em cerca de sete horizontes de tempo no topo da EAP, cada um um checkpoint para revalidar premissas antes de se comprometer com o próximo bloco de detalhe.

Trate isso como ponto de partida, não como regra. O teste real é se a sua onda de curto prazo se mantém precisa durante toda a sua janela. Se não se mantiver, encurte o horizonte; se o replanejamento parecer trabalho inútil porque nada mudou, alongue-o. A incerteza que já foi genuinamente resolvida não precisa de onda alguma, uma decisão que vale a pena tomar durante o gerenciamento de riscos do projeto, em vez de adotar por padrão um horizonte sugerido por uma tabela.

Rolling wave planning e a estrutura analítica do projeto

O rolling wave planning não substitui a estrutura analítica do projeto; ele muda o momento em que cada ramo é totalmente decomposto. A regra dos 100% continua valendo para o programa inteiro em todos os momentos, mas os ramos distantes a satisfazem com um único pacote de planejamento em vez de uma árvore de pacotes de trabalho. Vale tomar esse termo emprestado do gerenciamento de valor agregado mesmo sem EVM formal: o texto de Timothy Pasko no PMI o define como trabalho de longo prazo dentro de uma conta de controle que pode ser identificado, agendado e orçado, mas ainda não foi planejado em detalhe. A regra que lhe dá força: ele é convertido em um ou mais pacotes de trabalho antes que qualquer custo real seja lançado nele. Você pode orçar contra um marcador. Não pode gastar contra um.

Construir primeiro a EAP do programa completo no nível de pacote de planejamento é o que mantém a regra dos 100% intacta ao longo de todas as ondas. Pule essa etapa e comece a EAP de cada onda do zero, e você redescobrirá escopo esquecido três ondas depois, uma forma muito mais cara de encontrá-lo do que conferir com um marcador que você escreveu no primeiro dia.

Linhas de base e rolling wave planning: a parte difícil

Eis a parte que a maioria das explicações dessa técnica pula, e aquela em que um gerente de projetos de verdade realmente trava: como manter uma linha de base do projeto significativa quando metade da EAP está deliberadamente indefinida?

Você estabelece a linha de base de coisas diferentes em níveis diferentes de confiança, e diz isso explicitamente em vez de fingir que o plano inteiro tem o mesmo peso. O escopo, o cronograma e o custo da onda atual recebem linha de base no nível de pacote de trabalho, o mesmo rigor que você aplicaria em um projeto totalmente preditivo. Tudo além dela também recebe linha de base, só que no nível de pacote de planejamento: um orçamento total e uma data de marco, não uma lista de tarefas. A restrição externa, o orçamento total e a data final do programa, recebe linha de base desde o primeiro dia e é mantida como aquilo dentro do qual toda onda precisa caber.

É aqui que o rolling wave planning se cruza de forma mais direta com um processo de controle de mudanças. Converter um pacote de planejamento em pacotes de trabalho, no prazo, no limite com o qual você já se comprometeu, não é uma mudança, é o plano funcionando como projetado. O que é uma mudança: puxar escopo de uma onda futura sem revisar seu orçamento, ou deixar o detalhe da onda atual se expandir além do dimensionado para o pacote. Os dois se parecem, vistos de fora, exatamente com expansão do escopo no vocabulário do rolling wave, e a única coisa que os distingue é se a mudança passou pela mesma aprovação que toda outra mudança de linha de base. Converta pacotes sem que ninguém aprove o resultado e você terá uma linha de base que se redefine sozinha a cada poucos meses, sem ninguém responsável pelo que mudou.

Estimando em uma rolling wave

A estimativa da onda atual e a de uma onda a três horizontes de distância não devem usar o mesmo método. O trabalho da onda próxima é compreendido o bastante para merecer uma passada bottom-up: divida-o em tarefas e aplique a estimativa de três pontos para obter uma faixa otimista, mais provável e pessimista, em vez de um único número vestido de certeza. O trabalho de ondas distantes se apoia na estimativa análoga (comparar o pacote de planejamento com um semelhante de um programa anterior) ou na estimativa paramétrica (uma taxa histórica multiplicada por uma quantidade aproximada), as técnicas tratadas em estimativa de custos do projeto para o orçamento em estágio inicial.

O que deve se firmar, onda após onda, é a estimativa daquilo que está prestes a entrar no horizonte atual: na onda passada era um número análogo grosseiro, nesta é um valor bottom-up construído com o que você aprendeu executando a onda anterior. Você verá essa progressão descrita em outros lugares com uma porcentagem de confiança específica atribuída a cada classe de estimativa, ordem de grandeza aproximada em uma ponta, estimativa definitiva na outra. Trate qualquer versão que você não consiga rastrear até uma fonte nomeada e acessível como decoração, não como evidência. O que é verdadeiro sem número associado: a faixa se estreita porque você substitui suposição por medição, uma onda de cada vez, e esse estreitamento é o ponto.

Onde o rolling wave planning se encaixa: preditivo, híbrido e agile

O rolling wave planning nasceu do gerenciamento de projetos preditivo e centrado em programas, o mundo das contas de controle e do valor agregado. Ele é igualmente à vontade na entrega híbrida, onde costuma ser o tecido conectivo: o trabalho de curto prazo roda dentro de sprints agile, enquanto tudo o que está mais distante fica no nível de pacote de planejamento até ficar próximo o bastante para justificar um backlog pronto para o sprint. Isso explica em grande parte por que ele se espalhou além de seu lar original; a própria pesquisa do PMI sobre a mudança para a entrega adequada ao propósito constatou que a adoção do modelo híbrido subiu de 20% dos projetos em 2020 para 31,5% em 2023.

Algo que a maioria das comparações de agile vs waterfall passa por cima: uma equipe agile que faz refinamento de backlog está, estruturalmente, fazendo o mesmo que um programa que roda rolling wave planning, só que com vocabulário diferente e um horizonte mais curto. O Scrum Guide descreve o refinamento como dividir os itens do Product Backlog e acrescentar detalhe, de modo que os itens são "considerados prontos para seleção em um evento de Sprint Planning" apenas depois de ganharem esse detalhe, enquanto os itens mais abaixo permanecem grosseiros até sua vez chegar. Troque "sprint" por "onda" e "refinamento de backlog" por "conversão de um pacote de planejamento" e você estará descrevendo a mesma disciplina.

O argumento honesto para um patrocinador cético quanto à linguagem "com cara de agile": o rolling wave planning não é uma concessão à incerteza, é uma forma mais precisa de representar uma incerteza que já existe. O planejamento completo antecipado não remove essa incerteza, apenas a esconde dentro de números que parecem mais confiantes do que são.

Quando o rolling wave planning é a escolha errada

A técnica se justifica quando o fim do projeto é genuinamente impossível de conhecer. É a escolha errada quando isso não é verdade, ou quando quem paga precisa de uma certeza que ela estruturalmente não consegue oferecer.

Githens faz um comentário relacionado que vale repetir porque corta para o outro lado: o rolling wave foi concebido para trabalho de desenvolvimento, em que o fim é genuinamente indefinido, e aplicá-lo a um projeto de implantação (um rollout, uma migração, um go-live já bem compreendido antes de começar) pode torná-lo mais lento e menos eficiente do que planejá-lo todo antecipadamente. É uma resposta específica a um tipo específico de incerteza, e deve sair de cena quando essa incerteza desaparecer.

Como o rolling wave planning é usado de forma abusiva

Esta é a seção que a maioria das explicações pula, e a que mais importa quando você defende a técnica diante de um PMO cético. "Rolling wave" é um método legítimo, e também uma expressão que serve de pretexto para equipes que nunca pretenderam planejar.

Nenhum desses sinais é exótico. São o resultado previsível de adotar o vocabulário do rolling wave sem sua disciplina, e todos têm correção: colocar uma data, um responsável e uma etapa de aprovação onde antes havia uma vaga intenção.

Como implementar o rolling wave planning: passo a passo

Passo 1: Confirme que esta é realmente a técnica certa

Verifique se a incerteza é real, e não apenas não tratada. Se as fases posteriores são bem compreendidas, mas ninguém agendou o trabalho de planejá-las, isso é uma lacuna de planejamento, não um caso para rolling wave. A incerteza genuína geralmente remonta a dependências não resolvidas ou a um ciclo de vida do projeto em que as fases posteriores dependem de resultados que você ainda não tem.

Passo 2: Defina o horizonte e a cadência da onda

Use os fatores acima: volatilidade dos requisitos, prazo de aquisição, tipo de contrato, estabilidade da equipe. Escreva o horizonte e as datas de replanejamento no próprio cronograma, não em uma conversa paralela.

Passo 3: Construa a EAP do programa completo no nível de pacote de planejamento

Cada fase e entregável recebe pelo menos um pacote de planejamento, um valor de orçamento e uma data de marco, antes que qualquer coisa seja decomposta além disso. Isso protege a regra dos 100% ao longo de todas as ondas desde o primeiro dia.

Passo 4: Decomponha a onda atual até o nível de pacote de trabalho

Aplique a regra 8/80 apenas à onda atual. Estime-a com a estimativa de três pontos, agora que o trabalho é compreendido o bastante para sustentar uma faixa real.

Passo 5: Estabeleça a linha de base da onda atual e da restrição externa do programa

Estabeleça a linha de base da onda atual em pleno detalhe, e a do orçamento total e da data final do programa como a restrição dentro da qual toda onda futura precisa caber.

Passo 6: Execute, acompanhe e proteja a data do limite da onda

Conduza a onda atual como qualquer outro trabalho bem gerenciado, acompanhando os valores reais em relação à linha de base que você acabou de definir.

Passo 7: Replaneje no limite e trate-o como um entregável real

Quando o limite chegar, converta o próximo pacote de planejamento em pacotes de trabalho usando o que você aprendeu executando a onda anterior, faça qualquer mudança de linha de base resultante passar pelo controle formal de mudanças e avance o horizonte.

Erros comuns no rolling wave planning

O rolling wave planning não é uma proteção contra a necessidade de se comprometer. É uma forma mais honesta de se comprometer: detalhe completo para o que você sabe, um orçamento e uma data reais para o que você ainda não sabe e um ponto fixo em que essa lacuna se fecha. Defina o horizonte de forma deliberada, ponha uma data no trabalho de replanejamento de cada onda e mantenha estável a linha de base externa enquanto o detalhe interno avança, e você terá um plano em que um patrocinador pode confiar no primeiro mês e continuar confiando no décimo segundo.