Entenda como estruturar uma punch list e matriz de pendências em engenharia, classificar itens, definir responsáveis, validar correções e controlar o aceite técnico.

Confira!

A punch list em engenharia é a relação controlada de pendências, correções, complementações e verificações que permanecem abertas antes do aceite ou encerramento de uma obra, sistema ou pacote de entrega. Em português, o conceito aparece como lista ou matriz de pendências.

Em projetos de engenharia, uma punch list não deve funcionar como simples checklist final. Para sustentar decisões de recebimento e aceite, cada item precisa estar associado a localização ou sistema, requisito, criticidade, responsável, prazo, evidência de correção e condição de baixa.

É nesse ponto que a matriz de pendências amplia a punch list convencional: transforma itens abertos em um instrumento de governança técnica, permitindo distinguir pendências impeditivas, relevantes, menores, documentais e condicionantes e acompanhar sua resolução até o fechamento.

Em termos técnicos, a punch list funciona como uma interface entre execução e aceite. Ela transforma observações de campo, resultados de testes e lacunas documentais em itens verificáveis, com responsabilidade e condição de fechamento definidas.

Uma punch list madura também preserva a relação entre a correção realizada e a configuração final entregue. Se uma pendência altera instalação, parametrização, documentação ou desempenho, o fechamento precisa considerar os reflexos nos testes, no As-Built e nos demais registros que sustentam a entrega técnica.

O que é punch list e como ela se relaciona à matriz de pendências

Matriz de pendências é uma tabela ou registro estruturado que consolida itens ainda não concluídos, não conformes, incompletos, sem evidência suficiente ou dependentes de validação.

Ela pode ser aplicada em obras, sistemas técnicos, projetos executivos, implantação de infraestrutura, comissionamento, serviços consultivos, aceite parcial, aceite final ou encerramento contratual.

Uma boa matriz de pendências deve permitir responder:

  • qual é a pendência;
  • onde ela ocorre;
  • qual requisito não foi atendido;
  • qual é o impacto técnico;
  • quem é o responsável pela correção;
  • qual é o prazo acordado;
  • qual evidência comprovará a correção;
  • se o item impede o aceite;
  • se a entrega pode ser aceita com ressalvas;
  • quando a pendência foi baixada.

Sem esse controle, o encerramento técnico fica vulnerável a interpretações informais.

Lista de pendências, matriz de pendências e punch list

Os termos lista de pendências, matriz de pendências e punch list aparecem em contextos próximos, mas não têm exatamente o mesmo nível de controle.

Uma lista de pendências pode ser apenas uma relação simples de itens abertos. Uma punch list, em obras e comissionamento, costuma registrar itens finais a corrigir antes da entrega. A matriz de pendências acrescenta governança: classifica impacto, responsabilidade, prazo, evidência e status.

InstrumentoCaracterística principal
Lista de pendênciasRelação simples de itens abertos
Punch listLista de itens finais para correção antes da entrega
Matriz de pendênciasRegistro estruturado com impacto, responsável, prazo, evidência e status

Para contratos de engenharia consultiva, implantação técnica e sistemas críticos, a matriz tende a ser mais adequada porque conecta pendência, risco, evidência, aceite e encerramento.

Por que a matriz de pendências é importante no aceite técnico

O aceite técnico raramente ocorre em um cenário absolutamente sem pendências. O ponto central é saber quais pendências são impeditivas, quais são relevantes, quais são documentais e quais podem ser tratadas após aceite com ressalvas.

A matriz de pendências ajuda a evitar dois erros:

  1. aceitar uma entrega com problemas relevantes não tratados;
  2. bloquear o aceite por itens menores que não comprometem a finalidade da entrega.

Ela cria base objetiva para decidir se a entrega pode ser aceita, aceita com ressalvas ou rejeitada tecnicamente.

O artigo sobre Termo de Aceite Técnico em Engenharia aprofunda como essa decisão deve ser formalizada.

