Murilo Ohl, da Info CORPORATE
11 de julho de 2008
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
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 inicativa. 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 servista 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 emandamento”, 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 são 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 Cater-pillar 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.
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 da 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.
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, da Lojas Renner. Salvar um projeto não significa apenas eliminaros 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 quenã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 queimpediram 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 fimde 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 queo 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.
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çãode 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.
Publicado originalmente na Corporate de Julho de 2007
Fonte: INFO Corporate
| Tagged Gestão de Projetos, TI
Post visualizado 147 vezes.
José Eduardo Motta Garcia, PMP (jose.eduardo.garcia@gmail.com), graduado em Ciência da Computação pela Universidade do Vale do Paraíba, pós-graduado MBA em Gerenciamento de Projetos pela Fundação Getúlio Vargas, é certificado PMP pelo PMI, ITIL pelo EXIN, COBIT pelo ISACA, CPA-10 e CPA-20 pela ANBID e MCP, MCSA e MCSE pela Microsoft. Atua há mais de 10 anos na área financeira, é gerente de projetos no setor bancário e voluntário do PMI São Paulo.
Olá! Desde que coloquei o site 