Last Planner System em Projetos de Engenharia

Entenda o Last Planner System em projetos de Engenharia: Pull Planning, Lookahead, Make-Ready, restrições, Weekly Work Plan, PPC e integração com Project Controls.

Confira!

O Last Planner System — LPS — é um sistema de planejamento e controle orientado à confiabilidade do fluxo e dos compromissos de curto prazo. Em projetos de Engenharia e construção, sua principal contribuição é transformar um cronograma que diz o que deveria acontecer em um processo colaborativo que verifica o que pode acontecer, define o que será feito, mede o que foi realmente concluído e aprende com as causas das não conclusões.

O LPS não é um quadro de post-its nem uma reunião semanal com contratadas. Ele conecta planejamento por marcos, Pull Planning, Lookahead Planning, análise de restrições, Make-Ready, Weekly Work Planning, compromissos diários, Percent Plan Complete — PPC — e análise das razões de variação. O sistema procura aumentar a confiabilidade dos handoffs entre especialistas e evitar que trabalho seja liberado para execução antes de possuir condições reais de ser concluído.

Em empreendimentos complexos, isso não elimina CPM, baseline, planejamento executivo, EVM ou Project Controls. O Last Planner atua em uma camada complementar: aproxima planejamento e produção, incorpora conhecimento de quem está mais próximo do trabalho e cria um mecanismo sistemático para preparar tarefas, remover restrições e melhorar a previsibilidade operacional.

O que é o Last Planner System

Glenn Ballard desenvolveu o Last Planner System a partir da constatação de que sistemas tradicionais de controle de projetos tendem a identificar variações depois que elas já ocorreram, enquanto a produção exige mecanismos para tornar o plano executável antes do compromisso. Em sua tese de 2000, Ballard posiciona o LPS como um sistema de controle da produção que complementa a gestão do projeto e procura fazer com que os planos se realizem.

A evolução posterior ampliou essa leitura. O benchmark publicado por Ballard e Tommelein em 2021 descreve o LPS como sistema aplicável ao planejamento e controle do projeto e da produção, preservando a distinção entre estabelecer/monitorar metas e gerenciar o fluxo que efetivamente conduz a essas metas.

O Lean Construction Institute resume o método em cinco conversas conectadas:

Should — deveria: o que precisa acontecer para atingir os marcos e objetivos do projeto?
Can — pode: quais atividades possuem condições suficientes para serem executadas?
Will — fará: com o que os responsáveis se comprometem no horizonte imediato?
Did — fez: quais compromissos foram efetivamente concluídos conforme prometido?
Learn — aprender: por que compromissos falharam e o que precisa mudar no sistema?

Essa sequência parece simples, mas muda profundamente a lógica do planejamento. Ela impede que o plano semanal seja apenas uma fatia do cronograma mestre copiada para uma planilha.

Quem é o “Last Planner”

O nome não significa “o último profissional que planeja o projeto”. O last planner é quem está suficientemente próximo da execução para conhecer as condições reais do trabalho e possui autoridade para assumir um compromisso confiável em nome da unidade que executará esse trabalho.

Dependendo da fase e da organização, esse papel pode ser exercido por:

líder de disciplina;
coordenador de Engenharia;
supervisor;
encarregado;
líder de frente;
responsável de fornecedor;
especialista que controla uma entrega crítica;
responsável por uma equipe de design ou work package.

A qualidade do LPS depende de a promessa ser feita por quem conhece capacidade, restrições e precedências reais. Um gerente distante da operação pode definir prioridades e metas, mas não deveria prometer em nome de uma equipe sem verificar se ela efetivamente consegue entregar.

Project Controls e produção não são a mesma função

Last Planner e Project Controls não competem: um aumenta confiabilidade de produção e dos compromissos; o outro preserva a visão integrada de baseline, desempenho e forecast.

Conheça os serviços de Project Controls

Uma distinção essencial na literatura de Last Planner é entre Project Controls e production control.

Project Controls estabelece e mantém mecanismos como:

baseline de prazo;
budget e cost baseline;
caminho crítico;
progresso físico;
curvas e tendências;
forecast;
EVM;
change control;
relatórios de desempenho.

Esses mecanismos respondem perguntas como: estamos adiantados ou atrasados? Qual é a tendência do custo? Qual marco está ameaçado? Qual é o efeito de uma mudança aprovada?

O controle da produção responde outra classe de pergunta: o que precisa acontecer para que a equipe realmente execute o trabalho prometido na próxima semana? Quais restrições precisam sair da frente? Os handoffs estão confiáveis? O trabalho está suficientemente definido? Existe capacidade? Que falhas recorrentes prejudicam a execução?

O benchmark de Ballard e Tommelein usa justamente essa diferença para argumentar que estabelecer destino sem gerenciar o caminho é insuficiente, assim como administrar o caminho sem saber o destino também é insuficiente.

