Acreditar que seu projeto é único causa mais fracassos
O viés de unicidade — acreditar que seu projeto não tem precedentes relevantes — é uma das causas mais documentadas de estouro de orçamento e prazo em gestão de projetos. E é quase sempre uma ilusão: entre 59 projetos classificados como “altamente únicos” por seus gestores, todos tinham predecessores similares na mesma organização ou setor.
Evidências
- Análise de 1.300+ projetos de TI: cada ponto na escala de unicidade (1-10) = 5pp a mais de estouro de orçamento
- Projetos com unicidade máxima: 45pp a mais de estouro que projetos com unicidade mínima
- 37% dos projetos com unicidade máxima excederam orçamento em mais de 75%
- 100% dos 59 projetos “altamente únicos” tinham precedentes comparáveis quando investigados com rigor
Mecanismo: a “inside view” de Kahneman
O viés de unicidade alimenta o que Daniel Kahneman chama de “visão de dentro” (inside view): tomar decisões baseadas apenas nas próprias crenças e experiências pessoais, sem consultar dados de situações comparáveis.
Consequência: subestimação não apenas do risco médio, mas especialmente da probabilidade de resultados catastróficos raros.
O exemplo mais dramático: a NASA e o acidente do Challenger. A visão de dentro dos gestores sobre o risco de voo era tão estreita que levou a subestimação radical da probabilidade de explosão — com consequências fatais (investigação de Richard Feynman).
Por que o viés acontece
- O que é único para você parece único para todos — mas outros podem ter experiência equivalente que você desconhece
- Projetos novos, complexos, politicamente sensíveis e com muitas variáveis desconhecidas são mais propensos a serem percebidos como únicos
- A própria literatura de gestão de projetos reforça o viés (PMI e APA definem projetos como “esforços únicos”)
- Apresentar um projeto como único aumenta a chance de apoio e financiamento — há incentivo para manter a ilusão
O caso do SMS
Os inventores do SMS achavam que nada era comparável ao que criaram — único e não importante. Quando questionados, a plateia logo listou: telégrafo, rádio, telefone, fax — todos predecessores que mostrariam a curva S de adoção (início lento, aceleração depois). Não buscaram precedentes porque perceberam o projeto como único. Resultado: subestimaram o potencial e o padrão de adoção.
A antídoto: a “outside view” e o Reference Class Forecasting
Outside view: antes de fazer qualquer estimativa, perguntar “quem já fez algo parecido?” — dentro da organização, do setor, do mundo.
Técnicas:
- Reference Class Forecasting — prever o futuro comparando com o que aconteceu em situações similares (probabilidade histórica de overruns para a classe de projetos comparáveis)
- Similarity-based forecasting — usar desempenho passado de sistemas/projetos similares
- Premortems — assumir que o projeto falhou e perguntar “por que isso aconteceu?” (prospective hindsight)
- Noise audits — medir o quanto fatores irrelevantes influenciam as previsões dos decisores
Implicações
- Antes de qualquer estimativa de custo/prazo de projeto, buscar ativamente projetos comparáveis — dentro e fora da organização
- Se não houver análogos diretos: decompor o projeto em componentes (módulos, tarefas) que podem ser comparados separadamente
- Desafiar sistematicamente a afirmação “este projeto é único” — é quase sempre falsa
Fonte: The Uniqueness Trap - Flyvbjerg et al — Bent Flyvbjerg