O PMO foi desenhado para o problema errado. E, por isso, fracassou.

Todo mundo sabe que PMOs são reorganizados a cada três anos. Ninguém pergunta por quê. A resposta não é metodológica — é de design. E tem processo.

Todo mundo sabe que PMOs são reorganizados a cada três anos. Ninguém pergunta por quê.

A resposta mais comum é metodológica: o PMO usou o framework errado, não adotou ágil a tempo, ficou preso no PMBOK. Esta explicação é confortável porque tem solução técnica: trocar a metodologia. É também, na maioria dos casos, errada.

Brian Hobbs e Monique Aubry pesquisaram 500 organizações em 30 países entre 2007 e 2010 — a maior investigação empírica já realizada sobre PMOs. Documentaram que a reorganização a cada três anos é padrão universal, independente de setor, tamanho ou país. E identificaram os fatores que a causam. O fator dominante não é underperformance técnica. É tensão política. O PMO perdeu legitimidade com os stakeholders que deveria servir.

A causa da perda de legitimidade é mais profunda: o PMO foi desenhado antes do problema ser entendido. A solução precedeu a questão. O arquiteto foi contratado antes de o cliente saber o que o prédio precisava fazer.

Esta é a pergunta que nenhum dos dois artigos anteriores desta série respondeu — e que nenhum framework de PMO respondeu até agora: como se desenha um PMO a partir do problema organizacional real, e não do template do consultor?

O que se segue é o método — e, desta vez, o processo prático passo a passo.

---

TL;DR

• PMOs são reorganizados a cada 3 anos não porque a metodologia é errada, mas porque o design precedeu o diagnóstico. Hobbs & Aubry (2007–2010) documentaram isso empiricamente em 500 organizações. O fator dominante de reconfiguração é tensão política — perda de legitimidade com stakeholders.

• O problema central não é qual tipo de PMO escolher. É que a maioria das organizações escolhe o tipo antes de entender o problema que quer resolver. A solução precede a questão.

• O processo correto começa com contexto de maturidade — não como destino, mas como ponto de partida. O nível de maturidade organizacional determina qual processo de design é adequado, não qual PMO instalar.

• Facilitated modelling estrutura o problema antes de qualquer solução. Divergência → groan zone → convergência: o grupo de stakeholders define o problema que quer atacar. Só depois se desenha o PMO.

• Problem Structuring Methods (PSMs) tornam o processo rigoroso. Soft Systems Methodology, Strategic Choice Approach e SODA são os instrumentos que transformam opiniões em mapas estruturados de problema — e mapas em decisões de design.

• Value-Focused Thinking inverte a lógica de geração de alternativas. Em vez de avaliar tipos de PMO e escolher o melhor, parte dos valores dos stakeholders para gerar alternativas que nunca teriam sido consideradas de outra forma.

• O resultado é o Value Management Office: não um tipo novo de PMO, mas uma configuração construída a partir do problema desta organização específica, para capturar os benefícios que esta organização específica precisa.

• Este artigo cobre o diagnóstico e o início do design (Etapas 0–2). O design detalhado — estruturas, processos, funções e serviços do VMO — será tratado na próxima edição desta série, baseado no PMO Value Ring e no PMI PMO Handbook (2023).

Figura 1 · Departamento vs. Capability: duas lógicas incompatíveis

A distinção que precede qualquer discussão sobre tipo, metodologia ou tecnologia de PMO — e que explica por que PMOs são reorganizados em média a cada três anos. Elaboração própria. Baseado em: Hobbs & Aubry (2007, 2010); Teece, Pisano & Shuen (1997); Ward & Daniel (2006).

O padrão que a pesquisa documentou — e que a prática ignora

O dado de Hobbs e Aubry tem uma consequência que raramente é tirada até o fim. Se o fator dominante de reorganização de PMO é tensão política — não metodológica —, então trocar a metodologia não resolve o problema. A reorganização vai acontecer de novo. Em três anos.

A tensão política que Aubry, Müller, Hobbs e Blomquist documentaram em detalhe (2010, Project Management Journal, 41 fatores analisados) tem origem específica: o PMO foi mandatado para resolver um problema que não era o problema dos stakeholders que precisavam reconhecer seu valor. O CFO queria controle de CAPEX. O CTO queria acelerar o backlog tecnológico. O Chief Strategy Officer queria garantir que projetos prioritários não fossem deslocados por urgências. O líder de negócio queria autonomia de execução. Ninguém perguntou, formalmente, qual desses problemas o PMO devia atacar — e com que critério seria avaliado.

O PMO foi criado. Seis meses depois, o CFO achava que estava gerando burocracia. Dois anos depois, o CTO achava que era lento. No terceiro ano, alguém propôs “redesenhar” o PMO. A reorganização não foi fracasso de metodologia — foi fracasso de diagnóstico.