LPS não substitui CPM

CPM é adequado para representar lógica de precedências, durações, folgas e caminho crítico em uma rede de atividades. Last Planner trabalha sobre confiabilidade do fluxo e dos compromissos que materializam esse plano.

Uma arquitetura robusta pode manter:

cronograma mestre como referência do empreendimento;
phase plans alinhados a marcos relevantes;
lookahead para tornar trabalho futuro executável;
Weekly Work Plan para compromissos imediatos;
Project Controls para analisar desempenho agregado e forecast;
LPS para atuar sobre prontidão, fluxo e causas de não conclusão.

O problema começa quando um desses instrumentos é usado para responder perguntas para as quais não foi desenhado.

A arquitetura do Last Planner System

O LPS opera em horizontes progressivamente mais detalhados. Quanto mais próximo da execução, maior deve ser a certeza sobre inputs, capacidade, recursos e condições de realização.

Camada	Horizonte	Pergunta principal	Produto típico
Master / Milestone Plan	projeto e fases	quando os principais objetivos precisam ser atingidos?	marcos e datas-alvo
Phase Pull Plan	fase	quais handoffs são necessários para chegar ao marco?	sequência colaborativa de entregas
Lookahead	semanas futuras	o que precisa ser preparado para se tornar executável?	atividades detalhadas e restrições
Make-Ready	dentro do lookahead	o que impede cada atividade de estar pronta?	ações para remover restrições
Weekly Work Plan	semana	com o que as equipes realmente se comprometem?	promessas específicas e mensuráveis
Daily commitment	dia	como preservar o compromisso semanal?	coordenação imediata e ajustes
Learning	semanal e contínuo	por que o plano falhou e como melhorar?	PPC, razões de não conclusão e contramedidas

A integração dessas camadas é mais importante que qualquer template isolado.

Ciclo do Last Planner System do marco ao aprendizado operacional

Milestone Planning: o LPS começa antes da semana

Uma implantação superficial costuma começar pelo plano semanal. Isso elimina justamente a conexão entre estratégia e produção.

O milestone plan estabelece os principais objetivos temporais que orientam o restante do sistema. Em um projeto industrial, podem ser:

conclusão do projeto básico;
emissão de pacote para RFQ;
colocação de pedido de long-lead item;
IFC de determinado sistema;
início de fundações;
energização de subestação;
mechanical completion;
início de pré-comissionamento;
ready for start-up;
handover.

Esses marcos normalmente precisam permanecer coerentes com o cronograma mestre e com os compromissos contratuais. O LPS não cria um calendário paralelo.

Pull Planning: planejar a partir do resultado necessário

No Pull Planning, o time parte de um marco ou condição futura desejada e trabalha de trás para frente, identificando quais entregas precisam ocorrer para liberar as seguintes.

A lógica de pull é especialmente útil em projetos multidisciplinares porque obriga os participantes a explicitar handoffs. Em vez de cada disciplina apresentar sua própria lista de atividades, o grupo pergunta: o que eu preciso receber para concluir minha entrega e o que preciso fornecer para liberar o próximo participante?

Handoffs são mais importantes que atividades isoladas

Um handoff é uma transferência de condição, informação ou entrega que permite a outro participante avançar. Exemplos:

processo confirma lista de cargas → elétrica fecha balanço de potência;
elétrica define cargas térmicas → HVAC consolida demanda;
fornecedor entrega vendor data → Engenharia conclui interface;
estruturas libera opening → instalações fecham rota;
owner aprova filosofia → automação detalha lógica;
projeto IFC é emitido → suprimentos libera fabricação;
inspeção aceita instalação → comissionamento inicia testes.

Se o planejamento não tornar esses handoffs explícitos, as equipes podem cumprir suas atividades locais e ainda assim não liberar valor para o sistema.

Como conduzir uma sessão de Pull Planning

Uma sessão robusta deve começar com entradas mínimas:

marco claramente definido;
escopo da fase;
participantes que realmente conhecem o trabalho;
restrições conhecidas;
critérios de conclusão;
limites físicos e contratuais;
interfaces relevantes.

A equipe trabalha regressivamente a partir do marco, negociando sequência, dependências e entregas. O resultado não é simplesmente um cronograma colorido: é um entendimento compartilhado de como o trabalho de cada participante libera o trabalho dos demais.

Lookahead Planning: detalhar o futuro próximo com nível realista de certeza

O Lookahead Planning ocupa a camada intermediária entre o plano de fase e o compromisso semanal. Seu objetivo é detalhar e preparar o trabalho que se aproxima.

O Last Planner Workbook explica que a janela precisa ser compatível com o tempo necessário para identificar e remover restrições. Em muitos exemplos usa-se um horizonte próximo de seis semanas, mas a literatura não transforma esse número em regra universal. O horizonte deve considerar lead times, características do processo e capacidade de tornar o trabalho pronto.

