Estratégia PQP é uma forma pragmática de usar OKRs em organizações orientadas a projetos.
OKR virou uma prática amplamente conhecida. Livros, cursos e cases não faltam.
Ainda assim, quando saímos do discurso e entramos no dia a dia de organizações grandes, uma pergunta insiste em aparecer: como usar OKR em um contexto onde tudo já gira em torno de projetos?
Este texto não é sobre substituir projetos por OKRs, nem sobre implantar mais um framework. É sobre lidar com a realidade como ela é — e encontrar uma forma mais honesta e eficaz de conectar estratégia, execução e times em organizações orientadas a projetos.
Por que escrevi este artigo
Eu escrevi um livro sobre OKRs.
Mas essa história começou bem antes do livro.
Meu primeiro contato com OKR foi em 2008, no Google, quando eu ainda morava no Vale do Silício. A partir de 2013, comecei a usar OKR com mais frequência. Em 2019, já morando na Espanha, passei a facilitar workshops estratégicos com liderança sênior, quase sempre usando OKR como ferramenta de alinhamento estratégico — normalmente a partir de desdobramentos dos OKRs definidos no nível mais alto da organização.
Até aí, nada muito diferente do que muita gente já viveu.
A mudança mais significativa aconteceu a partir de 2022.
Foi quando eu decidi colocar menos energia em OKRs estratégicos e muito mais foco nos OKRs táticos, especialmente nos OKRs escritos e executados pelas equipes. Aquilo que eu passei a chamar de Team OKR, ou OKR de equipe. Onde o protagonismo não está na liderança definindo tudo, mas no time assumindo responsabilidade real por um objetivo e pelos resultados que importam.
Esse movimento acabou me levando naturalmente a escrever o livro Team OKR, publicado em 2025. Mas, mais importante do que o livro em si, foi o que aconteceu durante esse processo: eu passei por muitas organizações diferentes, de países diferentes, tamanhos diferentes — e comecei a ver o mesmo padrão se repetir.
Empresas grandes. Estruturadas. Bem-intencionadas.
Querendo usar OKR “do jeito certo”.
E, ao mesmo tempo, profundamente orientadas a projetos.
Projetos já aprovados.
Projetos com budget definido.
Projetos com sponsors nomeados.
Projetos que atravessam vários trimestres.
E aí vem a tentativa de encaixar OKR nesse cenário.
É exatamente dessa tensão que nasce o chamado para este artigo.
A tensão real: OKR em empresas orientadas a projeto
Em teoria, tudo parece simples.
A empresa define sua estratégia.
Depois define OKRs estratégicos.
Depois desdobra — ou “cascateia” — os OKRs táticos.
E, por fim, os times executam.
O problema é que, na prática, os times não são chamados a executar objetivos.
Eles são chamados a executar projetos.
É aí que o colapso acontece.
Executar um projeto não é a mesma coisa que alcançar um objetivo.
Projetos falam de escopo, entregas e planejamento.
Objetivos falam de impacto, aprendizado e resultado.
Em muitas organizações por onde eu passo, a lógica dominante não é orientada a objetivos.
Ela é claramente orientada a projetos.
O planejamento acontece por projetos — às vezes chamados de iniciativas ou programas, dependendo da organização, mas neste artigo vou usar “projetos”, que é o termo mais comum.
O orçamento acontece por projetos.
A governança acontece por projetos.
Os comitês aprovam projetos.
E os sponsors são donos de projetos.
Quando o ano começa — ou quando o planejamento estratégico termina — os projetos já estão decididos.
É nesse momento que o OKR tático, geralmente no nível de equipe, costuma entrar na conversa.
E entra, muitas vezes, de um jeito meio torto.
O projeto já existe, mas agora alguém pergunta:
“Qual é o OKR desse projeto?”
Ou pior:
“Como a gente encaixa esse projeto dentro dos OKRs?”
A partir daí, os sintomas clássicos começam a aparecer:
- Key Results viram milestones renomeados
- Objetivos descrevem fases ou entregas, não resultados
- Times “herdam” OKRs que não escreveram
- Autonomia vira discurso, não prática
E, olhando com calma, ninguém está realmente errado.
O problema não é falta de vontade.
Nem falta de conhecimento.
É um choque de modelos.
OKR parte da lógica de foco, aprendizado e resultado.
Projetos partem da lógica de escopo, planejamento e controle.
Quando você tenta martelar um framework de OKR em uma organização que já está toda estruturada em projetos, o atrito é inevitável.
E é nesse ponto que quem acredita em OKR — inclusive eu — acaba pensando, mesmo que não fale em voz alta:
“PQP… como é que a gente faz isso funcionar aqui?”
É exatamente aí que a conversa começa a ficar interessante.
Estratégia PQP (calma, não é o que você está pensando)
Antes de mais nada: sim, o nome é forte.
E não, não foi por acaso.
PQP aqui não é exatamente o que você pensou primeiro — embora a coincidência não seja totalmente inocente. A sigla nasceu de um contexto bem concreto: Project-Quarter-People.
Ela surgiu a partir de um trabalho que eu fiz para uma organização global, com forte presença no Brasil e pessoas espalhadas por vários países. Era um contexto em que tudo precisava ser escrito e estruturado em inglês, mesmo quando boa parte das conversas acontecia em português.
Nesse trabalho, eu comecei a usar o conceito de Project Quarter para falar de foco e execução trimestre a trimestre. Em inglês, naturalmente, isso virou PQ.
Em algum momento, ao reforçar a importância de deixar claro quem eram as pessoas responsáveis por fazer aquele quarter acontecer, eu adicionei o outro P: Project Quarter People.
A sigla virou PQP.
No início, confesso que eu nem percebi. Só quando voltei a falar disso em português é que caiu a ficha.
Esse trabalho tinha um objetivo muito claro: melhorar o alinhamento estratégico e a execução em um ambiente fortemente orientado a projetos. A ideia não era negar os projetos, mas estruturar estratégia e execução a partir de projetos pensados trimestre a trimestre, com clareza de responsabilidade e foco em resultado.
Quando eu trouxe essa sigla para o contexto brasileiro, a ironia ficou impossível de ignorar.
PQP também expressava muito bem o sentimento que aparece quando alguém tenta, honestamente, fazer OKR funcionar dentro de uma organização grande, cheia de projetos já definidos.
E aqui eu não estou falando da liderança como vilã.
Estou falando de quem acredita em OKR — e me incluo nesse grupo.
É aquele momento em que você entende o valor do framework, entende o discurso de foco e resultado, mas olha para a realidade da empresa e pensa, mesmo que não fale em voz alta:
“PQP… como é que a gente faz isso funcionar aqui?”
A decisão de levar esse nome foi influenciada por duas referências importantes para mim.
A primeira é o Rodrigo de Toledo, que há muitos anos compartilhou comigo sobre o trabalho de FDP do Product Owner — Fatiar, Descartar e Priorizar. Um jeito simples, direto e provocativo de falar sobre como um bom PO deve lidar com requisitos.
A segunda é o David Pereira, que fala abertamente sobre bullshit management. Aquela habilidade rara de olhar para uma prática, um processo ou um discurso e dizer: para com isso, isso não está ajudando ninguém.
Estratégia PQP nasce exatamente desse lugar.
Não como uma negação dos projetos.
Mas como uma tentativa honesta de lidar com a realidade — sem bullshit, sem romantizar autonomia, sem fingir que projetos não existem.
Antes de qualquer modelo ou prática, havia uma decisão mais básica a ser tomada: aceitar a realidade como ela é.
Aceitando a realidade: projetos existem (e tudo bem)
Antes de qualquer tentativa de melhorar alinhamento ou execução, tem uma coisa que precisa ser dita de forma explícita: projetos existem.
E em organizações grandes, eles não existem por acaso.
Projetos são como essas organizações tomam decisões de investimento.
É assim que budget é aprovado.
É assim que prioridades são negociadas.
É assim que a governança funciona.
Ignorar isso não é agilidade.
É ingenuidade.
Em muitos contextos em que eu trabalho, quando a conversa sobre OKR começa, os projetos já estão definidos. O escopo macro já foi aprovado. Existe um sponsor nomeado. Existe uma expectativa de duração — muitas vezes atravessando vários trimestres.
Tentar “apagar” isso ou fingir que não existe costuma gerar mais atrito do que valor.
Por isso, a primeira decisão da Estratégia PQP é uma decisão de aceitação.
Aceitar que:
- projetos vão continuar existindo
- projetos podem durar mais de um quarter
- projetos têm restrições reais de budget, escopo e governança
A questão não é se projetos devem existir ou não.
A questão é como lidar melhor com eles.
O problema começa quando um projeto longo é tratado como uma coisa única e contínua, sem pausas reais para foco, aprendizado e decisão. Tudo vira execução ininterrupta, trimestre após trimestre, até o projeto “terminar”.
É exatamente aí que foco se perde, a responsabilidade se dilui e o resultado real fica sempre para o final.
Aceitar a existência dos projetos não significa aceitar esse modelo de execução contínua e difusa.
Significa criar uma forma mais inteligente de conviver com essa realidade.
É a partir daqui que entra o conceito de Project Quarter.
Project Quarter: o truque que muda o jogo
Uma vez que você aceita que projetos existem e vão continuar existindo, a pergunta muda.
Ela deixa de ser:
“Como eu elimino projetos para implantar OKR?”
E passa a ser:
“Como eu executo projetos de forma mais focada, com mais aprendizado e melhores resultados?”
O conceito de Project Quarter nasce exatamente dessa mudança de pergunta.
A ideia é simples: qualquer projeto que dure mais de um trimestre não deve ser tratado como um bloco único de execução contínua, mas como uma sequência de quarters, cada um com um objetivo claro a ser perseguido.
Project Quarter não elimina o projeto.
Ele quebra o projeto no tempo, em trimestres.
O projeto continua tendo:
- um sponsor
- um budget
- um escopo macro
- uma expectativa de duração (por exemplo, três ou quatro trimestres)
O que muda é a forma como a execução é encarada.
Em vez de um plano anual detalhado tentando prever tudo, você passa a trabalhar com compromissos trimestrais explícitos. Compromissos com a busca de resultados, coerentes com a expectativa do todo, mas claros e alcançáveis dentro de um único quarter.
Cada quarter vira uma unidade clara de:
- foco
- aprendizado
- decisão
No início do quarter, fica explícito:
- em qual parte do projeto vamos focar agora
- qual resultado esperamos alcançar neste trimestre
- quem é responsável por fazer isso acontecer
No fim do quarter, também fica explícito:
- que resultados foram alcançados
- o que de fato aprendemos
- se faz sentido continuar, ajustar ou parar
Project Quarter cria ciclos naturais em projetos longos.
Ciclos que não existem para burocracia, mas para decisão.
Essa mudança aparentemente simples resolve vários problemas ao mesmo tempo:
- reduz a ilusão de controle de planos anuais
- força conversas sobre foco e prioridade
- cria momentos legítimos de revisão de direção e resultados parciais
Projetos continuam existindo.
Mas deixam de ser linhas contínuas e passam a ser uma sequência de ciclos trimestrais.
Visualmente, a diferença é esta:

