Projeto Problema

Guias de boas práticas em gerenciamento de projetos, como o PMBOK, apresentam uma realidade um tanto fantasiosa do plano perfeito, que não existe na prática. Quem nunca ouviu "para um projeto dar errado, basta nada fazer", segundo Ricardo Vargas. Basta apenas não assumir o leme quando o barco estiver indo para a direção errada.

Mas afinal, como podemos definir um projeto problema? Aparentemente é fácil de definir na teoria, onde torna-se perceptível um projeto problemático "quando temos uma diferença que ultrapassa os limites aceitáveis entre o que foi planejado e a situação atual".

Durante o projeto será preciso monitorar constantemente sinais de disfunção nos stakeholders, recursos, escopo, riscos, escopo e prazo. Esse monitoramento ajuda ao Gerente identificar possíveis problemas no projeto, entre elas, é possível citar, segundo [ESI]:

• Os envolvidos não tem a certeza quando o projeto será finalizado: uma equipe inexperiente e a falta de recursos [WU], são algumas causas dessa indecisão quanto a entrega do produto;
• O produto do projeto apresenta muitos erros: uma equipe inexperiente e testes funcionais inadequados [WU]. Testes de segurança e desempenho ausentes ou inadequados são outras causas do número de erros no projeto (trazendo para TI). Em casos de entregas com erros vale uma análise um pouco mais fria, pois muitas horas de trabalho, as mudanças de escopo emergenciais, a pressão e o próprio treinamento da equipe podem colaborar para essas entregas problemáticas. Nem sempre a culpa é exclusivamente da equipe;
• Realização de horas extras pelo time: clássico! Horas intermináveis de trabalho extra, seja para cobrir alterações de escopo na última hora, ou para correção de erros, é um fator muito subestimado de problema no planejamento do projeto, que pode acontecer por diversos motivos, sendo um deles a inadequação do patrocinador [WU];
• A gerência perde o controle sobre o progresso ou o status preciso do projeto: a indefinição do escopo ou até mesmo do não-escopo são causas para essa sensação. Aqui entra o Gerente com auxílio da equipe para fechar o projeto junto ao cliente. Formalizar o escopo? O mundo ágil não vê com bons olhos, mas apesar de ser um fã do Agile, esse ponto é bastante polêmico, vale outro post;
• Perda de confiança do cliente sobre o time de desenvolvimento: frequentes atrasos, entregas erráticas, imprecisão quanto a entrega, são fatores que descredenciam a equipe do projeto;
• A equipe é defensiva sobre o progresso do projeto: desacreditada e como citado abaixo, por vezes com a moral baixa, a equipe se torna reativa e defensiva quanto ao andamento do projeto. Por vezes descredita a manutenção do escopo, o que limita a visão do fim que a equipe tem sobre o projeto, fator desmotivador. Bola de neve;
• A relação entre o time de desenvolvimento e os demais envolvidos estão tensas e por vezes desgastadas: erros constantes e atraso por um lado, alteração constante de escopo pelo outro lado acirram os ânimos dos envolvidos. O Gerente deve tomar medidas diplomáticas para resolução desse problema e por vezes, em uma atitude mais radical, isolar a equipe de desenvolvimento, procurando manter o ambiente apropriado para o trabalho;
• O projeto está a beira do cancelamento: quando o próprio patrocinador já questiona a continuidade do projeto é um fator mais do que necessário para desencadear boa parte dos itens citados acima. Por vezes, e iremos ver em posts futuros, o cancelamento é a saída mais plausível a ser tomada, por outras, prejudica o andamento de um projeto já errático. O Sponsor é aquele que acredita e deposita a confiança nos envolvidos. Fala do projeto com entusiasmo e o abraça como se fosse a um sonho pessoal. Isso é inspirador e contagia a equipe;
• A moral o time está abalada e demasiadamente baixa: erros + insatisfação + pressão interna por vezes inevitável + projeto a beira do cancelamento. É uma fórmula bastante depreciativa e certamente abala qualquer equipe. Trazê-la de volta ao rumo certo é tarefa complicada e quase impossível em curto prazo;
• O cliente ameaça tomar medidas legais: projetos com contratos SLA, por exemplo, prevêem a ação judicial em caso de erros por pontos de função, por exemplo, que quando acionados, trazem intranquilidade e aumenta a pressão sobre a equipe de projeto. É um claro indicador de problemas no projeto.

Outros fatores citados por VARGAS, que identificam um projeto problema são:

• Ausência dos envolvidos no projeto: quem define o negócio? Onde está o Product Owner? Essa ausência compromete o produto do projeto, que poderá não atender ao negócio. Uma situação contrária, onde temos dois ou mais Product Onwer é também um problema ao projeto e o seu escopo. Uma fórmula que invariavelmente funciona é de um PO que centraliza ideias dos envolvidos;
• A escassez de recursos: esse é um dos grandes problemas do Gerente de Projetos, lidar com recursos limitados ou concorrentes entre projetos. A arte do gerenciamento de projetos é mensurar o tempo para esses casos, e ainda atender a expectativa dos envolvidos. É uma arte, inegavelmente;
• A saída voluntária de pessoas: aumento da pressão, a insatisfação, a não percepção de valor, a sensação de que aquela obra não é dele, como diria Mario Cortella, desmotiva o indivíduo;
• Indefinição entre as partes do que é ou não escopo: ausência de uma definição formal do escopo e não-escopo. Tarefa do Gerente (note que existe um mix entre termos do Agile e do gerenciamento de projetos tradicional, característica de alguém que flerta com os dois mundos);
• Os impactos dos riscos são maiores: projetos com problemas no escopo, tempo e/ou custo costumam reagir aos riscos de forma anormal, portanto, o planejamento de riscos deve prever uma reação aos riscos mais pessimista que em projetos em situação regular;
• Aumento da informalidade: a documentação do projeto é negligenciada por falta de tempo, diminuindo a confiabilidade desses documentos. É uma atitude desesperada que pode acarretar problemas futuros, principalmente em projetos com alterações frequentes no escopo, sem o controle das mudanças.

Após a identificação de um projeto problema o Gerente tem ao menos dois caminhos: corrigir o rumo ou terminar o projeto, afim de evitar ou minimizar a exaustão dos participantes, a redução da moral e da auto-estima da equipe, a potencialização da sensação de falta de controle, que são o reflexo de um projeto problema.

Nos próximos posts comento sobre essas duas escolhas: cancelar ou tocar em frente? Eis a questão.

Referências:

EIS Internacional. The rapid assessment and recovery of troubled projects. Disponível na Internet em http://www.projectsmart.co.uk/docs/rapid-assessment-and-recovery-of-troubled-projects.pdf. Atualizado em 2007. Acessado em 2010.

WU, Jonathan. Top 10 warning signs of a troubled BI project. Disponível na Internet em http://www.information-management.com/news/2707-1.html. Atualizado em 2000. Acessado em 2010.

VARGAS, Ricardo. Identificando e recuperando projetos problemáticos: como resgatar seu projeto do fracasso. Disponível na Internet em http://www.ricardo-vargas.com/wp-content/uploads/downloads/ricardo_vargas_identifying_recovering_troubled_projects_pt.pdf. Atualizado em 2006. Acessado em 2010.