“The question is not which PMO type to implement, but how to design a PMO that fits the organizational context.”— Hobbs & Aubry, The Project Management Office in the Organizational Context, PMJ (2010)

Hobbs e Aubry chegaram a essa conclusão e pararam — ela não estava no escopo do estudo. O que a literatura de PMO documentou abundantemente é o fenômeno da instabilidade. O que não documentou é o processo de design que produziria estabilidade. Essa é a lacuna que o Context-Sensitive PMO Design preenche.

O problema com “PMO customizado”

Qualquer consultor de PMO experiente dirá que seu trabalho é “customizar o PMO para o contexto do cliente.” Esta afirmação é verdadeira e, ao mesmo tempo, não diz nada de operacionalmente útil.

A pergunta relevante não é “o PMO é customizado?” — é “o processo de customização começa com o problema organizacional ou com o template de PMO?” Na maioria dos casos, o consultor chega com três ou quatro modelos de PMO (PMO de suporte, PMO de controle, PMO diretivo, PMO estratégico) e avalia qual deles “se encaixa melhor” no cliente. O problema organizacional é o dado de entrada para escolher entre alternativas pré-definidas.

É a lógica inversa da que produz PMOs que funcionam.

Ralph Keeney, em Value-Focused Thinking (1992), formalizou a distinção com precisão: a maioria das decisões começa com alternativas e tenta avaliá-las pelos valores. O problema é que as alternativas consideradas determinam o espaço de soluções possíveis — e se as alternativas foram pré-definidas antes dos valores serem elicitados, as soluções mais adequadas nunca são geradas. Keeney propôs inverter o processo: partir dos valores dos stakeholders, construir hierarquia de objetivos, e então gerar alternativas criativas que sirvam esses objetivos. Alternativas que não teriam surgido de outro modo.

Aplicado ao PMO: antes de escolher entre PMO de suporte ou PMO estratégico, a organização precisa responder — o que queremos que o PMO resolva que hoje não está sendo resolvido? Esta pergunta, quando feita de forma rigorosa com todos os stakeholders relevantes, quase sempre revela que diferentes stakeholders têm respostas radicalmente diferentes. E é aí que o processo real começa.

Figura 2 · Value-Focused Thinking aplicado ao design de PMO

A inversão de Keeney (1992): partir dos valores dos stakeholders para gerar alternativas de PMO que nunca emergiriam de uma abordagem baseada em templates pré-definidos. Fonte: Keeney, R.L. (1992). Value-Focused Thinking: A Path to Creative Decision-making. Harvard University Press. Vieira et al. (2024). Elaboração própria (Trentim, 2026).

O processo político que ninguém faz — e que determina tudo

A pergunta “o que queremos que o PMO resolva?” parece simples. Na prática, é uma das conversas mais difíceis que uma liderança organizacional pode ter — porque raramente há resposta única, e as respostas diferentes revelam conflitos de prioridade que a organização prefere não tornar explícitos.

O CFO quer o PMO para ter visibilidade de alocação de recursos e controle de CAPEX. O CTO quer o PMO para reduzir o backlog tecnológico e acelerar entregas. O Chief Strategy Officer quer o PMO para garantir que os projetos prioritários não sejam deslocados por urgências operacionais. O líder de negócio quer o PMO para ter autonomia de execução sem ter que escalar cada decisão.

Nenhuma dessas visões está errada. Mas um único PMO não pode ser todas elas simultaneamente — não sem escolha explícita de onde concentrar capability.

L. Alberto Franco e Gilberto Montibeller, em trabalho seminal publicado no European Journal of Operational Research (2010), formalizaram a abordagem que trata exatamente desse problema: facilitated modelling. A premissa é que problemas organizacionais complexos não são entidades objetivas que existem independentemente de quem os descreve. São socialmente construídos — sua natureza, seu escopo e sua prioridade dependem de quem os percebe e de que posição.

A consequência prática é importante: se o problema é socialmente construído, a solução que não passa por um processo de construção compartilhada do problema vai ser rejeitada — não porque é tecnicamente errada, mas porque não é reconhecida como solução para o problema que cada stakeholder enxerga.

Facilitated modelling não é uma reunião de alinhamento. É um processo estruturado, com método, que passa por três fases não-lineares:

Divergência: stakeholders explicitam suas diferentes visões do problema. O facilitador não busca consenso prematuro — busca que cada perspectiva seja articulada com clareza. Esta fase revela os conflitos reais, os interesses que raramente aparecem em apresentações formais, e os problemas que a organização sabe que existem mas não tem espaço formal para nomear.

Groan zone: o momento em que perspectivas conflitantes precisam ser integradas — não resolvidas por votação ou por hierarquia, mas genuinamente trabalhadas. Sam Kaner (2007) documentou que a maioria dos grupos abandona o processo nessa fase, porque o desconforto é interpretado como sinal de fracasso. É o oposto: é sinal de que o processo está funcionando.

Convergência: o grupo chega a foco priorizado — não necessariamente consenso sobre tudo, mas acordo sobre qual aspecto do problema organizacional será atacado com o PMO. Este foco é o dado de entrada para o design da capability. Não antes.

Por que isso é diferente de qualquer workshop de alinhamento?
A diferença está no uso de modelos formais durante o processo. Facilitated modelling usa mapas cognitivos, modelos de causa e efeito, e estruturas de decisão para externalizar e tornar visíveis as perspectivas dos participantes — não apenas para registrá-las, mas para criar artefatos que permitam a análise das relações entre elas. O modelo não é o produto do processo: é o instrumento que torna possível a convergência.

Figura 3 · O processo de engajamento político: da divergência ao foco priorizado

As três fases do facilitated modelling aplicado ao design de PMO — e por que a groan zone é o momento de maior valor, não de fracasso. Fontes: Franco & Montibeller (2010). European Journal of Operational Research, 205, 489–500. Kaner, S. (2007). Facilitator’s Guide to Participatory Decision Making. Jossey-Bass.

Context-Sensitive PMO: o que é — com precisão

O Context-Sensitive PMO não é um tipo de PMO. É um PMO cujo design deriva de um processo estruturado de definição do contexto organizacional — e que por isso é diferente para cada organização, não porque foi “customizado” pelo consultor, mas porque foi construído a partir do problema que os stakeholders priorizaram.

Quatro características definem o modelo:

1. Dynamic Capability, não estrutura estática. David Teece, Gary Pisano e Amy Shuen definiram dynamic capabilities como a capacidade de uma organização de integrar, construir e reconfigurar competências internas e externas para responder a ambientes que mudam rapidamente (1997). Um PMO como dynamic capability não tem configuração fixa — tem propósito fixo (capturar valor para a organização via governance de execução) e configuração variável conforme o contexto muda. A revisão anual é planejada por design, não emergencial por crise.

2. Distribuída, não centralizada. PMO 3.0 concentra expertise metodológica num departamento central. PMO 4.0 distribui capability de governance pelos pontos da organização onde as decisões de execução acontecem. O centro coordena; não executa por todos. Esta distinção responde diretamente à crítica recorrente de que PMOs centrais criam burocracia sem criar valor — a burocracia é propriedade de centralização excessiva, não de PMO.

3. Orientada a benefícios, não a conformidade. A pergunta de avaliação do PMO 4.0 não é “os projetos seguiram o processo?” — é “os benefícios definidos na fase de design estão sendo capturados?” John Ward e Elizabeth Daniel (2006) desenvolveram o conceito de Benefits Dependency Network: uma cadeia explícita que conecta investimentos em mudança a benefícios mensuráveis. Esta cadeia é construída durante o processo de design do PMO e serve de régua de avaliação permanente. Se os benefícios não estão sendo capturados, o design do PMO precisa ser revisado — não o relatório de conformidade.

4. Context-Sensitive por design. “Sensível ao contexto” não é característica acidental — é o resultado direto do processo de design. O PMO foi construído a partir do problema que este contexto organizacional específico tem, com os objetivos que estes stakeholders específicos priorizaram, para capturar os benefícios que esta organização específica precisa. Quando o contexto muda — a estratégia muda, os stakeholders mudam, as condições competitivas mudam — o PMO tem mecanismo de revisão para se reconfigurar. Não precisa esperar a próxima crise.

Figura 4 · PMO 3.0 vs. PMO 4.0: comparação operacional

As diferenças não são de grau — são de natureza. Adotar tecnologias novas num PMO 3.0 produz PMO 3.0 com tecnologia nova, não PMO 4.0. Elaboração própria (Trentim, 2026). Baseado em: Hobbs & Aubry (2010); Teece et al. (1997); Ward & Daniel (2006); Franco & Montibeller (2010); Keeney (1992).

O que muda na prática: Value Management Office

O PMO 4.0, quando orientado à captura de benefícios e construído via Context-Sensitive PMO Design, é mais precisamente denominado Value Management Office — não porque seja um nome diferente para a mesma coisa, mas porque o foco muda de forma que altera o que o PMO produz, como é avaliado e quem o governa.

A definição operacional: VMO é uma configuração organizacional de governança e execução estratégica, construída a partir do diagnóstico contextual, cuja função primária é assegurar a realização de benefícios ao longo de toda a cadeia portfólio–programa–projeto. Não é estrutura — é sistema de captura de valor calibrado ao contexto específico da organização.

Um PMO de portfolio com Excel produz relatórios de status. Um Value Management Office produz inteligência de valor: onde os investimentos da organização estão gerando retorno, onde estão sendo desperdiçados, e quais decisões precisam ser tomadas agora para garantir que os benefícios planejados sejam capturados.

