Planejamento de Projetos: como aplicar Rolling Wave Planning em projetos de Engenharia

Entenda como aplicar Rolling Wave Planning em projetos de Engenharia, estruturando planejamento progressivo, planning packages, cronograma, lookahead, FEL, PMO e Owner’s Engineering.

Confira!

Planejamento de projetos não exige que todas as atividades sejam detalhadas com o mesmo nível de precisão desde o primeiro dia. Em projetos de Engenharia, tentar definir minuciosamente um horizonte distante quando requisitos, interfaces, fornecedores ou condições de campo ainda estão em amadurecimento pode produzir uma falsa sensação de controle. O Rolling Wave Planning, ou planejamento em ondas sucessivas, resolve esse problema ao detalhar o trabalho próximo e manter o trabalho futuro em nível mais agregado até que exista informação suficiente para planejá-lo com qualidade.

A técnica não elimina o cronograma mestre, a linha de base nem os marcos do empreendimento. Ao contrário, ela cria uma disciplina para evoluir o nível de detalhe sem perder a visão integrada do projeto. O horizonte inteiro continua planejado; o que muda é a granularidade utilizada em cada período.

Para Engenharia, essa lógica é especialmente relevante em FEL, projetos brownfield, desenvolvimento multidisciplinar, procurement e implantação, porque a informação necessária para planejar o futuro surge progressivamente. A chave está em diferenciar incerteza legítima de falta de planejamento e estabelecer regras claras para transformar planning packages em atividades detalhadas antes que elas entrem no horizonte de execução.

O que é Rolling Wave Planning

Rolling Wave Planning é uma técnica de planejamento progressivo na qual atividades de curto prazo são decompostas com maior detalhe, enquanto trabalhos mais distantes permanecem representados em nível agregado.

O Practice Standard for Scheduling do Project Management Institute descreve a técnica como uma forma de detalhar atividades próximas — por exemplo, as próximas semanas ou meses — e manter períodos futuros como planning packages até que exista informação suficiente para detalhamento.

A lógica parte de uma constatação simples: a equipe tende a conhecer melhor aquilo que está próximo do que aquilo que ocorrerá muitos meses à frente.

Isso não significa ignorar o futuro. Significa representá-lo com o nível de precisão que a maturidade atual permite.

Planejamento de projetos não é o mesmo que detalhar tudo antecipadamente

Um cronograma pode ter milhares de atividades e ainda assim ser um instrumento ruim de gestão.

Detalhe excessivo não compensa premissas frágeis.

Se uma atividade prevista para daqui a oito meses depende de:

• uma solução técnica ainda não selecionada;
• um fornecedor ainda não contratado;
• dados de campo ainda não levantados;
• interfaces ainda não fechadas;
• aprovação do cliente ainda pendente;
• condição operacional ainda desconhecida;

a duração de “7 dias” registrada no software pode ser apenas precisão aparente.

Rolling Wave Planning aceita que essa atividade permaneça agregada por enquanto, mas exige que exista um processo explícito para detalhá-la no momento correto.

A diferença entre incerteza e ausência de planejamento

Esse ponto é crítico.

Uma atividade futura pode não estar detalhada, mas ainda precisa estar representada no plano.

O projeto deve conhecer, no mínimo:

• o resultado esperado;
• a posição temporal aproximada;
• as principais dependências;
• os marcos associados;
• o responsável pelo pacote;
• as premissas relevantes;
• as restrições conhecidas;
• o orçamento ou esforço previsto, quando aplicável.

O que fica para uma onda futura é a decomposição em atividades executáveis.

Portanto, Rolling Wave não é planejar depois; é planejar em níveis sucessivos de maturidade.

Por que a técnica é aderente a projetos de Engenharia

Projetos de Engenharia combinam trabalho previsível com trabalho cuja definição depende de informações que aparecem ao longo do ciclo de vida.

Exemplos são frequentes.

Levantamentos brownfield

Um projeto em instalação existente pode começar com documentação incompleta. A equipe conhece o objetivo geral, mas o detalhamento depende de inspeções, levantamentos e validação do as-built.

Projeto multidisciplinar

