Como matar um projeto de TI

Publicado: 31/07/2007 em Artigos

Por MURILO OHL

Passar pela experiência de cancelar um projeto de TI é um processo duro para qualquer CIO. Mas existem formas de enfrentar o problema com baixo impacto para a carreira e a empresa.

Fonte: Info CORPORATE

Matar um projeto de TI é sempre uma decisão difícil para o CIO, pelos prejuízos de tempo e dinheiro envolvidos. Também é necessário enfrentar a decepção de executivos e usuários e o abalo na motivação da equipe que trabalhou na iniciativa. Mas, apesar de todos os esforços de prevenção, realizados com o uso de metodologias de gestão, um quarto dos projetos corporativos de TI fracassam, segundo a consultoria americana The Standish Group. Pior: conforme aumentam a abrangência do projeto e os investimentos envolvidos, maior é a possibilidade de fracasso. A questão principal, então, não é como evitar, mas como proceder quando a equipe de TI depara-se com um projeto considerado problemático. Se a decisão for pelo encerramento antes do prazo, qual é a melhor forma de fazer isso, causando o mínimo de danos para a empresa e para todos os envolvidos?

A decisão de acabar com um projeto deve ser vista de maneira pragmática. “Encerrar um projeto não é bom nem para o CIO nem para a organização, mas é melhor do que mantê-lo em andamento mesmo com o risco de fracasso“, afirma Regina Pistelli, CIO da Medial Saúde.

Embora possa representar uma decepção pessoal para o gestor, o encerramento também revela senso de responsabilidade e comprometimento com os resultados da empresa. “Para o CFO, esse tipo de decisão pega bem, pois mostra que o CIO não tem envolvimento emocional como projeto“, afirma Ione de Almeida Coco, vice-presidente do programa para executivos do Gartner. “No final do processo, uma decisão como essa passa para a corporação uma imagem positiva do CIO“, afirma Ione.

A primeira pessoa que o CIO deve convencer de que não vale a pena seguir adiante com um projeto problemático é ele mesmo. “Ninguém gosta de matar a própria cria, mas em certos casos essa pode ser a melhor alternativa“, diz Ione.

Equipes de projeto também tendem a resistir à idéia de que as coisas não estão dando certo. Isso pode levar à perigosa situação de os problemas serem mascarados. “Apesar de experientes, alguns CIOs e gerentes de projetos acabam se tornando ‘bombeiros’ de suas iniciativas, na tentativa de recuperar heroicamente um projeto em andamento“, diz Marcelo Miranda, gerente da consultoria Everis, antiga DMR Consulting.

Correção de rumo – Mas a tendência aponta para uma diminuição, nas grandes empresas, da necessidade de atitudes extremas, como a extinção do projeto antes do seu término. Isso porque está se tornando comum nas organizações o emprego de metodologias de gestão de projetos, como PMI, Itil ou Six Sigma, que permitem a correção dos problemas a tempo. No Bradesco, dono de um dos maiores orçamentos de TI do país, a hipótese de encerramento antecipado de uma iniciativa de TI chega a ser praticamente nula, segundo conta Laércio Albino Cézar, vice-presidente de TI do banco. Correções de rumo com o projeto em andamento, por outro lado, ocorrem com certa freqüência. “Fazer mudanças durante o desenvolvimento é natural, mas é preciso ter agilidade“, diz Cézar.

O atual momento por que passa o mercado sugere atenção redobrada em relação aos projetos. Com muitas fusões e aquisições ocorrendo, tanto entre fornecedores de TI como em outros mercados, os riscos de impacto tendem a crescer. “Num cenário em que as empresas mudam muito, o cancelamento de projetos tende a ocorrer com mais freqüência“, diz Ione Coco. Veja, a seguir, como escapar (ou enfrentar) a decisão de matar um projeto de forma menos traumática.

1. Identifique os problemas

Já que problemas ocorrem, a melhor coisa a fazer é identificá-los rapidamente durante o desenvolvimento do projeto. Em geral, o acompanhamento diário fica por conta de um gerente de projeto. “É ele quem deve alertar o CIO“, diz Keiji Sakai, CIO do Deutsche Bank. O recomendado é que o CIO reúna-se com os gerentes de projeto pelo menos uma vez por semana para se manter atualizado. “Se aparecer uma luz amarela piscando, é hora de convocar uma reunião para apurar o que está havendo e começar a trabalhar em regime de emergência“, afirma Regina Pistelli, da Medial Saúde.

