Dificuldades para calcular o ROI em projetos de TI: as seis barreiras e como contornar cada uma

Autor: Pedro Tebaldi PM do KeepGreen

Publicado set/2014Atualizado ago/2026

A fórmula do ROI cabe em uma linha. Ganho menos custo, dividido pelo custo. Nenhum gestor de TI trava por causa da matemática.

O que trava é o preenchimento. Quanto vale a hora que a equipe deixou de perder? Aquele servidor entra no custo do projeto ou na conta de infraestrutura? O ganho do trimestre veio da nova ferramenta ou da reestruturação comercial que rodou em paralelo?

Este texto trata dessas perguntas, uma por seção. Ele não repete a fórmula nem apresenta exemplos numéricos completos, porque esses dois assuntos já têm endereço próprio. Aqui o assunto é a dificuldade em si, com a saída prática de cada barreira.

Por que o ROI de projetos de TI é difícil de calcular

Calcular o ROI de um projeto de TI é difícil porque as duas variáveis da fórmula raramente têm a mesma qualidade. O custo tende a ser subestimado, já que boa parte dele aparece depois da entrega. O ganho costuma ser parcialmente intangível, distribuído entre áreas e disputado por outras iniciativas do mesmo período.

Ou seja, o problema não é de cálculo. É de qualidade dos dados que entram nele.

Isso muda a natureza da solução. Nenhuma planilha mais sofisticada resolve entrada ruim, portanto o trabalho útil acontece antes de abrir a planilha. Para a mecânica da fórmula e a comparação com outras métricas financeiras, o guia de ROI e como calculá-lo cobre o terreno.

As seis barreiras que quebram o cálculo

Na prática, o cálculo emperra sempre nos mesmos seis pontos. Vale reconhecê-los antes de assumir compromisso de número com a diretoria.

As quatro primeiras são de dados. As duas últimas são de método e de governança, portanto costumam passar despercebidas em revisões técnicas.

Ganhos intangíveis: o que fazer quando o benefício não tem preço

Boa parte do valor de um projeto de TI não vira dinheiro de forma direta. Equipe menos sobrecarregada, decisão mais rápida, menos atrito com o cliente: tudo isso é real, mas nenhuma dessas coisas tem preço de mercado.

A saída errada é a mais comum: atribuir um valor arbitrário ao intangível para fazer o número fechar. Isso transforma o ROI em ficção. A primeira pessoa que perguntar de onde saiu o valor derruba a apresentação inteira.

A saída correta é separar o que entra e o que fica de fora. No cálculo entram apenas ganhos com origem rastreável: horas efetivamente medidas, contratos, multas, licenças eliminadas. O restante vai para um quadro de benefícios qualificados, apresentado ao lado do ROI.

Esse formato é mais honesto e costuma ser mais persuasivo. A diretoria compara um número defensável somado a uma lista de benefícios declarados como não monetizáveis, o que é bem diferente de receber um número inflado sem lastro.

Há um caso intermediário que vale resgatar: o intangível que vira tangível quando existe medição. “Menos incidentes” parece subjetivo até a empresa ter histórico de quantos ocorriam, quanto tempo duravam e quanto custava cada hora parada.

Custos ocultos: o TCO que só aparece no terceiro ano

A segunda barreira é a mais previsível de todas, o que a torna imperdoável. O custo do projeto quase nunca é o valor da proposta. Ele inclui uma cauda longa que só se manifesta depois que a entrega foi comemorada.

Por isso a conta correta é a de custo total de propriedade, considerando o mesmo período usado no cálculo do retorno. Projetos que parecem excelentes no primeiro ano viram empate no terceiro, quando a sustentação entra na conta.

Uma prática simples ajuda: peça a proposta com o custo de três anos, não com o preço de implantação. Fornecedor que resiste a essa pergunta já está respondendo. As alavancas para melhorar esse quadro estão reunidas nos passos para aumentar o ROI de investimentos em TI.

Atribuição: de quem é o ganho quando tudo roda junto

Suponha que o faturamento cresceu no semestre. Nesse mesmo semestre, a TI entregou um sistema novo, o marketing dobrou o investimento em mídia e o comercial contratou quatro vendedores. A quem pertence a alta?

Essa é a barreira menos discutida e a que mais destrói credibilidade. Quando a TI reivindica um ganho que outras áreas também reivindicam, o número inteiro vira suspeito, inclusive a parte legítima.

A saída é escolher, desde o desenho do projeto, uma métrica que apenas ele consiga mover. Tempo de processamento de um lote, número de retrabalhos por pedido, horas de indisponibilidade, custo de licença eliminado. Métricas assim não têm outro pai.

Depois é possível conectar essa métrica ao resultado financeiro, deixando a cadeia explícita. O ganho declarado passa a ser “reduzimos o retrabalho em X pedidos por mês, cada um custava Y em hora de operação”, em vez de reivindicar uma fatia do faturamento.

Linha de base: a barreira sem solução retroativa

Todas as barreiras anteriores admitem contorno depois que o projeto começou. Esta não. Se ninguém mediu como o ambiente se comportava antes, o “antes” não existe em números, portanto nenhuma comparação honesta é possível.

Na prática, é o que mais acontece. O projeto termina, alguém pergunta quanto melhorou e a resposta é uma estimativa de memória, feita justamente por quem defendeu o investimento.

