Como reajustar o cronograma de um projeto atrasado

Atrasou. E agora? Como tentar reajustar o cronograma a tempo de salvar o projeto . 1. Calma, muita calma A partir do momento em que voc percebeu o atraso, antes de mais nada, no adianta s e desesperar. Tente manter a calma, afinal voc no o primeiro e nem ser o ltimo geren te a atrasar um projeto e o seu descontrole em nada vai ajudar. Sem querer justi ficar a existncia de atrasos em projetos e sem achar que o atraso em projetos um fato que deve ser encarado normalmente, de acordo com Capers Jones (Assessment C ontrol of Software Risks), so vlidas as seguintes afirmativas: 70% dos grandes projetos sofrem de instabilidade de requisitos; Pelo menos 50% dos projetos so executados com nveis de produtividade abaixo do nor mal; Pelo menos 25% dos softwares de prateleira e 50% dos feitos por encomenda aprese ntam mais defeitos do que o razovel; Pelo menos 50% dos grandes projetos de software estouram seu oramento e prazo. Bom, agora que voc se encontra calmo, como primeiro procedimento analise a situao. Em hiptese alguma tente continuar sem essa anlise, pois, na medida em que o projet o avana, sem que sejam descobertas as causas do desvio, a situao s tende a piorar. A titudes audazes s vo fazer com que tudo saia definitivamente de controle e fazer c om que alguns fatores de risco aumentem a ponto de se tornar impraticvel seu gere nciamento. 2. Grite! Pea ajuda Orgulho um luxo ao qual voc no tem direito, alm de ser um sentimento indesejvel e mu ito prejudicial a qualquer projeto. Como gerente de projetos, voc pode e deve sol icitar toda ajuda que achar necessria. Lembre-se de que se resolver ir adiante so zinho, voc pode se tornar o heri ou o vilo da histria. Uma alternativa muito boa solicitar um observador externo (de preferncia um outro gerente de projeto) para ajud-lo na avaliao da situao. Muitas vezes, um observador e xterno tende a ficar mais atento aos detalhes e, com certeza, vai descobrir algu m ponto falho que passou despercebido por voc ou pela equipe do projeto. Pode ser (e na maioria das vezes realmente ser) que pequenos detalhes tenham caus ado um grande problema. Mas no se recrimine: normal que, em situaes crticas, nosso s entido de observao e o nosso bom senso esteja afetado. Mais normal ainda que as pe ssoas que esto dentro do contexto do projeto, principalmente enquanto vivenciam o problema, no julguem com tanta clareza os problemas quanto as que esto olhando de um ngulo externo. 3. Tente descobrir como aconteceu o desvio Provavelmente um ou mais problemas descritos abaixo foram os causadores do atras o em seu projeto. A correta identificao das causas do desvio o principal fator de sucesso durante a negociao e o realinhamento do projeto aos seus objetivos iniciai s. A lista abaixo no pretende abranger a totalidade das causas possveis para um desvi o em projetos, mas contm algumas das mais comuns e provveis causas deste tipo de e vento. So elas: Desconhecimento ou desconsiderao da importncia de um ou mais interessados do projet o; Ausncia de padres e/ou mtodos, desde o gerenciamento at a implementao do projeto; Requisitos mal definidos, entendidos ou implementados; Estimativas falhas ou excesso de otimismo durante a estimativa; Tentativa de implementao de todos os requisitos que surgem no decorrer do projeto sem que seja feita uma renegociao do prazo inicial; Aceitao por parte do gerente do projeto de um cronograma imposto e virtualmente im possvel de ser cumprido; Aceitao por parte do gerente do projeto de uma diminuio de prazo sem a contrapartida de aumento dos recursos; Mudanas constantes das prioridades por parte dos interessados;

