Por que grandes projetos de TI fracassam com tanta frequência?

Agora, quase todos os cidadãos americanos já ouviram falar ou testemunham o fraco desempenho do website healthcare.gov.

Inicialmente, apenas um em cada cinco usuários conseguia, de fato, acessar o website, enquanto desempenho insatisfatório e sistemas indisponíveis continuavam castigando operações federais e estudais. Jeffrey Zients, requisitado pelo próprio Obama para consertar o website healthcare.gov, prometeu em 25 de Outubro que o site ?funcionaria sem percalços para a grande maioria de usuários? até o final de Novembro.

Logo após o lançamento em 1 Outubro, o ex-CTO federal Aneesh Chopra, em uma entrevista no Instituto Aspen para Thomas Friedman, do New York Times, menosprezou os problemas do website dizendo que ?falhas acontecem?. Chopra comparou as interrupções do healthcare.gov com as frequentes aparições da famosa baleia do Twitter quando o tráfego intenso prejudicou o bom desempenho do microblog durante a Copa do Mundo Fifa 2010.

No entanto, considerando que o tamanho do público que acessaria o site já era bem conhecido e que a tecnologia do site é madura e bem compreendida, como o governo conseguiu promover tanto tumulto com a TI? Especialmente considerando o tempo de execução que o governo teve (mais de três anos) e o quanto gastou para construir o site (estima-se que o gasto tenha sido entre US$ 300 milhões e US$ 500 milhões).

O fracasso deste projeto não é tão raro, infelizmente. Pesquisas da indústria sugerem que grandes projetos de TI corram muito mais risco de fracassar do que esforços menores. Um estudo da McKinsey realizado em 2012 revelou que 17% dos projetos de TI com orçamento de US$ 15 milhões ou mais podem dar tão errado a ponto de ameaçarem a existência da empresa, e mais de 40% realmente fracassam. Lançamentos tão ruins quanto o website de saúde dos EUA já aconteceram aos montes, tanto no setor público quanto privado, com desastres similares.

Em um estudo memorável, realizado em 1995, o Grupo Standish estabeleceu que apenas cerca de 17% dos projetos de TI podiam ser considerados ?sucesso absoluto?, outros 52% eram ?desafiadores? (não respeitavam orçamento, qualidade ou prazo) e 30% eram ?debilitados ou fracassados?. Em uma recente atualização deste estudo, conduzido pela ComputerWorld, Standish examinou 3.555 projetos de TI entre 2003 e 2012, com custo de mão de obra mínimo de US$ 10 milhões, e descobriu que apenas 6.4% deles foram bem-sucedidos.

Combinando problemas herdados associados a projetos de TI grandes demais e as práticas governamentais desatualizadas, os fatores de risco são ainda maiores. Empresas de todos os tipos podem relacionar o fracasso de projetos de TI com diversas razões-chave:

– Patrocínio pobre ou ambíguo

– Exigências confusas ou mutáveis

– Design pobre ou uso inapropriado de nova tecnologia

Patrocínio forte e exigências sólidas são especialmente difíceis de conseguir em ambientes políticos (entenda: ObamaCare), quando muitos indivíduos e grupos têm motivos para brigar uns com os outros e mudar o projeto. Aplicar processos políticos com longos debates, buscar consenso e as diversas reuniões para definir as exigências de um projeto são a receita do desastre.

Além disso, com base em minha experiência, suspeito que os profissionais terceirizados que realizam o trabalho para o governo tenham incentivado as mudanças, já que viram uma oportunidade de aumentar o escopo do projeto com muito trabalho de margem mais alta (os pedidos de alterações são sempre muito mais lucrativos do que a oferta inicial). O patrocínio inadequado e as exigências pobres são, sem dúvida alguma, combinados a uma metodologia de desenvolvimento em cascata e uma abordagem geralmente especificada por métodos de aquisição do governo. Na verdade, declarações iniciais desses profissionais indicavam a ausência de testes no sistema completo e alterações de última hora.

Por que o projeto não optou por uma abordagem de entrega iterativa para afiar as exigências e interfaces mais cedo? Por que não começar com um site-piloto ou uma versão beta por meses ou até anos antes do lançamento de 1 de Outubro? O projeto esteve em andamento por mais de três anos, ainda assim, nada foi disponibilizado antes de 1 de Outubro. E por que o esforço do governo não se aproveitou de capacidades de nuvem pública  para escalonamento eficiente? Onde estava o design de escalonamento horizontal dentro do aplicativo para permitir a adição fácil de capacidades para demanda inesperada?

Essas técnicas parecem ter sido ignoradas na implementação do website. Além disso, o código do site parece ser medíocre, nem sequer utilizando técnicas comuns de cache para melhorar o desempenho. Portanto, além de sofrer com patrocínio pobre e exigências ambiciosas, o programa falhou ao não se aproveitar de tecnologias bem estabelecidas e melhores práticas de design.

Poderíamos até imaginar que, devido ao tamanho e as despesas deste programa, o governo teria designado recursos técnicos de primeira e aplicado as melhores práticas. Agora os federais estão mexendo com uma ?explosão? de recursos técnicos para o site.

Por mais que eu deseje sucesso aos novos líderes e implementadores do projeto, esta ?explosão? trará seus próprios problemas. As ideias apresentadas podem não ser aceitas ou integradas tão facilmente. E, se o projeto não conseguir lidar com o trabalho técnico ?fácil? ? design sólido de website e escalabilidade horizontal ?, como irá lidar com os desafios mais difíceis de qualidade de dados e segurança?

O que fazer?

Patrocínio claro e governança apropriada são essenciais em qualquer projeto de TI, mas, neste caso, mudanças mais radicais são necessárias. Por que fazer todos os 36 estados e o governo federal lançarem as trocas de serviços de saúde em uma abordagem de cascata? Os sites que estão rodando razoavelmente bem (como o do Distrito de Columbia) foram desenvolvidos independentemente. Divida o trabalho quando for possível e mude para uma metodologia espiral ou interativa. Entregue cedo e frequentemente.

Talvez introduza tensão competitiva, fazendo com que profissionais compitam entre si para completar cada ciclo. Mas que seja uma corrida e não uma maratona. Ciclos de três ou seis meses devem ser suficientes. A equipe que atender às exigências em tempo terá a oportunidade de propor o próximo ciclo. O profissional que não completar a tarefa é barrado no próximo ciclo, portanto, não há vantagem alguma para quem incentivar mudanças intermináveis. Além disso, você divide o trabalho em componentes mais manejáveis, que podem, então, ser aprimorados na implementação seguinte.

Por fim, utilize apenas tecnologias aprovadas. E por que não perguntar ao CIO ou ao arquiteto-chefe de tecnologia sobre algumas empresas web de larga escala para passar alguns dias revisando o programa e os designs em pontos apropriados. É o tipo de parceria indústria-governo que todos gostariam de ver.

Se quiser aprender mais sobre como gerenciar (e como não gerenciar) grandes programas de TI, eu recomendo ?Software Runaways?, de Robert L. Glass, que documenta alguns fracassos espetaculares. Ler esse livro é como assistir a um acidente de trânsito: é terrível, mas você não consegue evitar. Eu me aprofundo nas causas raízes e nos consertos de projetos de TI fracassados em meu blog, no post project management best practices.  E, que tal alguns projetos governamentais de TI que deram certo? Aqui está o top 10 de 2012 de um site.

Quais melhores práticas de gerenciamento de projeto você acrescentaria? Por favor, compartilhe conosco nos comentários abaixo.