Quando um projeto derrapa: ver cedo em vez de explicar tarde

Um projeto que falha o prazo em julho começou a falhá-lo em maio. A data não se perde no dia em que se anuncia: perde-se semanas antes, numa tarefa que ficou à espera de uma resposta, num marco que escorregou duas vezes sem ninguém somar as duas, numa pessoa que foi chamada para outra coisa «só esta semana».

Quando alguém diz em voz alta que vai derrapar, já não há decisões boas disponíveis — só explicações. A diferença entre as empresas que dão más notícias com tempo e as que as dão no fim raramente está no cuidado das pessoas. Está no que elas conseguem ver, e em quando.

«Percentagem concluída» é o indicador que mente melhor

É o campo mais preenchido dos planos de projeto e o menos informativo. Uma tarefa que está «quase pronta» há três semanas continua a parecer saudável, porque a percentagem não é uma medição: é uma opinião, e ninguém quer ser o dono da opinião pessimista.

O problema agrava-se por soma. Dez tarefas quase prontas dão um projeto com muito bom aspeto e nenhum resultado entregue, e o dia em que isso se descobre é o dia em que faltava uma semana.

A alternativa é trivial e desconfortável: estados binários e tarefas pequenas. Uma tarefa está por começar, em curso ou feita. Se «em curso» durar mais do que uns dias, o problema não é o estado — é o tamanho da tarefa, que é grande demais para ser uma tarefa. Um plano feito de peças pequenas informa sobre o seu próprio estado sem obrigar ninguém a estimar progresso, e é a razão por que vale a pena gastar tempo a dividir trabalho antes de começar.

Os sinais que aparecem antes de a data falhar

Nenhum dos sinais fiáveis é sobre a data. Todos aparecem antes dela, e todos são visíveis a quem estiver a olhar:

• Um marco que muda de data sem nunca falhar. Adiado três vezes por duas semanas, chega a julho sem que exista um único registo de incumprimento.
• Trabalho que volta atrás. Tarefas dadas por feitas que reabrem. É o sinal mais barato de todos e o que costuma não ser medido, porque cada caso parece isolado.
• Tarefas que mudam de responsável a meio. Cada troca custa o tempo de quem entra a perceber o que já foi feito, e esse tempo não está em plano nenhum.
• Horas a subir num projeto cujo estado não muda. É o cruzamento mais útil que existe e o mais fácil de esquecer.
• A mesma pergunta do cliente duas vezes. Quem pergunta duas vezes já não confia na primeira resposta, e normalmente tem razão.

Ver isto não exige relatórios sofisticados. Exige que o estado das tarefas e o tempo registado vivam no mesmo sítio e sejam lidos na mesma reunião — que é o que alimenta os indicadores de entrega do módulo de gestão em vez de os deixar numa folha paralela que alguém atualiza na véspera.

Quem tem autorização para dizer que está a derrapar

Quase sempre o sinal existe, alguém o vê e não o diz. Não é um problema de ferramenta, é de consequência: se quem trouxe a má notícia da última vez levou com a conversa, a próxima chega mais tarde. Uma equipa aprende isto depressa e sem ninguém lhe explicar.

Há um detalhe de reunião que muda mais do que parece. A pergunta «está tudo bem?» tem uma única resposta socialmente possível, e é «sim». As perguntas que funcionam são outras: de que é que estás à espera? O que é que te está a bloquear? O que é que te preocupa nas próximas duas semanas? São perguntas sobre obstáculos, não sobre desempenho, e é por isso que obtêm respostas verdadeiras.

Vale a pena tornar isto explícito com a equipa: um risco comunicado a tempo é trabalho bem feito, e não uma confissão. Quem gere tem de o dizer em voz alta e, sobretudo, tem de se comportar assim na primeira vez que acontecer.

Há três respostas possíveis, e nenhuma é trabalhar mais depressa

Descoberta a derrapagem, as opções são sempre as mesmas três, e cada uma tem um custo e um dono.

Mover a data. Custa ao cliente e à reputação, e é a opção mais barata de todas quando é exercida cedo. Reduzir ou trocar o âmbito. Exige o cliente na conversa, e é por isso a que mais se evita — mas é a única que preserva a data sem estragar o trabalho, e funciona particularmente bem quando há uma parte que ele próprio não tem pressa em receber. Acrescentar quem faz. Custa o tempo de quem já está a trabalhar, porque alguém tem de explicar o contexto a quem entra; feita no último mês, atrasa quase tanto quanto ajuda.

«Trabalhar mais depressa» não é uma quarta opção. É o que a equipa já está a tentar, e insistir nisso produz trabalho por revalidar — ou seja, produz a reabertura de tarefas que é exatamente o sinal com que este problema começou.

O que a derrapagem deixa para o orçamento seguinte

Depois de entregar, há uma conversa que vale uma hora e quase nunca acontece, porque a equipa está exausta e o projeto seguinte já começou. A pergunta certa não é «quem falhou». É «que informação nos faltava em maio, e onde é que ela estava?».

A resposta habitual é incómoda: existia. Estava num email, na cabeça de uma pessoa ou num registo que ninguém consultava. Uma derrapagem raramente é um problema de previsão — é um problema de leitura, e por isso melhora-se mudando o que se olha, não estimando com mais medo.

Comece pelo último projeto que derrapou. Marque no calendário a semana em que era possível saber, e escreva o que já se sabia nessa semana. Esse exercício dá-lhe a lista curta dos sinais que a sua empresa devia estar a ver todas as semanas — e é com ela que faz sentido olhar para o módulo de Projetos, para a qualidade das estimativas que a alimentam e para o que o tempo registado consegue dizer sobre um projeto ainda a decorrer. Traga um caso seu ao diagnóstico e percorremo-lo do fim para o princípio.