A disciplina elétrica pode depender de carga definida pela mecânica. Telecomunicações pode depender de arquitetura. Automação pode depender de listas de equipamentos e filosofia operacional.

Procurement

A Engenharia pode conhecer a necessidade de um equipamento, mas o detalhamento de interfaces pode depender da seleção do fabricante.

Implantação

Frentes futuras podem depender de liberações civis, suprimentos ou decisões de projeto ainda não consolidadas.

Nesses casos, detalhar tudo com a mesma granularidade desde o início cria retrabalho de planejamento.

Rolling Wave e o princípio da elaboração progressiva

Projetos evoluem por elaboração progressiva.

A ABNT NBR ISO 21502:2021 trata o planejamento como uma atividade iterativa e progressiva ao longo do ciclo de vida: o futuro imediato deve receber maior nível de detalhe do que o trabalho mais distante, enquanto o plano permanece integrado e suas linhas de base são alteradas de forma controlada. Essa diretriz é particularmente aderente ao Rolling Wave Planning.

No início, a organização trabalha com objetivos, premissas e estimativas de maior amplitude. Conforme o conhecimento aumenta, a definição se torna mais precisa.

Essa lógica aparece naturalmente em Front-End Loading — FEL.

Em FEL, cada etapa busca aumentar maturidade antes de assumir compromissos maiores de investimento. O planejamento pode seguir o mesmo princípio: quanto maior a maturidade da informação, maior o detalhamento esperado.

O Rolling Wave transforma essa ideia em rotina de planejamento.

Como estruturar os horizontes de planejamento

Um modelo simples pode utilizar três horizontes.

Horizonte 1 — curto prazo detalhado

Contém as atividades que serão executadas em breve.

Devem possuir:

• escopo claro;
• responsável definido;
• duração coerente;
• predecessores e sucessores;
• recursos, quando aplicável;
• entradas necessárias;
• critérios de conclusão;
• vínculo com entregáveis e milestones.

Horizonte 2 — médio prazo em preparação

As atividades já são conhecidas, mas ainda podem precisar de amadurecimento.

Esse horizonte é usado para remover restrições e preparar o trabalho que entrará na próxima onda.

Horizonte 3 — longo prazo agregado

O trabalho futuro é representado em planning packages ou atividades sumárias.

O objetivo é preservar visibilidade de dependências, orçamento e marcos sem criar detalhe especulativo.

Qual deve ser o tamanho de uma onda

Não existe duração universal.

O PMI utiliza exemplos de horizonte próximo de cerca de 90 dias em sua explicação da técnica, mas o período deve ser definido pela natureza do projeto.

Em Engenharia Consultiva, uma onda pode ter quatro a oito semanas.

Em implantação, pode ser necessário detalhar três ou quatro semanas e manter um lookahead mais amplo.

Em projetos de longo prazo, o planejamento detalhado pode alcançar três meses ou mais.

Os critérios mais importantes são:

• velocidade com que a informação amadurece;
• duração das atividades;
• lead time de procurement;
• cadência de decisões;
• necessidade de mobilização;
• frequência de atualização do cronograma;
• risco de mudança.

A onda precisa ser longa o suficiente para permitir preparação e curta o suficiente para manter o detalhe confiável.

O ciclo de Rolling Wave Planning passo a passo

1. Construir a visão integrada do projeto

Antes de qualquer onda, o projeto precisa de visão de ponta a ponta.

Isso inclui:

• objetivos;
• principais entregáveis;
• EAP;
• marcos;
• grandes dependências;
• contratos e aquisições;
• gates;
• principais restrições.

Sem essa visão, o planejamento de curto prazo vira gestão local sem conexão com o empreendimento.

2. Identificar o horizonte de detalhe

Definir até que data as atividades precisam estar completamente decompostas.

3. Manter o futuro em planning packages

Pacotes futuros devem ser suficientemente claros para permitir integração com cronograma, custos e recursos.

4. Preparar a próxima onda

Antes que o horizonte avance, a equipe revisa os planning packages que entrarão no período detalhado.

5. Remover restrições

O pacote só deveria ser detalhado como trabalho executável quando entradas mínimas estiverem disponíveis.

6. Decompor o pacote

Transformar o planning package em atividades com lógica, responsáveis, duração e critérios de conclusão.