Classificação das pendências

Nem toda pendência possui o mesmo impacto.

Uma matriz técnica deve classificar os itens para orientar prioridade, decisão de aceite e responsabilidade de correção.

Pendência impeditiva

É aquela que impede operação, segurança, desempenho mínimo, conformidade essencial ou validação da entrega. Deve bloquear o aceite até correção ou tratamento formal.

Pendência relevante

Não impede necessariamente a operação inicial, mas afeta qualidade, manutenção, documentação, desempenho, confiabilidade ou rastreabilidade. Pode permitir aceite com ressalvas, desde que haja prazo e responsável definidos.

Pendência menor

É um ajuste pontual sem impacto significativo na finalidade da entrega. Ainda assim, deve ser registrada para baixa posterior.

Pendência documental

Envolve ausência, inconsistência ou incompletude de documentos, como as built, manuais, certificados, relatórios de teste, registros fotográficos, boletins de medição ou documentação de comissionamento.

Pendência condicionante

Depende de terceiro, fornecedor, área interna, liberação de acesso, infraestrutura externa, janela operacional ou decisão do contratante.

Essa classificação deve estar alinhada aos critérios de aceite definidos para a contratação.

Campos recomendados para uma matriz de pendências

Uma matriz de pendências deve ser objetiva, mas completa o suficiente para sustentar decisões técnicas.

Campos recomendados:

  • número ou código da pendência;
  • sistema, área, disciplina ou local afetado;
  • descrição objetiva;
  • origem da pendência;
  • requisito ou critério associado;
  • classificação da pendência;
  • impacto técnico;
  • responsável pela correção;
  • prazo;
  • evidência exigida para baixa;
  • status;
  • data de abertura;
  • data de baixa;
  • responsável pela validação;
  • observações ou ressalvas.

Esses campos permitem transformar uma lista informal em instrumento de gestão técnica.

Evidência de correção e baixa da pendência

A pendência não deve ser baixada apenas porque alguém informou que foi resolvida.

A baixa deve estar associada a evidência. Essa evidência pode ser um relatório, teste, fotografia, certificado, ata, checklist, as built revisado, registro de sistema ou nova inspeção.

Em sistemas críticos, a evidência pode exigir teste funcional, revalidação de integração, atualização documental ou registro de comissionamento.

A lógica é simples: a pendência só deve sair da matriz quando houver comprovação suficiente de correção ou quando o contratante aceitar formalmente a ressalva.

Aceite com ressalvas

O aceite com ressalvas é possível quando as pendências não comprometem a finalidade principal da entrega.

Para isso, a matriz deve indicar claramente:

  • quais pendências permanecem abertas;
  • por que elas não impedem o aceite;
  • quem deve corrigi-las;
  • qual prazo foi acordado;
  • qual evidência será exigida;
  • qual condição pode suspender ou limitar o aceite.

Sem esse registro, o aceite com ressalvas pode virar aceite informal, sem controle real de correção.

Matriz de pendências e boletim de medição

A matriz de pendências deve se conectar ao boletim de medição em engenharia consultiva.

O boletim registra o que foi entregue e medido. A matriz registra o que ainda precisa ser corrigido, comprovado ou validado. Juntos, eles ajudam a separar entrega medida, entrega aceita, entrega aceita com ressalvas e entrega pendente.

Essa relação é essencial para evitar pagamentos, encerramentos ou aceites sem evidência técnica suficiente.

Matriz de pendências no comissionamento

Durante o comissionamento, é comum surgirem pendências de configuração, integração, documentação, desempenho, interface, alarmes, automação, treinamento ou operação.

A matriz permite organizar esses itens e vinculá-los a testes, responsáveis e evidências.

Quando a pendência decorre de FAT, SAT ou testes integrados, ela deve referenciar o teste que identificou o problema e o critério que não foi atendido. O conteúdo sobre FAT, SAT e testes integrados complementa esse ponto.

