# Estimativa de projeto de tecnologia: apresente uma faixa > Em 1.471 projetos de TI, um em seis estourou o custo em média 200%. Veja como levar à diretoria uma faixa de custo com gatilhos de revisão, não um número único. - Autor: Marlon Trettin - Publicado: 2026-10-27 · Atualizado: 2026-10-27 - Idioma: pt-BR - Canonical: https://yowpi.com/blog/estimativa-de-projeto-de-tecnologia-apresente-uma-faixa --- Leve à diretoria uma faixa de custo com gatilhos de revisão, não um número único. Num estudo com 1.471 projetos de TI, o custo estourou 27% em média, mas a média esconde o risco: cerca de um em seis projetos estourou 200%. Um número único promete uma precisão que o histórico não sustenta. ## TL;DR - O estouro de custo em projetos de tecnologia não se distribui como uma curva comportada. Numa análise de 5.392 projetos, poucos estouram muito e puxam o risco para cima. - Em 1.471 projetos de TI estudados em Oxford, o custo estourou 27% em média. Um em seis estourou cerca de 200%, com atraso de quase 70%. - O Tesouro britânico orienta ajustar custo, benefício e prazo com base em projetos parecidos, porque quem estima tende a ser otimista. - O pedido mais fácil de defender é uma faixa por etapa, com premissas escritas e um gatilho que obriga a voltar à diretoria. ## Por que um número único é o formato errado? Porque ele transforma uma estimativa em promessa. Quando você diz "R$ 480 mil" e o projeto chega a R$ 600 mil, a conversa deixa de ser sobre o que mudou e passa a ser sobre quem errou. Muita diretoria já viu isso acontecer e desconta o número antes de ouvir o resto. A faixa muda o que está em discussão. Ela mostra onde a estimativa é firme e onde não é, e quanto a diferença pode custar. Quem apresenta uma faixa com premissas escritas mostra que conhece o risco, em vez de escondê-lo. ## O que os dados dizem sobre o estouro de projetos de tecnologia? Dizem que o problema está na cauda, não na média. Bent Flyvbjerg e Alexander Budzier, da Escola de Negócios Saïd, da Universidade de Oxford, analisaram 1.471 projetos de TI e publicaram o resultado na *Harvard Business Review* em 2011. O estouro médio foi de 27%. Cerca de um em seis projetos, porém, teve custo 200% acima do previsto em média, com atraso de quase 70%. Em 2022, Flyvbjerg e outros cinco autores ampliaram a base para 5.392 projetos de TI, no *Journal of Management Information Systems*. O achado é que os estouros seguem uma lei de potência: muitos projetos com desvios pequenos e poucos com desvios extremos. Quem planeja como se o erro fosse simétrico, em torno de uma média, subestima a chance de um estouro grande. Os autores propõem, com simulação, que a interdependência entre os componentes tecnológicos ajuda a explicar a cauda: um problema num componente dispara outros. Há um limite que vale dizer em voz alta. A amostra de 2011 é de projetos grandes, com custo médio de US$ 167 milhões por projeto, e 92% deles vinham de órgãos públicos. Os percentuais não são uma previsão para um projeto do seu porte. O que você leva deles é o formato do risco: poucos projetos concentram a maior parte do estouro, e a média não avisa qual será o seu. O Tesouro do Reino Unido chega à mesma conclusão pelo lado da gestão pública. O suplemento do Green Book sobre viés de otimismo afirma que quem avalia projetos tende a ser otimista demais e que custos, benefícios e prazos devem ser ajustados explicitamente, com base em projetos passados ou semelhantes. O guia anexo à página traz percentuais de ajuste por categoria genérica de projeto, para usar quando faltam dados próprios mais confiáveis, e não os reproduzimos aqui. ## Como montar uma faixa que a diretoria consiga aprovar? Com três decisões: dividir o projeto em etapas, escrever as premissas de cada uma e definir de antemão o que obriga a voltar para uma nova decisão. A primeira é dividir. A própria recomendação de Flyvbjerg e Budzier é quebrar projetos grandes em partes de tamanho, complexidade e duração limitados, e cada parte limita quanto um estouro pode custar. Cada etapa precisa entregar algo que funcione sozinho, para que a diretoria possa parar ali sem perder o que já pagou. A segunda é escrever as premissas. A faixa de cada etapa depende de coisas que você ainda não verificou: a qualidade dos dados que serão migrados e o número de integrações, por exemplo. Liste cada uma. Quando uma delas falha, o gatilho dispara por um motivo que todos já conheciam, e não por surpresa. A terceira é o gatilho. Combine antes quando o projeto volta à diretoria: quando o custo acumulado da etapa passa do limite da faixa, quando uma premissa se mostra falsa ou quando surge um escopo que não estava no pedido. Sem essa regra, a faixa vira uma desculpa para gastar mais. A faixa nasce do seu histórico quando ele existe. Se a empresa já entregou projetos parecidos, compare a estimativa original com o custo final de cada um e use a dispersão como base. Se não existe histórico, a faixa deve ser mais larga e a primeira etapa, menor, para que o primeiro projeto gere o dado que falta. ## Um exemplo prático: o pedido de um sistema de ordens de produção O cenário é hipotético, e os valores são ilustrativos, não medições. Uma indústria de embalagens com 120 pessoas quer trocar o controle de ordens de produção, hoje feito em planilhas e no ERP, por um sistema interno. A gerente de inovação tem duas formas de levar o pedido à diretoria. Na primeira, apresenta um orçamento de R$ 480 mil. Se a conta fechar em R$ 600 mil, a discussão será sobre o erro dela. Na segunda, apresenta três etapas, cada uma com faixa e com a premissa principal escrita. A etapa 1, o núcleo de ordens e apontamento de produção, vai de R$ 120 mil a R$ 170 mil e supõe que o cadastro de produtos esteja limpo. A etapa 2, a integração com o ERP e com a expedição, vai de R$ 180 mil a R$ 260 mil e supõe que o ERP exponha os dados necessários. A etapa 3, os painéis gerenciais e o portal do cliente, vai de R$ 120 mil a R$ 170 mil. A soma é uma faixa de R$ 420 mil a R$ 600 mil. O pedido imediato é só a etapa 1, com teto de R$ 170 mil. Antes de aprovar, a gerente pergunta à diretoria uma coisa simples: se a etapa 1 custar o dobro, a empresa segue? Essa pergunta é nossa, não uma regra dos estudos, mas aplica a ideia deles de testar se a empresa absorve um estouro. Se a resposta for não, o problema é de tamanho da etapa, e a etapa encolhe antes de começar. O gatilho também fica combinado: se o custo acumulado da etapa 1 passar de R$ 170 mil, ou se o cadastro de produtos se mostrar pior do que a premissa, o projeto volta à diretoria antes de a etapa 2 começar. O dado da etapa 1 vira o histórico que estreita a faixa das seguintes. Entregar em etapas não é teoria para nós. No [case da UniTrust](/cases/unitrust), IMO de seguros dos Estados Unidos, a Yowpi foi contratada em agosto de 2022 e colocou o primeiro sistema no ar em duas semanas. A plataforma evoluiu sobre essa base ao longo dos anos seguintes. ## Onde a faixa se encaixa nos outros argumentos do pedido A faixa resolve o custo, e o pedido ainda precisa dos outros argumentos. [Adiar um projeto de tecnologia tem custo](/blog/adiar-projeto-de-tecnologia-custo-do-atraso) trata do outro lado da conta: o que a empresa paga enquanto espera. E [Justificar investimento em tecnologia para a diretoria](/blog/justificar-investimento-em-tecnologia-diretoria) mostra como ligar o pedido a um resultado que a diretoria já acompanha. A faixa de custo é a parte que impede que os dois acabem desmentidos pelo primeiro estouro. ## Perguntas frequentes **Não consigo justificar o investimento agora. Uma faixa não enfraquece o pedido?** Não necessariamente. A faixa mostra que o risco foi considerado, e um primeiro compromisso pequeno, só a etapa 1 com teto, é mais fácil de aprovar do que um projeto inteiro de preço fechado. O que enfraquece o pedido é uma faixa sem premissas. **A implementação vai exigir tempo demais do time. Como as etapas ajudam?** Elas limitam o tempo que você pede de cada vez. Em vez de reservar a equipe por meses, você pede as horas da etapa 1 e usa o que ela mostrar para estimar a seguinte. A revisão no gatilho é curta: custo acumulado contra a faixa e estado das premissas. **Não vejo como mensurar o resultado. Isso muda com a faixa?** Muda o momento em que você mede. Defina na etapa 1 qual indicador vai mostrar o ganho e meça a linha de base antes de começar. Assim, na revisão, a diretoria vê custo e resultado juntos, e a decisão de seguir para a etapa 2 se apoia em dado, não em expectativa. ## O próximo passo Se o seu pedido de investimento hoje está preso a um número único, o Diagnóstico de Arquitetura Operacional, uma conversa de 30 minutos, é um convite para desenhar as etapas, as premissas e os gatilhos antes de levar o projeto à diretoria: [fale com a Yowpi](/contato).