OKRs focados em um Project Quarter, criando foco e clareza sem quebrar a continuidade do projeto.

OKRs usados como fases do projeto, virando milestones e perdendo foco em resultado.
OKR não acompanha o projeto inteiro. Ele cria foco dentro de um ciclo.
Um exemplo para tornar isso mais concreto
Imagine uma organização global, com operações em todos os continentes e escritórios em mais de trinta cidades. Um dos projetos estratégicos aprovados para o ano é a migração da ferramenta de colaboração usada internamente — um projeto grande, com budget definido, sponsor nomeado e impacto em milhares de pessoas.
Além da simplificação tecnológica, existe uma expectativa estratégica clara de redução de custo associada a esse projeto. No modelo tradicional, esse tipo de benefício costuma aparecer apenas no final, depois da última fase concluída.
Na gestão de projetos mais tradicional, essa iniciativa normalmente seria organizada em fases:
Fase 1: piloto em algumas regiões
Fase 2: expansão gradual
Fase 3: rollout global
Fase 4: estabilização e otimização
Nada disso é errado.
A mudança acontece quando o projeto deixa de ser pensado como uma sequência fixa de fases e passa a ser estruturado como uma sequência de Project Quarters, cada um com um objetivo claro — inclusive em relação a resultado de negócio.
Nesse exemplo, o primeiro Project Quarter substitui o que, em um plano tradicional, seria chamado de Fase 1. A diferença é que o quarter não existe apenas para testar a solução, mas para começar a capturar valor desde o início.
Nesse primeiro quarter, o trabalho acontece com os times do Brasil e da Argentina. O foco não é desligar a ferramenta anterior imediatamente, mas reduzir sua dependência de forma mensurável, enquanto a nova solução é validada no dia a dia.
Com o quarter definido, o sponsor do projeto identifica quem é o grupo de pessoas responsável por fazer esse ciclo acontecer. Só então esse grupo assume um Team OKR — não para o projeto inteiro, mas para aquele quarter específico.
Objetivo
Criar confiança na nova ferramenta de colaboração no dia a dia dos times do Brasil e da Argentina, enquanto geramos aprendizado, sinais iniciais de eficiência de custo e evidências suficientes para decidir o avanço da migração da ferramenta de colaboração nos próximos quarters.
Key Results
– Mais de 60% dos times participantes no Brasil e na Argentina passam a usar a nova ferramenta como principal meio de colaboração, de forma recorrente ao longo do trimestre.
– A percepção dos usuários nesses países é, em média, igual ou melhor do que a ferramenta atual, medida por pesquisa comparativa de feedback, com foco em qualidade de reuniões e facilidade de uso.
– O uso da ferramenta anterior pelos times do Brasil e da Argentina é reduzido em pelo menos 50%, criando flexibilidade real para revisão de licenças e custos nos próximos quarters.
– A operação se mantém estável durante o piloto, sem incidentes críticos que comprometam o trabalho diário dos times envolvidos.
No fim do quarter, a conversa não é “concluímos a Fase 1?” (output).
Mas sim: temos evidências suficientes, já começamos a capturar valor e temos base para decidir o próximo quarter? (outcome)
O projeto continua existindo.
A governança continua existindo.
O que muda é a forma de pensar e executar o projeto:
ele deixa de ser uma sequência de fases com benefícios só no fim e passa a ser uma sequência de quarters com objetivos claros, responsabilidade explícita e captura de valor (outcome) desde o primeiro ciclo.
Pessoas antes do objetivo
Quando você começa a trabalhar com Project Quarter, a tentação natural é pular direto para a pergunta errada:
“Qual é o objetivo deste quarter?”
Eu prefiro começar por outra.
Antes de falar de objetivo, eu pergunto:
quem é o grupo de pessoas responsável por fazer esse quarter acontecer?
Isso não é um detalhe.
É uma mudança de lógica.
No meu livro Team OKR, eu defino time como um grupo de pessoas com um objetivo comum. Repare na ordem: primeiro vem o grupo de pessoas, depois vem o objetivo.
Em organizações orientadas a projetos, é muito comum o inverso acontecer. O projeto é definido primeiro, e só depois se tenta “encaixar” pessoas, times ou áreas para dar conta da execução.
E, quando isso acontece, o foco naturalmente fica nos outputs, os entregáveis do projeto. Em vez de discutir qual resultado precisa ser alcançado, a conversa passa rapidamente para quais tarefas ou atividades cada pessoa ou área precisa executar para entregar o projeto.
É por isso que, na Estratégia PQP, o último P — People — vem antes da definição do objetivo do quarter para aquele Project Quarter.
Para cada Project Quarter, fica explícito:
- quem é o grupo de pessoas responsável
- quem realmente faz parte desse grupo
- quem não faz
Esse grupo pode ser um time já existente.
Pode ser um grupo temporário.
Pode incluir pessoas internas e externas.
O que importa não é a estrutura formal.
O que importa é que seja um grupo com responsabilidade real sobre o resultado.
Só depois que esse grupo está claro é que faz sentido olhar para:
- o OKR estratégico definido pela liderança
- o contexto e o escopo do projeto já aprovado
E então responder à pergunta certa:
“Qual é o objetivo que nós, como um time de verdade, vamos assumir para este quarter?”
É nesse momento que o time escreve o seu Team OKR.
Não um OKR cascateado.
Não um OKR imposto.
Mas um OKR assumido.
E quando isso acontece, algo muda de verdade.
O objetivo deixa de ser “do projeto”.
Passa a ser do time.
O que muda na prática (e o que NÃO muda)
Quando apresento a Estratégia PQP, uma reação é quase inevitável:
“Ok, entendi a lógica… mas isso muda tudo?”
A resposta curta é: não.
A resposta honesta é: muda o que realmente importa.
Vamos começar pelo que não muda.
Projetos continuam existindo.
Continuam sendo aprovados por comitês.
Continuam tendo sponsor, budget e escopo macro.
A governança continua funcionando como antes.
A estratégia continua sendo definida em ciclos mais longos.
Os OKRs estratégicos continuam existindo.
Nada disso precisa ser desmontado para a Estratégia PQP funcionar.
O que muda é como a execução acontece dentro desse contexto.
Em vez de projetos longos rodando de forma contínua e difusa, você passa a ter:
- foco explícito por trimestre
- expectativas claras de resultado
- momentos reais de decisão
Você passa a trabalhar com grupos de pessoas claramente responsáveis e com autonomia para decidir como executar.
E os OKRs deixam de ser listas de tarefas ou milestones disfarçados para cumprir o papel que fazem melhor:
- criar foco
- orientar decisões
- explicitar aprendizado
- e, como consequência, entregar resultado
A Estratégia PQP não cria uma nova camada de processo.
Ela cria clareza.
Clareza sobre:
- o que importa agora
- quem é responsável por isso
- quando e com base em quê decisões serão tomadas
E essa clareza faz diferença justamente onde organizações grandes mais sofrem: na execução do dia a dia.
Por que a Estratégia PQP funciona
A Estratégia PQP funciona por um motivo simples:
ela não tenta lutar contra a realidade das grandes organizações.
Ela parte do princípio de que:
- projetos já existem
- a estratégia já foi definida
- a governança não vai desaparecer
- e nem deveria
Em vez de tentar substituir tudo isso, a Estratégia PQP atua no espaço onde normalmente falta clareza: do tático à execução no dia a dia.
Ao trabalhar com projetos fatiados em quarters, você cria um ritmo mais saudável de foco, aprendizado e decisão. Ao deixar explícito quem são as pessoas responsáveis em cada quarter, você evita a diluição natural que acontece em projetos longos. E ao usar OKRs no nível certo — tático, de equipe — você devolve ao framework o papel que ele realmente cumpre bem.
Nada disso é revolucionário.
E talvez seja exatamente por isso que funcione.
A Estratégia PQP não promete agilidade instantânea, nem autonomia irrestrita. Ela propõe algo mais pragmático: melhorar a qualidade das decisões trimestre a trimestre, dentro das restrições que já existem.
Em organizações grandes, isso já é muita coisa.
No fim das contas, projetos continuam existindo.
A estratégia continua sendo definida em horizontes mais longos.
O que muda é a forma como estratégia e projetos se encontram no dia a dia.
E quando esse encontro fica mais claro, menos burocrático e mais orientado a resultado, a execução melhora. Não porque alguém mandou. Mas porque as pessoas passaram a saber, com mais clareza, o que importa agora, por quê, e quem é responsável por fazer acontecer.
É nesse espaço — entre estratégia e execução — que a Estratégia PQP tem feito diferença.
————
Se você gostou deste artigo e quer se aprofundar, há alguns caminhos naturais para seguir.
📘 Se gosta de ler, o livro Team OKR aprofunda exatamente esse tema: como equipes assumem objetivos, tomam decisões e executam OKRs na prática, mesmo em contextos complexos e orientados a projetos.
🎥 Se prefere aprender com vídeos, troca com outras pessoas, exemplos reais e mentoria, vale explorar o Hub Team OKR, onde compartilho conteúdos, discussões e materiais focados em OKRs táticos e de equipe.
💼 E se você quer aplicar essa prática na sua empresa— Estratégia PQP, Project Quarter e Team OKR — no seu contexto, conheça os serviços que ofereço ou, melhor ainda, me chame no LinkedIn ou via Caroli.org para marcarmos uma conversa.