7. Atualizar o cronograma integrado

O detalhamento entra no modelo sem perder a ligação com o baseline e os marcos originais.

8. Repetir em cadência definida

A técnica é chamada “rolling wave” justamente porque o horizonte avança continuamente.

Planning package: o elemento que evita falsa precisão

Um planning package representa trabalho conhecido em alto nível, mas ainda não detalhado em atividades executáveis.

Considere o pacote:

“Projeto executivo de adequação elétrica do Bloco B”.

Meses antes, talvez seja possível conhecer:

• período aproximado;
• orçamento de horas;
• principais predecessores;
• milestone de emissão;
• disciplinas participantes.

Mais perto da execução, após levantamento e projeto básico, esse pacote pode ser decomposto em:

1. atualizar lista de cargas;
2. consolidar diagrama unifilar;
3. dimensionar alimentadores;
4. verificar curto-circuito e seletividade;
5. definir quadros e dispositivos;
6. elaborar plantas;
7. compatibilizar interfaces;
8. realizar verificação técnica;
9. emitir revisão para aprovação.

O detalhe aparece quando se torna útil e confiável.

Rolling Wave não deve destruir a linha de base

Um dos maiores riscos da técnica é transformar cada onda em uma desculpa para mudar o compromisso original.

O planejamento progressivo e o rebaseline são coisas diferentes.

Ao detalhar um planning package, a equipe pode distribuir melhor o trabalho dentro do período previsto. Se, entretanto, o novo detalhe indicar que a data final ou o custo aprovado não são mais viáveis, isso representa uma variação ou mudança que precisa ser tratada pelo processo de governança correspondente.

Não se deve simplesmente “empurrar” a baseline para que ela coincida com o novo forecast.

Relação entre Rolling Wave e cronograma CPM

Rolling Wave Planning não substitui o Critical Path Method — CPM.

O cronograma integrado pode continuar estruturado em rede lógica, com caminho crítico, folgas, milestones e baseline.

O que o Rolling Wave altera é o nível de decomposição ao longo do horizonte.

No curto prazo, a rede possui maior granularidade.

No longo prazo, determinados trechos podem permanecer agregados em planning packages.

Conforme os pacotes são detalhados, a lógica é refinada.

Essa integração é importante porque o projeto não pode perder a visão das dependências críticas apenas por trabalhar com planejamento progressivo.

Evitando canibalização com o cronograma do projeto

O tema deste artigo é como planejar progressivamente, não como montar um cronograma do zero.

A estrutura básica de cronograma, atividades, dependências, caminho crítico e controle possui tratamento específico no artigo Cronograma de projeto: como elaborar, controlar e evitar atrasos.

Aqui, o foco é uma decisão diferente: qual nível de detalhe deve existir em cada horizonte do planejamento?

Rolling Wave e Lookahead Planning: qual é a diferença

Os conceitos são próximos, mas não idênticos.

Conceito	Foco principal	Horizonte típico	Resultado
Rolling Wave Planning	detalhamento progressivo do plano	variável	planning packages transformados em atividades detalhadas
Lookahead Planning	preparar trabalho futuro e remover restrições	curto/médio prazo	atividades prontas para execução
Plano semanal	compromisso de execução imediata	dias/semana	tarefas assumidas pela equipe

O Rolling Wave pode existir no planejamento de projeto mesmo sem Last Planner System.

O lookahead é particularmente associado à preparação do trabalho de curto prazo e ganha papel central em Lean Construction e Last Planner.

Rolling Wave e Last Planner System

Existe complementaridade.

O Rolling Wave responde ao problema da granularidade progressiva do planejamento.

O Last Planner System amplia a lógica para confiabilidade do planejamento e produção, trabalhando com restrições, compromissos e aprendizado sobre causas de não cumprimento.

Em uma implantação de Engenharia, o cronograma mestre pode utilizar Rolling Wave enquanto o sistema de produção usa lookahead e compromissos semanais.

Não são ferramentas concorrentes.

Rolling Wave como mecanismo de tailoring do planejamento

