Porque os projetos falham?
Quando um projeto é encerrado prematuramente, é cancelado ou termina sem que seus objetivos tenham sido atingidos, considera-se que ele fracassou. O Gestor do Projeto (GP) tem que se prevenir, o que não é muito difícil já que as causas são quase sempre as mesmas, uma (ou várias) destas:
Causa 1: Expectativas irrrealistas
Se é verdade que o segredo da felicidade é a administração das expectativas, se você não administrar as suas (e as do patrocinador), você pode acabar se decepcionando com resultados que, sob uma outra ótica, seriam considerados bons.
Seja por uma falha de compreensão do escopo ou por um cronograma muito apertado, os projetos que não têm sólidas bases realistas tendem a falhar mais do que os projetos que levam em conta a cultura da empresa e as restrições impostas naquele momento.
Mas como saber se as minhas expectativas são realistas? Pense em discutí-las com profissionais mais experientes que conhecem os problemas que você terá de resolver e que conhecem a organização.
Às vezes o procedimento mais simples fica travado pela burocracia e quem já passou por isso pode ajudá-lo contornar os obstáculos.
Causa 2: Planejamento deficiente
Depois de estudar muita estatística cheguei a uma conclusão: planejamento é muito mais arte do que ciência.
Você pode aprender os mais sofisticados métodos de previsão, saber calcular o desvio-padrão de uma estimativa e usar as ferramentas mais sofisticadas e mesmo assim errar. Porquê? Em geral por que partiu de premissas erradas. Você espera que determinado fornecedor entregue uma tarefa com uma eficiência de 95% e ele falha em 30% das vezes. Sua margem de manobra que era de 5% estourou e você deve acomodar os 25% (30%-5%) que aconteceram de forma imprevisível.
Vivemos num mundo complexo em que os eventos podem ser influenciados por acontecimentos de uma forma numa vez, mas por outra bem diferente na próxima ocorrência. Quando aproximamos um processo tendemos a buscar uma função com forma linear, algo como y=Ax+B. Neste modelo, a variável x que se observa explica a variável y segundo os parâmetros A e B. Mas se houver outro fator, digamos z, que afeta y e não colocamos na equação (porque quando medimos x e y, z era desprezível), podemos incorrer em grande erros nos casos em que esta variável omitida, z, assuma valores significativos.
Nos processos de Gestão de Riscos, deve-se identificar os fatores relevantes (no nosso caso, x e z) e procurar medir, ou estimar, qual o possível impacto no resultado final (no nosso caso, y).
Causa 3: Falha no controle de desempenho
Não há nenhuma desculpa aceitável para se perder o controle sobre o desempenho da equipe de projeto e de outros interessados que afetam diretamente os resultados. Alguns GPs preferem relatórios, outros vão para o contato cara-a-cara. Não importa como, mas é vital que este processo de acompanhamento seja permanente e regular. Se a tarefa parece cansativa, automatize-a mas faça.
As pessoas respondem de forma diferente quando são monitoradas, como nos ensina o “efeito Hawthorne”.
Neste experimento, o mero fato de estarem sendo acompanhados por pesquisadores fazia com que os trabalhadores de uma fábrica produzissem mais. Tentaram variar a luminosidade do ambiente de trabalho e descobriu-se que com mais ou menos luz, as pessoas eram mais produtivas. Ficou ficou claro que não era a luz que influía nos resultados, mas o ato de estar sendo monitorado é que fazia o pessoal dar duro.
Desempenho pode ser algo complicado de medir. Num projeto de software, usa-se muito como métrica a quantidade de linhas de código escritas. Mas um programador pode entregar mais código e ao mesmo tempo cometer mais erros do que os outros. Um bom indicador deve ser simples, mas não tão simples que esconda o que se deseja realmente medir, que é a quantidade de código de boa qualidade.
Lembre-se da velha fórmula: “tudo o que se deseja obter deve ser medido”.
Causa 4: Falta de liderança efetiva
Eu encontrei vários GPs que vinham de organizações matriciais fortes e acredito que foram muito influenciados por elas. Parece que nestas organizações, as pessoas demoram mais a responder por receio de entrar numa área alheia. No limite, a guerra entre os “feudos” impede que boas iniciativas inter-departamentais decolem. As pessoas estão reprimidas e, se o GP é “cria da casa”, ele pode
apresentar hesitações “inexplicáveis”.
Estas pessoas usualmente apostam que muitos ruídos se dissipam “sozinhos”, o que obviamente não acontece. O ruído, ie. um pequeno problema dentro da equipe, pode ser mais do que isso. Pode ser que não seja tão pequeno mas que assim pareça por uma falha de percepção do GP. Quanto maior o projeto, maior a inércia (leia-se, resistência a mudanças) e maiores as chances de ruídos.
Quanto mais rápido o problema for endereçado pelo GP, melhor para todos.
Além disso, a verdadeira liderança é inspiradora e viral: um bom líder acaba criando um ambiente propício ao surgimento de novos líderes a sua volta. Uma dica: se você topar com uma equipe cheia de pessoas motivadas e que apresentam um claro interesse em liderar, você tem uma boa pista de que o GP é um bom líder.
Causa 5: Falta de skills dos membros do time de projeto
Quando contratou um profissional, o GP pode ter sido enganado pensando que o candidato sabia fazer uma coisa que na verdade não sabe, mas isso é difícil de ocorrer se você tomar as devidas precauções como estabelecer uma descrição funcional (“job description”) bem detalhada e que especifique uma série de habilidades que possam ser verificadas. Discutimos técnicas para isso em outro artigo.
Mas mesmo que você tenha feito tudo certo, começou o projeto, definiu e plataforma de desenvolvimento (digamos por exemplo, Windows), contratou experts e depois, por uma daquelas voltas da vida, descobre que o produto deveria ser desenvolvido em outra plataforma (por exemplo, Unix) que sua equipe não conhece. O que fazer? Trocar ou retreinar?
Depende dos recursos de tempo e verba disponíveis mas via de regra prepare-se para mudar boa parte da equipe, sem se deixar levar por sentimentos de amizade ou pena. Melhor seria especificar o pagamento de um bônus de desligamento antes de contratar o profissional. Quanto antes ficam claras as regras do jogo, melhor para todos. No final, a opção é simples: agir quando ainda há tempo ou ver o barco afundar.
Causa 6: Falta de motivação do time e dos interessados
O moral da equipe sofre muito quando a gestão é fraca. Imagine se o João, que é um gerente júnior importante para o projeto acabou de casar e está sendo pressionado pela esposa a procurar outro emprego que pague mais. O GP, temendo perdê-lo, lhe promete um bônus mas não pede autorização da direção nem com do pessoal de RH. Ele pensa que não é necessário já que o projeto tem orçamento para isso.
João dá duro, se esforça e o projeto é um sucesso. Na hora “H”, o bônus não vem como prometido e João recebe um tapinha nas costas. As explicações são as mais diversas: não temos orçamento para isso, é política de empresa não fazer estas coisas, você não seguiu os procedimentos da empresa, etc…
Isso pouco importa para quem não recebeu a devida recompensa. O que acontecerá com o desempenho de João depois disso? Isso para não mencionar a perda de credibilidade.
Tenho uma regra: quando um bom profissional está entregando abaixo do seu potencial o GP tem “culpa no cartório”: ele deveria ter se informado sobre o que está acontecendo. No caso do João, ele agora está saindo mais cedo para ir a entrevistas de emprego em outras empresas. O GP deveria ter tomado as devidas medidas corretivas, como se informar sobre a possibilidade de bonificar o pessoal.
Moral de história: se você não puder oferecer um bônus, não o faça. Se fizer, tem de cumprir.
Causa 7: Falta de apoio dentro da organização
Apoio aqui é a força política que um diretor, sócio ou presidente pode dar ao projeto. A figura mais importante para o projeto é a do patrocinador que deve comunicar aos demais membros da organização a importância da iniciativa para a empresa, cobrando deles a atenção necessária para que as tarefas sejam concluídas.
Por exemplo, imagine instalar um sistema financeiro numa empresa pequena com um grande número de pedidos processados manualmente todos os dias. Haverá uma sobrecarga do pessoal do departamento pelo tempo necessário ao teste e implantação do projeto.
Esse tempo extra pode exigir a contratação de pessoal temporário para fazer as tarefas do dia-a-dia enquanto o pessoal da casa usa a nova ferramenta. Sem apoio de alguém com poder de decisão pode ser difícil contratar esta equipe para ajudar na transição ou para fazer o pessoal do departamento financeiro separar duas horas do seu dia para testar e aprender a usar a nova ferramenta.
Causa 8: Falta de recursos
Apesar de algumas pessoas não tomarem o cancelamento de um projeto por falta de fundos como um fracasso, entendo que de alguma forma o GP poderia ter se antecipado ao problema. Qualquer companhia pode enfrentar momentos difíceis, que exijam a redução rápida de custos. No entanto, isso dificilmente acontece do nada (como, por exemplo, na mini-crise de 11 de setembro de 2001).
Em geral os sinais estão por toda parte e cabe ao GP estar ligado neles. Por exemplo, se parte dos recursos para um projeto ainda devem ser captados no mercado e os juros (leia-se, a taxa Selic) sobem, é provável que surjam dificuldades para realizar esta captação.
E como tratar o problema com a equipe? É melhor abordar o tema claramente numa reunião do que deixar os rumores de demissões tomarem conta das mentes de pessoas que deveriam estar concentradas em obter resultados.
Se haverá um corte de orçamento, o GP deve se antecipar e planejar como se poderia reduzir custos e seguir com o projeto. No limte, ele deveria pensar em encerrar o projeto deixando resultados palpáveis, mesmo que não os originalmente esperados. A partir de algo concreto é mais provável que se possa retomar o projeto quando o ambiente econômico melhorar.
Mas se os recursos faltarem porque a empresa está vendo outros projetos como prioritários, o GP deve lutar por seu projeto e mostrar o que já se ganhou com ele e quanto ainda deve ganhar se completá-lo.
Se o patrocinador receber um plano para seguir com o projeto com custos reduzidos, isso pode evitar a suspensão/cancelamento do projeto.
Conclusão
Sejam quais forem as causas do cancelamento do projeto, recomendo que sempre se faça uma reunião de encerramento para se discutir “o que se pode aprender com essa experiência”. Quando há confiança e respeito mútuo a equipe enfrenta as consequências do fracasso de forma unida. Cabe ao GP informar aos demais os propósitos da reunião, senão corre-se o risco dos mais exaltados buscarem culpados, o que cria um clima desagradável que impede o diálogo.
Sugiro que cada um faça o seu mea culpa, levantando apenas os pontos em que deveria ter agido de outra forma, sem tentar explicar seus atos em resposta a erros dos outros. Assumindo que o grupo fez tudo o que podia ser feito para evitar o fracasso, o GP deve tirar as lições devidas e resumi-las para todos. Assim aumenta-se as chances de sucesso no próximo projeto.
De toda forma, planejamento e comunicação são as duas atribuições críticas que o GP não deve delegar.