Para uma frente de construção, algumas restrições podem ser resolvidas em dias. Para procurement de um equipamento importado, uma decisão necessária daqui a quatro meses pode precisar entrar no mecanismo de atenção agora.

“Explodir” atividades em detalhe suficiente

Uma atividade do cronograma mestre como “Projeto elétrico da subestação” não possui granularidade suficiente para análise de restrições. No lookahead, ela pode ser decomposta em entregas e condições mais específicas:

lista de cargas consolidada;
definição de níveis de curto-circuito;
diagrama unifilar;
estudo de curto-circuito;
seletividade;
especificação do transformador;
especificação de cubículos;
interface com proteção;
filosofia de automação;
vendor data requerida;
emissão para revisão;
incorporação de comentários.

A decomposição deve chegar ao nível em que a equipe consiga dizer se o trabalho está ou não executável.

Restrições: o que impede o trabalho de acontecer

O Last Planner Workbook define restrição como qualquer condição que impeça uma tarefa de ser executável ou sound. A categoria depende do contexto.

Em Engenharia, restrições comuns incluem:

input de outra disciplina;
requisito indefinido;
critério de projeto não aprovado;
decisão do proprietário;
survey faltante;
dado de fornecedor;
revisão pendente;
indisponibilidade de especialista;
modelo de referência desatualizado;
RFI sem resposta;
mudança ainda não autorizada.

Em implantação, somam-se:

projeto liberado;
material;
equipamento;
mão de obra;
acesso;
frente física;
predecessor;
permissão;
inspeção;
condição de segurança;
logística.

A simples existência da restrição não é o problema. O problema é descobri-la tarde demais.

Make-Ready: transformar trabalho desejado em trabalho executável

Make-Ready é a disciplina de agir sobre as restrições antes que a atividade chegue ao momento do compromisso.

O workbook descreve um processo que inclui confirmar lead times, puxar os inputs necessários e, quando apropriado, expedir ações para remover a restrição. Em termos mais gerais, Make-Ready significa garantir que as condições necessárias à execução sejam produzidas a tempo.

Um registro de Make-Ready deve responder:

Campo	Pergunta
atividade futura	qual trabalho precisa estar pronto?
restrição	o que impede a execução?
dono da restrição	quem pode remover o impedimento?
data necessária	quando a restrição precisa estar encerrada?
ação	o que será feito para removê-la?
status	aberta, em tratamento, removida ou escalada?
impacto	que entrega ou marco será afetado?

O objetivo é evitar que a reunião semanal descubra que a atividade “prevista” nunca poderia ter sido realizada.

Os critérios de uma atribuição de qualidade

O Last Planner System não trata um compromisso como bom apenas porque alguém aceitou uma data. A qualidade do compromisso depende de a atribuição estar suficientemente definida, executável, corretamente sequenciada e dimensionada para a capacidade disponível. O aprendizado sobre falhas anteriores também precisa retroalimentar o planejamento.

Critério	Pergunta de controle	Exemplo em Engenharia
Definição	o trabalho está descrito com clareza suficiente para saber quando estará concluído?	“emitir unifilar Rev. B com cargas consolidadas e comentários críticos resolvidos” é superior a “avançar elétrica”
Soundness / executabilidade	inputs, autorizações, recursos e predecessores necessários estão disponíveis?	não comprometer uma emissão que depende de carga de processo ainda indefinida
Sequência	a tarefa respeita a lógica de handoffs e não antecipa trabalho que será refeito?	fechar critérios e interfaces antes do detalhamento definitivo
Tamanho	o pacote cabe no horizonte e na capacidade da equipe?	decompor um pacote grande em entregas verificáveis compatíveis com a semana
Aprendizado	as causas das não conclusões anteriores foram consideradas?	ajustar políticas de prontidão quando aprovações ou inputs recorrentes falham

Esses critérios deslocam a conversa de “quem prometeu?” para “o sistema criou condições reais para cumprir?”. Essa mudança é central para aumentar confiabilidade sem transformar o planejamento semanal em pressão por datas inexequíveis.

Workable Backlog: reserva de trabalho pronto, não pilha de pendências

O workbook usa o conceito de workable backlog para designar trabalho não prioritário que já foi tornado executável e pode ser usado caso uma tarefa principal falhe ou a capacidade seja liberada antes do previsto.

Isso não significa criar uma fila gigantesca. A ideia é manter uma reserva controlada de trabalho de qualidade, sem restrições críticas, que preserve fluxo quando existe variabilidade.

A diferença para um backlog genérico é importante. O backlog de projeto em Engenharia pode conter demandas ainda em qualificação. Workable backlog representa um subconjunto suficientemente pronto para execução.

Weekly Work Plan: compromisso, não desejo

O Weekly Work Plan — WWP — é a camada em que a equipe transforma possibilidade em promessa operacional.

Uma regra fundamental é que o plano semanal deve ser construído a partir do que a equipe sabe que pode fazer, e não simplesmente do que o cronograma diz que deveria fazer. Quando uma atividade entra sem condição de execução, o sistema produz uma promessa fictícia e transfere incerteza para quem executa.

Cada compromisso deveria explicitar:

resultado esperado;
responsável;
período de conclusão;
predecessor relevante;
critério de conclusão;
condição de prontidão;
handoff liberado.

Capacidade precisa ser considerada

Uma equipe pode ter vinte atividades prontas e ainda assim capacidade para apenas oito. O plano semanal precisa equilibrar carga e capacidade.

Em Engenharia, isso é crítico porque especialistas não são recursos perfeitamente substituíveis. Um engenheiro de proteção, coordenador BIM, especialista em segurança funcional ou responsável por uma aprovação regulatória pode ser o gargalo de vários pacotes simultâneos.

Planejar acima da capacidade apenas cria WIP e filas.

Daily Huddles: preservar o compromisso durante a semana

O plano semanal não deve ser abandonado até a próxima reunião. Huddles curtos podem verificar diariamente:

compromissos do dia;
desvios;
bloqueios novos;
handoffs;
mudanças na sequência;
necessidade de ajuda;
risco de não concluir promessa semanal.

O objetivo não é microgerenciar pessoas. É detectar cedo o que ameaça o fluxo e permitir contramedidas antes do fechamento da semana.

Percent Plan Complete — PPC

PPC mede a confiabilidade do plano de compromissos. A formulação básica é:

PPC = número de compromissos concluídos conforme prometido ÷ número total de compromissos planejados × 100%

Se uma equipe assumiu 20 compromissos e concluiu 16 conforme definido, o PPC da semana é 80%.

O indicador parece trivial, mas sua interpretação exige disciplina.

Parcialmente concluído não é concluído

Se o critério de conclusão dizia “emitir documento para revisão” e o documento permanece em 95% internamente, o handoff não aconteceu. Contabilizar o item como concluído distorce a confiabilidade do sistema.

PPC não mede qualidade técnica

Um PPC alto não significa que o projeto está tecnicamente correto. Uma equipe pode cumprir 100% das promessas e ainda produzir trabalho inadequado se critérios de qualidade e aceite estiverem mal definidos.

PPC não deve ser ranking individual

Usar PPC para premiar ou punir pessoas cria incentivo para compromissos fáceis, subdimensionamento e manipulação do plano. O indicador deve apoiar aprendizado do sistema.

PPC alto sozinho não prova sucesso do projeto

Uma equipe pode atingir 95% de PPC em tarefas pouco relevantes e continuar ameaçando um marco crítico. Compromissos precisam estar conectados ao phase plan, aos handoffs e aos objetivos do empreendimento.

Reasons for Non-Completion: onde acontece o aprendizado

A parte mais valiosa do PPC pode estar nos itens que não foram concluídos.

Razões de não conclusão podem ser categorizadas para revelar padrões, por exemplo:

predecessor atrasado;
informação faltante;
mudança de prioridade;
falha de planejamento;
recurso indisponível;
problema de qualidade;
material atrasado;
decisão tardia;
produtividade abaixo da prevista;
interferência não detectada;
condição de campo diferente;
restrição externa.

O objetivo não é encontrar culpados. É identificar recorrências que o sistema consegue tratar.

Se “informação de fornecedor” aparece como causa em várias semanas, a contramedida pode envolver antecipação de vendor data requirements e mudança no processo de procurement. Se “decisão do cliente” é recorrente, talvez seja necessário criar um decision log com datas necessárias e autoridade clara.

PPC e causas precisam formar um ciclo de melhoria

Uma rotina madura pode seguir:

medir o compromisso;
identificar falhas;
classificar razões;
investigar causas relevantes;
definir contramedida;
acompanhar implementação;
verificar se a recorrência diminuiu.

Sem os passos finais, a equipe apenas documenta problemas.

Last Planner aplicado ao design de Engenharia

No design, a força do LPS está em transformar dependências de informação e decisões em handoffs explícitos, preparados antes de entrarem no compromisso de curto prazo.

Conheça Design Management em Engenharia

Uma contribuição importante da literatura é demonstrar que LPS não se limita à produção em campo. Ballard já discutia aplicação em design; Fosse e Ballard documentaram um caso específico de Lean Design Management com Last Planner em equipe multidisciplinar.

No estudo de 2016, o processo tradicional apresentava handoffs pouco claros, tarefas mal descritas, falta de inputs e baixo volume de entregas por semana. A equipe implementou planejamento colaborativo e uma rotina semanal estruturada de check, correct e lookahead.

Os post-its usados no Pull Planning representavam entregas e momentos de handoff — desenho, lista, decisão — e não simplesmente o período durante o qual alguém permaneceria trabalhando. Isso é particularmente aderente ao trabalho intelectual.

