Como controlar as etapas de projeto (LV, PN, EP, AP, PL, PB, PE) sem depender de planilha

Revisão: João Paulo Chagas, gestor de Marketing e Operações da Audatia · atualizado em 18 de agosto de 2026

As siglas LV, PN, EV, EP, AP, PL, PB e PE vêm das ABNT NBR 13531:1995 e NBR 13532:1995 — levantamento, programa de necessidades, estudo de viabilidade, estudo preliminar, anteprojeto, projeto legal, projeto básico e projeto para execução. Essas duas normas foram canceladas em dezembro de 2017. Quem está em vigor é a série ABNT NBR 16636, que reorganizou o mesmo percurso em duas fases e ampliou a nomenclatura (LV-ARQ, PN-ARQ, EV-ARQ, EP-ARQ, AP-ARQ, PL, PE-ARQ, além das etapas complementares e do as built). Na prática, o vocabulário antigo continua circulando no mercado, e é ele que o cliente usa no contrato.

O controle dessas etapas não falha por falta de planilha. Falha porque a planilha é um registro secundário: alguém precisa lembrar de atualizá-la, depois que o fato já aconteceu. Enquanto o dado de verdade estiver no e-mail, na pasta do servidor e na cabeça do coordenador, a planilha será sempre uma fotografia velha. A saída é parar de tratar etapa como linha de relatório e passar a tratá-la como status do próprio trabalho — com data, dono, número de revisão e situação de aprovação registrados no lugar onde o trabalho acontece, não num arquivo paralelo. Quando a etapa é o status, o estado dos quinze projetos é consequência de quem já está trabalhando neles, não de alguém consolidando na sexta-feira.

Quais são as etapas de projeto e o que cada uma entrega?

A tabela usa as siglas históricas — as que aparecem em contrato e proposta — e indica a correspondência na norma vigente.

Duas observações que evitam ruído com o cliente. Primeira: o EV é frequentemente suprimido da lista informal, mas existe na norma e costuma ser exatamente onde o escopo muda. Segunda: “projeto básico” não sumiu — mudou de casa. Em contratação pública ele é definido em lei, não em norma técnica:

“XXV – projeto básico: conjunto de elementos necessários e suficientes, com nível de precisão adequado para definir e dimensionar a obra ou o serviço…”
— Lei nº 14.133/2021, art. 6º

Se o escritório atende público e privado, os dois vocabulários convivem. O controle precisa aceitar isso sem criar duas listas paralelas.

Por que a planilha de controle sempre desatualiza?

Porque ela é alimentada depois — e por alguém que não é quem produziu o fato.

O arquiteto termina a revisão do EP na terça. Manda por e-mail na quarta. O cliente responde na sexta pedindo ajuste. A planilha é atualizada na segunda seguinte, por um coordenador que reconstruiu a sequência lendo a caixa de entrada. Nesse intervalo de cinco dias, qualquer pergunta sobre o estado daquele projeto teve resposta errada. Não por má-fé: por latência estrutural.

Isso escala mal. Com três projetos, a reconstrução manual funciona. Com quinze, cada um em etapa diferente, o custo de manter a planilha correta passa a competir com o trabalho técnico — e perde. A planilha então vira o que quase sempre vira: um documento que todo mundo sabe que está desatualizado e ninguém confia o bastante para decidir a partir dele.

Vale dizer o óbvio para não parecer perseguição à ferramenta: planilha é ótima para cálculo, para orçamento paramétrico, para comparar alternativas. O problema não é o Excel. O problema é usar um artefato de cálculo como fonte de estado de um processo vivo. Estado precisa de dono e de carimbo de tempo automático. Célula não tem nem um nem outro.

O que precisa estar registrado em cada etapa?

Cinco campos resolvem a maior parte das perguntas que um sócio faz numa reunião de segunda-feira.

O campo de responsável técnico merece atenção porque é o único com consequência jurídica:

“Art. 1º – Todo contrato, escrito ou verbal, para a execução de obras ou prestação de quaisquer serviços profissionais referentes à Engenharia, à Arquitetura e à Agronomia fica sujeito à ‘Anotação de Responsabilidade Técnica’ (ART).”
— Lei nº 6.496/1977

Para arquitetos e urbanistas, o instrumento equivalente é o RRT, do CAU. O ponto de gestão — e aqui falamos de registro, não de prática profissional — é que esses documentos têm prazo relativo à atividade: no caso do RRT, o CAU orienta que atividades do grupo Execução sejam registradas antes do início, e as demais, até o término. Ou seja: a emissão está atrelada a uma etapa e a uma data. Se a etapa não tem data registrada em lugar nenhum, o controle da responsabilidade técnica também não tem.

Por que a compatibilização entre disciplinas é onde o cronograma quebra?

Porque ela é a única etapa cujo insumo não pertence a quem executa.

Arquitetura, estrutural, hidráulica e elétrica avançam em ritmos próprios e sobre versões próprias. A compatibilização só pode acontecer quando as quatro estão numa revisão coerente entre si. Basta uma disciplina entregar R02 enquanto as outras trabalham sobre R01 para que o resultado seja uma lista de interferências que não descreve o projeto real — descreve o descompasso de versões.