A diferença operacional começa no design. Na fase de Value-Focused Thinking, os stakeholders definem não apenas o que querem que o PMO faça, mas quais benefícios são esperados dos investimentos que o PMO vai governar. Esta definição cria a Benefits Dependency Network — a cadeia de dependências entre mudanças organizacionais, capacidades desenvolvidas e benefícios realizáveis (Ward & Daniel, 2006). O VMO governa essa cadeia, não apenas o portfólio de projetos.

A implicação é significativa para como o PMO se relaciona com o board e com a liderança executiva. A pergunta que o PMO 3.0 responde ao board é “como estão os projetos?” A pergunta que o Value Management Office responde é “os benefícios que justificaram os investimentos estão sendo capturados — e o que precisamos decidir para garantir que sim?” São perguntas diferentes. Exigem PMOs diferentes.

“Benefits management is not an add-on to project management. It is the reason project management exists.”— Ward, J. & Daniel, E. (2006). Benefits Management: Delivering Value from IS & IT Investments. Wiley.

O processo na prática: diagnóstico e início do design

O Value Management Office não nasce de uma decisão de organograma. Nasce de um processo. E o que diferencia organizações que constroem PMOs que duram daquelas que os reorganizam a cada três anos não é o tipo de PMO escolhido — é o rigor com que percorrem as etapas que precedem o design.

O Context-Sensitive PMO Design tem quatro etapas sequenciais. Este artigo cobre as três primeiras — contexto de maturidade, estruturação facilitada do problema e elicitação de valor. A quarta — design detalhado (estruturas, processos, funções e serviços do PMO/VMO) — será tratada na próxima edição desta série, baseada no PMO Value Ring (Hüttner et al.) e no PMI PMO Handbook (2023).

Figura 5 · O processo de design Context-Sensitive PMO: quatro etapas

Este artigo cobre as Etapas 0–2. O design detalhado (Etapa 3) será tratado na próxima edição, baseado no PMO Value Ring e no PMI PMO Handbook. Elaboração própria (Trentim, 2026). Baseado em: Franco & Montibeller (2010); Keeney (1992); PMI (2023) PMO Handbook; Hüttner et al. PMO Value Ring; AXELOS P3M3.

Etapa 0 — Maturidade como contexto, não como destino

A maioria das organizações usa modelos de maturidade — P3M3, OPM3, CMMI adaptado — para definir onde quer chegar. Esta é uma aplicação legítima, mas deixa de fora a função mais urgente: entender de onde se está partindo.

No Context-Sensitive PMO Design, o assessment de maturidade é a primeira atividade não porque vai determinar o tipo de PMO, mas porque vai calibrar o processo de design. Uma organização no Nível 1 do P3M3 — onde processos de gestão de projetos são ad hoc e individuais — não consegue absorver um processo de facilitated modelling com 8 sessões de stakeholders em 6 semanas. Vai colapsar na groan zone não por resistência política, mas por ausência de vocabulário comum para discutir governance de execução. Uma organização no Nível 3 — processos definidos, linguagem comum, histórico de projetos rastreável — chega à fase de facilitated modelling com condições muito mais favoráveis de convergência.

O assessment de maturidade determina três parâmetros do processo de design:

O que fazer na Etapa 0: Conduzir assessment de maturidade com 10–15 perguntas em cada uma das 7 perspectivas do P3M3 (gestão de benefícios, riscos, governança, financeiro, partes interessadas, recursos, gestão organizacional). Tempo: 2–3 semanas, incluindo entrevistas com líderes-chave. O produto não é um relatório de maturidade para o board — é a calibração interna do processo de design que vem a seguir.

Etapa 1 — Facilitated Problem Structuring: os três métodos que estruturam o diagnóstico (4–8 semanas)

A Etapa 1 é onde o diagnóstico acontece de verdade. E o risco mais comum nessa etapa é confundir processo de facilitação com reunião de levantamento de requisitos. São coisas fundamentalmente diferentes. Uma reunião de requisitos parte do pressuposto de que os stakeholders sabem o que querem — e que o facilitador vai capturar. O facilitated modelling parte do pressuposto oposto: os stakeholders têm perspectivas parciais, frequentemente conflitantes, que precisam ser explicitadas, confrontadas e integradas antes que qualquer requisito possa ser definido.

Três Problem Structuring Methods (PSMs) compõem o processo, cada um com função específica:

Soft Systems Methodology (SSM) — mapear worldviews. Peter Checkland desenvolveu a SSM nos anos 1970 como resposta a problemas mal-definidos em sistemas humanos (Checkland & Scholes, 1990). A ferramenta central para o design de PMO é o CATWOE — um acrônimo que força os participantes a articular com precisão a transformação que o PMO deve operar e de qual visão de mundo essa transformação faz sentido:

Strategic Choice Approach (SCA) — mapear áreas de decisão interconectadas. Friend e Hickling (2005) desenvolveram o SCA para organizações que precisam tomar decisões sob incerteza em ambientes de múltiplos stakeholders — exatamente o perfil de redesign de PMO. A ferramenta central é o mapeamento de áreas de decisão: quais decisões sobre o PMO estão interconectadas de tal forma que decidir uma impõe restrições nas outras?

SCA aplicado ao PMO — exemplo de áreas de decisão interconectadas:
“Centralizado ou distribuído?” ↔ “Quem governa o portfólio — PMO ou liderança de negócio?” ↔ “PMO responde ao CEO ou ao CFO?” ↔ “Qual é o mandato de veto do PMO sobre iniciativas?” ↔ “Como se mede o sucesso do PMO?”

Estas decisões não são independentes. Escolher “distribuído” limita as opções de reporting hierárquico. Escolher “mandato de veto” pressupõe escolhas sobre governança. O SCA torna essas interdependências visíveis e produz commitment packages — conjuntos de decisões mutuamente consistentes — em vez de decisões isoladas que se contradizem depois da implementação.

SODA — Strategic Options Development and Analysis — mapear modelos mentais. Ackermann e Eden (2001, 2011) desenvolveram o SODA como método para elicitar e integrar os modelos mentais dos stakeholders por meio de mapas cognitivos. Cada participante começa com uma sessão individual (30–60 min) em que descreve como enxerga o problema do PMO em termos de causas, consequências e opções. O facilitador registra em mapa cognitivo — nós e setas causais. Os mapas individuais são então integrados num mapa agregado (Group Explorer), que serve de base para a sessão de grupo.

Por que mapas cognitivos antes de sessão de grupo: quando stakeholders chegam a uma sessão de grupo sem mapa prévio, a discussão é dominada por quem fala mais ou tem mais hierarquia. Com mapas individuais elaborados antes, cada perspectiva já está externalizada em estrutura visual — e a sessão de grupo trabalha sobre os mapas, não sobre a retórica dos participantes. O poder se desloca do mais eloquente para o mais bem-estruturado.

Os três métodos não precisam ser usados sequencialmente em todas as situações. A intensidade do processo — quantas sessões, quais ferramentas, com quais participantes — é calibrada pelo assessment de maturidade da Etapa 0 e pelo tempo disponível da liderança. O critério de encerramento da Etapa 1 não é cronológico: é quando o grupo chegou a foco priorizado — declaração acordada de qual problema o PMO deve atacar.

Etapa 2 — Value Elicitation: partir dos valores para gerar o design (2–3 semanas)

Com o problema estruturado e o foco priorizado definido na Etapa 1, a Etapa 2 aplica Value-Focused Thinking para transformar o problema em critérios de design. A sequência tem quatro passos:

Passo 1 — Elicitar valores fundamentais e instrumentais. Pergunta central para cada stakeholder: “Se o PMO funcionasse perfeitamente para você, o que você diria que conseguiu que antes não conseguia?” As respostas revelam objetivos fundamentais (o que a organização valoriza por si mesmo) e instrumentais (o que valoriza como meio para outro fim). A distinção importa: objetivos instrumentais conflitantes frequentemente servem o mesmo objetivo fundamental — e quando isso fica visível, o conflito dissolve ou se torna gerenciável.

Passo 2 — Construir a hierarquia de objetivos. Os objetivos elicitados são organizados em árvore: objetivos fundamentais no topo, instrumentais abaixo, alternativas potenciais na base. Esta hierarquia é o artefato mais importante do processo — é a régua contra a qual todas as decisões de design serão avaliadas.

Passo 3 — Gerar alternativas criativas a partir dos objetivos. Esta é a inversão central de Keeney: em vez de escolher entre PMO de suporte e PMO de controle, a equipe gera alternativas de design específicas para os objetivos desta organização. Alternativas que a lista padrão de tipos de PMO nunca teria incluído.

Passo 4 — Avaliar alternativas pelos objetivos, não por preferência. Cada alternativa gerada é avaliada sistematicamente por cada objetivo da hierarquia. O resultado não é ranking de alternativas — é mapa de complementaridade: quais alternativas combinadas produzem o máximo de cobertura dos objetivos priorizados. Esta combinação é o blueprint preliminar do PMO/VMO.

O que a Etapa 2 entrega: árvore de valor com objetivos fundamentais e instrumentais aprovada pelos stakeholders · lista de alternativas de design geradas (não selecionadas de catálogo) · avaliação de alternativas por objetivos · blueprint preliminar do PMO/VMO como combinação de alternativas de maior cobertura · critérios de avaliação de performance futura (o que será medido para saber se o PMO está capturando os benefícios priorizados).

