Por Neuton | Gestor de P&D C2Hub
Tem uma frase que aparece com frequência quando o assunto é gestão de projetos de capital. Ela vem de uma trajetória sólida, voz de quem já esteve no campo muitas vezes, e soa mais ou menos assim:
“Eu faço isso há anos. Sempre funcionou.”
Não estou aqui para questionar essa experiência. Estou aqui para fazer uma pergunta junto com quem a tem: funcionou, mas foi eficiente?
A McKinsey analisou mais de 300 megaprojetos acima de um bilhão de dólares e encontrou, em média, 80% de estouro de custo e 50% de atraso de prazo. Bent Flyvbjerg foi além: numa base de 16.000 projetos, apenas 8,5% cumpriram custo e prazo. Somente 0,5% entregaram todos os benefícios prometidos. Ele chama isso de lei de ferro dos megaprojetos. Não é exceção. É padrão.
Esses números não apontam para falha individual. Apontam para algo mais sistêmico: a normalização do desvio. Quando o setor inteiro aceita que é assim que projetos funcionam, ninguém para para perguntar se poderia ser diferente. E isso, de alguma maneira, até justifica o baixo crescimento da produtividade do nosso setor, quando comparado a outros setores nas últimas décadas.
Durante anos, essa ineficiência era absorvível. Margens generosas, demanda reprimida, poucos competidores capazes de entregar projetos complexos. O desperdício existia, mas ficava diluído. Hoje o ambiente mudou. Capital mais caro, pressão crescente por retorno, prazo de entrada em operação que define posição competitiva. O que antes era tolerável passa a ser um diferencial negativo.
E se a gente olhar com honestidade para os dados, a pergunta que fica não é se algo precisa mudar. A pergunta é onde, de fato, os projetos começam a dar errado.
A resposta está no que não foi alinhado, no que não foi previsto e nas decisões que ninguém tomou cedo o suficiente.
Três Problemas. Uma Raiz.
Quando um projeto estoura custo ou prazo, a narrativa costuma convergir para o canteiro: problema de execução, fornecedor que não entregou, equipamento que atrasou. Essas coisas acontecem. Mas na maior parte dos casos são consequências de decisões tomadas muito antes das construtoras e montadoras serem mobilizado.
O CII (Construction Industry Institute) identificou em pesquisa com mais de 200 profissionais da indústria que as causas centrais de disputas contratuais são contratos imprecisos e comunicação inadequada entre as partes. Não é falha técnica de execução. É falha de estrutura: de como o projeto foi concebido, contratado e organizado desde o início.
Esse problema se manifesta em três dimensões que se alimentam mutuamente.
A primeira é o modelo contratual que cria postura defensiva entre as partes. Quando o contrato é estruturado para transferir risco ao máximo para o outro lado, owner e contratantes entram no projeto olhando um para o outro com cautela. Um registra tudo para eventual pleito. O outro interpreta escopo da forma mais favorável possível. A colaboração necessária para resolver problemas em tempo real não acontece, porque o ambiente contratual não foi desenhado para isso. O resultado são disputas que consomem energia de gestão em vez de entrega de valor ao projeto.
A segunda dimensão é a participação tardia dos agentes chave. Construtoras, equipes de comissionamento e operação entram no projeto depois que as decisões de engenharia já foram tomadas. O cronograma foi montado sem levar em conta as prioridades reais do campo. Os documentos críticos para o início da construção não foram priorizados porque ninguém de construção estava na mesa quando o planejamento aconteceu. O CII tem dados diretos sobre isso: o Front End Planning bem feito, com participação integrada desde o início, reduz em média 10% o custo e 7% o prazo. O custo de fazer esse planejamento é de 2% a 5% do custo total instalado. A conta é simples. O desafio é cultural e estrutural.
A terceira dimensão é a fragmentação de dados. Cada parte opera com sua versão da verdade. A engenharia tem um sistema. A construção tem outro. O owner tem um terceiro. Quando há uma mudança, e sempre há, ela não se propaga de forma controlada. O resultado são decisões baseadas em informação desatualizada, retrabalho que poderia ter sido evitado e uma opacidade que impede qualquer gestão proativa de risco.
Separadamente, cada um desses problemas é sério. Juntos, eles são sistêmicos. Relação defensiva desincentiva compartilhamento de informação. Falta de integração entre os agentes garante que os problemas de engenharia só apareçam no campo. Dados fragmentados impedem que qualquer player enxergue o projeto como um todo.
Projeto Serra Dourada
Qualquer semelhança com projetos ou empresas reais é mera coincidência. O caso a seguir é fictício e construído exclusivamente para fins ilustrativos.
A Mineração Serra Dourada aprovou um projeto de expansão da sua planta de beneficiamento em Minas Gerais. Orçamento na casa de R$ 180 milhões, 24 meses para entrada em operação. O owner optou por um modelo onde ele próprio assumia o papel de integrador: contratou a engenharia separadamente, ficou responsável pelas compras dos equipamentos principais e pela coordenação das interfaces entre os agentes. Era ele o EPCista do projeto, com toda a responsabilidade que isso implica.
O site tinha uma restrição logística relevante: área de armazenamento muito limitada e muita interface entre construtoras e montadoras no campo. Isso significava que os equipamentos precisavam ser montados praticamente assim que chegassem. O cronograma de chegada dos equipamentos e o andamento das obras civis precisavam estar perfeitamente sincronizados.
O projeto tinha alta densidade de montagem mecânica. E isso tornava os documentos emitidos pelos fornecedores parte do caminho crítico do projeto. Sem eles, não havia como dimensionar fundações e estrutura metálica com precisão.
A empresa de engenharia contratada era competente e experiente. Montou seu cronograma com rigor técnico. O problema é que esse cronograma foi construído a partir da lógica interna da engenharia, focado na emissão de documentos e não na informação necessária para compras e construção, sem integração com as prioridades da construção e do comissionamento. Construção e equipe de comissionamento não foram engajadas antecipadamente.
Como o owner era o responsável pela compra dos equipamentos, ele também era responsável por garantir o prazo de emissão dos documentos dos fornecedores. Essa dependência existia, era conhecida, mas nunca foi formalizada num cronograma integrado. Cada parte conhecia seu pedaço. Ninguém enxergava o todo.
Os documentos de engenharia necessários para acionar as compras dos equipamentos prioritários saíram com atraso. Não por falha técnica, mas porque não estava claro, para nenhuma das partes, o que precisava sair primeiro para liberar frentes de ataque de obra. Quando as requisições chegaram aos fornecedores, os DFs vieram atrasados. E sem esses dados, a engenharia não conseguia fechar os projetos de fundação.
As partes se reuniram, avaliaram as opções e tomaram uma decisão conjunta: avançar com os projetos de fundação usando os Desenhos de Referência disponíveis, adotando um peso conservador para os equipamentos. Era uma decisão razoável dentro das circunstâncias, mas era uma decisão reativa. O projeto já estava respondendo a um problema que poderia ter sido evitado. O custo adicional com fundações e estrutura foi absorvido e se tornou um custo oculto.
A construção avançou. As bases civis foram executadas. E quando a equipe de montagem chegou ao campo, com equipamentos a caminho e sem espaço para aguardar, descobriu que as cotas não batiam. As perfurações para locação do equipamento estavam diferentes do que havia sido executado.
O que havia acontecido: o fornecedor havia feito uma alteração no modelo do equipamento depois que os Desenhos de Referência haviam sido usados como base. No CDE, o Common Data Environment do projeto, o documento aparecia com status de aprovado. A construtora havia executado a obra com base nessa versão, agindo corretamente dentro do que o sistema indicava. O problema estava no processo: uma revisão em andamento que não havia sido comunicada nem sinalizada no ambiente de dados compartilhado.
Cada parte tinha sua versão do documento. Nenhuma era a versão atual. E ninguém sabia disso até a equipe de montagem chegar ao campo.
Ajustes físicos foram necessários para viabilizar a montagem. Esses ajustes comprometeram a garantia do fabricante. A construtora registrou improdutividade. O prazo escorregou. O custo subiu.
O que veio depois foi previsível. Cada parte recuou para o que o contrato dizia. O owner questionou a qualidade da gestão documental da engenharia. A engenharia apontou que a validação do desenho de fabricação não estava no seu escopo. A construtora documentou cada hora de improdutividade. Ninguém estava errado na sua leitura contratual. E exatamente por isso, ninguém estava trabalhando junto para resolver.
E ainda nem tínhamos chegado no comissionamento.
dentro do seu contexto e das suas restrições. A engenharia entregou o que seu escopo previa. A construtora executou com base no que o sistema indicava como versão válida. O owner tomou decisões dentro da pressão que tinha. O problema foi que não havia estrutura para que essas decisões fossem tomadas de forma integrada e com informação confiável.
Não existia um cronograma que tornasse visível a dependência entre documentos de engenharia, compras de equipamentos e prioridades da construção. Não havia governança que incentivasse as partes a antecipar problemas em vez de gerenciá-los depois que já tinham virado crise. E o CDE, que deveria ser a fonte única da verdade, funcionava como repositório de arquivos sem controle de status adequado.
Nenhuma dessas ausências era inevitável. Todas tinham um ponto de intervenção claro. E todas se conectam diretamente às três dimensões que discutimos antes: governança contratual, integração antecipada dos agentes e dados confiáveis como base para decisão.
“Não é que não deu certo. É que a gente nunca soube o quanto poderia ter dado mais certo.”
Ao longo de muitos projetos, observei um padrão que se repete com consistência desconfortável. As lições aparecem, mas aparecem tarde. É muito comum, por exemplo, realizar uma sessão de planejamento integrado para alinhar a sequência de construção depois que os problemas já estão instalados, quando essa mesma sessão, feita antes das decisões críticas serem tomadas, teria mudado o resultado.
A diferença entre um projeto que entrega e um que vira disputa raramente está no que aconteceu no campo. Está no que foi, ou não foi, decidido muito antes da primeira estaca ser cravada.
Essa é a conversa que vale ter. Precisamos levar alinhamento e previsibilidade para projetos de capital e infraestrutura.
Este artigo inaugura uma série de publicações do Programa de Pesquisa C2Hub 2026, que reúne owners e parceiros da indústria para desenvolver e validar boas práticas em gestão de projetos de capital no Brasil. Os próximos artigos aprofundarão cada um dos três eixos discutidos aqui: contratos colaborativos e governança orientada a valor; engajamento antecipado e integração de parceiros chave; e integração tecnológica de dados como fonte única da verdade.
