Atrasou. E agora? Como tentar reajustar o cronograma a tempo de salvar o projeto.

Sergio Laranja Sá Corrêa, PMP .

1. Calma, muita calma.

A partir do momento em que você percebeu o atraso, antes de mais nada, não adianta se desesperar. Tente manter a calma, afinal você não é o primeiro e nem será o último gerente a atrasar um projeto e o seu descontrole em nada vai ajudar.

Sem querer justificar a existência 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 Control of Software Risks), são válidas as seguintes afirmativas:

. 70% dos grandes projetos sofrem de instabilidade de requisitos;

. Pelo menos 50% dos projetos são executados com níveis de produtividade abaixo do normal;

. Pelo menos 25% dos softwares de prateleira e 50% dos feitos por encomenda apresentam mais defeitos do que o razoável;

. Pelo menos 50% dos grandes projetos de software estouram seu orçamento e prazo.

Bom, agora que você se encontra calmo, como primeiro procedimento analise a situação.

Em hipótese alguma tente continuar sem essa análise, pois, na medida em que o projeto avança, sem que sejam descobertas as causas do desvio, a situação só tende a piorar. Atitudes audazes

só vão fazer com que tudo saia definitivamente de controle e fazer com que alguns fatores de risco aumentem a ponto de se tornar impraticável seu gerenciamento.

2. Grite! Peça ajuda.

Orgulho é um luxo ao qual você não tem direito, além de ser um sentimento indesejável e muito prejudicial a qualquer projeto. Como gerente de projetos, você

pode e deve solicitar toda ajuda que achar necessária. Lembre-se de que se resolver ir adiante sozinho, você pode se tornar o herói ou o vilão da história.

Uma alternativa muito boa é solicitar um observador externo (de preferência um outro gerente de projeto) para ajudá-lo na avaliação da situação. Muitas vezes, um observador externo tende a ficar

mais atento aos detalhes e, com certeza, vai descobrir algum 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 causado um grande problema. Mas não se recrimine: é normal que, em situações críticas, nosso sentido de

observação e o nosso bom senso esteja afetado. Mais normal ainda é que as pessoas que estão dentro do contexto do projeto, principalmente enquanto vivenciam o problema, não julguem com

tanta clareza os problemas quanto as que estão olhando de um ângulo externo.

3. Tente descobrir como aconteceu o desvio.

Provavelmente um ou mais problemas descritos abaixo foram os causadores do atraso em seu projeto. A correta identificação das causas do desvio é o

principal fator de sucesso durante a negociação e o realinhamento do projeto aos seus objetivos iniciais. A lista abaixo não pretende abranger a totalidade das causas possíveis

para um desvio em projetos, mas contém algumas das mais comuns e prováveis causas deste tipo de evento. São elas:

. Desconhecimento ou desconsideração da importância de um ou mais interessados do projeto;

. Ausência de padrões e/ou métodos, desde o gerenciamento até a implementação do projeto;

. Requisitos mal definidos, entendidos ou implementados;.. Estimativas falhas ou excesso de otimismo durante a estimativa;

. Tentativa de implementação de todos os requisitos que surgem no decorrer do projeto sem que seja feita uma renegociação do prazo inicial;

. Aceitação por parte do gerente do projeto de um cronograma imposto e virtualmente impossível de ser cumprido;

. Aceitação por parte do gerente do projeto de uma diminuição de prazo sem a contrapartida de aumento dos recursos;

. Mudanças constantes das prioridades por parte dos interessados;

. Ausência de um estudo detalhado e planejamento de riscos;

. Mudanças constantes na equipe do projeto;

. Inexperiência da equipe em relação às metodologias ou tecnologias utilizadas no projeto;

. Utilização de tecnologias novas, sujeitas a prováveis falhas futuras não catalogadas.

4. Use o lema “Dividir para conquistar”

Não tente atacar o problema como um todo. Lembre-se de que o projeto chegou ao ponto em que está provavelmente por esta razão. Tente tratar o conjunto de

problemas identificados no projeto como um novo projeto. E neste novo projeto deve ser aplicado o processo de decomposição, até que as partes possam ser

devidamente mensuradas, atribuídas a um responsável, orçadas e gerenciadas, de maneira que o problema como um todo seja solucionado por meio do equacionamento de suas

partes.

Após dividir o problema em partes menores e com maior possibilidade de gerenciamento, você deve conceber uma estratégia de abordagem das partes, criando de preferência um novo

cronograma. Neste cronograma, você deverá especificar todas as tarefas identificadas, dividindo-as em três grandes categorias: “tem de ser feito”, “deveria ser feito” e “poderia ser feito”. A divisão

das tarefas dentro destas categorias deve levar em conta principalmente as expectativas do cliente.

As tarefas que devem ser catalogadas na categoria “tem de ser feito” são todas aquelas que o cliente julga essenciais e que sem as quais o projeto não terá sucesso. Este é o ponto mais

crítico que deverá ser negociado, pois neste grupo estão aquelas tarefas que, apesar de o cliente julgar essenciais, podem comprometer o sucesso do projeto pela sua complexidade ou tamanho.

Para estas tarefas, o ideal é que sejam reanalisadas para que possam ser divididas em tarefas menores e reclassificadas nos três grupos.

A categoria “deveria ser feito” contém todas as tarefas que serão excluídas do escopo do projeto nesta nova negociação. Podem até ser contempladas em outro projeto, mas neste não

deverão ser objeto de sua atenção.

O restante das tarefas, a categoria “poderia ser feito”, podem ou não, dependendo do tipo de negociação, do prazo restante, de fatores políticos ou da disponibilidade de recursos, ser

incluídas no escopo do projeto, pois são tarefas que, quando devidamente gerenciadas, não causarão transtornos durante a execução do projeto.

5. Negocie.

Diz o PMBOK que 90% do tempo de gerente de projetos deve ser gasto em comunicação e que negociação é uma das habilidades que os gerentes de projeto devem possuir. Pois agora é a hora de utilizar toda essa sua capacidade.

Neste momento em que os problemas estão equacionados e divididos em partes menores é a hora de negociar novos prazos, custos, mudanças de escopo, características do produto, ou seja, tente redimensionar o projeto adequando-o à sua capacidade de trabalho, pois é fato que produtos feitos sob pressão de prazos podem ter quadruplicada sua quantidade de defeitos.

Utilizando uma linguagem bem popular, não tente “tampar o sol com a peneira”. Não é mais hora de ceder em acordos em que o risco seja alto para o projeto. Negocie de maneira proveitosa para ambos os lados. Porém, sempre tentando manter o cronograma proposto e a distribuição das tarefas nas três categorias e sempre mostrando ao cliente que, apesar da redução do escopo do.projeto, as tarefas eleitas serão realmente implementadas no prazo e custo combinados e com a qualidade desejada.

Lembre-se de que uma nova negociação será muito difícil, ou quase impossível. Portanto, todos os aspectos do projeto passíveis de serem renegociados devem ser levados em consideração neste momento. Agora é o momento de, a partir da triagem dos requisitos originais do projeto, tentar 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 número de entregas (marcos) que possam satisfazer o cliente (módulos funcionais). Geralmente, assim é possível ampliar o prazo quase que imperceptivelmente, e isso pode dar um novo fôlego à equipe do projeto para que possam implementar as entregas posteriores com certa tranqüilidade.

Por último, procure rever sua lista de interessados (stakeholders) do projeto. Quem sabe você não esqueceu de levar em consideração os interesses de alguém? Você deve ser muito criterioso neste aspecto, pois gerenciar interesses e interessados com expectativas diferentes pode ser uma experiência exaustiva, caso você não conheça exatamente este conjunto de variáveis.

6. Lembre-se.

Ao fazer a análise do desvio, verifique se a equipe estava tendo erros em demasia nos testes e se os códigos estavam sendo refeitos muitas vezes. Se isso for verdadeiro, deve-se rever toda a modelagem e desenho do projeto (incluir a verificação no novo prazo) e verificar o que pode realmente ser feito e o que realmente será jogado fora (Isso mesmo!). Lembre que um código ou desenho ruim trará futuramente (e provavelmente durante o projeto) um aumento significativo do esforço de implementação.

De nada adianta a equipe trabalhar horas e horas a fio, após o horário e durante o final de semana no início do cronograma. O stress causado na equipe pode comprometer o adiantamento do prazo conseguido, pois o cansaço dos membros da equipe pode vir a gerar uma quantidade excessiva de falhas, que causarão o dobro de retrabalho nas próximas semanas. Planeje o esforço dobrado de sua equipe para os momentos finais de cada marco no cronograma, intercalando o esforço de cada um com períodos de descanso alternados entre os membros.

Analise a equipe inicial do projeto. Várias falhas no projeto inicial podem estar relacionadas com o desempenho da equipe ou do gerente em relação a ela. Não reinicie o projeto sem a certeza do comprometimento de todos. Caso venha a notar qualquer problema em relação aos membros da equipe, negocie as substituições necessárias antes do início do projeto. Faça essa verificação, na medida do possível, em conjunto com a equipe, deixando “às claras” toda a situação. A equipe deve ver em você um líder; deve confiar na sua lealdade para com todos. Caso contrário, não haverá comprometimento. Isto quer dizer que você deve não só se preocupar com o quanto a equipe pode contribuir no projeto, mas também com o quanto você pode contribuir com a equipe.

Devemos acabar com a imagem do gerente de projeto que passa o dia conferindo cronogramas e cobrando tarefas e prazos. O gerente que realmente vivencia os problemas de sua equipe, ri e chora com os sucessos e fracassos junto com ela. É parte integrante da equipe e responsável direto pelo seu humor, ânimo, comprometimento e integração como uma unidade. O gerente que dá atenção aos problemas de todos, mesmo os de natureza pessoal, mostra não só companheirismo e amizade pelo próximo, mas também que está trabalhando para o sucesso do projeto.

Autor: . Sergio Laranja Sá Corrêa atua na área de desenvolvimento e implantação de sistemas de informação desde 1985, desempenhando as atividades de coordenação de equipes e gerência de projetos desde 1990. Obteve o certificado PMP e atualmente trabalha como Coordenador de Pós-Projeto na Fábrica DotNet, fábrica de software do Grupo LinkNet em Brasília-DF.

 

Washington Grimas