O valor do Rolling Wave aparece com mais clareza quando ele é tratado como uma decisão de tailoring, e não como uma regra fixa de “detalhar 30, 60 ou 90 dias”. O PMBOK contemporâneo reforça que práticas, processos e abordagens devem ser adaptados ao contexto; no planejamento, isso significa escolher a resolução temporal compatível com a maturidade da informação e com o risco de decidir cedo ou tarde demais.

Em Engenharia, o horizonte de alta resolução deveria ser influenciado por fatores como lead time de aquisição, latência de decisões do proprietário, custo de mudança, maturidade dos requisitos, disponibilidade de dados de fornecedor, capacidade das disciplinas e proximidade de liberações físicas. Um item de procurement que só será instalado meses depois pode exigir detalhamento hoje; uma atividade de projeto igualmente distante, mas dependente de dados ainda inexistentes, pode permanecer como planning package.

Essa distinção evita confundir proximidade temporal com necessidade de definição. O que deve ser detalhado primeiro é aquilo cuja decisão precisa acontecer primeiro para proteger o fluxo do empreendimento, mesmo que a execução física esteja distante.

Por isso, uma política madura de Rolling Wave define não apenas quantas semanas ficam detalhadas, mas também critérios de maturidade e gatilhos de decomposição: quando um pacote precisa deixar de ser agregado, quais entradas mínimas devem existir, quem autoriza sua abertura e como o novo detalhe será reconciliado com baseline, orçamento, recursos e interfaces.

Rolling Wave e gestão ágil

A técnica também se conecta à Gestão Ágil e Híbrida de Projetos de Engenharia.

Ambas reconhecem que planejamento precisa refletir o nível real de informação.

A diferença é que Rolling Wave é uma técnica específica de planejamento. Gestão ágil é uma abordagem mais ampla, que pode envolver priorização, fluxo, feedback, ciclos e métricas adaptativas.

Em um modelo híbrido, o projeto pode manter:

• baseline e milestones preditivos;
• Rolling Wave para detalhamento;
• Kanban para fluxo documental;
• Change Control para mudanças relevantes;
• EVM para desempenho agregado.

Aplicação durante FEL

O FEL é um dos ambientes mais adequados.

Em fases iniciais, a organização não deveria criar um plano executivo detalhado para decisões que ainda dependem da maturação do empreendimento.

Pode existir, porém, um roadmap claro para:

• levantamentos;
• estudos;
• decisões;
• análise de alternativas;
• estimativas;
• revisão de riscos;
• gates.

A cada gate, a maturidade aumenta e o próximo horizonte pode ser detalhado.

Essa relação ajuda a evitar um erro comum: confundir falta de definição natural da fase inicial com falta de gestão.

Aplicação no projeto básico

No projeto básico, Rolling Wave permite priorizar pacotes que destravam decisões de maior impacto.

Por exemplo:

• critérios gerais e interfaces principais são detalhados primeiro;
• sistemas com maior lead time recebem prioridade;
• áreas dependentes de levantamento permanecem agregadas até que os dados estejam disponíveis;
• pacotes liberados entram no detalhamento executivo.

Isso reduz esforço prematuro.

Aplicação no projeto executivo

O projeto executivo exige maior estabilidade, mas ainda pode possuir ondas.

Um pacote de área A pode estar completamente detalhado enquanto área B depende de fornecedor ou acesso de campo.

O planejamento deve permitir essa assimetria sem perder a visão global.

Aplicação em procurement

Procurement é um ponto em que o planejamento progressivo precisa ser usado com cautela.

Itens de longo lead time exigem antecipação.

Por isso, mesmo que o detalhamento de algumas disciplinas permaneça futuro, o planejamento deve identificar cedo:

• datas necessárias para requisição;
• tempo de cotação;
• equalização técnica;
• fabricação;
• inspeção;
• transporte;
• chegada ao site;
• interfaces necessárias para compra.

Rolling Wave não pode servir como justificativa para postergar decisões críticas de suprimentos.

Aplicação em Owner’s Engineering

No Owner’s Engineering, o planejamento precisa acompanhar não apenas a execução física, mas também aprovações, submittals, RFIs, inspeções e documentação.

Uma onda de curto prazo pode detalhar:

• documentos que precisam ser aprovados;
• inspeções previstas;
• decisões necessárias;
• interfaces que precisam ser fechadas;
• liberações de frente;
• testes programados.

O OE passa a enxergar não apenas o que a contratada pretende executar, mas o que precisa estar resolvido antes para que a execução seja confiável.

Rolling Wave em projetos brownfield

Projetos brownfield possuem uma característica especial: a descoberta de campo pode alterar premissas.

Uma onda bem estruturada pode começar pela aquisição de informação.

Exemplo:

Onda 1 — levantamento e validação

• inspeção;
• levantamento cadastral;
• verificação de documentação;
• registro de interferências;
• confirmação de cargas e interfaces.

Onda 2 — definição técnica

• consolidação de critérios;
• alternativas;
• decisões críticas;
• projeto básico.

Onda 3 — detalhamento

• projeto executivo;
• especificações;
• listas de materiais;
• procurement.

A sequência evita desenvolver projeto detalhado sobre uma base cadastral não confiável.

Como tratar restrições antes da próxima onda

Antes de mover um pacote para o horizonte detalhado, deve existir uma verificação de prontidão.

Perguntas úteis:

• os requisitos estão claros?
• as entradas das demais disciplinas estão disponíveis?
• o levantamento necessário foi concluído?
• decisões do cliente foram obtidas?
• o fornecedor foi definido quando necessário?
• existe acesso ao local?
• recursos especializados estão disponíveis?
• existem aprovações prévias necessárias?

Se a resposta for negativa, o pacote pode até ser detalhado parcialmente, mas a restrição precisa ficar visível.

Definition of Ready aplicada ao planejamento

A ideia de Definition of Ready pode ser adaptada para Engenharia sem transformar o projeto em Scrum.

Um pacote está pronto para detalhamento ou execução quando possui um conjunto mínimo de entradas.

Exemplo para um documento técnico:

• escopo identificado;
• template/codificação definidos;
• dados de entrada disponíveis;
• requisitos associados;
• interfaces críticas conhecidas;
• responsável nomeado;
• prazo necessário definido.

Isso reduz a prática de iniciar trabalho que inevitavelmente ficará parado.

Integração com gestão de requisitos

O detalhamento progressivo não pode alterar requisitos silenciosamente.

A Gestão de Requisitos em Engenharia deve garantir que cada onda utilize a versão correta das premissas e requisitos.

Quando uma nova informação exige mudança, ela precisa ser avaliada e registrada.

Integração com gestão de interfaces

Planning packages futuros muitas vezes dependem de interfaces ainda não fechadas.

A Gestão de Interfaces pode indicar quais decisões precisam ser concluídas antes que a próxima onda seja liberada.

Essa integração transforma a matriz de interfaces em insumo real de planejamento.

Integração com custos e recursos

O fato de uma atividade futura ainda não estar detalhada não significa que ela deva ficar sem previsão de custo ou esforço.

Planning packages podem carregar:

• orçamento;
• quantidade de HTEs;
• recursos previstos;
• contingência;
• período de utilização;
• responsabilidade organizacional.

Quando o pacote é decomposto, o orçamento é distribuído entre as atividades detalhadas.

O princípio é preservar consistência entre escopo, prazo e custo.

Rolling Wave e Earned Value Management

Rolling Wave pode coexistir com EVM, desde que a estrutura de controle seja bem definida.

O trabalho futuro pode permanecer em planning packages dentro de contas de controle. À medida que o detalhe aumenta, o orçamento é distribuído sem perder a rastreabilidade com a base aprovada.

O problema surge quando cada onda muda arbitrariamente o orçamento ou as datas sem processo de controle.

EVM exige referência estável suficiente para medir desempenho. Rolling Wave exige flexibilidade suficiente para detalhar o trabalho. Um modelo maduro preserva os dois princípios.

Métricas para controlar a qualidade do planejamento

Não basta atualizar o cronograma.

Alguns indicadores ajudam a verificar se o Rolling Wave está funcionando.

Percentual de pacotes detalhados no prazo

Mede se a próxima onda está sendo preparada antes de entrar em execução.

Quantidade de atividades iniciadas com restrição aberta

Ajuda a identificar planejamento prematuro.

Aging de decisões críticas

Mostra quanto tempo decisões necessárias permanecem pendentes.