Basicamente, há três grandes sinais vitais a serem monitorados: orçamento, prazo e escopo. “Se um desses três itens apresenta problemas, o projeto corre o risco de dar errado“, afirma Sakai. Gerenciar o desenvolvimento significa medir esses fatores e identificar problemas e riscos que possam comprometer um deles. O CIO precisa estar atento também às mudanças de estratégia da empresa e avaliar se elas podem causar algum impacto nas iniciativas ainda em gestação. Enquanto um projeto de TI é desenvolvido, uma companhia pode adquirir concorrentes, lançar novos produtos, abrir filiais ou promover reestruturações. “Todos esses fatores tendem a impactar os objetivos de um projeto de TI“, diz Ione Coco, do Gartner.

Quando um desses problemas ocorre, a saída costumeira é mexer em uma das variáveis, estendendo os prazos de entrega ou pedindo mais dinheiro para concluir o projeto. Normalmente, o que sufoca os projetos de TI são os prazos curtos e, em segundo lugar, o orçamento apertado. “Por isso, a solução mais usual é reduzir o escopo do projeto e tentar seguir em frente“, afirma João Gama Neto, vice-presidente da unidade de São Paulo do PMI (Project Management Institute), organização internacional que reúne as melhores práticas de gestão de projetos. A tática da redução do escopo baseia-se numa idéia de que só uma minoria das funcionalidades é realmente importante. É comum que só 20% do projeto atenda a 80% das demandas, por exemplo. Mas há quem considere esse tipo de intervenção pesada demais, preferindo um equilíbrio entre redução do escopo com alongamento do prazo e novos aportes de recursos.

Uma parte importante da tarefa de identificar problemas não está escrita nas metodologias ou nos relatórios dos gerentes. Há uma série de sinais, menos objetivos e mais intuitivos, que podem revelar problemas no projeto. Nessa seara, o que vale é a experiência e a sensibilidade do CIO. “Se o PMO faltou a uma reunião porque está apagando um incêndio, é indicativo de que algo de errado está acontecendo“, afirma Regina Pistelli. “Quando alguém da equipe entra na sala para relatar atritos com colegas ou com fornecedores, algum problema ocorreu e está emperrando o bom andamento dos trabalhos“, diz Flávio Reis, gerente de TI da Caterpillar para a América Latina. Existe até a chamada “regra do restaurante”: se na hora do almoço a equipe demonstrar empolgação, é sinal de que as coisas vão bem. Se o tom das conversas for sempre desanimado, a razão pode ser o projeto enviesado.

O problema é que, para aprender a identificar esse tipo de sinal, não existe uma receita pronta. A cada projeto mudam os pontos de atrito, os limites pessoais e as falhas técnicas. “É no dia-a-dia, no bate-papo com a equipe, que esses sinais de problema aparecem“, diz Reis. “A execução e o conserto dependem totalmente das pessoas“.

Essa habilidade em reconhecer obstáculos não deve estar restrita apenas ao CIO. Para Keiji Sakai, o gerente de projetos também precisa deter esse conhecimento. “Não basta o profissional ser gabaritado tecnicamente, com todas as certificações. Ele precisar ter jogo de cintura para negociar com os diversos envolvidos em um projeto“, afirma Sakai.

Durante um desenvolvimento, cada decisão gera reações distintas nos diversos envolvidos. Um bom gerente de projeto é aquele que sabe lidar igualmente com fornecedores, patrocinadores e funcionários, controlando ansiedades, mantendo a motivação e garantindo a transparência.

Eficiência em projetos de TI
Taxa de sucesso dos projetos de TI

  • 34% – Sucesso
  • 25% – Fracasso
  • 41% – Sucesso Parcial

Fonte: The Standish Group (2003)

2. Informe a empresa

Ao mesmo tempo em que procura resolver os problemas dentro da área de TI ou do escritório de projeto, o CIO também deve reportar os acontecimentos ao comando da empresa. “Os executivos devem ser informados do andamento com regularidade“, afirma Regina Pistelli. “É muito importante dar uma previsibilidade a todos os envolvidos, para que ninguém seja apanhado de surpresa pela decisão de encerrar um projeto“, afirma Regina. A responsabilidade de matar uma iniciativa não é exclusiva do CIO, mesmo que do ponto de vista da tecnologia o projeto já esteja comprometido. “O diretor de TI deve dar orientações e se posicionar, mas quem decide pelo futuro de uma iniciativa é o comitê ou o patrocinador do projeto“, afirma Sakai, do Deustche Bank.

Em geral, um comitê formado por outros diretores da empresa e usuários do sistema em desenvolvimento decide em assembléia o destino do projeto. No Bradesco, por exemplo, o comitê de tecnologia da informação reúne-se todas as quartas-feiras pela manhã para avaliar os projetos em andamento. Além dos líderes de TI, participam executivos de outros departamentos. Tem assento também um representante de uma área chamada Tecnologia de Negócios, que tem a atribuição exclusiva para fazer o intercâmbio entre a TI e os usuários. “Essa área dá apoio às decisões do comitê“, afirma Laércio Cezar.