A única solução é preventiva: instrumentar o ambiente antes de iniciar o projeto e registrar formalmente os números de partida. Esse é o motivo real pelo qual projetos de monitoração devem vir primeiro na fila do portfólio.

Vale reforçar o custo de ignorar isso. Sem linha de base, o projeto não fica sem ROI: ele fica com um ROI inventado, que é pior, porque ninguém consegue defendê-lo quando questionado em detalhe.

Horizonte: o prazo errado reprova o projeto certo

Um mesmo projeto pode ter ROI negativo em doze meses e excelente em trinta e seis. Escolher o horizonte, portanto, é escolher a resposta antes de fazer a conta.

O erro mais comum é usar o ano fiscal por conveniência administrativa. Ele serve para orçamento, não para avaliar investimento com vida útil de cinco anos. Infraestrutura, ERP e plataformas de dados raramente pagam a si mesmas dentro de um exercício.

O critério defensável é a vida útil do ativo ou a duração do contrato, o que for menor. Se o servidor será trocado em cinco anos, cinco anos é o horizonte. Se o contrato de serviço é de três, o horizonte é três.

Vale explicitar o horizonte na própria apresentação, junto do que acontece se ele mudar. Mostrar o resultado em dois cenários de prazo convence mais do que defender um número único. De quebra, antecipa a objeção que viria na reunião.

Viés: quem levanta o número quer o projeto aprovado

A última barreira não é técnica. Quem monta o business case normalmente é quem deseja executar o projeto, o que produz otimismo sistemático nas estimativas de ganho e pessimismo seletivo nas de custo.

Isso não costuma ser má-fé. É consequência de quem responde a pergunta. Áreas que resistem à mudança produzem o viés espelhado, informando dados que reforçam a inviabilidade.

O contorno é de governança, não de planilha: separar quem estima de quem valida. Alguém sem interesse no resultado precisa revisar as premissas. O mínimo aceitável é registrar cada uma por escrito, com a fonte ao lado.

O rigor de medição também pesa nesse arranjo.

A pesquisa anual do PMI sobre projetos mostrou que quem tem alto domínio de negócio usa em média 9,1 fatores para medir desempenho, contra 6,3 dos demais. Apenas 18% dos 2.254 respondentes chegam a esse nível.

Em outras palavras, medir por mais ângulos é raro e distingue quem entrega resultado. Um cálculo apoiado em várias dimensões resiste melhor ao contraditório do que um número solitário.

O checklist que destrava o cálculo

Reunindo as saídas de cada barreira, o trabalho útil se concentra em seis decisões tomadas antes da planilha. Nenhuma delas exige ferramenta nova.

Repare que cinco das seis são decisões tomadas antes do primeiro dia de execução. Quando o projeto termina e alguém pergunta pelo retorno, a janela para responder bem já fechou há muito tempo.

Para transformar essas respostas em apresentação, vale combinar o checklist com as técnicas descritas em como aprovar projetos de TI. Quem prefere ver a conta montada passo a passo encontra os exemplos numéricos no guia de ROI.

Quando o ROI não é a métrica certa

Existe uma classe de projeto em que insistir no ROI produz distorção. São os investimentos de conformidade, de segurança e de continuidade, cujo retorno é uma perda que não aconteceu.

Nesses casos, o denominador honesto não é ganho: é risco evitado. A pergunta correta passa a ser qual a probabilidade do evento, qual o impacto financeiro se ele ocorrer e quanto custa reduzir essa exposição.

Esse cálculo ganha base concreta quando existe histórico próprio de incidentes. Sem ele, a conversa volta ao terreno da opinião.

O levantamento anual de interrupções do Uptime Institute registra que quase 40% das organizações tiveram apagão grave por erro humano em três anos. Desses casos, 85% vêm de falha de procedimento.

Vale dimensionar também o contexto do gasto. A projeção de gastos globais da consultoria Gartner aponta US$ 6,37 trilhões em TI para 2026, alta de 14,2% sobre o ano anterior.

Volume desse tamanho exige mais de um critério de avaliação. Apresentar payback, custo evitado ou exposição residual costuma ser mais defensável do que forçar um ROI onde ele não cabe.

Escolher a métrica errada é, no fim, apenas mais uma forma de errar o cálculo. A decisão entre elas fica mais simples com a base conceitual de indicadores e como defini-los.

Conclusão

As dificuldades para calcular o ROI em projetos de TI não vêm da matemática financeira. Vêm de seis pontos concretos: intangíveis sem preço, custos que aparecem depois, ganhos disputados por outras áreas, ausência de linha de base, horizonte mal escolhido e viés de quem levanta o número.

Cinco desses seis pontos se resolvem antes de o projeto começar. Definir a métrica exclusiva, registrar o valor de partida, delimitar o custo total, fixar o horizonte e nomear um revisor sem interesse custa poucas horas de reunião. Fazer isso depois da entrega é praticamente impossível.

Vale encerrar com a consequência prática de ignorar tudo isso. Um projeto sem esse preparo não fica sem ROI: fica com um ROI frágil, que colapsa na primeira pergunta detalhada e contamina a credibilidade do pedido seguinte. Se quiser estruturar a medição antes do próximo investimento, converse com um especialista da OpServices.