Em 1986 foi publicado um paper comparando a construção de pontes com a construção de software, como premissa foi utilizado:
  • Pontes normalmente são entregues no prazo, dentro do orçamento e “não caem”
  • Softwares raramente são entregues no prazo ou dentro do orçamento. E normalmente eles tem bugs.
Uma das maiores razões para o sucesso na construção de pontes é o alto nível de detalhe “em momento de design”. O “design” é congelado e o contratante tem pouquíssima flexibilidade de mudanças. Todavia, no mundo de negócios atual, este “congelamento” pode não acomodar as mudanças de negócio necessárias pelas empresas. Portando, um modelo mais flexível deve ser aplicado.
Mas também há outro elemento primordial a ser analisado entre a construção de pontes e construção de software. A construção de pontes é feita a pelo menos 3.000 anos. Quando uma ponte caia, as causas da queda eram investigadas, documentadas e disseminadas para que ninguém cometesse o mesmo erro novamente. Isto raramente acontece no desenvolvimento de software, onde as falhas são muitas vezes tratadas como causas normais e rotineiras e em sua grande maioria, são ignoradas. Como resultado, continuamos a cometer os mesmos erros que tínhamos na década passada (muda a linguagem ou o dispositivo, mas o erro é o mesmo).
Neste sentido, o foco da pesquisa do The Standish Group foi identificar:
  • As falhas dos projetos de software
  • Os maiores fatores que influenciam na falha de projetos de software
  • Os pontos chave que podem reduzir estas falhas
Os Estados Unidos gastam mais de 250 bilhões de dólares cada ano no desenvolvimento de aproximadamente 175.000 projetos de software. O custo médio de um projeto em uma grande empresa americana é de 2.3 milhões de dólares, para uma empresa média é de 1.4 milhões d dólares e 434 mil dólares para uma empresa pequena. E a grande maioria destes projetos falha. Os projetos de desenvolvimento de software estão no caos.
O estudo classificou os projetos em três tipos:
  • Sucesso: Projeto dentro do prazo, dentro do orçamento e com boa parte do escopo
  • Sucesso parcial: Projeto funcionando, mas entregue sem atender ou custo, ou esforço ou com o escopo parcial
  • Fracassos: Projetos cancelados ou não utilizados
Sua última revisão (2009) mostrava que:
  • 24% dos projetos fracassam
  • 44% dos projetos são entregues com sucesso parcial
  • E apenas 32% dos projetos obtêm sucesso.


Os principais fatores que ajudaram no sucesso dos projetos foram:
  • Envolvimento do usuário: 15.9%
  • Apoio executivo: 13.9%
  • Declaração de requisitos clara e limpa: 13%
  • Planejamento apropriado: 9.6%
  • Expectativas realistas: 8.2%
  • Milestones pequenos: 7.7%
  • Equipe competente: 7.2%
  • Propriedade: 5.3%
  • Visão e objetivos claros: 2.9%
  • Trabalho duro e equipe focada: 2.4%
    Outros: 13.9%
Os fatores que influenciaram os projetos de sucesso parcial foram:
  • Falta de insumos do usuário: 12.8%
  • Requisitos & Especificações incompletas: 12.3%
  • Mudanças nos requisitos & especificações: 11.8%
  • Falta de apoio executivo: 7.5%
  • Ambiente tecnológico incompleto: 7.0%
  • Falta de recursos: 6.4%
  • Expectativas irrealistas: 5.9%
  • Objetivos nebulosos: 5.3%
  • Ciclos (tempo) irrealistas: 4.3%
  • Novas tecnologias: 3.7%
    Outras: 23%
O estudo mostrou também que quanto maior o tamanho do projeto, maior a probabilidade de fracasso. As principais causas de fracasso são:
  • Requisitos Incompletos: 13.1%
  • Falta de envolvimento do usuário: 12.4%
  • Falta de recursos: 10.6%
  • Expectativas não realistas 9.9%
  • Falta de apoio executivo: 9.3%
  • Mudanças de requisitos: 8.7%
  • Falta de planejamento: 8.1%
  • Não precisa mais daquilo: 7.5%
  • Falta de gestão da TI: 6.2%
  • Analfabetismo tecnológico: 4.3%
  • Outros: 9.9%