Dificuldades para aprovar projetos de TI: o que reprova um bom pedido

Autor: Pedro Tebaldi PM do KeepGreen

Publicado nov/2014Atualizado ago/2026

Existe um tipo de reprovação que confunde qualquer gestor de TI. O projeto tinha problema claro, solução adequada, retorno calculado e apresentação bem feita. Mesmo assim veio o não, sem explicação convincente, encerrado com um vago “vamos retomar depois”.

Quando isso acontece, a causa quase nunca está no slide. Está no percurso que o pedido faz depois de sair da sua mesa: o calendário em que ele chegou, a pessoa que o recebeu, a conta contábil em que foi classificado e a fila em que entrou.

Este artigo mapeia essas barreiras. Ele não ensina a montar o caso de negócio, tema que já tem lugar próprio aqui no blog. O objetivo é outro: ajudar você a identificar exatamente o que travou o seu pedido, para atacar a causa certa na próxima tentativa.

Por que um bom projeto de TI é reprovado

A aprovação de projetos de TI trava por três famílias de motivos: calendário, governança e narrativa. O calendário determina se existe verba naquele momento. A governança define quem tem poder para dizer sim. A narrativa decide se o pedido faz sentido para quem decide.

Só a terceira família costuma receber atenção. As duas primeiras decidem antes, quase sempre sem aparecer na justificativa que chega até você.

A explicação mais comum é a falta de dinheiro. A projeção da Gartner para 2026 aponta alta de 14,2% no gasto mundial com TI, para US$ 6,37 trilhões.

Ou seja, o orçamento existe e cresce. O que é escasso não é o dinheiro, é a posição na fila. Seu projeto não disputa contra o cofre fechado, disputa contra outros projetos que chegaram antes, melhor posicionados ou apadrinhados por quem decide.

Essa mudança de perspectiva reorganiza o diagnóstico. Em vez de perguntar “como convenço a diretoria”, a pergunta útil passa a ser “em que ponto do percurso o meu pedido parou”.

Barreiras de calendário: quando pedir muda a resposta

O ciclo orçamentário é a barreira mais invisível de todas, porque ela reprova sem nunca aparecer na justificativa. Empresas de médio e grande porte fecham o orçamento do ano seguinte entre setembro e novembro. Um pedido novo que chega em março disputa sobras, não o bolo principal.

Existem três momentos distintos, com regras diferentes. Durante o ciclo de planejamento, seu projeto compete pela alocação inicial e precisa de uma estimativa razoável, mesmo que grosseira. Fora do ciclo, ele só entra por remanejamento, o que exige tirar verba de outro lugar.

Já no fim do exercício, aparece a janela oposta: verba aprovada que não foi executada e que se perde na virada do ano. Nessa hora, um projeto pronto para começar tem vantagem enorme sobre um projeto melhor que ainda precisa de três meses de definição.

A lição prática é simples. Mantenha uma estimativa atualizada dos seus dois ou três projetos prioritários durante o ano inteiro. Quando a janela abrir, quem tem número pronto entra. Quem precisa de duas semanas para levantar custo perde a vez.

Há ainda o caso do projeto que atravessa exercícios. Iniciativas de infraestrutura costumam consumir verba em dois ou três anos consecutivos, o que exige compromisso plurianual. Se a empresa aprova apenas ano a ano, divida o pedido em fases com valor próprio e entrega útil ao fim de cada uma.

Essa divisão protege o projeto de um risco concreto: a troca de prioridade no meio do caminho. Uma fase concluída entrega valor mesmo que a seguinte não seja aprovada, enquanto um projeto interrompido pela metade não entrega nada.

Barreiras de governança: quem pode dizer sim

A segunda família de barreiras vem da estrutura de decisão. Ela costuma ser invisível para quem está fora dela, o que gera muito esforço direcionado à pessoa errada.

O interlocutor não tem alçada

Toda empresa define faixas de valor com aprovadores diferentes. Uma coisa é um pedido que o gerente resolve, outra é um valor que sobe para diretoria, conselho ou matriz. O detalhe que derruba projetos é assimétrico: quem não tem alçada para aprovar quase sempre tem autonomia para negar.

Antes de apresentar, descubra em que faixa o seu pedido cai e quem assina naquela faixa. Uma reunião de trinta minutos com a pessoa certa vale mais que três apresentações para quem só pode encaminhar.

O comitê de investimentos tem critério próprio

Em organizações com governança madura, projetos acima de um determinado valor passam por um comitê que avalia todo o portfólio junto. Esse fórum não compara o seu projeto com o nada: compara com os outros pedidos da mesma rodada.

Comitês costumam ter critérios publicados: aderência à estratégia, risco, prazo de retorno, dependência entre iniciativas. Ler esse critério antes de escrever o pedido muda o texto inteiro. Estruturas de governança de TI bem definidas tornam esse caminho previsível.

Falta patrocinador fora da TI

Projeto que só a TI quer costuma morrer na primeira restrição de caixa. Quando a área de negócio que sofre o problema assume o pedido como dela, a conversa muda de natureza: deixa de ser custo de tecnologia e passa a ser solução de um problema operacional com dono.

Procure o gestor que mais perde com o problema atual e construa o pedido junto com ele. O papel do diretor de TI aqui é articular esse apoio antes da reunião, não durante.

A fila de portfólio já estava formada

Poucos projetos são reprovados por serem ruins. A maioria é adiada por estar atrás de outros na fila, seja por chegarem antes, seja por atenderem uma prioridade declarada do ano. É a barreira mais comum e a menos explicada ao solicitante.

Nesse cenário, atacar o mérito do próprio projeto não muda nada. O que move a posição na fila é a dependência: demonstrar que uma iniciativa já aprovada precisa da sua para funcionar transforma o pedido em pré-requisito, não em concorrente.

Compras entra tarde no processo

Muita gente comemora a aprovação e descobre depois que o prazo de contratação inviabiliza o cronograma. Homologação de fornecedor, análise jurídica, exigência de três propostas e prazo de pagamento consomem semanas que ninguém colocou no plano.

Envolva compras na fase de estimativa, não na de execução. Saber que o fornecedor preferido ainda não está homologado muda a data prometida e evita um segundo desgaste depois do sim.

Pergunte o prazo médio de homologação de um fornecedor novo e inclua esse número no cronograma que você apresenta. Um projeto que promete entrega em noventa dias, com sessenta deles consumidos em contrato, nasce atrasado.

Barreiras de narrativa: o que o pedido não conta

A terceira família é a mais discutida, então vale tratar apenas do que costuma escapar. Três lacunas aparecem com frequência mesmo em pedidos bem escritos.

A primeira é a ausência de linha de base. Sem o número de hoje, não existe ganho demonstrável amanhã. Quem promete reduzir indisponibilidade sem saber quantas horas perdeu no último semestre está pedindo um ato de fé. Esse é um dos pontos tratados nas barreiras do cálculo de retorno.

A segunda é o custo apresentado pela metade. Licença é só o começo: implantação, treinamento, integração, suporte e o tempo da sua equipe entram na conta. Um pedido que ignora o custo total de propriedade perde credibilidade no momento em que alguém do financeiro faz a pergunta óbvia.

A terceira é o silêncio sobre o risco de não fazer. Todo pedido descreve o benefício da ação, quase nenhum quantifica a consequência da inércia. Quem decide precisa comparar dois cenários, não avaliar um.

Existe ainda uma quarta lacuna, mais sutil: a estimativa apresentada como número único. Um valor exato para algo que ninguém executou antes soa falso para qualquer executivo experiente, porque todos sabem que projetos variam.

Prefira faixas com premissa declarada. Dizer que o projeto custa entre um valor mínimo e um máximo, explicando o que empurra para cada extremo, transmite domínio do assunto.

Essa transparência sobre a incerteza é o que a disciplina de portfólio recomenda, conforme as pesquisas de maturidade em gestão publicadas pelo PMI.

Como descobrir qual barreira está travando o seu projeto

Cada barreira produz um sintoma característico na reunião ou na resposta que você recebe. Use a tabela abaixo para identificar a sua antes de refazer o pedido.

Repare que apenas duas das sete linhas se resolvem melhorando a apresentação. As outras cinco exigem mudar o caminho do pedido, não o seu conteúdo.

Vale considerar também que as barreiras se acumulam. Um pedido pode estar ao mesmo tempo fora do ciclo, sem patrocinador e classificado na conta errada, embora a reunião revele apenas uma delas.

Por isso a pergunta reservada depois do não vale mais que qualquer suposição: ela mostra qual barreira o decisor enxerga como principal. Trate uma de cada vez, começando por essa, em vez de refazer tudo ao mesmo tempo.

CAPEX ou OPEX: a classificação muda o caminho

A mesma solução pode ser comprada de duas formas, com percursos de aprovação bem diferentes. Entender isso resolve um dos “nãos” mais frustrantes, aquele em que existe verba na empresa, porém não na conta em que você pediu.

Investimento em ativo, o CAPEX, costuma passar por comitê, sofrer depreciação ao longo dos anos e concorrer com obras, frota e expansão. Despesa operacional recorrente, o OPEX, costuma ter alçada mais baixa, entra no orçamento da área e afeta o resultado do ano corrente.

Um aviso necessário: escolher a conta não é manobra contábil de quem pede. A classificação segue a natureza da despesa e a política da empresa, então converse com o financeiro antes. O ponto aqui é outro: entender que existe mais de um desenho possível para a mesma necessidade, com caminhos de aprovação distintos.

O que fazer depois de uma reprovação

A reprovação carrega informação valiosa que quase todo mundo descarta. Três movimentos aumentam bastante a chance na rodada seguinte.

O primeiro é perguntar a razão específica, de preferência em conversa reservada e sem defender o projeto. A pergunta útil é direta: o que precisaria ser diferente para isso ser aprovado. A resposta costuma revelar a barreira real, que raramente é a mencionada na reunião.

O segundo é reduzir o escopo do pedido. Um piloto de noventa dias em um sistema crítico, com meta declarada, custa uma fração e produz o dado que faltava. A partir daí, o segundo pedido deixa de ser promessa e passa a ser extensão de um resultado observado.

O terceiro é registrar o custo da espera. Sempre que o problema reaparecer, anote a data, a duração e o efeito. Seis meses depois, essa lista simples costuma valer mais que qualquer estimativa. É o mesmo raciocínio que sustenta a priorização de projetos de monitoração no portfólio.

O quarto movimento é escolher a hora de voltar. Reapresentar o mesmo pedido duas semanas depois queima crédito, porque nada mudou no intervalo. Espere um gatilho concreto: a próxima rodada orçamentária, um incidente que confirme o risco previsto ou a chegada de um número de linha de base que você não tinha.

Identificada a barreira, o próximo passo é reconstruir o pedido com método. O caminho completo está no nosso guia sobre como montar o business case que a diretoria entende. Para a disciplina de condução depois do sim, vale o material de gerenciamento de projetos de TI.

Conclusão

A maior parte do esforço de aprovação vai para a apresentação, embora a apresentação responda por uma fração pequena das reprovações. Calendário, alçada, fila de portfólio, patrocínio e classificação contábil decidem antes, quase sempre em silêncio.

O gestor que entende esse percurso muda a própria rotina. Ele mantém estimativas vivas o ano inteiro, sabe quem assina em cada faixa de valor, conhece o critério do comitê, cultiva um patrocinador no negócio e mede o custo do problema enquanto espera. Nada disso aparece em um slide, porém tudo isso aparece no resultado.

Comece pelo mais barato de todos: medir. Um número de linha de base coletado hoje é o que transforma o próximo pedido em uma comparação objetiva, em vez de uma promessa. Sem medição, todo pedido de TI vira uma questão de confiança pessoal, algo que não costuma sobreviver a um corte de orçamento.

Quer construir a linha de base que sustenta o seu próximo pedido? Fale com um especialista da OpServices e veja como medir o custo real dos problemas do seu ambiente.