Investimentos perdidos: como evitar projetos que consomem verba e não geram retorno

O projeto foi aprovado em comitê. O valor estava justificado, a apresentação era convincente, a liderança estava alinhada. Doze meses depois, o sistema foi entregue — dentro do prazo, dentro do orçamento, tecnicamente funcional. E ninguém usa. A área que pediu a ferramenta voltou a usar planilha. O problema que o projeto deveria resolver continua existindo. O dinheiro foi embora.

Esse tipo de situação é mais comum do que as empresas admitem, porque a conversa sobre fracasso de projeto raramente acontece em voz alta. O que foi entregue é contabilizado como sucesso pela tecnologia — o sistema está no ar, o escopo foi cumprido. Mas o negócio não mudou nada. O investimento foi consumido sem retorno.

Projeto entregue sem adoção é investimento perdido. E a diferença entre esse desfecho e um projeto que realmente gera resultado quase sempre está na qualidade das decisões tomadas antes do desenvolvimento começar — não durante.

Por que isso acontece

O primeiro problema é o escopo construído sem objetivo de negócio claro. Quando o ponto de partida é “precisamos de um sistema para X” em vez de “precisamos reduzir o tempo de Y em Z% para impactar a métrica W”, o projeto nasce sem critério de sucesso real. O time de tecnologia vai entregar o sistema — é o que foi pedido. Mas sistema entregue não é o mesmo que problema resolvido. Sem clareza do resultado esperado, qualquer entrega parece suficiente, e só depois da implantação o vazio fica evidente.

O segundo mecanismo é a aprovação de investimento sem tese de valor documentada. Em muitas empresas, projetos passam por comitê com base em intuição, relevância política ou urgência percebida — não em análise de impacto. Quando não há uma tese clara de “se fizermos isso, o resultado esperado é aquele, mensurável de tal forma”, não há como saber se o projeto valeu — nem como decidir se vale a pena continuar quando os primeiros sinais negativos aparecem. A ausência de tese de valor é a ausência de responsabilidade pelo resultado.

O terceiro fator é a falta de revisão ao longo do projeto. Projetos longos são aprovados com base num contexto que muda com o tempo. O problema que era crítico seis meses atrás pode já ter sido resolvido de outra forma, ou o mercado mudou, ou a estratégia da empresa mudou. Mas o projeto segue em frente porque foi aprovado, porque tem time alocado, porque parar seria admitir que a decisão inicial estava errada. O custo de continuar — completar o projeto sem impacto — é distribuído ao longo do tempo e parece menor do que o custo de parar. Mas frequentemente não é.

Por fim, há o problema de baixa adoção que poderia ter sido previsto. Usuários não adotam ferramentas que não resolvem o problema do jeito deles. E quando esses usuários não são envolvidos no processo de design e validação, o resultado é um sistema tecnicamente correto e praticamente inútil. A área de tecnologia constrói o que foi especificado, mas quem especificou não testou com quem vai usar. A distância entre quem decide e quem executa é onde a maioria dos projetos sem adoção nasce.

O que agrava

O custo que raramente aparece no relatório é o custo de oportunidade. O capital investido em projetos sem retorno poderia ter financiado iniciativas que gerariam resultado. Cada real gasto no projeto errado é um real que não foi para o projeto certo. Quando isso se acumula em múltiplos projetos ao longo de anos, o impacto na capacidade de crescimento da empresa é substancial — e completamente invisível nos demonstrativos financeiros.

Existe também o efeito de fadiga de mudança. Quando uma empresa implanta sistemas que não funcionam de forma repetida, os colaboradores perdem a disposição de engajar em mudanças futuras. “Mais uma ferramenta nova que vai ser abandonada em seis meses” é uma frase que qualquer profissional que trabalha em empresa com histórico de projetos fracassados já ouviu — ou disse. Essa ceticismo generalizado torna futuras iniciativas mais difíceis de implementar, mesmo quando são corretas.

E há a degradação da credibilidade da liderança de tecnologia. Cada projeto que não gera resultado reforça a narrativa de que tecnologia é custo, não investimento. Que a área de TI não entende o negócio. Que é melhor comprar uma solução pronta do que construir internamente. Essa percepção, quando se consolida, limita a capacidade de aprovação de projetos futuros — inclusive os que de fato fariam diferença.

Como resolver

O primeiro passo é exigir uma tese de valor antes de qualquer aprovação de projeto. Tese de valor não é apresentação de PowerPoint — é um documento de uma página que responde: qual problema de negócio isso resolve, qual é o resultado esperado e como vamos medir, quais são as hipóteses que precisam ser verdadeiras para isso funcionar, e qual é o plano de adoção. Se a área requisitante não consegue responder essas perguntas com clareza, o projeto não está maduro o suficiente para ser aprovado.

O segundo passo é criar marcos explícitos de go/no-go ao longo do projeto. Em vez de aprovar um projeto de doze meses de uma vez, aprove em fases de três meses com revisão formal. Em cada revisão, a pergunta é direta: os resultados parciais indicam que a tese de valor original ainda é válida? Se não, encerre ou redirecione. Encerrar um projeto no quarto mês é décadas mais barato do que entregá-lo no décimo segundo sem impacto.

O terceiro elemento é associar KPI de negócio — não de tecnologia — a cada fase. Não “o sistema foi entregue”, mas “o tempo de processamento reduziu X%”, “a taxa de erro caiu Y%”, “o volume processado por analista aumentou Z%”. Métricas de negócio são o único critério que importa para avaliar se o investimento está gerando retorno. Métricas técnicas são necessárias, mas insuficientes.

Por fim, envolva os usuários finais desde a fase de design — não como validadores do que já foi construído, mas como co-construtores do que vai ser construído. Isso reduz dramaticamente o risco de baixa adoção e, frequentemente, simplifica o escopo porque o usuário sabe exatamente o que precisa, sem o excesso de funcionalidade que ninguém vai usar.

O ponto de vista do Lucas

O maior desperdício de capital em tecnologia não é projeto cancelado — é projeto entregue que ninguém usa. O cancelamento tem o desconforto da decisão explícita, mas ao menos para o sangramento. O projeto entregue sem adoção continua consumindo recursos de manutenção, suporte e infraestrutura por anos, enquanto o problema original segue sem solução.

Governança de investimento não é burocracia. É o que separa empresa que aprende a alocar capital com inteligência de empresa que financia ilusão com disciplina. A pergunta que toda aprovação de projeto deveria responder é simples: como vamos saber, em noventa dias, se valeu a pena? Se não há resposta para isso, a aprovação é prematura.