Por que projetos falham e o que separa os que entregam dos que não entregam
Por que projetos falham? Planejamento, decisões adiadas e indicadores que escondem problemas estão entre as causas. Mario Trentim explica o que muda o jogo.
Projetos falham quando planejamento, execução e governança não conseguem detectar e responder aos desvios no tempo certo.
O chamado indicador melancia, verde por fora e vermelho por dentro, esconde problemas que poderiam ser corrigidos antes de comprometer a entrega.
Projetos complexos precisam de uma gestão decision-driven, na qual decisões tenham responsáveis, prazos e informações suficientes para serem tomadas rapidamente.
Há uma assimetria incômoda na gestão de projetos: existem milhares de maneiras de falhar e, essencialmente, uma única maneira de dar certo. Isso não é pessimismo. É diagnóstico.
Em 25 anos gerenciando projetos, na Força Aérea Brasileira, na UNOPS, na ModernPMO e em organizações públicas e privadas de diferentes países, aprendi a reconhecer o fracasso em duas formas recorrentes.
Teste vocacional
Qual carreira combina com o seu perfil?
Responda as perguntas e descubra o curso certo e as bolsas ideais para você!
A primeira é barulhenta e fácil de identificar. A segunda é silenciosa. E é justamente ela que mais destrói valor.
Planejamento insuficiente ou mal estruturado: escopo mal definido, dependências ignoradas e riscos sem respostas previamente estabelecidas.
Execução sem disciplina de monitoramento: decisões adiadas e problemas que se acumulam sem uma resposta efetiva.
Governança que não governa: relatórios que mostram o projeto como verde quando, na prática, os principais indicadores já estão comprometidos.
O Standish Group documenta há décadas diferentes causas associadas ao fracasso de projetos. O PMI Pulse of the Profession 2026 atualiza esse diagnóstico: 31% dos projetos complexos não atingem os benefícios pretendidos, mais que o dobro dos 12% registrados em 2024.
Além disso, 80% dos projetos complexos sofrem impacto negativo quando a complexidade não é gerenciada de forma ativa.
Esses números não surpreendem quem trabalha diretamente com projetos. Eles apenas confirmam algo que aparece no cotidiano das organizações.
O fracasso silencioso dos projetos: o indicador melancia
O fracasso ruidoso é relativamente simples de identificar.
O projeto ultrapassa o orçamento, atrasa de maneira evidente ou perde o apoio do patrocinador. Todos percebem o problema. Alguém intervém, ainda que muitas vezes tarde demais.
O fracasso silencioso funciona de outra maneira.
É o que chamo de indicador melancia: verde por fora, vermelho por dentro.
O relatório de status informa que o projeto está no prazo. O dashboard permanece verde. O gestor apresenta os resultados ao comitê com confiança.
Enquanto isso, as dependências estão atrasadas, os riscos foram reclassificados para baixo para evitar alarmes, os testes foram adiados e a equipe conhece os problemas, mas não os comunica.
Por quê?
Porque algumas culturas organizacionais punem o mensageiro.
O indicador melancia não é necessariamente um acidente. Ele pode ser uma adaptação racional a um ambiente em que comunicar problemas tem um custo imediato, enquanto escondê-los oferece uma recompensa de curto prazo.
O gerente que informa em março que o projeto está atrasado enfrenta pressão naquele momento.
O gerente que mantém o status verde até junho pode adiar o problema. Quando as consequências finalmente aparecem, porém, o projeto já pode estar além do ponto de recuperação.
Esse mecanismo destrói valor de maneira silenciosa. E pode ser ainda mais comum do que as pesquisas conseguem demonstrar, porque, por definição, um problema oculto dificilmente aparece nos indicadores oficiais.
Por trás do indicador melancia existe outro padrão recorrente: o adiamento de decisões.
Cada decisão postergada tem um custo imediato aparentemente baixo e um custo potencialmente alto no futuro.
A equipe aprende rapidamente essa lógica. Se levantar um problema agora, será necessário responder por ele.
Se esperar mais uma semana, talvez a situação se resolva sozinha. Talvez alguém em uma posição hierárquica superior tome a decisão. Talvez o problema só apareça depois que o projeto terminar.
O resultado é uma fila invisível de decisões não tomadas.
Ela não aparece necessariamente no cronograma. Também pode não aparecer no registro de riscos.
Mario Trentim apresenta competências estratégicas para profissionais de gestão de projetos durante palestra sobre priorização, inovação e capacidade de execução.
Mas permanece acumulando consequências.
Em algum momento, o problema fica grande demais para ser escondido. Muitas vezes isso acontece próximo do prazo de entrega, justamente quando o custo de correção é maior.
Daniel Kahneman documentou a tendência humana de valorizar mais as consequências imediatas do que aquelas que estão distantes no tempo.
Em projetos, organizações que não criam mecanismos explícitos para combater esse viés acabam reproduzindo o comportamento de adiar decisões importantes.
O que separa os projetos que entregam dos que falham?
Depois de acompanhar projetos que falharam e projetos que entregaram resultados, em contextos tão diferentes quanto operações humanitárias no Oriente Médio e implementações de tecnologia no setor privado brasileiro, percebo uma estrutura recorrente.
Não existe uma metodologia mágica.
O que existe é uma combinação consistente de planejamento detalhado, execução disciplinada, monitoramento rigoroso e decisões tomadas no momento adequado.
1. Planejamento detalhado
Não me refiro a um planejamento genérico.
Um bom plano precisa chegar ao nível das dependências reais, dos pacotes de trabalho, dos critérios de aceitação e dos riscos com respostas previamente definidas.
Um dos erros mais comuns é confundir um plano de alto nível com planejamento.
Um cronograma com 15 linhas não é um plano. É uma intenção.
Planejamento é aquilo que permite recalcular o impacto quando alguma coisa muda.
Se o plano não tem granularidade suficiente para isso, qualquer decisão de recuperação será baseada mais em intuição do que em dados.
2. Execução disciplinada
Disciplina de execução não significa rigidez.
Significa capacidade de identificar desvios cedo e agir antes que eles se tornem irreversíveis.
Para isso, as reuniões de acompanhamento precisam olhar para os desvios, e não apenas para o status. Os indicadores devem mostrar tendências, e não somente a situação atual. E a cultura precisa tratar o reporte de problemas como um comportamento esperado.
O PMI Pulse 2025 documentou um dado relevante: profissionais com alto business acumen rastreiam, em média, 9,1 fatores de sucesso por projeto. Entre os demais profissionais, a média é de 6,3.
A diferença pode parecer pequena.
Não é.
Ela representa a diferença entre um sistema de detecção precoce e um relatório semanal que apenas confirma aquilo que todos já sabem.
3. Monitoramento rigoroso
Monitorar um projeto não significa produzir mais relatórios.
Significa garantir que os dados cheguem à camada de decisão sem distorções.
É justamente nesse ponto que o indicador melancia costuma ser combatido ou perpetuado.
As organizações que conseguem enfrentar esse problema fazem algo diferente: tornam os dados do projeto objetivos e acessíveis, sem depender exclusivamente do julgamento do gerente para decidir o que deve ou não chegar aos níveis superiores.
Isso envolve:
dashboards acessíveis aos stakeholders relevantes;
critérios de escalada definidos antecipadamente;
indicadores objetivos;
separação entre fatos e interpretações;
acompanhamento de tendências, e não apenas do status atual.
O objetivo não é criar mais burocracia.
É reduzir a distância entre o problema e quem tem autoridade para resolvê-lo.
A distinção entre decisões reversíveis e irreversíveis também é operacionalmente útil. Muitas decisões de projetos são reversíveis e, por isso, podem ser tomadas no nível mais baixo possível, com a velocidade necessária.
O que paralisa projetos não é necessariamente a falta de dados.
É a falta de clareza sobre quem decide o quê e até quando.
Quando uma organização é genuinamente decision-driven, o indicador melancia deixa de ser sustentável.
Não há incentivo para esconder problemas quando a estrutura organizacional espera que eles sejam reportados cedo e tratados rapidamente.
Existe outra mudança importante de postura nas equipes de alta performance: tratar o fracasso como dado operacional, e não como vergonha.
Isso não significa ser indiferente ao resultado.
Significa entender que uma organização que transforma a falha em vergonha tende a escondê-la. E, quando esconde a falha, perde a informação necessária para melhorar.
Quem trata a falha como dado pode analisá-la.
Pode identificar padrões.
Pode descobrir onde o sistema está produzindo os mesmos problemas repetidamente.
Os 13 livros que escrevi sobre gestão de projetos e execução organizacional têm uma linha comum: organizações que aprendem sistematicamente com projetos fracassados tendem a superar aquelas que fingem que eles nunca aconteceram.
A revisão pós-projeto não deveria ser um ritual burocrático.
Ela é uma forma de coletar inteligência sobre a maneira como a organização trabalha.
No ITA, onde faço meu doutorado em engenharia aeronáutica, esse princípio aparece na própria estrutura da pesquisa: dados negativos têm valor. Uma hipótese que não se confirma também produz conhecimento sobre o modelo estudado.
Projetos que falham podem ensinar tanto sobre a arquitetura organizacional quanto os projetos que entregam.
Desde que alguém esteja disposto a olhar para eles.
Se você está gerenciando projetos hoje, proponho começar com duas perguntas.
Qual é o status real do seu projeto mais crítico?
Não o que está no relatório. Não o que aparece no dashboard. O que a equipe sabe, mas não está reportando?
E há uma segunda pergunta:
Qual decisão está na fila há mais de duas semanas sem resolução?
Mais importante: qual é o custo de cada semana adicional de adiamento?
Responder essas duas perguntas com honestidade pode localizar um problema com mais precisão do que qualquer metodologia.
Porque, no fim, a questão sobre por que projetos falham não se resume a processos, ferramentas ou metodologias.
Projetos falham quando a organização deixa de enxergar a realidade, demora para tomar decisões e permite que pequenos desvios se transformem em problemas grandes demais para serem corrigidos.
Projetos que entregam fazem o contrário.
Planejam com granularidade. Monitoram os desvios. Expõem os problemas. Tomam decisões.
Ver publicações 