Por que projetos com grandes fornecedores de tecnologia custam mais tempo do que o contrato diz

O custo mais alto de um projeto com um grande fornecedor de tecnologia raramente está na proposta. Está no calendário: alinhamentos entre áreas comerciais, gerência de projeto, arquitetura e desenvolvimento, cada uma com um responsável diferente e nenhuma com a visão completa do negócio do cliente. Cada passagem de bastão custa uma semana e um pouco da informação original.

O sintoma aparece no primeiro mês. O time que ouviu o problema não é o que desenha a solução, e o que desenha não é o que coloca em produção. Requisitos viram documentos, documentos viram tickets, e a regra de negócio que só quem opera conhece se perde no caminho. O resultado é um sistema correto no papel e errado na prática, corrigido em rodadas de mudança pagas à parte.

A alternativa não é contratar mais barato; é contratar diferente. Um time sênior e pequeno, em que quem faz o diagnóstico é quem revisa as regras de negócio, desenha o fluxo e implanta, elimina as camadas que existem para coordenar pessoas que não se falam. A conta passa a ser proporcional ao trabalho, não ao tamanho da estrutura, e a primeira entrega em produção acontece em semanas.

Enxuto não significa informal. O processo é ágil no ritmo, mas as decisões ficam registradas com data, custo e ganho estimado, e as evidências que auditoria, LGPD ou uma certificação como a ISO 27001 exigem são produzidas durante o trabalho, não reconstruídas no fim. Foi assim que uma empresa de serviços jurídicos com 60 anos de tradição obteve a certificação sem nenhuma ressalva técnica.

Três perguntas para fazer a qualquer fornecedor antes de assinar: quem vai conversar com o meu time sobre as regras de negócio, e essa pessoa vai construir o sistema? Em quantas semanas a primeira parte entra em produção? Se eu mudar de ideia no meio, quanto custa e quem decide? As respostas dizem mais sobre prazo e custo do que qualquer cronograma.

Onde o custo se esconde no contrato

Há três modelos de contrato e cada um esconde o custo de um jeito. No contrato por horas (time and materials), o fornecedor não tem incentivo para terminar: cada alinhamento, cada reunião de status e cada retrabalho é faturável, e o cliente descobre o custo real no fim, quando já não pode voltar atrás. No contrato de preço fechado com escopo detalhado, o custo se esconde nas mudanças: como o escopo foi escrito antes de alguém entender o processo, cada regra de negócio descoberta no caminho vira um pedido de mudança, com preço e prazo novos. No contrato por sprints sem critério de aceite, o custo se esconde no que não fica pronto: o sprint fecha, a fatura sai, e o fluxo do negócio continua pela metade.

O modelo que alinha interesses é o de ondas de valor: cada onda fecha um fluxo completo do negócio, tem escopo, indicador e preço definidos antes de começar e é faturada quando entra em produção e passa nos testes de ponta a ponta. O risco de prazo e de qualidade fica com quem constrói. Se a onda não entrega o combinado, não é cobrada até entregar. Poucos grandes fornecedores aceitam esse formato, e isso diz muito sobre onde está o lucro deles.

O que exigir na proposta

• Nome de quem vai mapear o processo com o seu time, e confirmação de que essa pessoa desenha e implanta a solução
• Etapa de mapeamento do processo atual e de revisão das regras de negócio antes de qualquer estimativa de desenvolvimento
• Primeira entrega em produção com data, em semanas, e o fluxo de negócio que ela fecha
• Escopo, indicador de sucesso e preço por onda, com faturamento na entrega
• Critério de aceite objetivo: testes de ponta a ponta e validação por quem opera
• Documentação funcional, treinamento e handover como entregáveis, não como opcionais
• Repositórios, contas de nuvem e credenciais em nome da sua empresa desde o primeiro dia
• Quem responde pelo resultado, com nome, e como o contrato termina

Uma proposta que não consegue responder a esses pontos com clareza não é uma proposta de projeto; é uma proposta de alocação de pessoas, e o prazo que ela promete não é o prazo que vai acontecer.

Quando o grande fornecedor faz sentido

Seria desonesto dizer que estrutura grande nunca serve. Ela serve quando o projeto exige centenas de pessoas ao mesmo tempo em vários países, quando o cliente precisa de um fornecedor com balanço para assumir passivos contratuais de grande porte, ou quando a compra é de um produto de prateleira com implantação padronizada e o que se contrata é capacidade de execução repetitiva. Nesses casos, o custo das camadas é o preço de coordenar escala. O problema é usar essa estrutura para o projeto de médio porte, com regras de negócio específicas, em que o que se precisa é de gente sênior sentada com quem opera. Ali, as camadas só somam tempo.

O sinal mais confiável

Antes de olhar proposta, olhe quem está na sala. Se a reunião comercial tem cinco pessoas e nenhuma delas vai escrever uma linha de código nem mapear um fluxo, o projeto vai ter passagem de bastão. Se quem apresenta é quem vai executar, e faz perguntas sobre o seu processo em vez de mostrar slides sobre metodologia, o prazo tem mais chance de ser real. É um teste simples, e raramente falha.

Os números

O padrão descrito acima está medido há mais de uma década. O estudo da McKinsey com a Universidade de Oxford, sobre mais de 5.400 projetos de TI, encontrou que projetos grandes (acima de US$ 15 milhões) estouram o orçamento em 45%, o prazo em 7% e entregam 56% menos valor do que o previsto; 17% deles ameaçam a existência da própria empresa. O CHAOS Report, do Standish Group, mostra ao longo de duas décadas que a taxa de sucesso cai conforme o projeto cresce. A Gartner, em pesquisa com CIOs de outubro de 2024, registrou que apenas 48% das iniciativas digitais atingem as metas de negócio. E a Panorama Consulting, no 2025 ERP Report, listou as causas de estouro: equipe subestimada (38%), escopo ampliado (35%) e problemas técnicos e de dados (34%), todos sintomas de quem desenha não ser quem entende o negócio nem quem implanta. Um time sênior enxuto, entregando em ondas, é a forma de manter cada projeto no tamanho em que os dados dizem que ele dá certo.