Variação entre duração preliminar e detalhada

Grandes diferenças recorrentes podem indicar planning packages mal estimados.

Retrabalho de planejamento

Mede quantas atividades precisam ser reconstruídas porque foram detalhadas cedo demais.

Confiabilidade dos milestones

Avalia se o detalhamento progressivo melhora ou degrada a capacidade de prever entregas.

Quem é responsável por detalhar a próxima onda

A responsabilidade não deveria ficar apenas com o planejador.

O planejamento precisa envolver quem conhece o trabalho.

Em um projeto de Engenharia, isso pode incluir:

• gerente de projeto;
• planejamento/Project Controls;
• coordenadores de disciplina;
• procurement;
• construção;
• comissionamento;
• Owner’s Engineering;
• fornecedores estratégicos.

O planejador integra. Os responsáveis técnicos fornecem lógica, durações, restrições e critérios de conclusão.

O papel do PMO

O PMO pode padronizar a aplicação de Rolling Wave entre projetos.

Pode definir:

• critérios mínimos de detalhamento;
• horizontes recomendados;
• frequência de atualização;
• campos obrigatórios para planning packages;
• regras de baseline;
• indicadores;
• processo de escalonamento de restrições.

Assim, cada projeto mantém flexibilidade operacional sem perder comparabilidade corporativa.

Exemplo completo de aplicação

Considere um empreendimento com duração de 12 meses.

O cronograma mestre possui milestones de projeto, procurement, mobilização, construção, testes e entrega.

Mês 0

Os próximos 60 dias são detalhados.

Meses 3 a 6 possuem pacotes de nível intermediário.

Meses 7 a 12 permanecem em planning packages.

Mês 1

A equipe revisa o período que entrará no novo horizonte detalhado.

Verifica:

• documentos necessários;
• equipamentos já definidos;
• interfaces abertas;
• disponibilidade de recursos;
• restrições de acesso;
• decisões pendentes.

Mês 2

O pacote do mês 3 é decomposto em atividades executáveis.

O cronograma é atualizado e as restrições remanescentes são escaladas.

Ciclos seguintes

O processo se repete.

O projeto inteiro permanece visível, mas a “janela de alta resolução” avança com o tempo.

Erros comuns ao aplicar Rolling Wave Planning

Usar planning package como gaveta de incertezas

O pacote precisa de responsável, prazo e premissas. Não pode ser apenas “definir depois”.

Detalhar a próxima onda tarde demais

Se o trabalho é detalhado no dia em que deveria começar, não existe tempo para remover restrições.

Rebaseline contínuo

Atualizar previsão não é alterar baseline.

Ignorar procurement

Atividades futuras com longo lead time precisam de antecipação mesmo quando outros detalhes permanecem abertos.

Planejar apenas no software

O cronograma não cria informação. O processo precisa envolver responsáveis técnicos.

Não registrar premissas

Quando um planning package é baseado em hipótese, essa hipótese deve ser visível.

Confundir curto prazo com prioridade

Uma atividade próxima pode não ser crítica; uma decisão distante associada a equipamento de longo prazo pode exigir ação imediata.

Quando Rolling Wave Planning não é necessário

A técnica agrega menos valor quando o projeto é curto, altamente repetitivo e possui escopo completamente conhecido.

Se todas as atividades podem ser detalhadas de forma confiável desde o início, criar múltiplas ondas pode introduzir processo sem benefício.

Mesmo nesses casos, algum nível de lookahead ainda pode ser útil para verificar restrições.

Quando Rolling Wave se torna especialmente valioso

A técnica tende a agregar valor quando existem:

• empreendimentos longos;
• múltiplas disciplinas;
• informações progressivas;
• brownfield;
• decisões de fornecedor;
• interfaces complexas;
• fases FEL/FEED;
• contratos de Engenharia Consultiva por demanda;
• programas com vários pacotes;
• implantação com forte interação entre Engenharia e campo.

Planejamento progressivo e governança

Rolling Wave Planning funciona melhor quando está dentro de uma estrutura clara de governança.

O projeto precisa saber:

• quem aprova baseline;
• quem pode alterar sequência;
• quais mudanças exigem Change Control;
• quando uma premissa vira compromisso;
• quais gates limitam avanço;
• como impactos de custo são tratados;
• como decisões são registradas.

Sem isso, flexibilidade pode virar instabilidade.

Relação com Gestão Ágil e Híbrida

Rolling Wave é uma das práticas mais naturais para construir um sistema híbrido.

O planejamento de longo prazo preserva objetivos e compromissos. O planejamento próximo incorpora informação mais recente. A produção técnica pode usar gestão visual e fluxo.

Essa arquitetura conecta:

estratégia → baseline → planejamento progressivo → execução de curto prazo → feedback → nova onda.

Ela evita tanto o extremo de tentar prever tudo com falsa precisão quanto o extremo de operar sem uma referência integrada.

Aplicação em Engenharia Consultiva e Owner’s Engineering

Na Engenharia Consultiva, o planejamento precisa acompanhar maturação de informação e entregáveis.

No Owner’s Engineering, precisa também acompanhar as decisões que liberam a contratada e protegem os interesses do proprietário.

Em ambos os casos, Rolling Wave permite manter uma visão de médio e longo prazo sem exigir um nível de detalhe incompatível com a informação disponível.

A A3A Engenharia utiliza planejamento progressivo, governança, gestão de interfaces e Project Controls conforme as características de cada empreendimento, integrando essas práticas a serviços de Engenharia Consultiva, PMO, gerenciamento e Owner’s Engineering.

Referências técnicas

[1] PROJECT MANAGEMENT INSTITUTE. Practice Standard for Scheduling — Second Edition. PMI. Disponível em: PMI.

[2] PROJECT MANAGEMENT INSTITUTE. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) — Eighth Edition. PMI, 2025. Disponível em: PMI.

[3] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 21502:2020 — Project, programme and portfolio management — Guidance on project management. Adoção brasileira: ABNT NBR ISO 21502:2021. Disponível em: ISO.

Perguntas frequentes

O que é Rolling Wave Planning?

É uma técnica de planejamento progressivo em que o trabalho de curto prazo é detalhado e o trabalho futuro permanece em nível agregado até que exista informação suficiente para decompô-lo com qualidade.

O que significa planejamento em ondas sucessivas?

É a tradução usual de Rolling Wave Planning. A cada ciclo, o horizonte detalhado avança e novos planning packages são transformados em atividades executáveis.

Rolling Wave Planning substitui o cronograma?

Não. A técnica opera dentro do planejamento e do cronograma integrado. Ela define diferentes níveis de detalhe ao longo do horizonte e pode coexistir com CPM, baseline, milestones e Project Controls.

Qual a diferença entre Rolling Wave e Lookahead Planning?

Rolling Wave trata principalmente do detalhamento progressivo do plano. Lookahead Planning concentra-se em preparar o trabalho futuro próximo e remover restrições antes da execução.

Rolling Wave pode ser usado com EVM?

Sim. Planning packages podem manter orçamento e posição temporal em contas de controle e ser detalhados posteriormente, desde que a decomposição preserve a rastreabilidade com a baseline aprovada.

Qual horizonte deve ser detalhado?

Depende do projeto. O horizonte deve considerar duração das atividades, velocidade de maturação das informações, lead times, cadência de decisão e frequência de atualização. Não existe uma duração única válida para todos os projetos.

Materiais técnicos complementares

Soluções relacionadas

• Implantação e Estruturação de PMO de Engenharia
• Governança de Projetos, Programas e Portfólios
• Gestão de Requisitos, Evidências e Critérios de Aceite

Serviços relacionados

• Gestão de Projetos e Project Controls
• Gerenciamento de Projetos de Engenharia
• FEL (Front-End Loading)

Conteúdos técnicos correlatos

• Gestão Ágil e Híbrida de Projetos de Engenharia
• Metodologias Ágeis em Projetos de Engenharia
• Cronograma de projeto: como elaborar, controlar e evitar atrasos
• PMO: o que é, tipos e funções
• Gestão de Interfaces em Projetos de Engenharia

Conteúdos principais sobre o tema

• Gerenciamento de Projetos: guia completo para engenharia, governança e controle
• Owner’s Engineering: framework executivo para contratação, governança e aceite