Punch list, As-Built, Data Book e recebimento técnico

A punch list não termina isoladamente. No fechamento técnico de uma obra ou sistema, as correções executadas precisam retornar à documentação, aos testes e às evidências de entrega. Caso contrário, a pendência pode ser considerada resolvida em campo enquanto o As-Built, o Data Book de Obra ou os registros de comissionamento permanecem desatualizados. A baixa de uma pendência precisa, portanto, fechar também a evidência técnica que sustentará o aceite e o handover.

Por isso, a sequência de encerramento deve ser tratada como um fluxo integrado: comissionamento → identificação de pendências → correção → reteste ou verificação → atualização do As-Built → consolidação do Data Book → recebimento técnico → aceite.

EtapaRelação com a punch list
ComissionamentoIdentifica falhas, desvios, configurações e itens que precisam ser corrigidos ou comprovados.
Punch list / matriz de pendênciasControla item, criticidade, responsável, prazo, evidência e condição de baixa.
As-BuiltDeve refletir a configuração final após correções, ajustes e modificações executadas.
Data BookConsolida documentos, testes, certificados, manuais, registros e evidências finais.
Recebimento TécnicoVerifica se execução, desempenho, documentação e pendências permitem subsidiar o aceite.

Essa integração evita um problema recorrente: encerrar a punch list administrativamente sem fechar tecnicamente a informação do ativo. Quando a etapa exige verificação estruturada da execução, dos testes, da documentação e das pendências, o Recebimento Técnico de Obras e Serviços de Engenharia funciona como continuação natural do processo. Quando as correções alteram a condição executada, o As-Built de Engenharia precisa refletir a configuração efetivamente entregue.

Relação com matriz de riscos

Matriz de pendências e matriz de riscos não são a mesma coisa.

A matriz de riscos trata incertezas que podem afetar o projeto. A matriz de pendências trata itens concretos identificados durante execução, comissionamento, aceite ou encerramento.

Ainda assim, elas se conectam. Uma pendência relevante pode gerar risco operacional, contratual, financeiro, documental ou de manutenção. Por isso, pendências críticas podem alimentar ou atualizar a matriz de riscos.

Governança da punch list em contratos de engenharia

Uma punch list eficiente não deve funcionar como uma planilha paralela criada nos últimos dias da obra. Ela precisa estar vinculada ao sistema de controle do contrato, aos requisitos técnicos, aos responsáveis pela execução e aos critérios que determinarão quando cada item poderá ser considerado encerrado.

Esse vínculo evita um problema recorrente: registrar sintomas sem preservar a origem da obrigação. Um item como “corrigir quadro elétrico” é pouco verificável. O registro precisa indicar o quadro, o requisito não atendido, a condição observada, a ação esperada, o responsável, a evidência necessária e a condição objetiva de baixa.

A punch list também não deve absorver indiscriminadamente qualquer assunto aberto do projeto. RFI, não conformidade, solicitação de mudança e pendência de punch list possuem funções diferentes. Misturá-las reduz rastreabilidade e pode transformar uma lista de fechamento em um depósito de decisões ainda não resolvidas.

RegistroFinalidadeQuando usar
Punch listControlar item físico, funcional ou documental pendente de conclusão ou correçãoQuando o requisito já é conhecido e o item precisa ser concluído, corrigido ou comprovado
RFIFormalizar dúvida ou necessidade de esclarecimento técnicoQuando ainda existe incerteza sobre requisito, projeto, interface ou interpretação
Não conformidadeRegistrar desvio comprovado em relação a requisito aplicávelQuando há evidência objetiva de não atendimento que exige tratamento formal
Solicitação de mudançaAvaliar alteração de escopo, requisito, solução, custo ou prazoQuando a ação proposta modifica a baseline ou a obrigação original

Quando uma pendência exige alterar projeto, escopo, prazo ou solução aprovada, o tratamento deve conversar com o processo de Engineering Change Management (ECM). A punch list controla o item aberto; ela não substitui a governança de mudança.

A governança também precisa definir quem possui autoridade para encerrar um item e em quais condições uma pendência pode permanecer aberta sem bloquear um marco. A ABNT NBR ISO 9001:2015 estabelece, para a liberação de produtos e serviços, que os arranjos planejados de verificação precisam ser concluídos e que a informação documentada deve demonstrar conformidade com os critérios de aceitação e identificar quem autorizou a liberação. Para saídas não conformes, a norma prevê controle do desvio, registro das ações adotadas, eventual concessão formal e nova verificação após a correção.

Essa lógica é particularmente importante na transição para Mechanical Completion, comissionamento e handover. A existência de itens abertos não deve ser avaliada apenas pela quantidade. Um único item impeditivo pode bloquear energização, teste ou operação, enquanto dezenas de pendências documentais menores podem ser administradas por plano de fechamento sem inviabilizar determinado marco. O critério deve considerar impacto em segurança, funcionalidade, desempenho, integridade do ativo, conformidade legal, capacidade de testar e possibilidade de operação segura.

Para evitar que itens antigos permaneçam indefinidamente abertos, a matriz também deve controlar aging e escalonamento. Pendências que ultrapassam o prazo ou são reabertas repetidamente precisam subir de nível de gestão, porque normalmente indicam falta de responsável, solução técnica ainda não consolidada, dependência de outra disciplina ou tentativa de encerrar o item sem evidência suficiente. Esse acompanhamento transforma a punch list em instrumento de fechamento técnico, e não apenas em lista de tarefas.

No handover, o objetivo não é chegar a “zero linhas” por pressão administrativa, mas demonstrar que cada pendência foi corrigida, formalmente aceita sob condição autorizada ou transferida para um plano de ação com responsabilidade e risco conhecidos. O handover técnico deve receber uma situação confiável do que está concluído, do que permanece aberto e de quais evidências sustentam cada decisão.

Quando a punch list deve ser aberta

Embora seja frequentemente associada ao encerramento da obra, a punch list não precisa nascer somente na inspeção final. Em empreendimentos complexos, o controle progressivo de pendências reduz o acúmulo de itens no final e evita que problemas fiquem ocultos após fechamento de forros, energização, montagem definitiva, integração de sistemas ou perda de acesso a determinadas áreas.

O momento de abertura depende do tipo de entrega. Pendências podem surgir durante inspeções de execução, verificações de qualidade, pré-comissionamento, FAT, SAT, testes funcionais, testes integrados, revisão documental e inspeções de recebimento. O item deve entrar no fluxo assim que existir evidência suficiente para descrevê-lo de forma objetiva.

Em comissionamento de sistemas, por exemplo, uma falha identificada em teste não deve esperar o encerramento da campanha para ser registrada. Ela precisa ser vinculada ao procedimento que a revelou, ao requisito esperado e à necessidade — ou não — de reteste após a correção.

Como escrever um item de punch list que possa ser verificado

A qualidade do fechamento depende diretamente da qualidade do registro. Uma descrição vaga transfere para a fase de verificação o trabalho de descobrir o que realmente precisava ser corrigido. Um item bem redigido deve ser compreensível por quem executa a correção e por quem posteriormente verificará a baixa.

  1. Identifique o objeto: sistema, equipamento, ambiente, documento ou interface afetada.
  2. Registre a condição observada: descreva o fato sem substituir evidência por opinião genérica.
  3. Relacione o requisito: projeto, especificação, memorial, checklist, procedimento de teste, contrato ou critério de aceite aplicável.
  4. Defina a ação esperada: correção, complementação, ajuste, substituição, atualização documental ou nova verificação.
  5. Defina a evidência de fechamento: fotografia, documento revisado, medição, relatório, teste, certificado ou inspeção.
  6. Defina a condição de baixa: indique o que deverá ser verdadeiro para o item mudar de aberto para encerrado.