Question matrix e decisões pendentes

O estudo também utilizou uma matriz de perguntas para questões que ainda não podiam ser transformadas em compromisso. Itens que permaneciam na matriz por várias semanas ficavam evidentes e recebiam atenção.

Essa ideia é diretamente aplicável a:

RFIs;
decision logs;
interface registers;
requirements clarifications;
vendor queries;
technical deviations.

O LPS não elimina esses registros, mas pode conectar sua resolução à prontidão do trabalho downstream.

Nem todo detalhe do LPS precisa ser aplicado da mesma forma

No caso estudado, a equipe adaptou elementos do sistema à duração e ao contexto da fase. Esse é um ponto importante: a implantação deve preservar funções essenciais — planejamento colaborativo, prontidão, compromisso, verificação e aprendizado — sem transformar o método em ritual burocrático.

Last Planner, Rolling Wave Planning e Kanban

Esses mecanismos são compatíveis, mas não equivalentes.

Rolling Wave Planning

O Rolling Wave Planning trabalha com detalhamento progressivo: curto prazo detalhado, longo prazo em nível mais agregado, refinado conforme informações amadurecem.

O Lookahead do LPS possui afinidade com essa lógica, mas acrescenta uma preocupação explícita com restrições e Make-Ready.

Kanban

O Kanban em projetos de Engenharia controla fluxo de work items, WIP, aging e previsibilidade. Pode ser utilizado para visualizar o próprio processo de Make-Ready, RFIs, documentos ou restrições.

LPS

Last Planner organiza planejamento colaborativo, prontidão e promessas confiáveis em vários horizontes. A combinação pode ser poderosa, desde que cada mecanismo preserve sua função.

Last Planner e Scrum: complementaridade possível, não equivalência

Scrum e LPS compartilham alguns temas — ciclos curtos, transparência, aprendizado, colaboração — mas têm origens e estruturas diferentes.

O Scrum aplicado a projetos de Engenharia é um framework para trabalho complexo baseado em empirismo, enquanto o LPS foi desenvolvido especificamente em torno de planejamento e controle da produção em projetos AEC.

Estudos recentes de Lean Construction investigam combinações entre Scrum, LPS e Takt, especialmente para gestão de impedimentos e preparação do trabalho. Essas propostas são promissoras, mas devem ser lidas como aplicações contextuais, não como regra universal.

LPS e a ABNT NBR ISO 21502:2021

A ABNT NBR ISO 21502 não prescreve Last Planner, mas vários princípios são compatíveis com a lógica do sistema. A norma orienta que:

o planejamento seja colaborativo quando possível;
dependências sejam definidas;
o planejamento seja iterativo e progressivo;
exista mais detalhe para o futuro imediato que para trabalho distante;
pacotes de trabalho sejam integrados ao plano geral;
interfaces sejam planejadas;
progresso seja monitorado;
riscos, questões e mudanças sejam controlados;
ações corretivas e preventivas sejam tomadas.

Essa compatibilidade ajuda a posicionar o LPS como uma prática operacional que pode existir dentro de uma arquitetura formal de gerenciamento de projetos.

Como integrar LPS ao cronograma mestre

Um erro é manter o cronograma e o Last Planner como universos separados. A equipe de planejamento atualiza Primavera P6 ou MS Project; a obra planeja em post-its; e os dois planos divergem.

A integração deve ser bidirecional.

Do cronograma para o LPS:

marcos;
prioridades;
caminho crítico e near-critical;
datas necessárias;
restrições contratuais;
sequências estruturantes.

Do LPS para o cronograma e forecast:

prontidão real;
mudanças de sequência;
restrições persistentes;
produtividade observada;
handoffs atrasados;
compromissos não confiáveis;
tendência de execução.

Project Controls precisa interpretar esses sinais para atualizar previsões sem destruir a baseline aprovada.

Não rebaseline para esconder falhas de confiabilidade

Se o plano de curto prazo falha, a resposta não é deslocar continuamente as datas de referência. Baseline e forecast possuem funções diferentes.

O LPS deve alimentar melhoria da execução e forecast mais realista. Alterações formais da baseline precisam seguir a governança e o change control aplicável.

Essa distinção é essencial para preservar a capacidade de aprender com o desvio.

Gestão de interfaces com Last Planner

Interfaces são uma fonte frequente de não confiabilidade. Um especialista conclui seu trabalho local, mas o próximo não consegue avançar porque o output não atende à condição necessária.

O Pull Planning ajuda a especificar handoffs. O Lookahead permite identificar o que pode impedir o handoff. O Weekly Work Plan converte a entrega em compromisso. A verificação confirma se ela realmente foi liberada.

Uma interface pode ser representada por:

Interface	Output necessário	Fornecedor	Receptor	Data necessária	Restrição	Estado
Processo → Elétrica	lista de cargas	Processo	Elétrica	10/09	duas cargas sem definição	make-ready
Civil → Elétrica	salas e shafts	Civil	Elétrica	12/09	layout em revisão	bloqueada
Fornecedor → Engenharia	curvas de proteção	Vendor	Proteção	15/09	PO ainda não liberada	escalada

Essa abordagem complementa o registro formal de interfaces e direciona a conversa para o que precisa ser liberado no horizonte imediato.

Procurement dentro do Lookahead

Nem todas as restrições estão dentro da obra ou da equipe de projeto. Long-lead items exigem tratar procurement como parte do sistema de produção.

O lookahead pode acompanhar:

especificação;
requisição;
bid tabulation;
TBE;
aprovação do fornecedor;
pedido;
vendor data;
aprovação documental;
fabricação;
inspeção/FAT;
transporte;
entrega.

Cada etapa possui lead time e pode se tornar restrição de um pacote futuro. O horizonte precisa ser ampliado quando o tempo de resposta do fornecedor é maior que a janela operacional típica.

Takt, localização e repetitividade

Em obras com repetição espacial, Takt Planning pode estruturar ritmo e zonas. LPS pode apoiar readiness, compromissos e aprendizado em torno desse sistema.

A integração precisa respeitar uma diferença importante: Takt define ritmo e sequência espacial; Last Planner trabalha com preparação, compromisso e controle de fluxo. Misturar termos sem compreender funções reduz a clareza do sistema.

Como implantar Last Planner System sem cair no “teatro dos post-its”

A implantação precisa começar por um problema real de produção: baixa confiabilidade do plano, restrições descobertas tarde, handoffs frágeis, excesso de trabalho iniciado ou pouca conexão entre planejamento de longo e curto prazo. Se o objetivo for apenas reproduzir uma dinâmica visual com cartões, a equipe pode adotar a aparência do LPS sem construir o sistema de controle que lhe dá valor.

Etapa	Objetivo	Evidência de que está funcionando
Definir o problema e os marcos reais	conectar o LPS à necessidade do empreendimento	phase planning e lookahead vinculados a milestones relevantes
Identificar participantes e last planners	envolver quem possui conhecimento e autoridade sobre o trabalho	compromissos assumidos por quem controla a execução
Executar Pull Planning	explicitar handoffs, lógica de sequência e condições de satisfação	dependências compreendidas e conflitos de sequência tratados
Estruturar Lookahead e constraint log	detalhar o futuro próximo e tornar restrições removíveis	restrições possuem responsável e data necessária antes da execução
Aplicar critérios de qualidade	evitar compromissos vagos ou inexequíveis	tarefas claras, sound, corretamente sequenciadas e compatíveis com capacidade
Operar WWP, PPC e análise de causas	medir confiabilidade e aprender com falhas	PPC acompanhado de razões de não conclusão e contramedidas
Integrar ao Project Controls	ligar produção de curto prazo à baseline, forecast e marcos	desvios operacionais conseguem ser relacionados a impactos de prazo e custo
Revisar maturidade	evitar que a rotina se degrade em ritual	políticas, horizontes, métricas e responsabilidades são ajustados com base em evidência

A implantação não precisa começar com todos os componentes simultaneamente. Em um projeto em andamento, pode ser mais seguro aplicar primeiro Pull Planning a uma fase crítica, implantar Lookahead com gestão de restrições e só então amadurecer Weekly Work Planning, PPC e aprendizado sistemático. O importante é preservar a lógica de sistema e não transformar cada ferramenta em iniciativa isolada.

Anti-padrões que enfraquecem o Last Planner

O LPS perde eficácia quando seus artefatos são usados sem a lógica de produção que os conecta. O problema não é apenas “usar errado” uma ferramenta; é quebrar a relação entre planejamento colaborativo, prontidão, compromisso, medição e aprendizado.

Anti-padrão	Efeito	Resposta adequada
Copiar o cronograma para um quadro	mantém a lógica push e apenas muda a apresentação	usar Pull Planning para discutir handoffs, condições e sequência real
Tratar “deveria” como “pode”	tarefas entram no plano com restrições ainda abertas	separar Lookahead, Make-Ready e compromisso semanal
Planejar sem quem executa	compromissos não incorporam conhecimento de produção	envolver last planners e responsáveis pelas interfaces críticas
Usar PPC como punição	incentiva manipulação de compromissos e reduz aprendizado	usar PPC como medida de confiabilidade do sistema
Não analisar causas	o mesmo tipo de falha se repete semana após semana	registrar razões de não conclusão e atuar sobre causas recorrentes
Manter restrições sem data necessária	o constraint log vira inventário passivo	relacionar cada restrição ao trabalho afetado e ao horizonte de necessidade
Misturar planejamento com solução técnica detalhada	reuniões ficam longas e perdem foco na coordenação	identificar a necessidade e encaminhar a análise para fórum técnico adequado
Confundir atualização com colaboração	o plano é apenas reportado, não construído coletivamente	usar a reunião para negociar compromissos e remover conflitos
Ignorar qualidade e segurança	a busca por cumprimento semanal pode premiar produção inadequada	incorporar critérios técnicos e de segurança às condições de conclusão

