Ambidestria organizacional: quando o PMO se torna obstáculo à inovação

O PMO não mata a inovação por má vontade. Mata porque foi projetado para reduzir variância — e inovação exige variância.

Mario H. Trentim · Novembro 2026 · PMO e Inovação

Uma das reclamações mais recorrentes que ouço em advisory de médias e grandes empresas soa assim: “o PMO aprova o plano do projeto de inovação e mata a inovação no processo.” A frase geralmente vem de um diretor de inovação, em tom de frustração — não de acusação. Ele sabe que o PMO não está agindo de má-fé. O problema é estrutural.

O PMO tradicional foi projetado para reduzir variância. Isso é o que um PMO faz bem: padroniza processos, exige planos detalhados antes da aprovação, controla o desvio de escopo, monitora cronograma e orçamento com frequência, e escala qualquer desvio significativo para decisão executiva. Esse conjunto de comportamentos é exatamente o que você quer em um projeto de infraestrutura, de implantação de ERP, de expansão industrial. São projetos em que a variância é risco — e reduzir risco é o objetivo.

O problema começa quando o mesmo PMO, com as mesmas ferramentas, é colocado para supervisionar projetos de inovação. Porque em inovação, variância não é risco. É informação.

O conceito que explica a tensão

James March, em artigo de 1991 no Organization Science, introduziu a distinção entre exploitation e exploration. Exploitation é refinamento e extensão do que já existe: processos melhores, produtos incrementais, eficiência crescente. Exploration é busca por alternativas que ainda não existem: experimentos, protótipos, descoberta. Ambos são necessários para que uma organização sobreviva no longo prazo. Mas exigem lógicas de gestão radicalmente diferentes.

Tushman e O’Reilly, em 1996, desenvolveram o conceito de ambidestria organizacional: a capacidade de uma organização gerenciar exploitation e exploration simultaneamente, com estruturas e culturas separadas quando necessário. A pesquisa que se seguiu nas décadas seguintes confirmou que empresas ambidestras superam as que priorizam apenas um dos dois modos — mas também mostrou que a separação precisa ser real, não apenas nominal.

O PMO que supervisiona projetos de inovação com os mesmos critérios dos projetos de operação está fazendo o oposto: trata exploitation e exploration como se fossem o mesmo tipo de trabalho. O resultado é previsível. Os projetos de inovação que sobrevivem ao crivo do PMO são aqueles que já foram tão bem-definidos que não são mais realmente exploratórios. Os que tinham maior potencial de descoberta foram cancelados porque não tinham plano suficientemente detalhado.

O que diferencia um projeto de exploração de um de operação

Em um projeto de operação, o objetivo é conhecido. O escopo pode ser detalhado antes de começar. O cronograma pode ser estimado com razoável precisão. Os riscos são mapeáveis com base em projetos similares. O sucesso tem critérios claros desde o início.

Em um projeto de exploração, o objetivo é uma hipótese, não uma certeza. O escopo correto só pode ser definido após alguns experimentos. O cronograma é uma estimativa com incerteza alta, e isso é esperado. Os riscos mais relevantes são os que ainda não foram identificados. O sucesso às vezes é aprender que a hipótese estava errada — o que é um resultado válido, desde que o aprendizado seja rápido e barato.

Pedir a um projeto de exploração um plano com o nível de detalhe que um projeto de operação requer não é rigor. É exigir que a exploração produza, antes de começar, as respostas que só a exploração pode gerar. É como pedir a um cartógrafo que entregue o mapa antes de fazer a viagem.

O que o PMO ambidestro faz diferente

Em advisory, quando trabalho com organizações que querem desenvolver capacidade de inovação sem abrir mão do controle de portfólio, a solução não é eliminar o PMO do processo de inovação. É construir dois modos de operação dentro do mesmo escritório — ou, quando a escala justifica, estruturas separadas com governança própria.

Para projetos de exploração, o PMO precisa trocar o plano detalhado por um conjunto de hipóteses a serem testadas, com critérios claros de o que aprenderemos e em quanto tempo. Trocar o controle de escopo por controles de aprendizado: o que descobrimos que não sabíamos? A hipótese inicial se sustentou? Trocar a revisão quinzenal de cronograma por decisões de go/no-go baseadas em evidências de aprendizado, não em adesão ao plano original.

Isso não significa ausência de controle. Significa controle adaptado ao tipo de trabalho. Um projeto de exploração bem governado tem critérios de sucesso definidos antes de começar, iterações curtas com decisões de continuidade explícitas, e limites claros de investimento por fase. O que ele não tem é a expectativa de que o plano original vai sobreviver ao contato com a realidade — porque nenhum plano de exploração sobrevive.

A diferença entre um PMO que habilita inovação e um que a sufoca é a capacidade de reconhecer qual tipo de trabalho está supervisionando — e calibrar seus instrumentos de acordo. Quem usa o mesmo compasso para medir exploração e operação vai medir as duas errado.

A pergunta que o gestor precisa responder é simples. O método para respondê-la raramente é.