Considere um alarme de supervisão que não chega ao sistema central. “Verificar alarme” é uma descrição fraca. Um registro melhor identifica o ponto, informa o cenário de teste, registra o resultado esperado e o observado, aponta a interface envolvida e exige novo teste funcional como evidência de fechamento.

Fluxo de status: abertura, correção, verificação e fechamento

O status de uma pendência não deve refletir apenas quem está trabalhando nela. Ele precisa mostrar em qual etapa de validação o item se encontra. Separar “corrigido” de “fechado” é particularmente importante: a execução da correção pelo responsável não significa que a correção já foi tecnicamente verificada.

StatusSignificado técnico
AbertaPendência identificada e ainda não tratada
Atribuída / em correçãoResponsável definido e ação corretiva em andamento
Pronta para verificaçãoResponsável informa conclusão e apresenta a evidência prevista
ReabertaVerificação constatou correção insuficiente, evidência inadequada ou recorrência
FechadaCritério de baixa atendido e evidência validada
Aceita com ressalvaItem permanece aberto sob condição formalmente aceita, com responsável e prazo definidos

Esse workflow evita a prática de encerrar itens apenas por declaração do executor. Em sistemas sujeitos a teste, a baixa pode exigir repetição do procedimento original. Em documentação, pode exigir nova revisão do arquivo. Em instalações, pode exigir inspeção de campo ou medição.

Reteste, regressão e impacto em outras disciplinas

Nem toda correção termina com a verificação do ponto alterado. Alguns ajustes podem afetar funções que já haviam sido testadas, especialmente em automação, proteção, redes, controle de acesso, CFTV, sistemas de incêndio, supervisão, energia e integrações entre subsistemas.

Nesses casos, o fechamento deve avaliar se existe necessidade de reteste do item e de teste de regressão das funções potencialmente afetadas. Alterar uma lógica de controle para corrigir um alarme, por exemplo, pode exigir nova validação de sequências relacionadas. Substituir um equipamento pode exigir atualização de configuração, identificação, lista de ativos e documentação As-Built.

Quando a origem da pendência está em FAT, SAT ou testes integrados, o registro de baixa deve preservar a relação com o teste original e com o resultado posterior à correção.

Punch list por sistema, área e pacote de entrega

Em projetos com muitas disciplinas, uma lista única tende a perder capacidade de gestão. A estrutura pode ser organizada por sistema, subsistema, área, disciplina, pacote contratual, fornecedor ou etapa de entrega, desde que exista um identificador único que permita consolidar a visão geral do empreendimento.

Essa segmentação ajuda a responder perguntas operacionais importantes: quais sistemas ainda possuem pendências impeditivas? Qual pacote concentra maior quantidade de itens reabertos? Quais documentos impedem a entrega de determinado sistema? Quais áreas estão tecnicamente prontas para recebimento mesmo que o empreendimento completo ainda não esteja encerrado?

A relação com o Recebimento Técnico de Obras e Serviços de Engenharia é direta. O recebimento pode ocorrer por etapa, sistema ou pacote, mas a decisão precisa estar sustentada pela situação real das pendências e pelas evidências de atendimento.

Indicadores úteis para controlar a punch list

Contar apenas o número total de itens abertos pode produzir uma leitura enganosa. Dez pendências impeditivas são mais críticas do que cinquenta ajustes cosméticos. Por isso, indicadores devem ser usados como apoio à decisão, e não como substitutos da análise técnica.

  • quantidade de pendências abertas por criticidade;
  • itens vencidos por responsável ou pacote;
  • tempo médio entre abertura e correção;
  • tempo médio entre correção e verificação;
  • taxa de reabertura;
  • pendências documentais ainda associadas a sistemas fisicamente concluídos;
  • itens impeditivos de comissionamento, recebimento ou operação;
  • evolução do backlog por período.