Aplicação Ilustrativa · Empresa de Manufatura Industrial Brasileira

O caso a seguir é uma composição ilustrativa baseada em padrões observados em múltiplos projetos de redesign de PMO. Nomes, setores e dados específicos são ficcionais.

Uma empresa de manufatura industrial — 4.200 funcionários, R$ 1,1 bilhão de receita, quatro plantas no Brasil — havia criado um PMO de controle há quatro anos. Quarenta projetos ativos, processos padronizados de gestão, relatórios mensais ao board. Do ponto de vista técnico, o PMO funcionava. Do ponto de vista político, estava agonizando: o CEO havia sinalizado que “o PMO precisa ser repensado”, sem conseguir articular exatamente por quê.

O assessment de maturidade (Etapa 0) revelou que a organização estava no Nível 2 do P3M3 em gestão de portfólio e no Nível 3 em gestão de projetos individuais. O gap era sintomático: a organização sabia gerir projetos, mas não sabia decidir quais projetos gerir.

Na Etapa 1, as sessões individuais de SODA com os seis membros do comitê executivo revelaram três modelos mentais radicalmente diferentes sobre o problema. O CFO enxergava o PMO como ferramenta de controle de CAPEX. O CDO (Chief Digital Officer) enxergava como acelerador de transformação digital que o PMO estava travando com burocracia. O COO enxergava como árbitro de conflito de recursos entre as quatro plantas — uma função que o PMO nunca havia sido desenhado para exercer. Ninguém havia explicitado essas perspectivas antes. O “PMO precisa ser repensado” do CEO era um sintoma de três problemas diferentes operando simultaneamente.

O CATWOE (SSM) revelou a worldview de conflito central: para o CFO, governance significava controle e visibilidade de gastos; para o CDO, governance significava velocidade e autonomia de decisão; para o COO, governance significava arbitragem de prioridade entre unidades de negócio competindo pelos mesmos recursos. A Transformation que todos concordaram, depois de duas sessões de groan zone, foi: “demandas de iniciativas desalinhadas entre si e com a estratégia” → “portfólio integrado com alocação de recursos decidida por critérios de valor, não por hierarquia de urgência”.

Na Etapa 2 (VFT), o objetivo fundamental emergiu com clareza: “capturar os benefícios do programa de transformação digital antes que a janela competitiva feche”. Os objetivos instrumentais incluíam priorização rigorosa de iniciativas, eliminação de projetos de baixo valor capturando recursos escassos, e velocidade de decisão sobre iniciativas travadas. As alternativas geradas — nunca teriam emergido de um catálogo de tipos de PMO — incluíam um Comitê de Valor quinzenal com poder de matar projetos, dois analistas de benefícios dedicados à Benefits Dependency Network, e governance nodes nas quatro plantas com autonomia de execução dentro de parâmetros estratégicos definidos centralmente.

O resultado foi um Value Management Office com estrutura radicalmente diferente do PMO de controle anterior — não porque alguém escolheu um tipo diferente de PMO, mas porque o processo de design partiu do problema real e gerou alternativas específicas para aquele contexto. Dezoito meses depois da implementação, a taxa de cancelamento de projetos de baixo valor havia saltado de 5% para 28% — liberando capacidade para as iniciativas estratégicas prioritárias. O board passou a receber relatório mensal de captura de benefícios em vez de relatório de status de projetos. A próxima reorganização, por design, está agendada para daqui a doze meses — não como crise, mas como revisão planejada.

O que este artigo cobre — e o que vem a seguir

As Etapas 0–2 descritas aqui — assessment de maturidade, facilitated problem structuring e value elicitation — produzem um blueprint preliminar do VMO e os critérios contra os quais seu design será avaliado. Elas respondem a: qual é o problema? quais são os valores? quais alternativas de design existem?

O que este artigo deliberadamente não cobre é a Etapa 3: o design detalhado das estruturas, processos, funções e serviços do PMO/VMO. Esse nível de detalhe exige um framework próprio — e há alguns que foram desenvolvidos especificamente para isso, mapeando os serviços do PMO em função do valor que entregam a cada stakeholder e consolidando as melhores práticas de design operacional de PMOs em múltiplos contextos organizacionais.

A próxima edição desta série (W29 desta newsletter) cobrirá exatamente esse nível — com as ferramentas de design detalhado que transformam o blueprint da Etapa 2 em estrutura operacional do VMO. Se as Etapas 0–2 são o diagnóstico e o framing, a Etapa 3 é o blueprint de engenharia.

A integração com as camadas anteriores: citizen development e IA

No artigo anterior desta série, mostramos que organizações que construíram governança de citizen development entre 2018 e 2024 chegaram ao momento da IA com três condições que o PMI AI Standard pressupõe mas não cria: coordenação horizontal, cultura de experimentação, e IT como habilitador.

O PMO 4.0 é a camada de governance que integra esses elementos. A plataforma de citizen development e os agentes de IA são a infraestrutura operacional do PMO 4.0 — não o contrário. O erro mais comum que vejo em organizações que tentam “modernizar” o PMO é começar pela tecnologia. Compram a ferramenta de PPM, implementam dashboards de IA, automatizam relatórios — e depois descobrem que o PMO ainda não está entregando valor estratégico. Porque a tecnologia operacionaliza o PMO que foi desenhado. Se o design é equivocado, a tecnologia operacionaliza o equívoco com mais eficiência.

A sequência correta: problema → design → capability → tecnologia. Não o inverso.

Figura 6 · A Hélice da Execução: como o PMO 4.0 integra estratégia, portfolio, governance e stakeholders

O modelo que substitui a cadeia linear estratégia→portfolio→projetos→resultados por um movimento contínuo, iterativo e adaptativo entre quatro dimensões. Fonte: Trentim, M.H. (2025-2026). Hélice da Execução — framework proprietário em desenvolvimento. Baseado em: Teece et al. (1997); Ward & Daniel (2006); Beer, S. (1985).

O que fazer nesta segunda-feira

Este artigo apresentou o argumento e o processo. A mudança de lógica — da lógica do departamento para a lógica da capability — precede qualquer ação técnica. Mas há três perguntas diagnósticas que qualquer líder responsável por um PMO pode responder agora, antes de qualquer consultoria ou redesign formal:

1. O PMO atual foi desenhado a partir de um problema priorizado coletivamente pelos stakeholders — ou a partir de um template? Se a resposta for template, a pergunta seguinte é: os stakeholders que precisam reconhecer valor no PMO participaram ativamente da definição do que ele deveria resolver? Se não, a tensão política que Aubry et al. documentaram como causa dominante de reorganização está presente — mesmo que ainda não se manifeste.

2. O PMO é avaliado por captura de benefícios ou por conformidade metodológica? A métrica de avaliação revela o design. PMOs avaliados por “aderência ao processo” são PMOs de controle. PMOs avaliados por “benefícios capturados em relação ao que foi planejado na aprovação do portfólio” são VMOs. Se não há Benefits Dependency Network — cadeia explícita conectando investimentos a benefícios mensuráveis —, o PMO não tem como ser avaliado pela segunda métrica, independente de qualquer intenção de direção.

3. Quando foi a última revisão planejada do modelo de PMO — não por crise, mas por design? Um PMO como dynamic capability tem revisão anual por design. Se a última revisão aconteceu porque alguém propôs “repensar o PMO” num momento de insatisfação, o modelo operacional é estático — e vai gerar a próxima insatisfação no mesmo intervalo de três anos.

Para ir além do diagnóstico, as áreas de aprofundamento que habilitam a ação:

Facilitated Modelling e Problem Structuring Methods. O livro de referência é Rosenhead & Mingers (2001), Rational Analysis for a Problematic World Revisited. O paper de Franco & Montibeller (2010) é o ponto de entrada mais acessível para quem vem do campo de gestão. Para SSM especificamente: Checkland & Scholes (1990). Para SODA com foco em stakeholder estratégico: Ackermann & Eden (2011).

Value-Focused Thinking. O livro de Ralph Keeney (1992) é leitura direta para qualquer líder responsável por decisões de design organizacional. O artigo de Keeney na HBR de 1994 (”Creativity in Decision Making with Value-Focused Thinking”) é suficiente para começar.

Modelos de maturidade. P3M3 (AXELOS, 2013) e OPM3 (PMI, 2013) são os dois frameworks de maior adoção global. Para quem já conhece maturidade e quer o passo seguinte: a integração entre maturidade e benefits management em Serra & Kunc (2015), International Journal of Project Management.

Nota sobre a literatura de base: Os campos citados — facilitated modelling, value-focused thinking, PSMs e benefits management — têm literatura acadêmica extensa e rigorosa. Não são frameworks de consultoria. São métodos com validação empírica publicada em periódicos como European Journal of Operational Research, Journal of the Operational Research Society, Management Science e International Journal of Project Management.

---

Se você está redesenhando um PMO ou avaliando se o modelo atual ainda serve ao contexto da sua organização, posso ajudar no diagnóstico inicial — uma conversa de 30 minutos para entender o ponto de partida e indicar o caminho mais adequado. O contato é mario@trentim.com.

Os conceitos desenvolvidos nesta série de artigos fazem parte de pesquisa em andamento no ITA (Instituto Tecnológico de Aeronáutica) e das diretrizes que tenho contribuído para o debate global sobre o futuro dos PMOs/VMOs.

---

