Como recuperar um projeto à beira do fracasso

Quarto mês da implantação de um novo sistema de gestão em uma rede varejista com lojas em cinco estados. O relatório semanal continua amarelo. A equipe parou de pedir decisões e começou a pedir paciência. O patrocinador já ouviu três vezes que o atraso está sendo recuperado, e a diretoria vai cobrar uma data firme antes do fechamento do ano. Quem trabalha perto do projeto sente que ele não vai chegar onde deveria, e ninguém quer ser a pessoa que diz isso em voz alta.

Esse silêncio é o que transforma um projeto recuperável em um projeto perdido.

Se há orçamento e pessoas alocadas em um trabalho, é porque o resultado esperado vale isso. Dedicá-los a uma tarefa infrutífera tem um custo duplo: os recursos queimados em um trabalho que não vai dar o resultado previsto e o trabalho que, em outro lugar, nunca chega a receber esses recursos. Decidir se um projeto será resgatado, ou se será encerrado a tempo, é uma das decisões mais difíceis de uma organização bem conduzida e uma das mais valiosas.

Reconheça o fracasso enquanto ainda há tempo

O primeiro passo é o mais óbvio, e é exatamente por isso que é pulado. Quando um projeto vai mal, alguém precisa admitir.

Admitir fica bem mais fácil em projetos preparados para dar avisos antecipados. Três hábitos fazem quase todo esse trabalho:

• Riscos identificados com a resposta planejada de antemão. Saber que um fornecedor pode atrasar não serve de nada sozinho. O que serve é saber o que acontece no dia em que ele atrasa. As 6 fases para controlar riscos mostram como sair da primeira situação e chegar à segunda.
• Marcos intermediários com um resultado definido. Um marco que apenas registra uma data não diz nada. Um marco que precisa produzir alguma coisa diz, enquanto ainda existe margem de reação, se o resultado final vai atender ao que o cliente espera.
• Um acompanhamento que antecipe os desvios em vez de apenas constatá-los. O sentido de medir é enxergar o desvio chegando. Conte ao cliente quais são as suas estimativas atuais, com relatórios periódicos e sempre que algo relevante mudar, em vez de confirmar a má notícia depois que ela já aconteceu.

O primeiro dos três é o que mais costuma ficar só no rótulo:

Um plano de mitigação reduz a probabilidade de um risco acontecer. Um plano de contingência não mexe nessa probabilidade: ele prepara a resposta que limita o impacto caso o risco se materialize mesmo assim.

No ITM Platform, os dois planos ficam registrados no mesmo risco e, quando o plano de mitigação falha, o risco é escalado para um incidente, cuja resolução guarda o que aquele evento custou ao projeto em prazo, custo ou escopo. A gestão de riscos e incidentes explica como os dois registros se conectam.

Admitir um problema é também o ponto de partida de uma análise, na escala da empresa ou individual, em busca do que dá para melhorar. Não existe um momento único para isso. Se o risco é iminente, vale rodar a análise durante a execução, mesmo que ela atrase o trabalho. Se o estrago já está feito, uma análise post mortem oferece um retrato mais calmo e mais completo.

Decida se vale continuar, e que a decisão siga uma regra

Depois que fica claro que o projeto tem grandes chances de fracassar, a pergunta passa a ser se ainda faz sentido executá-lo. Um projeto ativo consome recursos, vá entregar ou não.

O custo de oportunidade de um projeto que vai mal não é o orçamento já gasto. São os resultados que outros projetos deixam de produzir porque os recursos estão presos aqui.

Sobram três opções honestas, e a escolha entre elas deveria se apoiar em evidências, não em quem tem mais a perder.

Opção	Quando se encaixa	O que custa
Continuar como previsto	O desvio está explicado, delimitado e já diminuindo	Nada a mais, desde que o diagnóstico esteja certo
Rever o escopo e replanejar	O objetivo ainda tem valor, mas o plano ou o escopo atuais não	Um ciclo de replanejamento e uma renegociação com o patrocinador
Cancelar	Nenhuma versão realista do projeto entrega um resultado que compense o esforço restante	O trabalho já feito, menos o que der para reaproveitar em outro lugar

Uma derrota a tempo pode ser uma vitória final. O que a transforma em vitória, e não em boato, é a decisão ser tomada abertamente, por quem tem atribuição para tomá-la, e ficar registrada onde todos possam ver. Caso contrário, o projeto não para de verdade: apenas deixa de ser mencionado enquanto segue consumindo recursos.

Essa é a parte que a maioria das organizações deixa informal. No ITM Platform, o status de um projeto avança por um fluxo de trabalho que a sua organização define, e uma transição pode exigir aprovação: passar um projeto para um status de descartado pode ficar restrito, por exemplo, aos membros do escritório técnico de projetos. O cancelamento passa a ter responsável, data e rastro. Fluxos de trabalho e aprovações de status do projeto descreve como essas regras são configuradas.

Traga alguém que não construiu o projeto

Encontrar os próprios erros é difícil. Seja por orgulho, seja por acomodação, a gente tende a dar por bom aquilo que produziu e a passar batido pelas partes que preferiria não reabrir.

As equipes de software aprenderam isso cedo. Os programas não são testados só na máquina em que foram escritos, e raramente só por quem os escreveu, porque a revisão sai mais minuciosa e mais objetiva quando quem revisa está de fora do trabalho. A autoavaliação costuma ser benevolente e se dar por satisfeita rápido demais.

Um leitor externo, ainda mais um leitor experiente, traz o que uma equipe mergulhada no trabalho não consegue trazer: distância. Uma equipe ocupada com os problemas superficiais que tem pela frente costuma deixar passar os de fundo, que são justamente os que merecem atenção. As árvores não deixam ver a floresta, e é para isso que serve uma revisão de fora.

Não precisa ser uma auditoria formal. Três versões leves funcionam:

• Um gerente de projetos de outra área faz uma revisão curta contra o plano e o status atual.
• O escritório de projetos compara o projeto como ele está hoje com o business case que o justificou.
• O patrocinador responde a uma única pergunta: com o que sabemos hoje, você aprovaria este projeto?

Divida a recuperação em pequenas vitórias diárias

Terminar um projeto inteiro pode parecer grande demais, e um projeto com problemas parece ainda maior. Mas as recuperações raramente se apoiam em medidas extraordinárias. Uma pequena vitória por dia pode somar até o resultado final.

Os bons engenheiros dominam essa arte. Diante de algo tão imponente quanto uma ponte, um porta-aviões ou um software novo, eles analisam o objetivo final, quebram tudo nas menores peças possíveis e organizam o trabalho em torno delas. Em vez de uma meta inalcançável a vários meses de distância, o responsável pelo projeto e a equipe têm pela frente o dia de hoje, com as tarefas que cabem nele.

Isso também torna a motivação administrável. Concentrar-se no trabalho do dia elimina boa parte da ansiedade diante da complexidade do projeto inteiro, e dá a cada pessoa algo que ela consegue terminar.

A única condição é que as vitórias sejam reais. Uma vitória diária medida com otimismo é uma ilusão diária, e um projeto em recuperação não pode se dar a esse luxo. Compare o que foi estimado com o que aconteceu de verdade: a diferença entre as porcentagens de avanço estimadas e reais é o que diz se a recuperação está funcionando ou se apenas está sendo contada assim.

Mais recursos raramente consertam um projeto que vai mal

Pense na atenção e na motivação como o capital psicológico de uma organização. A regra que sai daí é fácil de enunciar e difícil de aplicar: o que importa não é quanto você consegue mobilizar, e sim como distribui e controla esse capital.

Uma equipe espalhada por todo o ciclo do projeto, fazendo malabarismo entre as próprias entregas e as responsabilidades de outra área, produz menos que uma equipe com escopo claro e energia para dedicar a ele. Concentração não é traço de personalidade: é consequência de como o trabalho foi distribuído.

Com os recursos financeiros, materiais e humanos acontece o mesmo. As organizações que mais tiram proveito de seus projetos não são necessariamente as que começaram com mais meios. O primeiro escritório do Google foi uma garagem.

Então, antes de colocar mais gente em um projeto com problemas, olhe para onde está indo a gente que você já tem. A análise de recursos confronta a capacidade de cada pessoa com o esforço estimado e o esforço real dela em todos os projetos e serviços, que é onde as diferenças entre o trabalho planejado e o trabalho real ficam visíveis. Muitas vezes, o projeto que vai mal não precisa de mais pessoas: precisa que as que já tem parem de ser puxadas para outras três frentes.

Não são os recursos que separam uma organização cujos projetos vão em frente de outra cujos projetos fracassam. O que separa é como esses recursos são geridos.

Próximos passos

• Comece um teste gratuito do ITM Platform e configure riscos, marcos e regras de status no projeto que mais preocupa você agora.
• Veja o que a administração de projetos do ITM Platform cobre, do planejamento e do acompanhamento até risco, incidentes e controle de recursos.
• Confira as regras de aprovação que a sua organização precisaria ter para registrar um cancelamento do jeito certo.