Como aprovar projetos de TI: o business case que a diretoria entende

Autor: Pedro Tebaldi PM do KeepGreen

Publicado mai/2014Atualizado ago/2026

A cena se repete em quase toda empresa. O projeto de TI é tecnicamente impecável, resolve um gargalo real e já tem fornecedor escolhido. Mesmo assim, volta da reunião de orçamento sem aprovação.

Na maioria dos casos o problema não está no projeto. Está na tradução. A equipe apresenta latência, throughput e disponibilidade para um comitê que decide com base em receita, custo evitado e exposição a risco. São dois vocabulários diferentes na mesma sala.

Este guia percorre o caminho inverso: parte do que a diretoria já mede e chega até a especificação técnica. São 7 passos para transformar uma necessidade de infraestrutura em um caso de negócio defensável, com evidência que sustenta o pedido depois que a reunião termina.

O que decide não é o orçamento, é a tradução

Falta de verba costuma ser a explicação mais confortável. Raramente é a verdadeira.

A Gartner projeta alta de 14,2% nos gastos mundiais com TI em 2026, até US$ 6,37 trilhões, conforme a projeção divulgada pela consultoria.

O dinheiro existe, portanto. O que existe também é fila: marketing, comercial, operações e TI disputam a mesma verba, cada um com um caso melhor ou pior contado. Quem perde não é quem tem o pior projeto. É quem tem a pior tradução.

Na prática, três padrões derrubam a aprovação de projetos de TI antes mesmo da discussão técnica começar. O pedido chega como despesa, não como retorno. O risco de manter tudo como está nunca é quantificado. E o projeto é grande demais para caber em um único “sim”.

Passo 1: traduza o problema técnico em problema de negócio

Antes de escrever qualquer linha do documento, responda a uma pergunta única: qual processo da empresa para, degrada ou fica mais caro por causa disso?

A resposta precisa nomear um processo real, com dono conhecido fora da TI. Emissão de nota fiscal, atendimento no call center, fechamento contábil, expedição de pedidos. Se você não consegue nomear o processo, o projeto ainda não está pronto para ser apresentado.

Esse exercício muda o interlocutor. Um pedido de storage vira um pedido do diretor de operações, que passa a defender o projeto junto com você. Aliados internos pesam mais do que slides bem feitos, porque o comitê confia em quem sente a dor.

Vale registrar a cadeia inteira por escrito: componente técnico, sistema afetado, processo de negócio impactado e área responsável. Essa cadeia é a espinha dorsal de todo o restante do caso.

Passo 2: quantifique o custo de não fazer nada

Este é o argumento mais forte disponível para infraestrutura, também o mais ignorado. Todo projeto concorre com uma alternativa silenciosa: manter tudo como está. Quando ninguém precifica essa alternativa, ela parece gratuita.

Comece pelo cálculo básico do custo por hora parada. Divida o faturamento do período pelas horas úteis desse período, aplique a fração que depende do sistema em questão e some o custo da equipe ociosa durante a parada. O resultado não precisa ser exato. Precisa ser defensável.

Em seguida, some o que já aconteceu. Quantas horas de indisponibilidade o ambiente acumulou nos últimos doze meses? Quantos chamados críticos vieram da mesma causa raiz? Quantas horas de equipe foram consumidas em contorno manual? Esses dados já existem nos registros de incidentes.

Se você nunca fez essa conta, o material sobre o custo real de um downtime mostra as variáveis que costumam ficar de fora, como multas contratuais e retrabalho posterior.

Custo evitado também é resultado

Projetos defensivos não geram receita nova. Geram receita preservada, que aparece no orçamento como perda que não ocorreu.

Apresente esse valor com a mesma seriedade de um ganho. A frase que funciona na reunião é direta: sem o projeto, a empresa continua exposta a um custo recorrente conhecido. Com ele, essa exposição cai para um patamar declarado.

Passo 3: escolha a métrica financeira certa

ROI, payback e TCO não são sinônimos. Cada um responde a uma pergunta diferente. Usar o indicador errado enfraquece um caso que seria sólido.

A regra prática é simples. Projeto que cria capacidade nova pede cálculo de retorno sobre o investimento. Projeto que substitui um custo existente pede payback. Decisão entre duas arquiteturas pede custo total de propriedade, porque o preço de aquisição raramente é o maior componente da conta.

Um cuidado adicional: leve sempre a memória de cálculo em anexo. O comitê não vai auditar a planilha na reunião, mas saber que ela existe muda a percepção de rigor do pedido.

