O número de casos de desenvolvimento de projetos de TI que fracassaram, infelizmente, aumentou nos últimos anos. Nesse post, o primeiro de uma sequência de 2, discutirei algumas razões para esse quadro. Já no segundo pretendo abordar como o framework Scrum pode servir de instrumento para aumentar os casos de sucesso.

Periodicamente o The Standish Group, um instituto de pesquisa americano que atua no mercado de TI, publica o relatório “CHAOS Summary report”. O mais recente, de abril de 2009, mostra números preocupantes.  Para entendê-los, entretanto, preciso primeiro enumerar três conceitos, espécie de status final de projetos de TI, do próprio instituto. São eles:

1. Um projeto é considerado bem sucedido se for entregue no prazo, dentro do orçamento e com os atributos e funcionalidades originalmente previstos;

2. Um projeto é considerado fracassado se for cancelado antes de sua finalização ou se nunca for utilizado após à sua conclusão; e

3. Um projeto é considerado contestado se for entregue depois do prazo, acima do orçamento ou com menos atributos e funcionalidades do que originalmente previstos.

Entendidas essas três definições, o relatório apontou em 2009 que apenas 32% dos projetos foram considerados bem sucedidos enquanto 24% foram classificados como fracassados e os restantes 44% ganharam o status de contestado. Em um artigo publicado em 30 de junho de 2009, a Computerworld descreve que de 2006 (ano do penúltimo relatório) para 2009 o número de projetos bem sucedidos diminuiu de 35% para 32%, de projetos fracassados aumentou de 19% para 24% e de contestados diminuiu de 46% para 44%.

Jim Johnson, presidente do The Standish Group na época, explica que a recessão econômica contribuiu de três formas para isso:

1. Nesse cenário há redução de orçamentos e as organizações ficam mais propensas a cancelar projetos que evoluem mal.

2.  A redução do quadro de funcionários nas empresas, tanto dentro do departamento de TI quanto fora, também contribuiu para os números do relatório do Standish Group, porque sobrecarregou gerentes de projetos e stakeholders de negócio, diminuindo o tempo gasto por essas pessoas em atividades importantes para projetos serem exitosos.

3. A recessão aumenta a aversão das empresas a risco. Por isso elas exageraram no número de check-points e verificações para garantir a aderência às melhores práticas de governança de desenvolvimento em TI.

Essa situação ampliou a duração dos projetos, postergando sua conclusão. Como seu valor para o negócio materializa-se somente quando estiver concluído, o atraso contribuiu para: os stakeholders se desinteressarem pelo projeto pois o valor inicial não se configurava mais na conclusão do projeto; e quanto maior for a duração maior é o seu risco. Um projeto de desenvolvimento de longa duração pode perder o seu valor independentemente de cenário desfavorável. As mudanças são constantes no mundo de hoje e as organizações precisam reagir de forma e em tempo adequados aos estímulos recebidos dos mercados onde atuam.

Um cenário econômico é apenas uma, importante é claro, das variáveis em constante mutação. No próximo post discutirei como as empresas, que compram serviços de desenvolvimento de software, assim como os seus fornecedores, podem se beneficiar do framework Scrum para evitar as consequências de um cenário desfavorável, utilizando uma proposta que Jeff Sutherland, um dos criadores do Scrum, apelidou de “Money for Nothing or Change for Free”.