Três fracassos desastrosos em gerenciamento de projetos e o que eles nos ensinam

Um projeto que dá errado é frustrante. Um projeto que dá catastroficamente errado vira estudo de caso. A diferença entre um e outro quase sempre se resume a quão cedo os problemas foram identificados e se alguém tinha a autoridade e os dados para agir a tempo.

Estudar fracassos reais de projetos é uma das formas mais eficazes de aprimorar a sua própria prática em gerenciamento de projetos. Os três casos a seguir abrangem setores, décadas e escalas diferentes, mas compartilham um fio condutor: os sinais de alerta existiam muito antes do colapso final. Em todos eles, uma identificação de riscos mais robusta, um acompanhamento de custos mais rigoroso e um engajamento mais deliberado com as partes interessadas poderiam ter mudado o resultado.

O sistema automatizado de bagagens do Aeroporto Internacional de Denver

O objetivo: Em 1991, o Aeroporto Internacional de Denver (DIA) decidiu construir um sistema totalmente automatizado de manuseio de bagagens. Etiquetas com código de barras direcionariam cada mala por meio de “veículos de destino codificado”, integrando os três terminais e reduzindo significativamente o tempo de rotação das aeronaves.

O que deu errado:

O projeto enfrentou problemas em todas as dimensões que um gerente de projetos precisa monitorar: escopo, prazo, custo, qualidade e risco.

• Cronograma irreal. O DIA contratou a BAE Systems para construir o sistema, mas ignorou os prazos estimados pela BAE e insistiu no seu próprio prazo de dois anos. A tecnologia não havia sido testada nessa escala e o cronograma não deixava margem para os imprevistos inevitáveis.
• Definição de escopo insuficiente. O sistema automatizado foi concebido sem consultar as companhias aéreas que iriam utilizá-lo. Requisitos essenciais para bagagens de grande porte, equipamentos esportivos e esteiras de manutenção separadas foram ignorados ou tratados tarde demais.
• Sem gestão de riscos estruturada. Um projeto dessa complexidade exigia um registro de riscos formal, com avaliações de probabilidade e impacto para cada premissa importante. Em vez disso, os riscos foram tratados de forma reativa, uma crise por vez. Uma matriz de riscos cruzando probabilidade e impacto teria revelado várias dessas ameaças antes que comprometessem o cronograma.
• Custos descontrolados. Sem uma linha de base para comparar os custos reais, os estouros se acumularam sem disparar alertas antecipados. A inauguração do aeroporto atrasou 16 meses, as perdas atingiram aproximadamente US$ 2 bilhões e o sistema automatizado inteiro foi desativado em 2005.

Um projeto que pula a análise de partes interessadas e o planejamento de riscos não está economizando tempo. Está contraindo uma dívida que se acumula com juros.

A lição: Validar o escopo com as partes interessadas e tratar a identificação de riscos com disciplina não são burocracia. São a diferença entre um projeto controlado e um desperdício de US$ 2 bilhões. As ferramentas PPM atuais permitem manter um registro de riscos junto ao plano do projeto, garantindo que ameaças emergentes fiquem visíveis para todos e não fiquem enterradas no e-mail de alguém.

O projeto de TI civil do NHS

O objetivo: O Serviço Nacional de Saúde do Reino Unido (NHS) lançou o National Programme for IT (NPfIT) para criar um sistema nacional de prontuários eletrônicos, infraestrutura de digitalização e sistemas de TI integrados entre hospitais e centros de atenção comunitária. Teria sido o maior sistema de computação civil já construído.

O que deu errado:

• Caos contratual. Disputas com fornecedores, especificações em constante mudança e incompatibilidades técnicas assombraram o programa desde o primeiro dia. Contratos foram assinados antes que os requisitos estivessem estabilizados, travando compromissos que rapidamente se tornaram inviáveis.
• Sem revisões de progresso. O programa não tinha revisões periódicas em etapas-chave para verificar cronograma, orçamento e escopo contra uma linha de base. Sem esses pontos de controle, os desvios cresceram sem freio durante meses. Estabelecer linhas de base em marcos importantes e comparar o desempenho real contra elas teria tornado os desvios visíveis muito antes.
• Decisões de cima para baixo, resistência de baixo para cima. O programa, de natureza política, impôs um sistema centralizado a divisões locais do NHS com realidades muito distintas. Profissionais de saúde e equipes locais de TI não foram consultados adequadamente, gerando uma resistência que nenhuma tecnologia poderia superar.
• Destruição orçamentária. As estimativas de desperdício total giram em torno de 10 bilhões de libras. O programa foi rotulado como “o maior fracasso de TI já visto” e um alerta sobre o que não se deve fazer em gerenciamento de projetos no setor público.

Quando um projeto não faz comparações periódicas com a linha de base nem revisões de progresso, pequenos desvios se transformam em grandes antes que alguém perceba.

A lição: Programas de grande porte precisam de uma estrutura de governança em camadas com pontos de controle claros. Um acompanhamento orçamentário que compare as alocações top-down com as estimativas bottom-up em tempo real pode revelar desalinhamentos meses antes que se tornem crises. Igualmente importante, o engajamento das partes interessadas no nível operacional não é opcional, especialmente quando os usuários finais têm o poder de rejeitar o sistema por completo.

O supercomputador Stretch da IBM