O sintoma clássico é a reunião de compatibilização que termina sem decisão porque “o estrutural mandou uma versão nova ontem”. O cronograma não quebrou na compatibilização. Quebrou antes, quando ninguém registrou que a revisão do estrutural invalidava a base da elétrica.

O que torna isso controlável é modesto e chato: cada disciplina com etapa própria, cada etapa com número de revisão visível, e uma dependência explícita entre elas. Não é método de engenharia — é registro. A decisão técnica sobre como compatibilizar continua sendo do coordenador de projetos. O que muda é que ele para de descobrir o desencontro na reunião.

E quando o prazo está na prefeitura ou na concessionária?

Sim, esse prazo não é seu. Análise em prefeitura, aprovação no corpo de bombeiros, viabilidade junto à concessionária — nada disso responde ao seu cronograma interno, e prometer data para o cliente sobre esse trecho é assumir risco de terceiro.

Mas “fora do controle” não é o mesmo que “fora do registro”. Três coisas continuam sendo suas:

• A data de protocolo. Quando o processo entrou, com número.
• O estado atual. Em análise, exigência emitida, exigência respondida, deferido.
• O relógio da bola em quadra. Quanto tempo o processo está parado do lado de lá — e, principalmente, quanto tempo ficou parado do lado de cá esperando alguém responder a uma exigência.

Essa última é a que dói. Escritório costuma culpar o órgão pelo atraso e, quando o histórico existe, descobre que uma parte relevante do tempo foi de exigência recebida e não respondida. Sem registro, essa conversa é impossível de ter — com o cliente e internamente.

Aprovação externa, portanto, entra no controle como etapa de espera com dono e data de protocolo, não como buraco no cronograma.

Por que “% concluído” não funciona em projeto — e o que colocar no lugar?

Sim, o percentual é confortável: dá um número único para o cliente e cabe numa barra. O problema é que ele não é observável. Ninguém consegue verificar se um anteprojeto está 60% ou 75% pronto. O número sai da percepção de quem responde, e percepção infla perto do prazo.

Pior: percentual esconde retrabalho. Um projeto a 80% que recebe uma mudança de programa volta para 40%, mas quase nunca alguém baixa o número na frente do cliente. Ele sobe, trava em 90% e fica lá por semanas — o famoso “noventa por cento eterno”.

O que substitui é discreto e verificável: etapa atual e etapa seguinte; revisão corrente; status de aprovação; data prometida versus data efetiva; tempo em espera externa, separado do tempo de produção interna.

Nenhum desses é opinião. Todos podem ser conferidos por alguém de fora.

O que muda quando a etapa vira status com data e dono?

Muda a direção do fluxo de informação. Hoje o coordenador busca o estado: abre pasta, procura e-mail, pergunta no grupo. Quando a etapa é status, o estado se publica sozinho — porque quem move o trabalho move o status, e é o mesmo gesto.

Três efeitos práticos aparecem. A reunião de coordenação deixa de ser levantamento de estado e passa a ser decisão sobre exceção. O histórico passa a existir: data prometida e data efetiva, acumuladas por dezenas de etapas, formam a única base honesta para dimensionar a próxima proposta. E a pergunta do sócio tem resposta em segundos.

Uma ressalva séria, para não vender mágica: se a planilha continuar existindo em paralelo e funcionando, ela vence. Sempre. O hábito antigo é mais confortável, e o registro novo sempre tem uma etapa a mais no começo. A migração só se sustenta quando a planilha de controle é desativada de fato — não quando é mantida “por garantia”. Duas fontes de verdade produzem zero fontes de verdade.

E vale o limite de escopo: nada disso substitui coordenação técnica. Definir o que caracteriza um anteprojeto concluído, decidir uma interferência entre estrutural e hidráulica, avaliar exigência de órgão — isso é competência do responsável técnico. O que se descreve aqui é o registro do processo, não a prática de projeto.

Resumo

Se o seu controle de etapas hoje é uma planilha, comece mapeando uma etapa

Não é preciso redesenhar o escritório inteiro para testar isso. Pegue uma etapa — normalmente o PL, porque concentra espera externa — e registre nela os cinco campos. Rode com os projetos que estiverem nessa etapa por um ciclo. Se a pergunta “como está?” passar a ter resposta sem abrir pasta, o modelo se sustenta para as demais.

A Audatia é consultoria de tecnologia para operação e ajuda escritórios a desenhar esse registro — quais etapas viram status, o que cada uma exige, como as disciplinas se relacionam e o que fica visível para o cliente. Trabalhamos com ClickUp e monday.com, e a escolha da plataforma vem depois do desenho do processo, nunca antes.

Escritório de engenharia ou arquitetura? A página gestão para escritórios de engenharia e arquitetura reúne como a Audatia estrutura etapas, revisão, aprovação de cliente e horas por contrato.