O alinhamento com as metas da empresa deve começar bem antes, no planejamento do projeto. É nesse ponto que a TI deve se reunir com as áreas usuárias para afinar expectativas, estabelecer regras e gerar os documentos que conduzirão o desenvolvimento. “É fácil falar que a TI deve ser rápida e eficiente no término do projeto, mas, se a TI recebe uma informação com problema no início, no final ela só poderá entregar um sistema com problemas“, diz Luiz Agnelo Franciosi, gerente geral de TI das Lojas Renner. Uma falha típica dos projetos é subestimar o tempo que as áreas de negócios necessitam para homologar as soluções. Segundo Miranda, da Everis, a fase de provas e homologação responde por 30% da duração de um projeto. “Como esse tempo quase sempre deixa de ser considerado no planejamento, ele é um dos principais fatores de comprometimento dos prazos“, diz Miranda. Em megaprojetos, a Lojas Renner documenta todos os requisitos com os clientes internos. Depois faz conferências com as áreas envolvidas para discutir o projeto. “Essas revisões garantem a detecção de falhas de sistemas ou de processos antes do desenvolvimento“, diz Franciosi.

Porque os projetos falham
Conheça as principais razões que levam as iniciativas ao fracasso

  • 72% – falta de definição de prazos
  • 71% – falhas de comunicação
  • 69% – mudanças de escopo
  • 66% – estimativa errada para o projeto

Fonte: PMISP

3. Dá para salvar?

Se tudo estiver dando errado, a hora é de decidir por matar ou não o projeto. Se a intenção é salvá-lo, é preciso colocar em prática um plano de recuperação. Nessa hora, a revisão de prazos, orçamentos, escopo e riscos deve ser completa. O custo de recuperação deve ser calculado. “O gerente de projeto precisa apresentar uma previsão atualizada com esses dados para informar quanto custará ir adiante“, afirma Keiji Sakai, lembrando que na fase de planejamento devem-se definir as normas de como serão os procedimentos de salvação ou cancelamento do projeto.

A melhor decisão nessa hora é interromper o projeto momentaneamente e voltar à origem do problema, para tentar resolvê-lo. Mas o CIO não precisa tentar consertar o avião em pleno vôo. “Se algo deu errado, não siga em frente. Pare, volte, encontre o problema, corrija-o e então avalie se é necessário começar do zero ou partir do ponto em que estava“, afirma Franciosi, das Lojas Renner. Salvar um projeto não significa apenas eliminar os problemas, mas também rever seus objetivos. “Por isso, uma vez consertados os problemas, é preciso renegociar os acordos com os patrocinadores do projeto“, afirma Franciosi.

Quando o empreendimento já está bastante comprometido, mas a companhia quer salvá-lo a qualquer custo, uma sugestão é criar uma equipe de resgate, que vai entrar para promover a reestruturação do projeto. Nesses casos, contratar uma consultoria externa pode ser uma alternativa. “Mas o CIO precisa dar carta branca para que esse consultor faça as mudanças necessárias, inclusive trocando pessoas“, afirma Luís Augusto dos Santos, presidente do PMI de São Paulo.

4. O plano de encerramento

Se a decisão for matar o projeto, também existe um plano de encerramento a ser posto em prática. Todo o processo de desenvolvimento deve estar muito bem documentado, para elaborar a justificativa de cancelamento que será apresentada ao comando da empresa. O CIO deve se ater às evidências, sem tentar defender ou menosprezar o projeto. “A justificativa tem de ser precisa, sem sentimentos“, afirma Regina Pistelli, da Medial Saúde.

Nessa hora, não existe excesso de rigor. “Quando passei por uma situação dessas, a fundamentação da decisão de encerramento foi muito mais completado que a utilizada para aprovar o projeto no início“, afirma Flávio Reis, da Caterpillar. Mais do que isso, como houve transparência durante todo o processode implementação, quando Reis comunicava a ocorrência de problemas, a alta direção já estava ciente de que o encerramento era uma das alternativas em jogo. No momento em que a decisão de matar o projeto tornou-se inevitável, o comando da empresa não foi surpreendido.

Definida a situação com o comando da empresa, é preciso dar início à desarticulação da iniciativa. Deve-se começar a comunicar as áreas que serão afetadas pelo encerramento do projeto, mas que não participaram diretamente da decisão de cancelá-lo. Também é necessário lidar com os fornecedores. Em alguns casos, quando há contratos assinados, é preciso avaliar as cláusulas de cancelamento. “Já ouvi histórias de multas tão altas que impediram o projeto de ser cancelado. Era menos custoso concluir um sistema ruim“, diz Sakai. Há questões contratuais semelhantes a serem avaliadas, no caso dos consultores e de analistas terceirizados. Parte das licenças de software e alguns equipamentos podem ser reaproveitados em outros projetos. Outra parte vira prejuízo.

Tão complicado quanto falar com o board é comunicar a equipe interna de TI. Um cancelamento abrupto pode causar demissões ou ociosidade das pessoas. Trabalhar a motivação da equipe é fundamental. “Por mais que faça parte da vida de um profissional de TI, a sensação de perda com o fim de um projeto é muito grande“, afirma Regina Pistelli. Muitas vezes, as pessoas investem até a carreira num projeto. “Se na hora de decidir encerrar, o CIO deve demonstrar distanciamento crítico, no momento de gerenciar o impacto na equipe, é necessário ter muita sensibilidade“, afirma Regina.

Outra parte importante é entregar para a organização um relatório com as lições aprendidas e o que o projeto fracassado pode deixar de valor para a empresa. “Provavelmente também será necessário apresentar algumas providências que você pretende tomar para que os problemas não se repitam“, afirma Flávio Reis.

Como identificar projetos problemáticos

Os recursos estão dentro do planejado?
Variação Pontos
Menos de 10% 0
Entre 10% e 20% 1
Mais de 20% 2
Os custos do projeto estão acima do orçamento?
Variação Pontos
Menos de 10% 0
Entre 10% e 20% 2
Mais de 20% 4
O prazo está sendo cumprido?
Variação Pontos
Menos de 10% 0
Entre 10% e 20% 2
Mais de 20% 4

As entregas estão sendo concluídas no tempo previsto?

Variação Pontos
Mais de 90% 0
Entre 80% e 90% 2
Menos de 80% 4
Quantos fatores de risco podem comprometer o projeto?
Variação Pontos
1 a 3 riscos 0
4 a 6 riscos 3
Mais de 6 riscos 5

Resultados

Saudável: 1 a 5 pontos
Projeto tem variações de prazo, custos e escopo dentro de limites normais.
Atenção: 6 a 10 pontos
Projeto vai mal. Um plano pode corrigir os problemas
Perigo: 11 ou mais pontos
Projeto fora de controle. Hora difícil de decidir entre o encerramento ou a salvação

5. Como fica o CIO?

Até que ponto a decisão de encerrar um projeto compromete o CIO? “Quando o fracasso é determinado por um problema de tecnologia ou por uma escolha errada de fornecedor, a repercussão pode ser muito ruim“, diz Keiji Sakai. No entanto, a conduta do CIO durante o processo costuma definir a sua avaliação. É preciso ter em mente que, para a empresa, resolver a questão de maneira eficiente representa um alívio. Segundo Regina Pistelli, após um choque inicial, uma reação de solidariedade costuma aparecer. “Se o CIO tem a decência de assumir, na frente de toda a direção, que o projeto fracassou, os outros executivos saberão reconhecer o peso dessa atitude“, diz Regina. Também é preciso estar convencido de que matar um projeto não é sinal de incompetência, mas de responsabilidade. “Não conheço nenhum CIO que foi demitido por isso“, diz Ione Coco.

Flávio Reis, da Caterpillar, lembra que não se deve misturar o desafio pessoal com o plano corporativo. O insucesso precisa ser visto como uma ocorrência pontual. Não pode valer para projetos futuros. “Essa regra é aplicada tanto para os fornecedores que participaram do projeto quanto para o CIO e a equipe“, diz Reis.

Há ainda os projetos que foram entregues completos, no prazo e com a verba esperada, mas que mesmo assim não atenderam às expectativas do negócio. Na gestão de projetos, o próximo passo é o que o Gartner e o PMI chamam de gestão de portfólio. O modelo propõe uma forma de medir se um projeto atende de fato às demandas da organização. Por ainda ser novidade, é algo que exigirá uma reavaliação da definição de sucesso de um projeto corporativo. Diante desse modelo, os indicadores objetivos de prazo, custo e escopo passam a ter importância mais superficial. As verdadeiras medidas de sucesso refletirão o valor entregue para o negócio, e para isso é preciso estabelecer como o projeto será medido. Só assim os CIOs podem amenizar os riscos e evitar a difícil situação de ter que comunicar a morte súbita de um projeto de TI. 

Valor para o negócio
Proporção de projetos que trouxeram os resultados esperados para o negócio nos últimos três anos

  • 1% – nenhum projeto
  • 19% – 10% dos projetos
  • 17% – 25% dos projetos
  • 20% – 50% dos projetos
  • 27% – 75% dos projetos
  • 16% – todos os projetos
Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s