O objetivo: No final dos anos 1950, a IBM decidiu construir o computador mais rápido do mundo, o IBM 7030 Stretch. A meta era ambiciosa: 100 a 200 vezes mais rápido que qualquer máquina existente. O preço foi fixado em US$ 13,5 milhões para corresponder a essas expectativas.

O que deu errado:

• Previsões excessivamente otimistas. A meta de desempenho foi definida como uma promessa comercial, não como uma estimativa de engenharia. Quando a primeira versão funcional foi testada no início dos anos 1960, era aproximadamente 30 vezes mais rápida que a antecessora, muito aquém da meta de 100x.
• Complexidade simultânea. Como relembrou o líder do projeto, Stephen W. Dunwell: “nunca antes tantas coisas precisaram funcionar simultaneamente em um único computador.” O switch de compartilhamento de carga, a memória de núcleo de ferrite e outras inovações traziam, cada uma, um risco técnico que se multiplicava ao combiná-las.
• Colapso do preço. O déficit de desempenho forçou a IBM a reduzir o preço das unidades já encomendadas para US$ 7,78 milhões, abaixo do custo. O que era um projeto de prestígio se transformou em prejuízo financeiro.

Houve, no entanto, um lado positivo. As inovações em fabricação, embalagem e arquitetura nascidas do Stretch se tornaram a base de muitos sucessos posteriores da IBM, ajudando a catapultar a empresa à vanguarda da indústria. Se as expectativas tivessem sido definidas de forma mais realista, o projeto poderia ter sido considerado um sucesso, e não um fracasso.

A distância entre o que um projeto promete e o que entrega é onde reputações são construídas ou destruídas. Linhas de base realistas protegem ambas.

A lição: Projetos técnicos ambiciosos precisam de linhas de base honestas tanto para desempenho quanto para custo. Quando as estimativas são conduzidas pelo marketing e não pela engenharia, a lacuna resultante corrói a credibilidade mesmo quando o trabalho subjacente é genuinamente inovador. A comparação periódica entre desempenho planejado e real, medida contra uma linha de base clara, mantém as expectativas com os pés no chão à medida que o projeto evolui.

Padrões comuns nos três fracassos

Apesar das diferenças de setor e época, esses projetos compartilham padrões que continuam relevantes hoje:

Padrão de fracasso	Aeroporto de Denver	NHS IT	IBM Stretch
Cronograma ou metas irrealistas	Prazo de 2 anos ignorando estimativas do contratante	Sem revisões por etapas para detectar atrasos	Promessa de desempenho 100x baseada em marketing
Má gestão de partes interessadas	Companhias aéreas excluídas do planejamento	Profissionais de saúde e equipes de TI locais não consultados	Realidades de engenharia anuladas por compromissos comerciais
Gestão de riscos deficiente	Sem registro de riscos formal	Riscos contratuais não gerenciados	Riscos técnicos multiplicados em frentes de trabalho paralelas
Sem linhas de base de custo ou desempenho	US$ 2 bi de estouro sem alerta antecipado	10 bilhões de libras de desperdício sem revisões orçamentárias periódicas	Preço reduzido abaixo do custo após déficit de desempenho

Todos esses padrões podem ser prevenidos com gerenciamento de projetos disciplinado. Um registro de riscos com pontuação de probabilidade e impacto detecta ameaças antes que se tornem crises. Linhas de base estabelecidas no início de cada fase tornam o desvio visível assim que começa. O acompanhamento orçamentário que compara custos planejados e reais, discriminados por mão de obra, aquisições e receita, sinaliza estouros enquanto ainda há tempo para corrigir o rumo.

O que você pode fazer diferente

Esses casos têm décadas de idade, mas os padrões de fracasso se repetem em projetos de qualquer porte. A boa notícia é que as ferramentas e práticas necessárias para evitá-los são mais acessíveis do que nunca:

• Defina os riscos de forma estruturada. Não trate a gestão de riscos como um exercício pontual no início do projeto. Mantenha um registro de riscos vivo e revise-o a cada marco. Classifique os riscos por probabilidade e impacto para que a equipe se concentre no que realmente importa.
• Estabeleça linhas de base cedo. Uma linha de base captura o seu plano em um momento específico: cronograma, custo e escopo. Sem ela, não há forma objetiva de medir se o projeto está se desviando. Defina uma nova linha de base a cada mudança de fase importante e compare-a periodicamente com os dados reais.
• Acompanhe custos em tempo real. Esperar até o final de uma fase para conciliar orçamentos é a receita para um estouro de US$ 2 bilhões. O acompanhamento contínuo que discrimina mão de obra, aquisições e outras despesas frente ao orçamento aprovado mantém as surpresas sob controle.
• Engaje as partes interessadas antes de se comprometer. O erro de Denver ao não incluir as companhias aéreas e o do NHS ao não consultar os profissionais de saúde mostram a mesma coisa: um plano tecnicamente sólido que ignora seus usuários não é sólido de verdade.

Próximos passos

• Revise os conceitos básicos da gestão de riscos em projetos e avalie se os seus projetos atuais possuem registros de riscos ativos e atualizados
• Audite as linhas de base dos seus projetos: se você não tem uma linha de base atualizada de cronograma, custo e escopo, defina uma nesta semana
• Solicite uma demo para ver como os registros de riscos, o acompanhamento de linhas de base e os painéis de orçamento em tempo real do ITM Platform ajudam equipes a detectar problemas antes que eles cresçam