Passo 4: ancore o projeto nos indicadores que a empresa já acompanha

Toda empresa tem um painel que a diretoria olha todo mês. Projetos que movem um número desse painel são aprovados em ritmo diferente dos demais.

Descubra quais são esses números antes de escrever o documento. Podem ser margem por produto, prazo médio de entrega, índice de satisfação, custo por atendimento. Depois, conecte o projeto a pelo menos um deles com uma relação causal explícita.

Essa conexão evita a armadilha mais comum: apresentar apenas indicadores de performance técnicos, como disponibilidade e tempo médio de resposta. Eles importam, mas funcionam como evidência intermediária, não como objetivo final.

Quando o projeto nasce dentro do planejamento estratégico de TI já aprovado, o trabalho fica mais fácil ainda. O pedido deixa de ser uma iniciativa isolada e vira a execução de algo que a empresa já decidiu fazer.

Passo 5: declare os riscos antes que perguntem

Existe uma intuição errada de que apontar riscos enfraquece a proposta. O efeito é o oposto. Um caso sem riscos declarados soa ingênuo. O comitê então passa a procurar sozinho o que você deixou de fora.

Liste os riscos reais com probabilidade, impacto e mitigação já definida. Essa disciplina vem da gestão de risco em TI e transforma uma objeção potencial em demonstração de preparo.

Passo 6: quebre o pedido em um roadmap com entregas curtas

Comitês não reprovam apenas projetos ruins. Reprovam também projetos grandes demais para o nível de confiança atual da relação.

Um pedido único de doze meses concentra todo o risco em uma única decisão. O mesmo escopo dividido em três fases de quatro meses distribui esse risco, permite correção de rota e cria pontos naturais de renegociação.

Cada fase precisa entregar algo que funcione sozinho. Fase que só faz sentido quando a seguinte for aprovada não reduz risco nenhum, apenas adia a discussão inteira para depois.

Esse fatiamento também melhora a execução, porque força escopo explícito por etapa. Boas práticas de gerenciamento de projetos de TI tratam o marco de fase como ponto de decisão, não como formalidade de cronograma.

Passo 7: leve prova externa e prova interna

Na reta final da apresentação, dois tipos de evidência sustentam a decisão. A prova externa mostra que outras empresas do mesmo porte resolveram o problema pelo mesmo caminho. A prova interna mostra que a sua operação sabe medir o que promete.

Prova externa vem de casos comparáveis, referências de fornecedor e benchmarks de mercado do setor. Evite estudos genéricos, prefira empresas com perfil de operação semelhante ao seu.

A prova interna é mais poderosa, porque vem dos seus próprios dados. Um histórico de monitoramento de TI com registro de incidentes, capacidade e disponibilidade transforma promessa em série histórica verificável.

É o que permite dizer, com números na tela, qual era a linha de base antes do projeto anterior e o que mudou depois dele. Comitês aprovam com mais facilidade quem já provou uma vez.

Depois do sim: como sustentar a aprovação seguinte

A aprovação não encerra o ciclo. Ela abre uma janela de observação em que a diretoria confere se o que foi prometido aconteceu.

Estabeleça a linha de base antes de começar a execução. Registre onde estavam os indicadores no dia zero, com data e fonte. Sem esse retrato inicial, qualquer ganho posterior vira opinião.

Reporte em intervalos curtos, mesmo quando a notícia é ruim. Um desvio comunicado cedo custa credibilidade baixa, enquanto o mesmo desvio descoberto pelo comitê custa a confiança inteira.

Ao final, feche o ciclo com um comparativo honesto entre o prometido e o entregue. Esse documento vira o primeiro anexo do próximo pedido. É ele que encurta a discussão da próxima rodada orçamentária.

Conclusão

A aprovação de projetos de TI raramente depende de argumento técnico melhor. Depende de tradução: nomear o processo de negócio afetado, precificar o custo de não agir, escolher o indicador financeiro adequado ao tipo de projeto, ancorar tudo em números que a empresa já acompanha e declarar riscos com mitigação definida.

Os 7 passos deste guia formam um método repetível. Quem aplica esse método uma vez descobre que o esforço maior está na primeira rodada, porque a base de dados de incidentes, capacidade e disponibilidade passa a servir para todas as seguintes.

O passo que mais trava as equipes é justamente o da evidência interna. Sem histórico confiável de operação, o pedido depende de estimativa. Estimativa perde para quem chega com série histórica.

Se a sua operação ainda não tem esse histórico organizado, comece por aí. Fale com um especialista da OpServices para entender como estruturar a medição que sustenta o próximo business case.