Um bom diagnóstico do LPS não pergunta apenas se existem quadros, post-its, PPC ou reuniões semanais. Pergunta se o sistema aumenta a confiabilidade do fluxo, antecipa restrições e melhora a capacidade de cumprir o que foi realmente assumido.

Exemplo completo: Last Planner em um pacote elétrico industrial

Considere um empreendimento que precisa liberar para compra um QGBT crítico em seis semanas. O cronograma mestre possui o marco “RFQ QGBT emitida” na semana 6.

O Pull Planning identifica os handoffs regressivos:

RFQ liberada;
especificação técnica aprovada;
diagrama unifilar aprovado;
curto-circuito e seletividade consolidados;
lista de cargas congelada para a etapa;
dados de motores críticos recebidos;
filosofia de proteção aprovada;
requisito de automação definido.

No lookahead, a equipe identifica três restrições:

dois motores ainda sem corrente de partida confirmada;
vendor data de um transformador pendente;
interface de intertravamento com automação sem decisão do proprietário.

O Make-Ready estabelece ações:

Restrição	Dono	Data de remoção	Ação	Impacto se atrasar
dados dos motores	Processo/Suprimentos	semana 2	reunião com vendor e confirmação formal	bloqueia estudo de partida
vendor data do transformador	Suprimentos	semana 2	expedição documental	afeta curto-circuito
intertravamento	Owner/Automação	semana 3	workshop de decisão	afeta especificação funcional

Na semana 3, apenas trabalho sem restrição entra no WWP. Um item que estava previsto, mas ainda aguarda vendor data, permanece em Make-Ready; outro item do workable backlog pode ser puxado para preservar capacidade.

No encerramento semanal, oito de dez compromissos são concluídos conforme definição. PPC = 80%. As duas não conclusões têm causas distintas: uma decisão tardia e uma estimativa de esforço subdimensionada. A equipe não apenas registra “20% atrasado”; cria contramedidas diferentes para cada causa.

Essa é a diferença entre controlar produção e simplesmente atualizar percentuais de avanço.

Métricas complementares ao PPC

PPC é central, mas não precisa ser a única medida. Conforme o contexto, podem ser úteis:

razões de não conclusão por categoria;
restrições identificadas;
percentual de restrições removidas antes da data necessária;
idade das restrições;
número de tarefas prontas no workable backlog;
throughput semanal;
confiabilidade de handoffs;
tempo entre identificação e remoção de impedimento;
variação entre phase plan e forecast;
retrabalho;
percentual de tarefas replanejadas.

A interpretação conjunta evita otimizar apenas o indicador mais visível.

LPS em Owner’s Engineering

Owner’s Engineering pode usar princípios do Last Planner principalmente para coordenar informação e decisões entre múltiplos agentes.

Aplicações possíveis:

design reviews;
RFIs;
submittals;
vendor data;
interfaces;
preparação para FAT/SAT;
prontidão para comissionamento;
fechamento de punch list;
liberação de documentos para aceite.

O Owner’s Engineer não precisa assumir o planejamento interno de cada contratada. Pode, porém, estruturar conversas de prontidão e compromisso nos pontos em que a integração entre organizações ameaça a entrega do proprietário.

LPS no PMO e na governança

O PMO não deve transformar Last Planner em um template corporativo rígido. Sua função pode ser definir princípios mínimos, métricas, integração de dados e critérios de qualidade, permitindo tailoring por projeto.

Uma governança madura pode exigir:

vínculo com marcos aprovados;
calendário de Pull Planning e lookahead;
constraint log;
registro de PPC e causas;
ownership de ações;
integração com risk/issue/change management;
conexão com forecast;
revisão periódica de eficácia.

O PMO Ágil e Híbrido pode usar LPS como uma prática de produção em projetos onde fluxo, handoffs e compromisso de curto prazo sejam determinantes.

Quando o Last Planner System faz mais sentido

O método tende a gerar mais valor quando o projeto apresenta:

muitas interfaces;
alta interdependência entre especialistas;
variabilidade operacional;
forte necessidade de coordenação de curto prazo;
dependência de inputs e liberações;
múltiplas contratadas;
design e obra parcialmente sobrepostos;
fast-track;
pressão por confiabilidade de marcos;
problemas recorrentes de restrições tardias.

Em atividades simples, independentes e altamente previsíveis, parte da estrutura pode ser desnecessária. Tailoring é preferível a implantar rituais sem função.

