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.
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, 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 trata do outro lado da conta: o que a empresa paga enquanto espera. E Justificar investimento em tecnologia para a 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.
Cases relacionados
Reconheceu a sua operação neste artigo?
Agende o Diagnóstico de Arquitetura Operacional: 30 minutos para mapear onde está o gargalo da sua operação. Sem proposta na primeira conversa.
Agendar diagnóstico