Ausncia de um estudo detalhado e planejamento de riscos; Mudanas constantes na equipe do projeto; Inexperincia da equipe em relao s metodologias ou tecnologias utilizadas no projeto; Utilizao de tecnologias novas, sujeitas a provveis falhas futuras no catalogadas. 4. Use o lema Dividir para conquistar No tente atacar o problema como um todo. Lembre-se de que o projeto chegou ao pon to em que est provavelmente por esta razo. Tente tratar o conjunto de problemas id entificados no projeto como um novo projeto. E neste novo projeto deve ser aplic ado o processo de decomposio, at que as partes possam ser devidamente mensuradas, a tribudas a um responsvel, oradas e gerenciadas, de maneira que o problema como um t odo seja solucionado por meio do equacionamento de suas partes. Aps dividir o problema em partes menores e com maior possibilidade de gerenciamen to, voc deve conceber uma estratgia de abordagem das partes, criando de preferncia um novo cronograma. Neste cronograma, voc dever especificar todas as tarefas ident ificadas, dividindo-as em trs grandes categorias: tem de ser feito, deveria ser feit o e poderia ser feito. A diviso das tarefas dentro destas categorias deve levar em c onta principalmente as expectativas do cliente. As tarefas que devem ser catalogadas na categoria tem de ser feito so todas aquelas que o cliente julga essenciais e que sem as quais o projeto no ter sucesso. Este o ponto mais crtico que dever ser negociado, pois neste grupo esto aquelas tarefas que, apesar de o cliente julgar essenciais, podem comprometer o sucesso do proje to pela sua complexidade ou tamanho. Para estas tarefas, o ideal que sejam reana lisadas para que possam ser divididas em tarefas menores e reclassificadas nos t rs grupos. A categoria deveria ser feito contm todas as tarefas que sero excludas do escopo do p rojeto nesta nova negociao. Podem at ser contempladas em outro projeto, mas neste no devero ser objeto de sua ateno. O restante das tarefas, a categoria poderia ser feito, podem ou no, dependendo do t ipo de negociao, do prazo restante, de fatores polticos ou da disponibilidade de re cursos, ser includas no escopo do projeto, pois so tarefas que, quando devidamente gerenciadas, no causaro transtornos durante a execuo do projeto. 5. Negocie Diz o PMBOK que 90% do tempo de gerente de projetos deve ser gasto em comunicao e que negociao uma das habilidades que os gerentes de projeto devem possuir. Pois ag ora a hora de utilizar toda essa sua capacidade. Neste momento em que os problemas esto equacionados e divididos em partes menores a hora de negociar novos prazos, custos, mudanas de escopo, caractersticas do pro duto, ou seja, tente redimensionar o projeto adequando-o sua capacidade de traba lho, pois fato que produtos feitos sob presso de prazos podem ter quadruplicada s ua quantidade de defeitos. Utilizando uma linguagem bem popular, no tente tampar o sol com a peneira. No mais hora de ceder em acordos em que o risco seja alto para o projeto. Negocie de maneira proveitosa para ambos os lados. Porm, sempre tentando manter o cronograma proposto e a distribuio das tarefas nas trs categorias e sempre mostran do ao cliente que, apesar da reduo do escopo do projeto, as tarefas eleitas sero re almente implementadas no prazo e custo combinados e com a qualidade desejada. Le mbre-se de que uma nova negociao ser muito difcil, ou quase impossvel. Portanto, todo s os aspectos do projeto passveis de serem renegociados devem ser levados em cons iderao neste momento. Agora o momento de, a partir da triagem dos requisitos originais do projeto, ten tar negociar o desenvolvimento de somente parte deles (somente o que tem que ser feito). Uma outra alternativa seria tentar dividir o projeto em um maior nmero de entregas (marcos) que possam satisfazer o cliente (mdulos funcionais). Geralmente , assim possvel ampliar o prazo quase que imperceptivelmente, e isso pode dar um novo flego equipe do projeto para que possam implementar as entregas posteriores com certa tranqilidade. Por ltimo, procure rever sua lista de interessados (stakeholders) do projeto. Que m sabe voc no esqueceu de levar em considerao os interesses de algum? Voc deve ser mui to criterioso neste aspecto, pois gerenciar interesses e interessados com expect

ativas diferentes pode ser uma experincia exaustiva, caso voc no conhea exatamente e ste conjunto de variveis. 6. Lembre-se Ao fazer a anlise do desvio, verifique se a equipe estava tendo erros em demasia nos testes e se os cdigos estavam sendo refeitos muitas vezes. Se isso for verdad eiro, deve-se rever toda a modelagem e desenho do projeto (incluir a verificao no novo prazo) e verificar o que pode realmente ser feito e o que realmente ser joga do fora (Isso mesmo!). Lembre que um cdigo ou desenho ruim trar futuramente (e provavelmente durante o pr ojeto) um aumento significativo do esforo de implementao. De nada adianta a equipe trabalhar horas e horas a fio, aps o horrio e durante o final de semana no incio do cronograma. O stress causado na equipe pode comprometer o adiantamento do prazo conseguido, pois o cansao dos membros da equipe pode vir a gerar uma quantidade excessiva de falhas, que causaro o dobro de retrabalho nas prximas semanas. Planeje o esforo dob rado de sua equipe para os momentos finais de cada marco no cronograma, intercal ando o esforo de cada um com perodos de descanso alternados entre os membros. Analise a equipe inicial do projeto. Vrias falhas no projeto inicial podem estar relacionadas com o desempenho da equipe ou do gerente em relao a ela. No reinicie o projeto sem a certeza do comprometimento de todos. Caso venha a notar qualquer problema em relao aos membros da equipe, negocie as substituies necessrias antes do i ncio do projeto. Faa essa verificao, na medida do possvel, em conjunto com a equipe, deixando s claras toda a situao. A equipe deve ver em voc um lder; deve confiar na sua lealdade para com todos. Caso contrrio, no haver comprometimento. Isto quer dizer q ue voc deve no s se preocupar com o quanto a equipe pode contribuir no projeto, mas tambm com o quanto voc pode contribuir com a equipe. Devemos acabar com a imagem do gerente de projeto que passa o dia conferindo cro nogramas e cobrando tarefas e prazos. O gerente que realmente vivencia os proble mas de sua equipe, ri e chora com os sucessos e fracassos junto com ela. parte i ntegrante da equipe e responsvel direto pelo seu humor, nimo, comprometimento e in tegrao como uma unidade. O gerente que d ateno aos problemas de todos, mesmo os de natureza pessoal, mostra no s companheirismo e amizade pelo prximo, mas tambm que est trabalhando para o suces so do projeto. Sergio Laranja S Corra Graduado em Gesto de Tecnologia da Informao e Ps-Graduando em Planejamento Estratgico , obteve os certificados de PMP, ITIL, CobiT e MS Project Orange Belt. Fontes: PMBOK Guide Edio 2000 Project Management Institute Gerncia de Projetos de Tecnologia da Informao Phillips, Joseph Ed. Campus Projetos Virtualmente Impossveis Yourdon, Edward Ed. Makron Books