04/09/2013

Por que os projetos de TI fracassam?

A cada ano, centenas de bilhões de dólares são investidos em grandes projetos de TI que não cumprem o que prometem. Muitas vezes, os executivos não compreendem que os esforços em torno da gestão dos projetos de TI devem levar em conta a transformação da organização e de suas operações como um todo, e não apenas mudanças pontuais para adoção de uma nova tecnologia.

Assim, acabam correndo o risco de perder de vista os objetivos do projeto ou de deixar de escolher bons líderes, aqueles com influência suficiente para motivar as transformações necessárias.

Independentemente dos motivos, as falhas dispendiosas continuam figurando entre os maiores desafios para os CIOs . Decepções recorrentes minam a credibilidade de TI e ameaçam as perspectivas de carreira dos líderes da área. Não existe uma abordagem única, mas é possível perceber que as empresas com melhores resultados costumam fazer cinco coisas muito bem.

Uma boa estruturação inicial, por exemplo, passa por escolher os talentos certos, principalmente líderes capazes de entregar resultados mais estratégicos. Um lançamento bem planejado também é fundamental, juntamente com um plano para medir a utilização e os benefícios entregues pelo novo sistema. E, é claro, nenhuma transformação é bem sucedida sem a orientação de uma boa equipe de acompanhamento que possa garantir o cumprimento das principais metas.

Mas uma das razões mais traiçoeiras para o fracasso é o aumento do escopo – a tendência de adicionar funcionalidades durante o desenvolvimento do projeto que pouco ou nada têm a ver com as metas do programa. Projetos de TI de alta visibilidade são particularmente propensos a esse risco, portanto, os gestores devem ter atenção especial. Um escopo inicial bem planejado define o que o projeto pretende realizar – e o que não pretende – e reduz a probabilidade de um sistema superdimensionado ou de um que requeira alterações durante os estágios finais ou após a entrega.

Algumas alterações durante o desenvolvimento do projeto podem ser justificáveis. Por exemplo, um grande banco sul-americano precisou atualizar funcionalidades durante um projeto de TI plurianual, a fim de cumprir exigências regulatórias. Muitas vezes, porém, as mudanças solicitadas vêm de uma lista de melhorias que nunca para de crescer, e que pode atolar um projeto ou mudar completamente seu curso.

Definir o escopo do projeto adequadamente no início também estabelece as bases para uma homologação eficiente do sistema. Em algumas organizações a estratégia de homologação é só considerada no fim. Mas os designers devem refletir tanto sobre esta fase de testes quanto como fazem com o desenho do sistema. Os testes precisam ser robustos o suficiente para garantir que os novos sistemas possam lidar com a demanda diária e com picos de uso/carga.

A fase de homologação também é um momento em que normalmente os usuários pedem novas funcionalidades, então os gestores de projetos devem ficar atentos, pesando esses pedidos contra objetivos originais do projeto. Ao longo desta etapa final, eles precisam se manter fieis para não fugir do escopo original assim como fizeram na fase inicial.

Fonte/Autor: Jean-Claude Ramirez (sócio da Bain & Company)

Nenhum comentário: