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 Guia 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.

Fontes: PMBOK® Guide – Edição 2000 – Project Management Institute. Gerência de Projetos de Tecnologia da Informação – Phillips, Joseph – Ed. Campus. Projetos Virtualmente Impossíveis – Yourdon,  Edward – Ed. Makron Books

Copyright© 2009 Sergio Laranja Sá Corrêa, PMP

Teremos o maior prazer em publicar seu artigo.