Entenda como aplicar Kanban em projetos de Engenharia para visualizar fluxo, controlar WIP, identificar gargalos, reduzir filas e melhorar a previsibilidade de entregas técnicas.
Confira!
Kanban é uma estratégia para otimizar o fluxo de valor por um processo. Em projetos de Engenharia, sua aplicação mais útil não é transformar o cronograma em um quadro de tarefas, mas tornar visível como documentos, decisões, RFIs, interfaces, revisões e pacotes técnicos entram, avançam, aguardam e são concluídos dentro do sistema de trabalho.
O ponto central é o fluxo. Um projeto pode ter cronograma aprovado e, ainda assim, acumular dezenas de documentos em revisão, comentários sem resposta, interfaces bloqueadas e pacotes iniciados simultaneamente sem capacidade real de conclusão. O Kanban expõe essas filas e permite controlar o trabalho em progresso — WIP — para aumentar foco, reduzir tempo de atravessamento e melhorar previsibilidade.
Em Engenharia, portanto, Kanban funciona melhor como uma camada operacional de gestão visual e fluxo, integrada ao cronograma, à governança e aos Project Controls. Ele não substitui caminho crítico, marcos contratuais, baseline ou gestão de mudanças; complementa esses mecanismos onde o problema principal está no movimento cotidiano do trabalho técnico.
O que é Kanban
O Kanban Guide, edição de maio de 2025, define Kanban como uma estratégia para otimizar o fluxo de valor através de um processo. A abordagem é estruturada em três práticas que atuam em conjunto:
- definir e visualizar o workflow;
- gerenciar ativamente os itens que percorrem esse workflow;
- melhorar continuamente o workflow.
A diferença entre Kanban e um simples quadro de tarefas começa aqui. Colunas com cartões não constituem, por si sós, um sistema Kanban. É necessário explicitar o que está fluindo, quais são os estados, quando um item é considerado iniciado e concluído, quais políticas regem sua movimentação e como o WIP será controlado.
Definition of Workflow: o que realmente está fluindo
O Kanban Guide chama de Definition of Workflow — DoW o entendimento explícito e compartilhado sobre o fluxo. Em um projeto de Engenharia, a DoW precisa responder perguntas concretas.
- Qual é a unidade de trabalho: documento, RFI, submittal, pacote de engenharia, decisão, issue BIM ou pendência de interface?
- Em que ponto esse item passa a ser considerado iniciado?
- Quais estados atravessa até ser concluído?
- Quem pode mover ou aprovar o item?
- Qual evidência caracteriza conclusão?
- Como o volume simultâneo de trabalho será limitado?
- Qual expectativa de prazo de atravessamento é razoável?
A resposta muda conforme o processo. Uma revisão de desenho executivo pode utilizar estados diferentes de uma RFI de obra ou de uma análise de submittal. Por isso, projetos complexos podem ter mais de um workflow conectado.
Quadro Kanban não é apenas “a fazer, fazendo e feito”
Se o cronograma está atualizado, mas documentos, RFIs e decisões continuam acumulando, o problema pode estar no fluxo — não no planejamento macro.
O quadro Kanban é a visualização da Definition of Workflow. Em Engenharia, três colunas genéricas frequentemente escondem exatamente o que precisa ser gerenciado.
Um fluxo documental, por exemplo, pode ser representado como:
Esse desenho torna visíveis estados que um cronograma tradicional tende a representar apenas como uma atividade agregada. O ganho aparece quando a equipe consegue enxergar onde os itens estão envelhecendo, onde existe excesso de WIP e qual etapa está limitando o throughput do sistema.
Swimlanes, classes e diferentes tipos de item
Quando necessário, o quadro pode separar disciplinas, projetos, criticidades ou classes de serviço. Uma RFI que bloqueia montagem em campo não deveria competir em igualdade com uma revisão editorial sem impacto no caminho crítico.
A gestão visual pode incorporar critérios como:
- disciplina de Engenharia;
- pacote de trabalho;
- criticidade técnica;
- impacto em caminho crítico ou marco contratual;
- necessidade de decisão do cliente;
- dependência de fornecedor;
- bloqueio de fabricação, montagem, teste ou comissionamento.
O objetivo não é criar um quadro visualmente complexo. É representar informação suficiente para que a priorização seja tecnicamente defensável.
WIP: por que começar menos pode fazer a Engenharia entregar mais
Excesso de trabalho iniciado aumenta filas e pode reduzir a capacidade efetiva de conclusão da Engenharia.
Work in Progress — WIP é o número de itens iniciados e ainda não concluídos. O Kanban Guide exige que o WIP seja explicitamente controlado entre os pontos de início e término definidos no workflow.
Em projetos de Engenharia, excesso de WIP ocorre quando diferentes partes interessadas pressionam a equipe para “começar tudo”. O resultado aparente é alta ocupação; o resultado real pode ser aumento de filas, alternância de contexto, revisões incompletas, espera por decisão e redução da taxa de conclusão.
Um exemplo típico é uma equipe de projeto que inicia simultaneamente dez pacotes, embora tenha capacidade de compatibilizar e revisar apenas três. Os sete pacotes adicionais entram no sistema, mas não avançam de forma sustentável. O projeto passa a medir trabalho iniciado, não trabalho efetivamente concluído.
Sistema puxado e capacidade disponível
Ao controlar WIP, o Kanban tende a criar um pull system. Novos itens são puxados quando há capacidade no estágio seguinte, em vez de serem empurrados para dentro do processo apenas porque alguém deseja vê-los iniciados.
Isso é particularmente útil em funções de Engenharia Consultiva e Owner’s Engineering que recebem demanda contínua: revisão de documentos, RFIs, submittals, pareceres, comentários, punch items e decisões técnicas.
Nesses ambientes, controlar entrada pode ser mais importante do que produzir uma lista cada vez maior de prioridades.
A origem Lean do pull: Kanban é mecanismo de informação, não o sistema inteiro
A leitura de Taiichi Ohno ajuda a evitar uma simplificação comum. No Toyota Production System, o processo posterior retira do processo anterior apenas o que necessita, quando necessita e na quantidade necessária; o Kanban surge como o meio visual de transmitir a informação que coordena esse sistema puxado.
Reproduzir cartões e colunas sem tratar capacidade, filas, políticas e causas de espera equivale a copiar o mecanismo visual sem implantar a lógica de fluxo que lhe dá sentido. Ohno alerta para o risco de aplicar Kanban isoladamente sem compreender o sistema de gestão que o sustenta.
Em Engenharia, um quadro pode mostrar dezenas de documentos em andamento e continuar reproduzindo um sistema push. A mudança real ocorre quando a capacidade downstream influencia a entrada de trabalho e a equipe prioriza concluir e liberar valor antes de abrir novas frentes.
Gargalos, filas e trabalho bloqueado
Um gargalo é uma restrição que limita a capacidade efetiva do fluxo. Em Engenharia, ele nem sempre está dentro da equipe que executa o trabalho.
Pode estar em:
- revisão de uma disciplina especialista;
- aprovação do cliente;
- disponibilidade de Technical Authority;
- informação de fornecedor;
- levantamento de campo ainda não realizado;
- decisão de interface entre duas disciplinas;
- análise contratual;
- liberação de orçamento;
- retorno de uma RFI crítica.
O quadro Kanban permite distinguir trabalho ativo de trabalho bloqueado. Essa separação é relevante porque aumentar a quantidade de itens em execução não resolve um bloqueio externo. Frequentemente apenas aumenta a fila em torno da restrição.
Um bom sistema de gestão visual transforma bloqueios em informação acionável: causa, responsável, tempo de bloqueio, impacto e regra de escalonamento.
Métricas essenciais do Kanban
A edição 2025 do Kanban Guide estabelece quatro métricas mínimas de fluxo.
| Métrica | O que mede | Aplicação em Engenharia |
| WIP | itens iniciados e não concluídos | quantidade de RFIs, documentos ou análises simultaneamente abertas |
| Throughput | itens concluídos por unidade de tempo | documentos emitidos, RFIs respondidas ou submittals analisados por semana |
| Work Item Age | idade de um item ainda em andamento | há quanto tempo uma pendência permanece aberta |
| Cycle Time | tempo entre início e conclusão | tempo necessário para revisar, decidir ou emitir uma entrega |
Essas métricas não substituem indicadores de prazo, custo ou valor agregado. Elas respondem a outra camada: como o sistema de produção da Engenharia está se comportando agora.
Por isso, podem ser combinadas com CPI, SPI, marcos, caminho crítico e Curva S em um sistema híbrido de controle.
SLE e previsibilidade
O Kanban Guide inclui a Service Level Expectation — SLE na Definition of Workflow. A SLE é uma previsão de quanto tempo um item deveria levar entre início e fim, associada a uma probabilidade.
Em Engenharia, isso pode ser aplicado a processos repetitivos com dados históricos suficientes, como análise de RFI, revisão de submittal, emissão de parecer padronizado, tratamento de issue BIM e revisão de documento por determinada disciplina.
A SLE não deve ser confundida automaticamente com prazo contratual. Ela é um instrumento de previsibilidade operacional baseado no comportamento real do sistema.
Kanban em design e coordenação 3D
A aplicação do Kanban em Engenharia não é apenas conceitual. Modrich e Cousins documentaram o uso de Digital Kanban Boards em processos de design e coordenação 3D, combinados com Last Planner System.
Nos casos estudados, os quadros permitiam visualizar tarefas por stakeholders, WIP e necessidades futuras de informação. A combinação ajudou a sincronizar participantes, acompanhar lookahead e reduzir latência na entrega de decisões necessárias ao design.
Esse tipo de aplicação é especialmente aderente a ambientes multidisciplinares em que arquitetura, civil, elétrica, mecânica, automação, telecomunicações e fornecedores produzem informação interdependente.
Kanban x cronograma: ferramentas diferentes
Um erro recorrente é tratar Kanban como substituto do cronograma. Em projetos de Engenharia, as duas ferramentas atuam em escalas diferentes.
O cronograma representa dependências, durações, marcos, lógica de rede, caminho crítico e compromissos temporais do empreendimento. O Kanban torna visível o fluxo de itens em processos de conhecimento e permite controlar filas, WIP e aging.
| Pergunta | Cronograma | Kanban |
| Qual é a sequência lógica do projeto? | forte | limitado |
| Qual atividade está no caminho crítico? | forte | não é o objetivo |
| Onde documentos estão acumulando? | limitado | forte |
| Quantos itens estão simultaneamente em progresso? | limitado | forte |
| Qual item está envelhecendo? | limitado | forte |
| Quando ocorre o marco contratual? | forte | complementar |
A arquitetura mais madura é integrada: o cronograma estabelece compromissos e horizontes; o Kanban governa parte do fluxo operacional que precisa entregar esses compromissos.
Kanban em PMO, Project Controls e Owner’s Engineering
O Kanban ganha relevância quando aplicado não apenas à equipe individual, mas aos fluxos de governança.
Em um PMO, pode apoiar portfólios de decisões, relatórios, riscos e solicitações de mudança. Em Project Controls, ajuda a identificar causas operacionais que antecedem variações de prazo. Em Owner’s Engineering, pode estruturar o fluxo de RFIs, submittals, documentos, interfaces, inspeções e aceite.
A condição é preservar a diferença entre gestão de fluxo e governança do projeto. Limites de responsabilidade, baseline, change control e alçadas de aprovação continuam existindo.
Como implementar Kanban em um processo de Engenharia
Uma implementação útil pode seguir sete passos.
- Escolher um processo com fluxo reconhecível e problema real de fila ou previsibilidade.
- Definir a unidade de trabalho e os pontos de início e término.
- Tornar os estados do workflow explícitos.
- Definir políticas de movimentação e critérios de conclusão.
- Estabelecer controle de WIP compatível com a capacidade real.
- Medir WIP, throughput, aging e cycle time.
- Revisar o sistema e ajustar o workflow com base nos dados.
O primeiro quadro não precisa ser sofisticado. O ganho vem da disciplina de tornar o sistema explícito, observar seu comportamento e ajustar políticas.
Erros comuns ao aplicar Kanban em Engenharia
Criar cartões para tudo sem definir unidade de valor
Quando tarefas, documentos, decisões e problemas de tamanhos radicalmente diferentes são tratados como itens equivalentes, throughput e cycle time perdem comparabilidade.
Não controlar WIP
Um quadro sem limite ou política de WIP pode apenas visualizar o congestionamento sem modificar seu comportamento.
Usar Kanban para esconder falta de planejamento
Kanban não corrige ausência de escopo, cronograma, requisitos, responsabilidades ou baseline. Ele precisa operar dentro de uma arquitetura mínima de gestão.
Transformar o quadro em relatório para a chefia
Se o quadro existe apenas para prestação de contas e não orienta decisões de fluxo da equipe, tende a ficar desatualizado e perder utilidade.
Medir velocidade individual
O foco é o desempenho do sistema, não a comparação simplista entre pessoas. Gargalos muitas vezes surgem de políticas, dependências, filas ou restrições externas.
Kanban como sistema de decisão: efetividade, eficiência e previsibilidade
Uma leitura mais madura de Kanban começa antes do quadro. O Kanban Guide 2025 define a estratégia em torno da otimização do fluxo de valor e associa esse objetivo a um equilíbrio entre efetividade, eficiência e previsibilidade. Em Engenharia, essas três dimensões ajudam a evitar uma distorção comum: melhorar apenas a velocidade aparente do fluxo sem verificar se o trabalho certo está chegando ao stakeholder, se a capacidade técnica está sendo usada de forma racional e se a equipe consegue fazer previsões com nível de incerteza aceitável.
| Dimensão | Pergunta de gestão em Engenharia | Sinal de deterioração |
| Efetividade | Estamos concluindo os entregáveis, decisões e interfaces que realmente liberam valor? | muito trabalho concluído sem liberar projeto, fabricação, obra ou aceite |
| Eficiência | A capacidade dos especialistas está concentrada em trabalho útil ou dispersa em filas, trocas de contexto e retrabalho? | muitos itens simultâneos e baixa taxa de conclusão |
| Previsibilidade | Conseguimos estimar, com base no histórico, quando um tipo de item tende a atravessar o fluxo? | datas definidas apenas por pressão, sem evidência do comportamento do sistema |
Essa leitura muda a pergunta de “quantos cartões estão no quadro?” para “como o sistema está convertendo capacidade em entregas previsíveis?”. O próprio Kanban Guide relaciona Kanban a teoria de filas, variação, pensamento sistêmico, princípios Lean e controle da qualidade. Portanto, o quadro é uma representação do sistema; não é o sistema em si.
Por que limitar WIP funciona: filas, variação e capacidade técnica
Projetos de Engenharia frequentemente sofrem de uma forma pouco visível de sobrecarga: cada disciplina inicia vários documentos, análises, RFIs e revisões em paralelo, mas poucos itens chegam efetivamente ao estado de conclusão. O resultado é uma coleção de trabalhos parcialmente desenvolvidos, cada um aguardando informação, revisão, decisão ou disponibilidade de especialista.
O controle de WIP atua exatamente nessa condição. Segundo o Kanban Guide, um item só deveria ser selecionado quando existe um sinal claro de capacidade no sistema. Na prática, isso cria um mecanismo de pull: concluir e liberar trabalho existente passa a ter prioridade sobre iniciar continuamente novos itens.
Em Engenharia, o efeito é particularmente importante porque capacidade não é fungível. Um engenheiro de proteção, um especialista em automação, um coordenador BIM ou uma autoridade técnica não pode ser substituído instantaneamente por qualquer outro recurso. Quando muitos itens dependem da mesma competência rara, o gargalo aparece como fila — ainda que todos os responsáveis estejam “ocupados”.
O limite de WIP não precisa ser um número arbitrário imposto ao quadro. Ele deve refletir como o fluxo foi definido, quais estados realmente consomem capacidade e quais exceções são admissíveis. O Kanban Guide recomenda que exceções ao controle de WIP sejam explícitas na Definition of Workflow. Isso permite, por exemplo, tratar uma RFI crítica de segurança ou uma pendência que bloqueia caminho crítico sem transformar toda urgência declarada em exceção permanente.
Work Item Age, SLE e gestão por exceção
Depois que um item entra em execução, a pergunta relevante deixa de ser apenas “qual é o prazo final?” e passa a incluir há quanto tempo este item está em andamento e como essa idade se compara ao comportamento histórico do fluxo?
O Kanban Guide inclui o Work Item Age entre as quatro métricas mínimas do sistema e recomenda usar a Service Level Expectation — SLE como referência para evitar que itens envelheçam desnecessariamente. A SLE combina um período de tempo com uma probabilidade, baseada preferencialmente em dados históricos de cycle time. Assim, em vez de afirmar deterministicamente que “todo RFI será respondido em cinco dias”, o sistema pode estabelecer uma expectativa probabilística coerente com sua própria capacidade e variabilidade.
SLE não deve ser confundida automaticamente com SLA contratual. O SLA pode representar uma obrigação formal; a SLE é uma expectativa operacional usada para compreender e gerenciar o fluxo. Essa distinção é útil em Owner’s Engineering, design review e gestão documental, onde um prazo contratual pode permanecer fixo enquanto o comportamento real da fila sinaliza antecipadamente risco de descumprimento.
Uma rotina de gestão por exceção pode, por exemplo, revisar diariamente ou em cadência definida os itens bloqueados e aqueles cuja idade se aproxima ou supera a expectativa do sistema. O objetivo não é pressionar cada responsável isoladamente, mas investigar o que está impedindo o fluxo: ausência de input, dependência entre disciplinas, autoridade de decisão, fila de revisão, mudança de prioridade ou capacidade insuficiente.
Kanban conectado ao lookahead e ao make-ready de Engenharia
O Kanban se torna mais poderoso em Engenharia quando é conectado a uma camada anterior de preparação do trabalho. O Last Planner System trata essa preparação por meio do lookahead, da análise de restrições e do make-ready: atividades são detalhadas, avaliadas quanto a inputs e pré-requisitos e somente avançam para compromisso quando existe confiança suficiente de que podem ser executadas.
O workbook do Last Planner distingue o que o projeto deveria fazer do que efetivamente pode fazer. Entre os critérios de uma atribuição de qualidade estão definição suficiente, soundness, sequência, tamanho compatível com a capacidade e aprendizado a partir das não conclusões. Para tarefas de design, restrições típicas incluem inputs de outras disciplinas, clareza de critérios, aprovações, liberações e disponibilidade de recursos de Engenharia.
Fosse e Ballard, ao estudar Last Planner em design, observaram precisamente esse tipo de problema: handoffs pouco claros, tarefas mal descritas, falta de inputs e baixo volume de entregas semanais. A rotina aplicada separava check, correct e lookahead; tarefas não concluídas eram movidas, reformuladas ou divididas, enquanto os compromissos futuros eram revistos para confirmar predecessores e realismo.
Uma arquitetura híbrida pode, portanto, separar duas funções. O backlog de projeto e o lookahead ajudam a qualificar e tornar o trabalho executável; o Kanban controla o fluxo dos itens que efetivamente entraram no sistema. Isso evita usar o quadro como depósito de demandas ainda imaturas.
Handoffs como unidade de gestão
Em design multidisciplinar, muitas vezes o valor de um item não está em “trabalhar no desenho”, mas em produzir uma saída que libera o trabalho seguinte: uma definição de carga que libera dimensionamento, uma lista que libera especificação, uma decisão que libera detalhamento ou uma revisão que libera emissão.
O estudo de Fosse e Ballard utilizou post-its representando entregas e momentos de handoff, e não simplesmente todo o período durante o qual alguém estava ocupado. Esse princípio é diretamente útil na construção de um quadro Kanban de Engenharia: estados e itens devem tornar visível onde o valor está parado entre especialistas, não apenas quem está executando uma tarefa.
Quando criar mais de um workflow
O Kanban Guide admite explicitamente múltiplas Definitions of Workflow quando grupos ou níveis diferentes precisam representar fluxos distintos. Em um projeto complexo, isso pode significar não misturar no mesmo quadro um RFI, uma revisão de documento e um pacote de engenharia multidisciplinar se cada classe atravessa estados, políticas e tempos radicalmente diferentes.
O princípio é preservar a capacidade de interpretar o sistema. Um quadro único com centenas de itens heterogêneos pode aumentar visibilidade superficial e, ao mesmo tempo, destruir a qualidade das métricas. Fluxos separados podem ser conectados por handoffs e por uma camada comum de governança, PMO ou Project Controls.
Considerações finais
Kanban é especialmente poderoso em Engenharia quando o projeto possui grande volume de trabalho de conhecimento circulando entre pessoas, disciplinas e organizações. Documentos, RFIs, revisões, submittals, issues, decisões e pendências criam filas que nem sempre aparecem claramente no cronograma.
Ao definir o workflow, controlar WIP, observar aging, medir cycle time e throughput e tratar bloqueios de forma explícita, a organização passa a administrar o fluxo em vez de apenas registrar tarefas. Integrado a PMO, Project Controls e governança, Kanban se torna uma camada complementar de controle — útil para aumentar transparência e previsibilidade sem simplificar a complexidade do empreendimento.
Assinatura técnica — Eng. Altair Galvão Badge editorial selecionado: Engenharia Consultiva — gestão de projetos, governança técnica e coordenação de empreendimentos.
Kanban e Project Controls respondem perguntas diferentes; a arquitetura mais robusta usa ambos de forma integrada.
Referências técnicas
[1] COLEMAN, John et al.. The Kanban Guide — May 2025. 2025. Disponível em: https://kanbanguides.org/the-kanban-guide/2025.5/.
[2] MODRICH, Ralf-Uwe; COUSINS, Bruce C.. Digital Kanban Boards Used in Design and 3D Coordination. 25th Annual Conference of the International Group for Lean Construction, 2017. Disponível em: https://www.iglc.net/Papers/Details/1454.
[3] PROJECT MANAGEMENT INSTITUTE. A Guide to the Project Management Body of Knowledge — PMBOK Guide. 8th ed.. 2025. Disponível em: https://www.pmi.org/standards/pmbok.
[4] FOSSE, Roar; BALLARD, Glenn. Lean Design Management in Practice with the Last Planner System. 24th Annual Conference of the International Group for Lean Construction, 2016.
[5] LEAN CONSTRUCTION INSTITUTE. Last Planner System Workbook: improving planning reliability. 2007.
[6] OHNO, Taiichi. Toyota Production System: Beyond Large-Scale Production. Portland: Productivity Press, 1988. Disponível em: https://www.routledge.com/Toyota-Production-System-Beyond-Large-Scale-Production/Ohno/p/book/9780915299140.
Perguntas frequentes
Kanban é uma estratégia para otimizar o fluxo de valor por um processo. Sua aplicação exige definir e visualizar o workflow, gerenciar ativamente os itens em fluxo e melhorar continuamente o sistema.
Não. O quadro é a visualização do workflow. Um sistema Kanban também exige definição explícita do fluxo, políticas, controle de WIP e análise de métricas como throughput, aging e cycle time.
Sim. É especialmente útil para fluxos de conhecimento como documentos, RFIs, submittals, revisões, issues e decisões técnicas, desde que integrado à governança do projeto.
Não. O cronograma representa dependências, caminho crítico, durações e marcos. Kanban atua principalmente sobre fluxo, filas, WIP, aging e previsibilidade operacional.
WIP é o trabalho iniciado e ainda não concluído. Controlar WIP evita que a equipe inicie mais itens do que sua capacidade de processar e concluir.
O Kanban Guide 2025 estabelece como métricas mínimas WIP, throughput, work item age e cycle time.
Materiais técnicos complementares
Conteúdos principais sobre o tema
- Gestão Ágil e Híbrida de Projetos de Engenharia
- Metodologias Ágeis em Projetos de Engenharia
- Métricas Ágeis x EVM em Projetos Híbridos
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
