Metodologia sem contexto é decoração.

Todo gestor de projetos tem um momento em que percebe que sabe aplicar o framework, mas não sabe resolver o problema.

Para mim esse momento veio numa reunião onde alguém apresentava um case de gestão de uma empresa americana como modelo para adotarmos. O case era sólido: times multidisciplinares, cerimônias bem definidas, métricas de entrega claras. A empresa tinha 2.000 pessoas e orçamento para manter um PMO de quinze só para garantir que o processo rodasse. Nós tínhamos três projetos em paralelo e um gestor de projetos.

Ninguém perguntou se fazia sentido.

Aqui está o problema real com boas práticas de gestão de projetos: elas viram resposta antes de virar pergunta. A pessoa aprende o PMBOK, o Scrum, o SAFe, e passa a ver cada novo projeto como um exercício de aplicar o que aprendeu. O contexto da empresa entra como dado de entrada, não como critério de decisão.

O resultado é o que chamo de gestão de decoração: processos bem documentados que ninguém segue porque foram criados para parecer maduros, não para funcionar naquele ambiente. Retrospectiva toda semana num time que nunca teve autonomia para mudar nada. Risk register detalhado num projeto cujo maior risco é a decisão informal que o CEO vai tomar na próxima quinta.

O que separa um gestor que gera resultado de um que gera relatório não é domínio técnico. É a capacidade de ler o ambiente antes de decidir qual ferramenta usar.

Isso exige uma inversão de postura que é mais difícil do que parece. A maioria das certificações e cursos parte de uma premissa implícita: existe uma forma correta de fazer as coisas, e seu trabalho é aprender e aplicar. Isso é confortável porque transfere a responsabilidade da decisão para o método. Se deu errado, foi o time que não seguiu o processo.

O problema é que o mundo real não funciona assim. Cada empresa tem uma história de como as coisas são decididas de verdade, não como o organograma diz. Quem tem poder informal. Onde os acordos realmente são feitos. Qual é o ritmo natural de entrega daquele time, considerando tudo que compete por atenção ao mesmo tempo. Um bom case de outra empresa pode ser uma referência útil para entender o que é possível. Raramente é um mapa de como chegar lá.

Quando comecei a trabalhar com gestão de projetos de forma mais sistemática, passei tempo tentando encontrar o método certo: um conjunto de práticas que funcionasse de forma consistente, independente do contexto. Levei um tempo para perceber que estava procurando algo que não existe.

O que existe são princípios que funcionam em contextos amplos — comunicação clara, visibilidade de progresso, gestão de dependências — e práticas que só funcionam em contextos específicos. Confundir um com o outro é onde a maioria dos problemas começa.

Há uma distância considerável entre "equipes autônomas entregam mais rápido" (princípio observado em contextos variados) e "vamos implementar squads autogerenciáveis" (prática que pressupõe um conjunto muito específico de condições organizacionais). Empresas que pulam essa distância invariavelmente adotam o vocabulário sem as condições.

O que diferencia a gestão de projetos que funciona não é o framework adotado. É o nível de honestidade com que o gestor lê o contexto onde está operando.

Isso inclui coisas que nenhum framework captura formalmente: a qualidade da relação entre as áreas que precisam colaborar, a maturidade real do time para lidar com autonomia, o quanto os decisores sabem de fato o que querem. Ignorar esses fatores porque não cabem num campo do projeto template não resolve o problema. Empurra ele para frente com juros.

A adaptação não é fraqueza metodológica. É o trabalho real.