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.
Um erro comum – fonte de muitos atrasos e, em alguns casos, até fracassos em projetos de TI – é a tendência de investir em customização quando pacotes de software já disponíveis no mercado poderiam atingir os objetivos do projeto com custos drasticamente mais baixos. Os líderes de projeto precisam de autoridade, e pulso firme, para resistir aos pedidos de customização onde eles não agregam valor significativo. Os usuários que fazem lobby para adicionar novas funcionalidades tendem a superestimar seus benefícios enquanto esquecem os custos adicionais para construí-las e mantê-las durante a vida útil do sistema.
Uma maneira de se proteger contra isso é a nomeação de um “guardião” do sistema. Uma empresa de serviços que estava atualizando seu sistema de ERP criou um conselho encarregado de rever e limitar customizações para garantir que qualquer investimento e modificações no sistema suportem os objetivos de negócios. O conselho também assegurou que a quantidade total modificações – não poderia ultrapassar mais do que 10% de customização - permaneceria dentro de um patamar que permitisse que o sistema acompanhasse as atualizações do fornecedor. Qualquer coisa além destes níveis pode tornar upgrades muito caros, arriscados e demorados, prejudicando os benefícios dos pacotes de software.
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: CorpTV
Nenhum comentário:
Postar um comentário