Próxima edição (W29): O design detalhado do VMO — estruturas, processos, funções e serviços. Baseado no PMO Value Ring e no Project Management Offices: A Practice Guide (PMI, 2025). Como transformar o blueprint das Etapas 0–2 em estrutura operacional.

Mario H. Trentim
Membro do Board of Directors do PMI (2025–2027) · Microsoft Regional Director e MVP 2016–2026 · IoD UK Certificate (2025) · 13 livros publicados · Doutorando ITA — pesquisa em Context-Sensitive PMO Design e Problem Structuring Methods aplicados à governance de execução estratégica

Se esta edição trouxe algo que vai mudar como você pensa sobre governance de execução, encaminhe para um colega que precisa ouvir o argumento. O debate que precisamos ter sobre PMO no Brasil ainda não aconteceu com a seriedade que o tema merece.

Referências

1. Hobbs, B. & Aubry, M. (2007). A multi-phase research program investigating project management offices (PMOs): The results of phase 1. Project Management Journal, 38(1), 74–86.

2. Hobbs, B. & Aubry, M. (2010). The Project Management Office (PMO): A Quest for Understanding. Project Management Institute.

3. Aubry, M., Hobbs, B. & Thuillier, D. (2007). A new framework for understanding organisational project management through the PMO. International Journal of Project Management, 25(4), 328–336.

4. Aubry, M., Hobbs, B. & Thuillier, D. (2008). Organisational project management: An historical approach to the study of PMOs. International Journal of Project Management, 26(1), 38–43.

5. Aubry, M., Müller, R., Hobbs, B. & Blomquist, T. (2010). Project management offices in transition. International Journal of Project Management, 28(8), 766–778.

6. Teece, D.J., Pisano, G. & Shuen, A. (1997). Dynamic capabilities and strategic management. Strategic Management Journal, 18(7), 509–533.

7. Eisenhardt, K.M. & Martin, J.A. (2000). Dynamic capabilities: What are they? Strategic Management Journal, 21(10–11), 1105–1121.

8. Keeney, R.L. (1992). Value-Focused Thinking: A Path to Creative Decision-making. Harvard University Press.

9. Keeney, R.L. (1994). Creativity in decision making with value-focused thinking. Harvard Business Review, 72(4), 33–41.

10. Vieira, G.B.B. et al. (2024). Using VFT in an integrated process to support decisions. Pesquisa Operacional, 44.

11. Franco, L.A. & Montibeller, G. (2010). Facilitated modelling in operational research. European Journal of Operational Research, 205(3), 489–500.

12. Rosenhead, J. & Mingers, J. (Eds.) (2001). Rational Analysis for a Problematic World Revisited: Problem Structuring Methods for Complexity, Uncertainty, and Conflict. Wiley.

13. Checkland, P. & Scholes, J. (1990). Soft Systems Methodology in Action. Wiley.

14. Friend, J. & Hickling, A. (2005). Planning Under Pressure: The Strategic Choice Approach, 3rd ed. Elsevier.

15. Ackermann, F. & Eden, C. (2001). SODA — Strategic Options Development and Analysis. In: Rosenhead & Mingers (Eds.), Rational Analysis for a Problematic World Revisited. Wiley, pp. 43–60.

16. Ackermann, F. & Eden, C. (2011). Strategic management of stakeholders: Theory and practice. Long Range Planning, 44(3), 179–196.

17. Kaner, S. (2007). Facilitator’s Guide to Participatory Decision Making. Jossey-Bass.

18. Ward, J. & Daniel, E. (2006). Benefits Management: Delivering Value from IS & IT Investments. Wiley.

19. Bradley, G. (2010). Benefit Realisation Management: A Practical Guide to Achieving Benefits Through Change, 2nd ed. Gower.

20. Serra, C.E.M. & Kunc, M. (2015). Benefits realisation management and its influence on project success and on the execution of business strategies. International Journal of Project Management, 33(1), 53–66.

21. Hurt, M. & Thomas, J.L. (2009). Building value through sustainable project management offices. Project Management Journal, 40(1), 55–72.

22. Beer, S. (1985). Diagnosing the System for Organizations. Wiley.

23. Rittel, H.W.J. & Webber, M.M. (1973). Dilemmas in a general theory of planning. Policy Sciences, 4(2), 155–169.

24. Monteiro, A., Varajão, J. & Santos, V. (2024). A systematic review of PMO typologies. Project Management Journal, 55(2), 134–151.

25. AXELOS (2013). Portfolio, Programme and Project Management Maturity Model (P3M3), Version 2.1. AXELOS.

26. Project Management Institute (2013). Organizational Project Management Maturity Model (OPM3), 3rd ed. PMI.

27. Project Management Institute (2023). PMO Handbook. PMI.

28. Mingers, J. & Brocklesby, J. (1997). Multimethodology: Towards a framework for mixing methodologies. Omega, 25(5), 489–509.