Quando o LPS não resolverá o problema sozinho

Last Planner não corrige:

escopo estruturalmente indefinido sem processo de decisão;
contrato incoerente;
falta crônica de recursos;
baseline inviável;
ausência de autoridade;
engenharia tecnicamente inadequada;
mudanças descontroladas;
procurement sem estratégia;
riscos executivos ignorados.

Nesses casos, o sistema pode tornar a fragilidade mais visível, mas a solução exige governança e ação em outra camada.

Considerações finais

O Last Planner System é valioso porque muda o foco do planejamento de curto prazo: de uma lista do que deveria ser executado para um sistema que investiga o que pode ser executado, constrói compromissos confiáveis, verifica conclusões e aprende com as falhas.

Em Engenharia, essa lógica é especialmente relevante porque grande parte do trabalho depende de informação, decisões, interfaces e competências especializadas. O problema muitas vezes não é desconhecer a data-alvo, mas chegar perto dela e descobrir que o pacote ainda não possui condições reais de avançar.

Integrado ao CPM, Rolling Wave Planning, Kanban, Project Controls, gestão de interfaces e governança, o LPS forma uma camada operacional de produção e coordenação. A maturidade não está em adotar post-its ou reuniões Lean; está em aumentar a confiabilidade com que o projeto transforma planos em entregas efetivamente utilizáveis.

Em Owner’s Engineering, o LPS pode estruturar prontidão e compromissos nos pontos de interface entre projetistas, fornecedores, contratadas e proprietário.

Conheça o serviço de Owner’s Engineering

Referências técnicas

[1] BALLARD, Glenn. The Last Planner System of Production Control. Thesis (Doctor of Philosophy) — School of Civil Engineering, University of Birmingham, 2000. Disponível em: https://leanconstruction.org/lean-topics/last-planner-system/

[2] BALLARD, Glenn; TOMMELEIN, Iris D. 2020 Current Process Benchmark for the Last Planner System of Project Planning and Control. Lean Construction Journal, 2021. Disponível em: https://leanconstructionjournal.org/

[3] LEAN CONSTRUCTION INSTITUTE. Last Planner System. Disponível em: https://leanconstruction.org/lean-topics/last-planner-system/

[4] LEAN CONSTRUCTION INSTITUTE. Last Planner System Workbook. 2007. Disponível em: https://leanconstruction.org/wp-content/uploads/2022/08/Last-Planner-System-Workbook.pdf

[5] LEAN CONSTRUCTION INSTITUTE. Last Planner System for Design. Disponível em: https://leanconstruction.org/lean-topics/last-planner-system-for-design/

[6] FOSSE, Roar; BALLARD, Glenn. Lean Design Management in Practice With the Last Planner System. Proceedings IGLC 24, 2016. Disponível em: https://iglc.net/Papers/Details/1297

[7] ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR ISO 21502:2021 — Gerenciamento de projetos, programas e portfólios — Orientação sobre gerenciamento de projetos. Rio de Janeiro: ABNT, 2021.

Perguntas frequentes

O que é o Last Planner System?

É um sistema de planejamento e controle voltado à confiabilidade do fluxo e dos compromissos. Ele conecta marcos, Pull Planning, Lookahead, Make-Ready, Weekly Work Planning, PPC e aprendizado com razões de não conclusão.

Qual é a diferença entre Last Planner System e Pull Planning?

Pull Planning é uma das práticas do Last Planner System. O LPS é mais amplo e inclui preparação do trabalho, análise de restrições, compromissos semanais, coordenação diária, PPC e aprendizado.

Last Planner System substitui o cronograma CPM?

Não. O CPM representa lógica, durações, folgas e caminho crítico; o LPS atua sobre prontidão, fluxo e confiabilidade dos compromissos que ajudam a materializar o plano.

O que é Lookahead Planning no Last Planner?

É a camada de planejamento do futuro próximo em que atividades são detalhadas, restrições são identificadas e ações de Make-Ready são executadas antes de o trabalho entrar no compromisso semanal.

O que é Make-Ready?

É o processo de remover restrições e produzir condições para que uma atividade futura esteja realmente executável quando chegar o momento do compromisso.

Como calcular o PPC?

PPC é o número de compromissos concluídos conforme prometido dividido pelo total de compromissos planejados no período, multiplicado por 100. Ele mede confiabilidade do plano, não qualidade técnica.

O Last Planner pode ser usado na fase de projeto e Engenharia?

Sim. A literatura de Lean Construction registra aplicações em design, nas quais handoffs, inputs, decisões e entregáveis são planejados colaborativamente e preparados no lookahead.

Qual é a diferença entre Project Controls e Last Planner?

Project Controls monitora desempenho integrado em relação a baseline, custo, prazo e forecast. Last Planner atua mais diretamente sobre produção, prontidão, restrições, handoffs e compromissos de curto prazo. Os dois são complementares.