Checklist de maturidade e aprovação do projeto básico antes da licitação: escopo, documentos, orçamento, riscos, compatibilização e aceite.
Confira!
Antes de licitar ou contratar uma obra, a pergunta mais importante não é apenas quanto ela vai custar. A pergunta central é: o projeto básico está maduro o suficiente para sustentar uma contratação segura?
Um projeto básico incompleto pode gerar propostas incomparáveis, orçamento inconsistente, falhas de escopo, aditivos, pleitos, retrabalho e paralisações. Por outro lado, um projeto básico bem estruturado permite que o contratante defina o que será executado, estime custos com mais segurança, organize o cronograma, aloque riscos e fiscalize a entrega com critérios objetivos.
Este checklist de projeto básico complementa o artigo Projeto básico não é formalidade e ajuda gestores, engenheiros, áreas de compras e donos de empreendimentos a decidir se a obra está pronta para licitação, tomada de preço ou contratação direta.
Por que aplicar um checklist antes da contratação?
Contratar uma obra sem verificar a maturidade do projeto básico é transferir incerteza para a execução. O canteiro não deve ser o lugar onde o contratante descobre que faltavam levantamentos, que os quantitativos estavam incompletos, que as disciplinas não estavam compatibilizadas ou que o orçamento não representava a solução real.
O IBRAOP define o projeto básico como o conjunto de elementos técnicos necessários e suficientes para caracterizar a obra, estabelecer dimensões, especificações, quantidades, custos e tempo de execução. O TCU reforça que o orçamento é peça de fechamento do projeto e serve como referência para análise de exequibilidade, economicidade, medição, fiscalização e alterações de escopo.
Checklist de projeto básico: 15 pontos essenciais
1. O problema ou necessidade está claramente definido?
Antes de desenhar a solução, é preciso definir o problema, os objetivos do empreendimento, os requisitos do usuário, as restrições de operação e os resultados esperados. Em empreendimentos complexos, essa etapa pode exigir FEL em projetos de engenharia.
2. Existem estudos preliminares e análise de viabilidade?
O projeto básico deve ser elaborado com base em estudos que sustentem a solução escolhida. Verifique se existe análise de viabilidade técnica, diagnóstico da situação atual, avaliação de alternativas e restrições do empreendimento.
3. Os levantamentos de campo são suficientes?
Levantamentos topográficos, cadastrais, inspeções, sondagens, medições, registros fotográficos, interferências e restrições de acesso precisam ser compatíveis com o risco da obra. Em infraestrutura tecnológica, elétrica, telecomunicações e segurança eletrônica, o site survey é decisivo.
4. O escopo está descrito de forma objetiva e contratável?
Escopo contratável é aquele que permite ao fornecedor entender o que será executado, quais entregáveis serão exigidos, quais responsabilidades estão incluídas e quais limites devem ser respeitados. Escopos genéricos dificultam a comparação de propostas e aumentam o risco de aditivos.
5. O memorial descritivo explica a solução e suas premissas?
O memorial descritivo deve explicar a solução técnica, justificar escolhas, indicar normas aplicáveis, registrar premissas e complementar os desenhos. Um memorial superficial fragiliza a fiscalização e a gestão contratual.
6. As especificações técnicas são claras e verificáveis?
As especificações devem definir materiais, equipamentos, sistemas, padrões de instalação, desempenho esperado, métodos executivos, normas aplicáveis e critérios de aceitação. Isso é essencial em instalações elétricas de baixa tensão, cabeamento estruturado, segurança eletrônica, SPDA, climatização e data centers.
7. Os desenhos e documentos gráficos são suficientes?
Plantas, cortes, diagramas, detalhes, layouts, unifilares e diagramas de blocos devem caracterizar a solução e orientar orçamento, contratação e execução. Em projetos multidisciplinares, o BIM para compatibilização de projetos pode reduzir interferências.
8. As disciplinas técnicas foram compatibilizadas?
Civil, arquitetura, elétrica, hidráulica, incêndio, telecomunicações, automação, segurança eletrônica, climatização e infraestrutura de TI precisam estar coordenadas. Em data centers e ambientes críticos, essa compatibilização é ainda mais importante.
9. Os quantitativos possuem memória de cálculo?
Quantitativos sem memória de cálculo tornam o orçamento difícil de verificar. A memória deve permitir rastrear como cada quantidade foi levantada, com base em quais desenhos, critérios e unidades de medição.
10. O orçamento é analítico e defensável?
O orçamento deve conter composições de custos unitários, BDI, encargos, curva ABC, premissas, cotações e memórias. Se o orçamento não é defensável, uma auditoria técnica de engenharia pode identificar omissões e inconsistências antes da contratação.
11. O cronograma físico-financeiro é realista?
O cronograma deve refletir a sequência real de execução, interfaces, dependências, aprovações, compras críticas, mobilização, marcos de medição e caminho crítico. Ele não deve ser apenas uma tabela documental.
12. Os critérios de medição, pagamento e aceite estão definidos?
Critérios de medição e pagamento evitam discussões sobre avanço físico, qualidade, escopo entregue e valores devidos. Em sistemas técnicos, os critérios de aceite devem incluir testes, documentação, certificações e validação de desempenho.
13. Licenças, aprovações e responsabilidades técnicas foram tratadas?
Licenças, aprovações, ARTs, RRTs, anuências, concessionárias, Corpo de Bombeiros e demais entidades competentes devem ser avaliadas antes da contratação, sempre que aplicável. Pendências deixadas para depois podem bloquear a execução.
14. Existe matriz de riscos?
A matriz de riscos deve identificar eventos que podem afetar custo, prazo, qualidade, segurança e operação, indicando responsáveis e medidas de mitigação. Esse ponto se conecta diretamente com Owner’s Engineering e apoio técnico à contratação.
15. O projeto está pronto para receber propostas comparáveis?
O teste final é simples: fornecedores diferentes conseguem orçar o mesmo escopo, com as mesmas premissas e responsabilidades? Se a resposta for não, o projeto ainda precisa de revisão, compatibilização ou due diligence técnica.
Quando contratar uma revisão independente?
A revisão independente de projeto deve ser considerada antes de licitar, contratar, retomar uma obra, validar orçamento ou comparar propostas. Ela é especialmente recomendada quando há múltiplas disciplinas, ambiente crítico, alto CAPEX, prazo restritivo, integração de sistemas ou histórico de aditivos.
Quando há necessidade de formalizar achados e recomendações, a análise pode ser complementada por pareceres técnicos.
Diagnóstico inicial da prontidão para contratar
O projeto básico é a base técnica da contratação. Quando ele está completo, o contratante consegue comparar propostas, controlar orçamento, fiscalizar execução e gerir mudanças com mais segurança. Quando ele está incompleto, a obra começa carregando riscos que normalmente aparecem como aditivos, pleitos, atrasos ou paralisações.
A validação deve documentar quais informações autorizam a contratação, quais requerem esclarecimento técnico e quais impedem avançar. O parecer precisa ser inteligível para engenharia, compras e gestores do empreendimento, separando riscos de especificação, orçamento, interface, prazo e responsabilidade.
| Item decisivo | Evidência mínima | Se não atender |
| Escopo e requisitos | Matriz de necessidades e especificações | Revisar escopo e critérios |
| Levantamentos | Cadastro, medições e condições existentes | Complementar visita e diagnóstico |
| Engenharia | Desenhos, memoriais e cálculos compatibilizados | Corrigir interfaces |
| Quantitativos e orçamento | Memórias e planilha conciliadas | Revisar quantitativos e preços |
| Prazo e implantação | Cronograma e restrições operacionais | Replanejar execução |
| Riscos e responsabilidades | Matriz de riscos e interfaces | Atribuir donos e mitigações |
| Critérios de aceite | Ensaios, documentação e recebimento | Definir antes do edital |
Matriz de documentos: como reconhecer uma pendência impeditiva
Um checklist de aprovação precisa indicar não só se o arquivo existe, mas se sua informação sustenta a licitação. A simples presença de uma planta, planilha ou memorial não prova coerência entre essas peças. Uma planta que prevê circuitos adicionais e um orçamento que não contempla cabos ou dispositivos associados ilustram uma falha de interface que deve ser tratada antes da comparação de propostas. Cada verificação precisa identificar o documento, sua versão, o responsável e a evidência de compatibilização.
O projeto básico precisa ser estruturado com requisitos, critérios de dimensionamento e informações de campo. O serviço de Projeto Básico organiza os documentos e interfaces para tornar a contratação tecnicamente verificável.
Pendências podem ser classificadas por consequência. Uma ausência que impede definir quantitativos, limites físicos, desempenho ou riscos relevantes tende a bloquear o avanço. Uma pendência documental sem impacto na formação do preço ou na execução pode permitir correção controlada, desde que o contratante registre responsabilidade e prazo. Essa classificação deve ser fundamentada, não uma autorização genérica para contratar com dados incompletos. A equipe de engenharia precisa avaliar como cada lacuna pode modificar preço, prazo, método ou segurança.
Os requisitos de informação incluem escopo e entregáveis de cada disciplina, levantamentos e premissas, desenhos, especificações, orçamento, cronograma, licenças e condições de recebimento. É recomendável trabalhar com uma matriz que indique o que deve existir, o que foi entregue, o que está adequado e o que precisa de ação. Uma coluna de evidência pode apontar para a revisão aprovada do documento, evitando que decisões posteriores dependam de mensagens dispersas ou de uma versão substituída.
A etapa de revisão independente deve transformar o checklist em decisões. Não é suficiente identificar vinte inconformidades sem registrar prioridade e consequência contratual. Para cada item, descreva o risco, a disciplina, o prazo para correção e o profissional que fará a validação. Quando várias pendências decorrem da mesma premissa, é preferível revisar a arquitetura antes de corrigir uma sequência de documentos que provavelmente será descartada.
Verificação cruzada de orçamento, quantitativos e escopo contratual
O orçamento deve poder ser reconciliado com desenhos, memoriais e especificações. As quantidades de equipamentos, cabos, painéis, obras civis e testes precisam possuir origem identificável e método de medição. Uma planilha analítica sem memória de cálculo pode parecer precisa, mas esconder omissões. O checklist deve verificar unidades, quantitativos, composição de preços, custos indiretos, exigências de mobilização e condições de execução. A rastreabilidade permite que licitantes orcem a mesma solução.
Em infraestrutura tecnológica, as diferenças de escopo podem aparecer em itens de baixo valor unitário e alto impacto de implantação: suportes, fibras, bandejas, eletrocalhas, conectores, identificação, ensaios, software, licenças, acessórios e integração. Um projeto de CFTV pode especificar câmeras e esquecer armazenamento ou rede; uma instalação de baixa tensão pode quantificar quadros e ignorar ajustes e testes de proteção. É preciso avaliar o sistema completo e as dependências, não apenas equipamentos principais.
Uma divergência entre memorial, desenho e orçamento exige uma decisão formal de qual informação deverá prevalecer e como as demais serão atualizadas. Não é adequado esperar que os participantes interpretem lacunas de maneiras diferentes para depois negociar ajustes. Caso o escopo dependa de condicionantes de campo, o contratante deve definir levantamentos adicionais, parâmetros de preço e distribuição de riscos aplicável. O projeto precisa permitir comparação técnica e econômica, preservando a possibilidade de identificar propostas inexequíveis ou com exclusões relevantes.
A avaliação do cronograma deve distinguir fornecimentos longos, aprovações, mobilização, desligamentos, acesso às instalações e testes de aceite. Uma proposta de prazo pode ser inviável mesmo que os quantitativos estejam corretos se não contempla janelas operacionais ou liberações. O checklist deve cruzar o cronograma com interfaces e etapas de contratação, inclusive quando houver dependência de concessionárias, licenciamento ou terceiros.
Compatibilização entre disciplinas e maturidade do projeto básico
Um projeto básico pode conter documentos individualmente bem elaborados e ainda ser inadequado ao empreendimento. A análise das interfaces entre elétrica, redes, arquitetura, estruturas, climatização, automação e segurança deve verificar se as soluções podem coexistir e ser implantadas. A compatibilização não significa somente detectar colisões geométricas. Ela inclui revisar cargas, capacidade disponível, espaços técnicos, trajetos, segurança de pessoas, procedimentos de operação e responsabilidade por equipamentos compartilhados.
A revisão independente identifica incoerências entre disciplinas, premissas, quantitativos e condições contratuais antes que sejam transferidas para a obra. O Design Review documenta os riscos e as decisões necessárias para amadurecer o empreendimento.
Quando a solução inclui UPS, geradores, CFTV, controle de acesso ou redes industriais, os requisitos de continuidade precisam ser consistentes entre disciplinas. Um sistema pode declarar disponibilidade elevada e ainda depender de um único quadro ou enlace. A matriz de interface deve indicar origem de alimentação, pontos de conexão, caminhos de comunicação, necessidades de proteção, integração e falhas que precisam ser verificadas. O objetivo é impedir que cada fornecedor suponha que a outra disciplina providenciará um elemento essencial.
O nível de detalhamento adequado depende do objeto e do regime de contratação. O projeto básico deve conter elementos suficientes para definir, dimensionar e avaliar a obra, mas não significa antecipar indiscriminadamente todo o detalhamento executivo. O contratante precisa identificar o que é requisito de desempenho, o que deve estar especificado e quais decisões serão desenvolvidas na fase seguinte. A legislação aplicável pode admitir diferentes configurações contratuais, que exigem avaliação específica; não existe uma lista universal que dispense análise jurídica e técnica.
A validação deve incluir quem utiliza e mantém o ativo. Espaços de manutenção, acessos, substituição de equipamentos e procedimentos de interrupção podem mudar decisões de projeto. Um quadro ou rack localizado em espaço inacessível talvez atenda ao layout em planta, mas comprometa operação e manutenção. Revisar a solução com usuários e responsáveis por segurança pode evitar mudanças custosas depois do início da implantação.
Matriz de risco, responsabilidades e decisão de avanço
A matriz de risco deve relacionar eventos e consequências concretos, não somente expressões genéricas como atraso, sobrecusto ou falha de fornecedor. É preciso identificar causa, probabilidade ou cenário, impacto, responsável pela mitigação, controle existente e risco residual. Podem aparecer atrasos de licenças, subdimensionamento elétrico, ausência de projeto de drenagem, divergências de quantitativos, indisponibilidade de área, dependência tecnológica e interferências com instalações em operação. A análise orienta quais requisitos precisam ser resolvidos antes do edital.
Ao definir responsabilidades, diferencie quem produz o projeto, quem revisa, quem aprova, quem contrata, quem fiscaliza e quem recebe. A mesma organização pode desempenhar várias funções, mas a atribuição precisa ser explícita. Um integrador responsável por fornecimento de equipamentos não deve receber implicitamente a responsabilidade por uma infraestrutura civil cuja definição ficou ausente. Essa fronteira deve estar documentada na matriz de interfaces e nas condições contratuais.
Em contratos públicos, a Lei 14.133/2021 estabelece regras para planejamento e definição do projeto básico, mas os requisitos dependem do objeto, da modalidade e do regime de execução. A revisão precisa confrontar o processo com as exigências legais concretas, sem presumir que determinada prática privada substitui controles formais. A orientação técnica do IBRAOP ajuda a detalhar documentos de engenharia, mas deve ser distinguida da lei e de regulamentos obrigatórios.
A decisão final pode assumir três resultados: aprovado para contratação, aprovado com condições formalmente tratadas ou devolvido para maturação. O resultado deve ser acompanhado por evidências e responsável. A condição não pode ocultar lacuna que torne o orçamento incomparável ou o objeto indefinido. Em situações críticas, adiar o edital para corrigir requisitos é uma decisão de engenharia e governança, não apenas um atraso administrativo.
Aplicação prática do checklist: exemplo de infraestrutura tecnológica
Considere uma contratação que inclui rede estruturada, câmeras IP, controle de acesso e adequações elétricas em uma unidade ocupada. O primeiro passo é confirmar os objetivos: quantidade e função dos pontos, áreas protegidas, requisitos de gravação, usuários, interfaces e disponibilidade. O segundo é analisar o levantamento das instalações existentes, incluindo racks, caminhos, capacidade de energia e redes. Sem esses dados, os fornecedores não conseguem dimensionar materiais, mão de obra e interrupções sobre uma referência comum.
O checklist deve verificar a correspondência entre planta, lista de pontos, topologia de rede, especificação de câmeras e controladoras, quantitativos e memória orçamentária. Se a solução requer alimentação de backup, o escopo precisa indicar quais equipamentos terão autonomia e em quais condições. Se há integração com sistemas existentes, devem estar documentados protocolos, versões, responsabilidades e ensaios. O projeto não pode transferir à execução a definição das interfaces essenciais sem regras claras.
Na fase de preparação da obra, a equipe precisa de cronograma que considere acesso a áreas, segurança, horários de intervenção, proteção das operações e testes por etapas. O orçamento deve prever infraestrutura temporária, recuperação de acabamentos e identificação, quando pertinentes. A especificação precisa incluir requisitos de ensaio e certificação dos enlaces e testes funcionais dos sistemas de segurança, além de documentação As-Built.
O recebimento deve comprovar que cada sistema e suas integrações funcionam de acordo com critérios verificáveis. Esse exemplo mostra a diferença entre uma lista de materiais e um projeto contratável: o segundo vincula funções, interfaces, quantidades, responsabilidades, verificação e documentação. Uma proposta pode atender à lista de equipamentos e ainda não fornecer a solução completa se esses vínculos não foram estabelecidos.
Documentação de aprovação e gestão de versões
Uma revisão técnica deve registrar identificadores de documentos, revisões, datas, autores, responsáveis pelas verificações e estado de aprovação. O uso de documentos sem controle de versão pode levar a orçamento baseado em uma configuração e execução orientada por outra. Quando um documento é reemitido, as peças relacionadas precisam ser analisadas para determinar se também exigem atualização. Essa disciplina é especialmente importante para projetos executados por múltiplas empresas e contratações por pacotes.
Quando diferentes fornecedores compartilham responsabilidades, requisitos e interfaces precisam ser organizados de forma integrada. O planejamento técnico relaciona riscos, escopo e critérios de verificação antes da contratação.
O parecer final não deve se limitar a marcar itens como presentes ou ausentes. Deve indicar quais condições impedem a contratação, quais pendências podem ser corrigidas de maneira controlada e quais riscos foram aceitos. Para fundamentar a decisão, convém anexar matriz de interfaces, quadro de quantitativos críticos, comentários de projeto e lista de premissas. O resultado precisa permitir que um gestor compreenda por que o projeto está maduro o suficiente ou por que não está.
Após a publicação do edital ou envio da solicitação de propostas, esclarecimentos técnicos que afetem preço, prazo ou escopo devem seguir o processo previsto e alcançar todos os participantes nas condições pertinentes. Ajustes informais podem comprometer comparabilidade e produzir disputas posteriores. O processo de controle de mudanças precisa preservar a origem da dúvida, a decisão tomada e os documentos atualizados.
Com o início da execução, o checklist continua útil como referência para fiscalizar e receber. Cada requisito aprovado deve estar relacionado a um produto contratual e a um teste ou evidência. Mudanças de campo devem ser avaliadas contra essa linha de base, com registro da decisão e de seus impactos. Assim, o checklist deixa de ser apenas uma ferramenta pré-licitação e se torna parte do encadeamento entre planejamento, contrato, execução e aceite.
Como concluir o parecer de prontidão da contratação
O parecer de maturidade precisa esclarecer quais documentos foram examinados, quais revisões estavam vigentes, quais disciplinas participaram e quais limitações permaneceram. Uma avaliação realizada somente sobre arquivos eletrônicos pode não revelar a condição real de um retrofit ocupado. Por isso, as conclusões devem separar evidência documental, observação direta e premissa ainda não verificada. Essa distinção evita transmitir uma confiança incompatível com as informações disponíveis.
Em contratações multidisciplinares, a análise deve priorizar interfaces que frequentemente provocam aditivos: energia para equipamentos especiais, infraestrutura de telecomunicações, espaços técnicos, interferências civis, licenças e requisitos de integração. A equipe precisa conferir se o orçamento contempla acessórios, configuração, testes e documentação. A ausência de um componente de baixo custo pode exigir interrupções e retrabalho cujo impacto supera o preço do item omitido.
Nem todos os documentos possuem o mesmo peso na tomada de decisão. Uma inconsistência em proteção de pessoas ou capacidade de alimentação tem consequência diferente de ajuste de nomenclatura sem efeito no preço ou na execução. O checklist deve explicitar o impacto da falha e a necessidade de julgamento técnico, evitando que tarefas cosméticas recebam prioridade enquanto dúvidas capazes de comprometer o objeto permaneçam abertas.
Orçamento e cronograma devem compartilhar a mesma estrutura de escopo. Se a planilha distribui serviços por ambiente e a programação os organiza por fornecedor, a correspondência precisa ser documentada. Convém verificar se licenças, mobilização, desligamentos e entregas técnicas estão contemplados nas premissas de prazo. Cronogramas que consideram apenas a instalação física podem ignorar testes, inspeções e aprovações necessários para a entrada em operação.
Na avaliação de modelos de contratação, o responsável precisa demonstrar o que já está definido e quais decisões serão detalhadas depois. Não basta pressupor que o fornecedor resolverá lacunas sem critérios. Quando houver liberdade para propor soluções, os requisitos de desempenho, as interfaces e os ensaios de aceitação devem estar claros. Quando o contratante fixa uma solução, cabe verificar a consistência dos documentos e a justificativa das características exigidas.
O parecer final deve registrar decisão, data, responsável e evidências. Pendências críticas precisam de nova verificação antes do encerramento, enquanto riscos aceitos exigem registro e plano de tratamento. Após a aprovação, o conjunto de documentos se torna a linha de base para esclarecimentos, propostas, fiscalização, mudanças e recebimento. Esse vínculo facilita demonstrar os fundamentos técnicos de ajustes futuros e evita que uma revisão substituída continue orientando a execução.
Uma avaliação de maturidade precisa tratar também a disponibilidade do empreendimento. Instalar novos quadros, racks e sistemas de segurança em edifício ocupado pode exigir planejamento de desligamentos, acesso a salas, rotas provisórias e comunicação com usuários. Se essas condições não aparecem nos documentos, os proponentes podem estimar métodos e custos incomparáveis. O projeto básico deve registrar limitações de intervenção e requisitos de continuidade pertinentes à operação.
Contratos por múltiplos pacotes exigem uma matriz de interfaces entre fornecimentos. A empresa responsável pelo cabeamento pode depender da passagem civil, do aterramento e dos pontos de energia; o fornecedor de VMS pode depender de servidores, licenças e conectividade contratados separadamente. Sem responsabilidades explícitas, o custo de integração pode ser atribuído informalmente a partes distintas. A revisão antes da licitação deve demonstrar quais insumos cada pacote recebe e entrega.
Uma forma de verificar a qualidade do checklist é pedir que profissionais de engenharia, orçamento e fiscalização respondam de maneira independente às mesmas perguntas sobre escopo. Se as interpretações divergem sobre materiais, métodos, fronteiras de responsabilidade ou condições de aceite, há indício de indefinição que merece análise. O objetivo não é eliminar todo risco, mas reduzir ambiguidades previsíveis e estabelecer mecanismos objetivos de controle.
Na revisão final de projetos, recomendações devem ser priorizadas com base no efeito sobre segurança, contratação e desempenho. Ações relativas a dados essenciais precisam ter confirmação de conclusão, e alterações devem atualizar também planilhas e desenhos correlatos. Um checklist fechado formalmente, mas sem controle de correções, não oferece proteção efetiva ao contratante. A qualidade está na rastreabilidade entre problema identificado, decisão, documento atualizado e verificação.
Um checklist pode ser aplicado em diferentes marcos, desde a revisão de viabilidade até a autorização final para publicar o edital. Entretanto, não deve ser utilizado para transferir ao fornecedor decisões que precisam estar fundamentadas na fase de planejamento. Se uma interface crítica permanece indefinida, a equipe deve especificar seu método de resolução e avaliar o impacto na contratação antes de afirmar que o projeto está pronto. O documento de aceite da revisão também deve identificar a autoridade que autorizou a decisão e as condições que permanecerão sujeitas a verificação posterior.
O trabalho pode ser apoiado por modelos BIM, planilhas de controle ou sistemas de gestão documental, mas a ferramenta utilizada não comprova maturidade por si só. O essencial é que requisitos, revisões, riscos e evidências estejam ligados ao escopo e que os diferentes responsáveis possam reconstruir a decisão. Essa abordagem torna a auditoria mais consistente, reduz disputas sobre informações de origem e facilita a verificação de mudanças na execução. A organização deve preservar os documentos e o histórico de aprovações conforme suas obrigações contratuais e legais.
Considerações finais
O checklist de projeto básico protege a contratação quando transforma documentos em evidências de maturidade. A presença de desenhos, memórias e planilhas não basta: eles precisam representar a mesma solução, ser verificáveis e permitir que diferentes proponentes precifiquem o objeto sobre premissas comparáveis. As interfaces entre disciplinas, o tratamento de riscos e os critérios de aceite são tão relevantes quanto o detalhamento de cada peça.
A decisão de licitar deve ser associada ao risco residual que o contratante está disposto e autorizado a assumir. Ausências capazes de alterar substancialmente escopo, quantitativos ou métodos de execução precisam ser corrigidas antes do avanço. Pendências menores podem ser controladas, desde que sua classificação, responsabilidade e prazo estejam claros e em conformidade com o regime contratual. O checklist não é autorização para contratar um projeto incompleto.
A revisão independente contribui quando questiona premissas, confronta desenhos com orçamento e identifica responsabilidades difusas. A utilidade não está na quantidade de achados, mas na capacidade de priorizar correções e demonstrar que as informações necessárias para a contratação foram atendidas. O proprietário preserva assim condições melhores para comparar propostas, fiscalizar mudanças e receber o ativo.
A gestão deve manter o vínculo entre requisito, documento, contratação, execução e teste. Esse encadeamento evita que uma decisão aprovada seja perdida durante substituições e alterações e permite reconstruir o histórico técnico de forma objetiva. Em obras públicas, o atendimento às exigências da Lei 14.133 e dos instrumentos aplicáveis continua necessário, em conjunto com o julgamento de engenharia.
Referências técnicas
[1] BRASIL. Lei nº 14.133, de 1º de abril de 2021. Lei de Licitações e Contratos Administrativos. Brasília, 2021. Disponível em: https://www.planalto.gov.br/ccivil_03/_ato2019-2022/2021/lei/l14133.htm
[2] INSTITUTO BRASILEIRO DE AUDITORIA DE OBRAS PÚBLICAS. OT-IBR 001/2006: Projeto Básico. Florianópolis: IBRAOP, 2006. Em revisão. Disponível em: https://ibraop.org.br/orientacoes-tecnicas/
[3] TRIBUNAL DE CONTAS DA UNIÃO. Orientações para elaboração de planilhas orçamentárias de obras públicas. Brasília: TCU, 2014. Disponível em: https://portal.tcu.gov.br/publicacoes-institucionais/cartilha-manual-ou-tutorial/orientacoes-para-elaboracao-de-planilhas-orcamentarias-de-obras-publicas
[4] INSTITUTO BRASILEIRO DE AUDITORIA DE OBRAS PÚBLICAS. OT-IBR 008/2020: Projeto Executivo. Florianópolis: IBRAOP, 2020. Disponível em: https://ibraop.org.br/orientacoes-tecnicas/
Perguntas frequentes
Verificar se escopo, levantamentos, estudos, desenhos, especificações, orçamento, riscos e condições de aceite são suficientes e coerentes para contratar a obra com base técnica.
Não. É um instrumento de organização; as evidências e decisões precisam ser avaliadas por profissionais competentes e responsáveis pelo objeto.
Quando atende às exigências aplicáveis e possui maturidade suficiente para definir o objeto, comparar propostas, estimar custo e prazo e distribuir responsabilidades de forma verificável.
O projeto básico define e dimensiona a solução para a contratação, dentro das exigências aplicáveis; o executivo detalha elementos necessários à execução. Os limites dependem do objeto e regime contratual.
A responsabilidade técnica e seu registro devem ser avaliados conforme legislação profissional, natureza do trabalho e exigências do processo. Não se pode dar resposta universal sem examinar o caso.
Confronte planilhas com desenhos, memoriais, especificações, interfaces, condições de campo e métodos de medição, registrando a origem de cada quantidade relevante.
Somente quando o tipo de pendência e o regime aplicável permitem avanço responsável. Ausências que tornam objeto, preço ou execução indefinidos exigem correção prévia.
Vincula eventos, consequência, responsáveis e medidas de tratamento, permitindo decisões antes de transferir incertezas para o contrato.
Cria uma linha de base de requisitos e entregáveis contra a qual mudanças de campo, medições, testes e recebimento podem ser confrontados.
Sim, como método técnico de análise de maturidade, adaptado ao regime contratual e às obrigações privadas, sem importar automaticamente regras de licitação pública.
Materiais técnicos complementares
Soluções relacionadas
- Engenharia Consultiva para Empreendimentos
- Engenharia ao Longo do Ciclo de Vida
- Governança de Projetos
Serviços relacionados
Conteúdos principais sobre o tema
- Projeto Básico na Lei 14.133 segundo o TCU
- FEL: maturidade antes de contratar
- Fase Preparatória da Licitação
