O projeto começou a dar errado. E agora?

“No meio do caminho tinha uma pedra”. Foi com essa frase de Carlos Drummond de Andrade que a matéria que foi capa da InformationWeek Brasil da segunda quinzena de junho começou. A matéria abordou diversos casos onde algum projeto começou a dar problema e o CIO teve a heróica função de contornar o problema – alguns casos com significativos 40% de aumento nos custos, outros com apenas 10% em situações inusitadas.

Um exemplo que me chamou a atenção foi o de uma determinada empresa da área farmacêutica que estava implementando um sistema para controle de RH, para aumentar a robustez do sistema e eliminar controles paralelos, diminuindo assim a margem de erro operacional e dimuindo custos. No meio do projeto, aconteceu de tudo: o sponsor deixou a empresa, os líderes das áreas de negócio foram alterados, questões culturais e de comunicação não foram tão bem trabalhadas quanto deveriam e o treinamento não teve um grau de aderência suficiente, por causa de um e-learning mal-sucedido.

Quando li isso na revista, tive a impressão de que não só o projeto tinha ido a pique como também a empresa. Quanta coisa ruim em um projeto só! Mas a CIO da empresa conseguiu contornar o problema e terminou o projeto com apenas dois meses de atraso e 10% de aumento no custo previsto. Resultado heróico, não?

A chave para o sucesso (ou sobrevivência) do projeto foi, em síntese, o trabalho em equipe: as medidas de controle foram usadas por um comitê de TI que incluía os representantes de cada área de negócio em reuniões semanais, que acompanhavam o status, prazo e custo do projeto.

Outro projeto, em outra companhia, também teve um atraso de quatro meses por falta de templates de documentos que seriam implementados no sistema. Esse risco havia sido levantado durante a fase de concepção do projeto, porém nenhuma atitude foi tomada para corrigir isso a tempo. Quando esses templates foram necessários, eles não existiam, e até que o problema fosse corrigido, o projeto acumulou mais 40% de custos além do previsto.

Outras causas para o desvio das rotas de projetos foram: escolha das pessoas erradas (é necessário envolver o pessoal da área mais operacional, e não os representantes dos departamentos!), falta de conhecimento dos processos a serem incorporados ao sistema, número de horas necessárias para desenvolvimento subestimadas e problemas de comunicação

E em todos os casos, o CIO foi o responsável por “tirar a água do barco”, para que o projeto cumprisse seu objetivo. Uma tarefa um tanto árdua, mas compensadora.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *