Veja como o TCU avalia o Projeto Básico na Lei 14.133, quais deficiências aparecem em auditorias e quais evidências técnicas reduzem riscos na licitação e execução.
Confira!
O Projeto Básico na Lei 14.133, quando analisado pela ótica do Tribunal de Contas da União, não é apenas um estágio de desenvolvimento do projeto: é uma das principais evidências de que a Administração definiu, dimensionou, orçou e tornou contratável a solução antes de submetê-la ao mercado. O TCU registra que projetos básicos incompletos, deficientes ou desatualizados aparecem com frequência nas auditorias de obras públicas e podem comprometer preço, prazo, competição, execução, funcionamento e durabilidade do empreendimento.
Por isso, a pergunta deste artigo não é “o que é Projeto Básico?”. Essa abordagem conceitual é tratada em conteúdo específico da A3A. Aqui, o foco é outro: o que a Lei 14.133 exige, o que o TCU verifica e quais falhas técnicas podem se transformar em achados de auditoria, aditivos, pleitos, paralisações ou responsabilização.
Sob essa régua, um Projeto Básico pode ter plantas, memoriais, especificações e planilhas e ainda assim ser insuficiente. A suficiência depende da coerência entre esses elementos, da rastreabilidade das decisões e da capacidade de o conjunto documental permitir propostas comparáveis, orçamento confiável, definição de métodos e prazo, fiscalização e controle de mudanças.
A régua do TCU para o Projeto Básico
O Manual de Licitações e Contratos do TCU trata o Projeto Básico como um dos elementos mais importantes tanto para a licitação quanto para a execução de obras públicas. A razão é direta: ele define detalhadamente o objeto a ser licitado e o respectivo custo, funcionando como conexão entre planejamento, orçamento, edital e futura execução contratual.
O art. 6º, XXV, da Lei 14.133/2021 estabelece que o Projeto Básico deve reunir elementos necessários e suficientes, com nível de precisão adequado para definir e dimensionar a obra ou serviço, elaborado a partir das indicações dos estudos técnicos preliminares, de modo a assegurar viabilidade técnica, adequado tratamento dos impactos ambientais, avaliação de custo e definição dos métodos e do prazo de execução.
O TCU traduz esse comando em seis grupos centrais de informação:
- levantamentos e dados necessários à solução escolhida;
- soluções técnicas globais e localizadas suficientemente detalhadas;
- identificação dos serviços, materiais e equipamentos e respectivas especificações;
- informações para definição de métodos construtivos, instalações provisórias e condições organizacionais;
- subsídios para plano de licitação e gestão da obra;
- orçamento detalhado fundamentado em quantitativos propriamente avaliados, quando exigido pelo regime de execução.
Esses grupos não devem ser lidos como seis arquivos independentes. Para fins de controle, interessa verificar se formam um baseline técnico coerente. Se um levantamento contradiz o desenho, se o desenho não sustenta o quantitativo, se o quantitativo não sustenta o orçamento ou se a especificação altera o desempenho considerado na solução, o processo apresenta uma ruptura de rastreabilidade.
A consequência é que a auditoria não se limita à pergunta “o documento existe?”. A análise precisa alcançar “o documento demonstra tecnicamente a decisão e permite controlar o contrato?”.
Projeto Básico não deve substituir o planejamento que deveria existir antes dele
A Lei 14.133 estrutura a fase preparatória a partir do planejamento. O Projeto Básico deve decorrer de uma necessidade já caracterizada e de uma solução tecnicamente selecionada. Quando o processo chega ao Projeto Básico ainda discutindo qual problema será resolvido, qual capacidade é necessária ou qual alternativa será adotada, existe um problema de maturidade anterior ao próprio projeto.
Esse encadeamento é importante porque a deficiência de uma etapa costuma reaparecer na seguinte. Um ETP superficial produz requisitos incompletos. Requisitos incompletos levam a levantamentos insuficientes. Levantamentos insuficientes contaminam o projeto. Projeto contaminado produz quantitativos frágeis. Quantitativos frágeis geram orçamento pouco confiável. O orçamento e o escopo mal definidos chegam ao edital e são finalmente precificados pelos licitantes.
Assim, o controle do Projeto Básico começa por sua origem. A equipe de revisão deve conseguir rastrear:
- qual necessidade pública motivou a contratação;
- qual solução foi selecionada e por quê;
- quais premissas e restrições foram herdadas do planejamento;
- quais dados de campo sustentaram o desenvolvimento do projeto;
- quais decisões ainda permanecem abertas;
- como essas decisões impactam custo, prazo, quantidade, desempenho ou risco.
Quando uma decisão material permanece aberta e pode alterar o objeto, o processo não deve tratá-la como simples “detalhamento executivo”. Essa distinção é central na jurisprudência do TCU.
Falha 1 — levantamentos insuficientes antes da licitação
Quando o problema nasce da falta de informação de campo, a correção deve ocorrer antes da licitação. Levantamentos cadastrais reduzem premissas frágeis e tornam o objeto mais mensurável.
A primeira classe de deficiência ocorre quando o Projeto Básico é elaborado sobre uma realidade de campo insuficientemente conhecida. A Lei inclui expressamente levantamentos topográficos e cadastrais, sondagens, ensaios geotécnicos, análises laboratoriais, estudos socioambientais e demais dados necessários à execução da solução escolhida.
O TCU tem reiterado que investigações necessárias à correta caracterização do empreendimento devem ocorrer antes da licitação quando influenciam o objeto e sua precificação. No Acórdão 1.370/2024-Plenário, por exemplo, o Tribunal registrou a necessidade de investigações geológicas prévias para correta caracterização do solo a ser escavado. No Acórdão 863/2024-Plenário, destacou que projetos rodoviários devem contemplar soluções relativas a desapropriações e remanejamento de interferências, como redes e tubulações de energia, gás, água, esgoto e fibras ópticas.
O princípio técnico é mais amplo do que os casos específicos: o licitante não deve ser obrigado a descobrir, depois da competição, informações que a Administração precisava conhecer para definir adequadamente aquilo que estava comprando.
Em edificações existentes, esse mesmo problema aparece como cadastro desatualizado, ausência de levantamento de infraestrutura, inexistência de inspeções, interferências não mapeadas, capacidade elétrica presumida, rotas técnicas desconhecidas ou documentação as built incompatível com a realidade.
Quando essas informações alteram quantitativos, método construtivo, logística, materiais ou tempo de execução, não são detalhes periféricos. São dados de formação do objeto.
Falha 2 — solução técnica ainda aberta ou reformulada depois da licitação
A alínea “b” do art. 6º, XXV, exige soluções técnicas globais e localizadas suficientemente detalhadas para evitar que o Projeto Executivo ou a obra exijam reformulações ou variantes que alterem qualidade, preço ou prazo inicialmente definidos.
Esse requisito impede que o Projeto Básico funcione como simples indicação de intenção. O documento deve congelar as decisões estruturantes da solução em nível suficiente para que o mercado precifique a mesma base.
O TCU sintetiza esse risco em sua jurisprudência sobre transfiguração do objeto. O Acórdão 1.576/2022-Plenário registra que a revisão do Projeto Básico ou a elaboração do Projeto Executivo não podem ser utilizadas para transformar substancialmente a solução originalmente submetida à licitação.
Na prática, o risco aparece quando a Administração licita e, durante a execução, precisa decidir questões como:
- tecnologia ou arquitetura principal do sistema;
- capacidade ou dimensionamento estrutural relevante;
- localização de equipamentos e instalações críticas;
- nível de redundância ou disponibilidade;
- método construtivo com impacto material em custo e prazo;
- interfaces essenciais entre disciplinas;
- padrão de desempenho que altera a classe do equipamento ou material.
O Projeto Executivo pode detalhar a solução. O que ele não deve fazer é substituir a definição que deveria ter sido suficientemente madura para permitir a competição.
Falha 3 — projeto formado por documentos que não fecham entre si
Se o Projeto Básico ainda depende de decisões capazes de alterar preço, prazo, qualidade ou quantidade, a licitação pode estar carregando uma indefinição que deveria ter sido resolvida antes da competição.
O Design Review testa coerência entre levantamentos, projetos, interfaces, quantitativos, orçamento e critérios de aceite.
Uma das fragilidades mais comuns não está na ausência total de documentos, mas na incompatibilidade entre eles. O processo pode conter desenho, memorial, especificação, planilha e cronograma, porém cada peça representar uma versão diferente do objeto.
Essa inconsistência cria múltiplos baselines. O licitante lê uma quantidade na planilha, encontra outra nos desenhos e uma terceira interpretação no memorial. A fiscalização, depois, precisa decidir qual peça prevalece. O contratado pode alegar omissão, divergência ou alteração. O orçamento-base deixa de ser reprodução econômica do projeto e passa a ser um documento parcialmente autônomo.
Uma revisão sob a ótica do TCU deve testar, ao menos, as seguintes correlações:
| Origem | Deve ser coerente com | Risco da divergência |
| levantamentos | plantas e memoriais | projeto baseado em condição inexistente |
| plantas | especificações | solução gráfica incompatível com desempenho exigido |
| plantas e memoriais | quantitativos | itens ausentes ou quantidades incorretas |
| quantitativos | orçamento | custo não representa o projeto |
| projeto | cronograma | prazo sem aderência à sequência executiva |
| especificações | critérios de aceite | fiscalização sem parâmetro objetivo |
| projeto e orçamento | edital | licitantes precificando objetos distintos |
| projeto | matriz de riscos | risco alocado sem correspondência com a solução |
Essa verificação é típica de Design Review e deve ser realizada antes de o edital transformar a documentação de engenharia em obrigação contratual.
Falha 4 — quantitativos sem memória e sem rastreabilidade
Quantitativo auditável precisa ter origem demonstrável. A revisão deve conectar desenhos, memoriais, memórias de cálculo, critérios de medição e planilha orçamentária antes do edital.
O orçamento detalhado deve ser fundamentado em quantitativos propriamente avaliados. Isso significa que quantidade não pode ser tratada como número isolado em uma planilha: precisa decorrer do projeto, de memória de cálculo, de critérios de medição ou de levantamento demonstrável.
O TCU historicamente rejeita estimativas genéricas quando existe necessidade de caracterização mais precisa. O Acórdão 896/2015-Plenário, por exemplo, considerou inadequado utilizar taxa estimativa de consumo de aço por volume de concreto como substituto do quantitativo necessário para caracterizar a obra e avaliar seu custo.
O princípio permanece útil sob a Lei 14.133: quanto mais relevante o item para o custo e para a execução, maior deve ser a rastreabilidade de sua quantidade.
A equipe de revisão deve conseguir responder:
- de qual desenho, modelo, levantamento ou cálculo nasceu o quantitativo;
- qual critério de medição foi utilizado;
- quais perdas, folgas ou fatores foram aplicados;
- qual versão do projeto sustenta a quantidade;
- como o quantitativo será atualizado se o projeto for revisado;
- quais itens concentram maior risco econômico segundo a curva ABC.
A ausência dessa trilha fragiliza a comparação de propostas e também a análise de futuros aditivos.
Falha 5 — orçamento que não reproduz o Projeto Básico
O TCU mantém capítulo específico sobre orçamento detalhado do custo global da obra. Para contratações baseadas em Projeto Básico, o orçamento deve discriminar serviços e fornecimentos com preços unitários, quantidades, preços totais e, quando aplicável, BDI e encargos sociais com suas composições.
O Manual também diferencia o orçamento detalhado do Projeto Básico da estimativa expedita utilizada no ETP. A estimativa de viabilidade pode ser paramétrica; o orçamento que sustenta a licitação precisa representar o objeto com nível de detalhamento compatível com a contratação.
Esse ponto é decisivo para auditoria porque o orçamento cumpre várias funções simultâneas:
- referencia o valor estimado da contratação;
- permite analisar aceitabilidade de preços;
- sustenta critérios de exequibilidade e julgamento;
- oferece baseline para medições e alterações;
- permite verificar sobrepreço em itens e no conjunto;
- conecta o custo à solução efetivamente projetada.
Um orçamento formalmente completo pode continuar deficiente se os quantitativos não vierem do projeto, se houver serviços omitidos, se as composições não representarem o método previsto ou se o projeto tiver sido alterado sem atualização da planilha.
Por isso, a revisão orçamentária precisa ser integrada à revisão de engenharia. Não basta auditar preços unitários isoladamente.
Falha 6 — itens genéricos que escondem o que será executado
A lógica de orçamento auditável exige decomposição suficiente para identificar serviços e custos. O TCU historicamente rejeita itens agregados que não permitem compreender a formação do preço quando seria tecnicamente possível detalhá-los.
No Projeto Básico, esse problema aparece em descrições como “serviços diversos”, “verba”, “conjunto”, “adequações gerais” ou pacotes sem memória que absorvem atividades heterogêneas. Esses agrupamentos reduzem a capacidade de:
- comparar propostas;
- verificar quantitativos;
- medir execução;
- analisar alterações;
- rastrear diferenças entre orçamento-base e contrato;
- identificar sobrepreço ou superfaturamento em itens específicos.
A necessidade de decomposição deve ser proporcional à materialidade e à natureza do objeto. O objetivo não é fragmentar artificialmente o orçamento, mas eliminar caixas-pretas econômicas.
Falha 7 — especificação técnica que restringe a competição ou não assegura desempenho
O art. 6º, XXV, exige que materiais e equipamentos sejam identificados e especificados para assegurar os melhores resultados para o empreendimento e a segurança de utilização, considerados riscos e perigos identificáveis, sem frustrar o caráter competitivo.
A especificação tem, portanto, duas fronteiras. De um lado, não pode ser tão aberta que permita produtos com desempenho incompatível. De outro, não pode converter características incidentais de uma solução de referência em barreiras injustificadas à competição.
A revisão deve investigar:
- quais requisitos são realmente funcionais ou de desempenho;
- quais derivam de norma, interoperabilidade, segurança ou condições de operação;
- quais apenas reproduzem atributos de um modelo específico;
- se existem critérios objetivos de equivalência;
- se a exigência pode ser comprovada na proposta e verificada no recebimento;
- se marca ou fabricante, quando mencionados, possuem justificativa técnica e enquadramento legal.
Esse teste será aprofundado em conteúdo específico sobre indicação de marca e padronização, porque o problema merece uma intenção própria dentro do cluster.
Falha 8 — Projeto Básico sem informações suficientes para método e prazo
A lei exige que o Projeto Básico possibilite a definição dos métodos e do prazo de execução. Isso não significa que o projetista precise prescrever cada procedimento operacional do futuro contratado, mas o projeto deve fornecer informações suficientes para estimar a sequência executiva e as condicionantes relevantes.
Em ambientes existentes, por exemplo, podem ser críticos:
- janelas de intervenção;
- continuidade operacional;
- necessidade de desligamentos;
- acessos restritos;
- trabalhos em áreas ocupadas;
- interferência com sistemas em produção;
- logística de materiais e equipamentos;
- liberações de segurança;
- obras temporárias ou instalações provisórias.
Quando o cronograma ignora essas condições, o prazo deixa de ser resultado do Projeto Básico e passa a ser uma expectativa administrativa. Isso aumenta o risco de pedidos de prorrogação, reprogramações e alegações de fatos não considerados na proposta.
Falha 9 — ausência de subsídios para fiscalização, medição e gestão contratual
O Projeto Básico não serve apenas para contratar; ele também precisa sustentar a gestão da obra. O próprio art. 6º, XXV, menciona subsídios para montagem do plano de licitação e gestão da obra, incluindo programação, estratégia de suprimentos e normas de fiscalização.
Na prática, um bom Projeto Básico deve permitir que a fiscalização saiba:
- o que inspecionar;
- qual documento estabelece o requisito;
- quais ensaios ou testes são aplicáveis;
- como medir quantitativamente a execução;
- quais evidências comprovam atendimento;
- em que momento um serviço pode ser aceito;
- quais documentos devem integrar o recebimento;
- como registrar desvios e alterações.
Quando o critério de aceite surge somente durante a execução, a Administração perde objetividade e aumenta o espaço para controvérsia.
Falha 10 — deixar para o Projeto Executivo aquilo que altera preço, qualidade ou prazo
Uma das fronteiras mais sensíveis de auditoria é distinguir detalhamento executivo de indefinição do objeto.
O Projeto Executivo desenvolve e completa a solução. O problema surge quando ele precisa redefinir algo que materialmente muda a contratação. O teste útil é simples: se a decisão posterior pode alterar significativamente qualidade, preço, prazo, quantidade, risco ou desempenho, há forte sinal de que não se tratava de mero detalhamento.
O TCU já registrou que projetos executivos não podem transfigurar o objeto licitado. Isso é especialmente relevante em contratos nos quais a Administração utiliza Projeto Básico para estabelecer a competição.
A exceção estrutural é a contratação integrada, em que a licitação se baseia em anteprojeto e a elaboração dos projetos básico e executivo é atribuída ao contratado. Mesmo nesse regime, porém, a solução não fica sem controle: o anteprojeto precisa fornecer os subsídios legalmente exigidos e o desenvolvimento posterior deve ser submetido à aprovação da Administração.
Quando a deficiência do Projeto Básico vira risco de responsabilização
A jurisprudência do TCU mostra que Projeto Básico deficiente não é tratado apenas como problema de qualidade documental. Em situações relevantes, a deficiência pode ser considerada falha grave.
O Acórdão 2.778/2020-Plenário registrou que iniciar obra pública com Projeto Básico deficiente, sem elementos necessários e suficientes e sem precisão adequada para caracterizar o empreendimento e assegurar a exatidão de sua orçamentação, constitui falha grave passível de multa aos responsáveis.
O Acórdão 678/2015-Plenário também tratou como atuação desidiosa a aprovação de Projeto Básico desatualizado ou incompleto que não reúna elementos necessários para demonstrar a viabilidade técnica, com possibilidade de responsabilização do corpo técnico encarregado de sua aprovação.
Embora parte dessa jurisprudência tenha se formado sob a Lei 8.666/1993, os elementos estruturantes permaneceram na Lei 14.133: suficiência, precisão, definição e dimensionamento do objeto, viabilidade técnica, orçamento e redução de reformulações posteriores.
A mensagem de controle é consistente: aprovar um Projeto Básico é um ato técnico, e não um despacho meramente formal.
O que a aprovação técnica deveria registrar
Para que a decisão seja auditável, a aprovação deveria demonstrar mais do que a existência dos arquivos. O processo precisa registrar quais verificações foram realizadas e quais riscos residuais foram aceitos.
Uma aprovação tecnicamente robusta pode registrar:
- documentos e revisões analisados;
- responsáveis técnicos e respectivas ARTs ou RRTs quando aplicáveis;
- escopo coberto pela revisão;
- principais premissas de projeto;
- levantamentos utilizados;
- compatibilização entre disciplinas;
- consistência entre projeto, quantitativos e orçamento;
- pendências classificadas por criticidade;
- justificativas para pendências aceitas;
- riscos transferidos ou mantidos pela Administração;
- data-base do conjunto documental aprovado.
Esse registro transforma a aprovação em evidência de governança.
Matriz de evidências para uma revisão sob a ótica do TCU
Uma forma prática de estruturar o controle é vincular cada risco a uma evidência verificável.
| Questão de controle | Evidência esperada | Risco se ausente |
| necessidade e solução estão maduras? | ETP e decisão de solução | projeto desenvolvendo alternativa ainda indefinida |
| condições reais foram levantadas? | cadastros, sondagens, inspeções, ensaios | quantitativos e método baseados em premissas frágeis |
| solução está suficientemente definida? | memoriais, plantas, cálculos e critérios | reformulação posterior com impacto em preço/prazo |
| disciplinas estão compatibilizadas? | relatório de coordenação/Design Review | conflitos descobertos em obra |
| quantitativos são rastreáveis? | memória de cálculo e vínculo com desenhos/modelo | orçamento sem base física confiável |
| orçamento representa o projeto? | planilhas sintética e analítica, composições e ART | preço-base dissociado do objeto |
| especificações preservam competição? | requisitos funcionais e justificativas | restrição indevida ou aquisição de desempenho inadequado |
| prazo decorre da solução? | cronograma e premissas executivas | prazo inexequível ou prorrogações previsíveis |
| riscos estão tratados? | matriz de riscos e registros de decisão | transferência genérica de incertezas |
| fiscalização consegue medir e aceitar? | critérios de medição, ensaios e aceite | controvérsia na execução e no pagamento |
Essa matriz não substitui a análise de engenharia. Ela organiza a evidência para que a revisão não dependa apenas da experiência tácita de quem lê o processo.
Como separar este controle do checklist de prontidão
A A3A mantém um conteúdo específico de checklist de Projeto Básico antes de licitar, voltado à conferência operacional de itens e documentos. A função deste artigo é diferente.
O checklist responde: “o pacote está pronto para seguir?”.
A análise TCU responde: “quais falhas têm materialidade de controle, como elas contaminam a contratação e quais evidências sustentam a decisão administrativa?”.
Da mesma forma, o artigo conceitual Projeto Básico de Engenharia: o que é, etapas e critérios de prontidão permanece como referência para compreender a etapa de engenharia em sentido amplo, inclusive fora das contratações públicas.
Essa separação evita que três páginas disputem a mesma intenção:
- conceito e engenharia do Projeto Básico;
- checklist de prontidão;
- Projeto Básico sob a régua da Lei 14.133 e do TCU.
Projeto Básico, orçamento e edital devem formar um único baseline de contratação
Projeto, orçamento e Termo de Referência precisam representar o mesmo objeto. A revisão técnica do TR fecha a interface entre engenharia e regra de contratação antes da publicação.
Um dos erros mais relevantes é tratar projeto, orçamento e edital como produtos de equipes independentes. Para o mercado, porém, todos formam uma única proposta de contrato.
Se o projeto define uma solução e a planilha omite parte dela, a proposta econômica fica incompleta. Se a planilha inclui serviços não previstos no projeto, o licitante precisa inferir o escopo. Se o edital cria uma obrigação que não aparece nos documentos técnicos, a Administração introduz custo sem base de quantificação. Se a matriz de riscos aloca evento que o Projeto Básico deveria ter investigado previamente, transfere-se incerteza que talvez não fosse residual.
A revisão final deve, portanto, ser transversal:
- Projeto Básico define o objeto;
- quantitativos materializam fisicamente o objeto;
- orçamento traduz os quantitativos em custo;
- cronograma traduz a solução em tempo;
- especificações traduzem desempenho em requisitos verificáveis;
- edital transforma esses elementos em regra de competição;
- contrato transforma a regra em obrigação executável;
- fiscalização verifica a obrigação com base no mesmo baseline.
Quando essa cadeia é coerente, a contratação se torna mais auditável. Quando cada peça representa um objeto diferente, o risco de conflito cresce exponencialmente.
Projeto Básico e aditivos: a pergunta que deve ser feita antes da licitação
Aditivos podem decorrer de fatos supervenientes legítimos. O problema é quando a alteração contratual apenas revela informação que já deveria ter sido investigada, definida ou quantificada no Projeto Básico.
Antes da licitação, a equipe deveria testar cada grande incerteza perguntando:
- o evento é realmente imprevisível ou apenas não investigado?
- o dado poderia ter sido levantado tecnicamente?
- a solução poderia ter sido definida sem comprometer a competição?
- a quantidade poderia ter sido estimada com método mais confiável?
- o risco foi conscientemente alocado ou apenas omitido?
- o orçamento contém contingência ou tratamento coerente com essa incerteza?
Esse exercício reduz a utilização do contrato como etapa de descoberta do escopo.
Design Review antes do edital como controle preventivo
A revisão independente do Projeto Básico é uma das ferramentas mais eficazes para identificar divergências antes que elas sejam incorporadas ao edital.
Um Design Review voltado à contratação pública deve ir além da verificação de desenhos. Ele deve conectar:
- requisitos e solução;
- projeto e levantamento;
- projeto e interfaces;
- projeto e quantitativos;
- quantitativos e orçamento;
- solução e cronograma;
- especificações e competitividade;
- projeto e matriz de riscos;
- projeto e critérios de medição;
- projeto e documentos do edital.
O produto da revisão pode ser estruturado como matriz de comentários, classificação de criticidade, registro de resposta, evidência de fechamento e parecer de prontidão. Isso cria histórico auditável de como os problemas foram identificados e tratados antes da publicação.
Como a engenharia reduz o risco de um Projeto Básico deficiente
Os serviços de engenharia aplicáveis dependem da origem da fragilidade.
Quando o problema está nos dados de campo, a resposta é levantamento cadastral, site survey, sondagem, inspeção ou diagnóstico. Quando está na solução, pode ser necessário revisar cálculos, memoriais, plantas, critérios e especificações. Quando está na integração, entram compatibilização e coordenação multidisciplinar. Quando está nos quantitativos e custos, a correção passa por memória de cálculo, orçamento, composições e curva ABC. Quando o problema está na transformação da engenharia em obrigação contratual, a revisão de Termo de Referência e edital fecha a última interface.
Essa abordagem evita tratar “Projeto Básico deficiente” como uma categoria genérica. Cada deficiência possui causa, evidência e serviço técnico capaz de reduzi-la.
Considerações finais
Sob a ótica do TCU, o Projeto Básico é uma peça de controle do risco da contratação. Sua qualidade não é medida pelo número de pranchas ou pelo volume de documentos, mas pela capacidade de definir e dimensionar o objeto, demonstrar a solução, sustentar os quantitativos e o orçamento, permitir competição comparável e fornecer uma base objetiva para execução, medição e fiscalização.
A Lei 14.133 preserva essa lógica e a conecta diretamente ao planejamento. Levantamentos, soluções, especificações, método, prazo, gestão e orçamento precisam formar um conjunto coerente. Quando decisões materiais são deixadas para depois da licitação, quando o projeto não representa a realidade de campo ou quando o orçamento não reproduz o objeto, a deficiência deixa de ser editorial e se transforma em risco contratual e de controle.
A melhor prevenção é produzir evidência antes da competição: investigar, projetar, compatibilizar, quantificar, orçar, revisar e registrar tecnicamente a aprovação. É essa cadeia que permite demonstrar, diante da fiscalização interna ou externa, que a Administração não apenas possui um Projeto Básico, mas possui um Projeto Básico suficiente, coerente e auditável.
Referências técnicas
[1] BRASIL. Lei nº 14.133, de 1º de abril de 2021. Lei de Licitações e Contratos Administrativos. Disponível em: https://www.planalto.gov.br/ccivil_03/_ato2019-2022/2021/lei/l14133.htm
[2] TRIBUNAL DE CONTAS DA UNIÃO. Licitações e Contratos: Orientações e Jurisprudência do TCU. 5. ed. Item 4.4.3 — Projeto Básico. Manual eletrônico atualizado em 29 ago. 2025. Disponível em: https://licitacoesecontratos.tcu.gov.br/4-4-3-projeto-basico-pb/
[3] TRIBUNAL DE CONTAS DA UNIÃO. Licitações e Contratos: Orientações e Jurisprudência do TCU. Item 4.4.3.6 — Orçamento detalhado do custo global da obra. Disponível em: https://licitacoesecontratos.tcu.gov.br/4-4-3-6-orcamento-detalhado-do-custo-global-da-obra/
[4] TRIBUNAL DE CONTAS DA UNIÃO. Acórdão 2.778/2020 — Plenário. Projeto básico deficiente e responsabilização. Disponível em: https://pesquisa.apps.tcu.gov.br/documento/publicacao/licita%25C3%25A7%25C3%25A3o%2520projeto%2520b%25C3%25A1sico%2520deficiente/%2520/DTRELEVANCIA%2520desc/0
[5] TRIBUNAL DE CONTAS DA UNIÃO. Jurisprudência selecionada sobre Projeto Básico: Acórdãos 1.370/2024, 863/2024, 1.576/2022, 2.778/2020 e 896/2015, Plenário. Disponível em: https://pesquisa.apps.tcu.gov.br/documento/sumula/6/%2520/DTRELEVANCIA%2520desc%252C%2520NUMEROINT%2520desc/0/sinonimos%253Dtrue
Perguntas frequentes
O TCU verifica se o Projeto Básico contém elementos necessários e suficientes para definir e dimensionar o objeto, se os levantamentos e soluções são adequados, se os quantitativos e o orçamento são rastreáveis, se as especificações preservam a competição e se o conjunto permite definir método, prazo, fiscalização e gestão contratual.
Sim. A jurisprudência do TCU registra situações em que a aprovação ou o início da execução com Projeto Básico deficiente foi tratada como falha grave, especialmente quando faltam elementos necessários para caracterizar o empreendimento e assegurar a confiabilidade do orçamento.
O Projeto Executivo pode detalhar a solução, mas não deve ser utilizado para redefinir materialmente o objeto licitado. Se a decisão posterior altera qualidade, preço, prazo, quantidade ou desempenho de forma relevante, existe risco de que a indefinição devesse ter sido resolvida no Projeto Básico.
Em regra, não. O TCU diferencia a estimativa expedita ou paramétrica usada para avaliar viabilidade no ETP do orçamento detalhado que integra o Projeto Básico e sustenta a licitação, quando exigido pelo regime de execução.
É recomendável realizar revisão técnica integrada do Projeto Básico, verificando levantamentos, solução, compatibilização, quantitativos, orçamento, cronograma, especificações, riscos, critérios de medição e coerência com TR e edital, registrando as pendências e evidências de fechamento.
O conteúdo geral explica o que é Projeto Básico, suas etapas e sua maturidade no ciclo de engenharia. Este artigo trata especificamente da Lei 14.133 e da régua de controle do TCU, com foco em falhas de auditoria, evidências de processo e riscos da contratação pública.
Materiais técnicos complementares
Conteúdos principais sobre o tema
- Projeto Básico de Engenharia: o que é, etapas e critérios de prontidão
- Checklist de projeto básico: o que não pode faltar antes de licitar ou contratar uma obra
- O que o TCU verifica nas contratações de obras e serviços de engenharia
Conteúdos técnicos correlatos
- Orçamento de obra pública: 18 peças para um processo auditável
- Obra sem projeto executivo? O que a Lei 14.133 exige antes de começar
- Matriz de Alocação de Riscos em Contratos de Engenharia
Serviços relacionados
- Projeto Básico de Engenharia
- Revisão e Validação Técnica de Projetos — Design Review
- Revisão Técnica de Termo de Referência
- Orçamento de Obras e Serviços de Engenharia