Porque falham?

Porque falham os projetos?
* Este texto pode ser livremente citado e distribuído desde que identificada a fonte/autoria.

Fernando C Barbi, PMP
fernando@gestaodeprojeto.info

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



Copyright (C) 2009-2010, Fernando C Barbi