A taxa de reabertura merece atenção especial. Quando muitos itens retornam para correção, o problema pode estar na qualidade da execução, na descrição inadequada da pendência, em critérios de baixa pouco claros ou na apresentação de evidências insuficientes.

Erros que tornam a punch list ineficaz

Uma punch list perde valor quando vira apenas um inventário de observações. Os erros mais comuns estão ligados à ausência de critério de verificação e à falta de integração com os demais registros do projeto.

  • descrições genéricas que não identificam requisito nem condição observada;
  • ausência de responsável e prazo;
  • classificação de criticidade sem critérios definidos;
  • baixa realizada apenas por informação do executor;
  • correções que não retornam ao As-Built ou aos documentos de configuração;
  • pendências de escopo tratadas como se fossem simples correções;
  • itens duplicados em planilhas, atas e plataformas diferentes;
  • lista criada apenas no final, quando parte das áreas já não pode ser facilmente reinspecionada;
  • aceite com ressalvas sem prazo, responsável e evidência futura definida.

O objetivo final não é zerar uma planilha. É demonstrar, com rastreabilidade, que os itens relevantes foram tratados e que aquilo que permanece aberto está claramente conhecido, classificado e formalmente condicionado.

Conclusão

A matriz de pendências é essencial para organizar itens abertos durante comissionamento, aceite técnico e encerramento contratual.

Ela permite classificar pendências, definir responsáveis, registrar prazos, exigir evidências, controlar baixa e decidir se a entrega pode ser aceita, aceita com ressalvas ou rejeitada tecnicamente.

Quando bem estruturada, a matriz de pendências reduz subjetividade, melhora a rastreabilidade e fortalece a governança da entrega.

Em engenharia, pendência não deve ser memória de reunião. Deve ser registro técnico, com impacto, responsável, prazo, evidência e condição de baixa.

Regra prática de fechamento: uma pendência corrigida ainda não é necessariamente uma pendência fechada. O encerramento exige evidência compatível com o critério de baixa e, quando aplicável, reteste, atualização documental e verificação dos impactos em outras interfaces.

Referências técnicas

[1] PROJECT MANAGEMENT INSTITUTE. Construction Extension to the PMBOK® Guide. Disponível em: PMI. Acesso em: 12 ago. 2026.

[2] PROJECT MANAGEMENT INSTITUTE. Project Closing. Disponível em: PMI. Acesso em: 12 ago. 2026.

[3] AACE INTERNATIONAL. Recommended Practices. Disponível em: AACE International. Acesso em: 12 ago. 2026.

Perguntas frequentes
O que é matriz de pendências em engenharia?

É um registro estruturado que consolida pendências técnicas, responsáveis, prazos, impactos, evidências de correção e status de validação durante implantação, comissionamento, aceite ou encerramento contratual.

Qual é a diferença entre lista de pendências e matriz de pendências?

A lista apenas relaciona itens abertos. A matriz acrescenta classificação, impacto técnico, responsável, prazo, evidência exigida, status e condição de baixa.

O que é punch list?

Punch list é uma expressão usada para lista de itens pendentes a corrigir antes da entrega ou aceite final. Em engenharia, pode ser estruturada como matriz de pendências para maior rastreabilidade.

Uma entrega pode ser aceita com pendências?

Pode ser aceita com ressalvas quando as pendências não comprometem a finalidade da entrega e quando há responsável, prazo e evidência de correção definidos.

Como dar baixa em uma pendência técnica?

A baixa deve ocorrer após evidência de correção, como teste, registro fotográfico, relatório, checklist, documento revisado ou validação formal pelo responsável técnico.

Materiais técnicos complementares

Soluções relacionadas

Serviços relacionados

Conteúdos principais sobre o tema

Conteúdos técnicos correlatos