Identificar as Partes Interessadas — PMBOK 8

Artigo atualizado em março/2026 para o PMBOK® Guide — Eighth Edition.

Identificar as Partes Interessadas: O Processo que Mapeia Quem Pode Fazer o Projeto Triunfar ou Fracassar (PMBOK 8)

Anteriormente: Identificar as Partes Interessadas (PMBOK 6) — mesmo nome

Cadastre-se para navegar sem anúncios e participar do Project Together →

Imagine este cenário: o projeto está no segundo mês de execução e tudo parece correr bem. Até que um diretor de área — que nunca foi consultado durante o planejamento — descobre que o projeto impacta diretamente sua equipe. Ele bloqueia a alocação de dois recursos-chave, questiona a prioridade do projeto perante o comitê executivo e gera uma crise política que atrasa o cronograma em 6 semanas. O projeto tinha plano de comunicação, tinha plano de riscos — mas não tinha esse stakeholder no radar.

No PMBOK 8, o processo Identificar as Partes Interessadas é o Processo 2.5.2.1 do Domínio de Partes Interessadas — o primeiro de 7 processos dedicados à gestão de stakeholders. Ele existe porque não é possível gerenciar, engajar ou comunicar com quem você não sabe que existe.

Neste guia completo você vai encontrar:

• O que é o processo e onde ele se encaixa no PMBOK 8
• Por que usá-lo — e o que acontece quando você não usa
• ITTO completo — Entradas, Ferramentas/Técnicas e Saídas
• Passo a passo prático para aplicar o processo
• Quando aplicar — cenários e gatilhos
• Exemplos práticos — Projeto Horizonte e Projeto ProjectAdm
• Atalhos, templates e dicas
• 5 erros comuns — e como evitá-los
• Tailoring para Preditivo, Ágil e Híbrido
• Interações com outros processos e domínios
• Checklist de aplicação rápida

1. O que é o Processo Identificar as Partes Interessadas

Identificar as Partes Interessadas é o processo de identificar regularmente as partes interessadas do projeto e analisar e documentar informações relevantes sobre seus interesses, envolvimento, interdependências, influência e impacto potencial no sucesso do projeto.

No PMBOK 8, este é o Processo 2.5.2.1 do Domínio de Partes Interessadas — o primeiro de sete processos. A posição é intencional: antes de planejar engajamento, comunicação ou qualquer interação, é necessário saber quem são as pessoas e organizações que importam.

O processo produz as seguintes saídas:

• Registro das Partes Interessadas (Stakeholder Register) — o documento central que lista todos os stakeholders identificados com suas informações de classificação, incluindo papel, interesse, nível de influência, impacto potencial e requisitos de comunicação
• Solicitações de Mudança — quando a identificação de novos stakeholders revela necessidade de ajustes no plano de gerenciamento ou em outros componentes do projeto
• Atualizações — de documentos do projeto como o registro de premissas e o registro de riscos

O que define uma “parte interessada”

Segundo o PMBOK 8, uma parte interessada (stakeholder) é qualquer indivíduo, grupo ou organização que possa afetar, ser afetado ou se perceber afetado por uma decisão, atividade ou resultado de um projeto. Essa definição é ampla por design — e a amplidão é necessária.

Categoria	Exemplos	Por que incluir
Internos diretos	Patrocinador, equipe do projeto, GP	Impacto direto no projeto
Internos indiretos	Diretores de áreas impactadas, RH, jurídico, TI	Podem bloquear ou facilitar recursos e decisões
Externos contratuais	Fornecedores, consultores, subcontratados	Entregas dependem deles
Externos regulatórios	Órgãos reguladores, auditorias, sindicatos	Podem impor restrições ou aprovar entregas
Externos de mercado	Clientes finais, concorrentes, comunidade	Afetados pelo resultado do projeto

Identificação contínua, não pontual

Uma evolução importante do PMBOK 8: a identificação de stakeholders é tratada como processo contínuo, não como atividade pontual da iniciação. Novos stakeholders podem surgir a qualquer momento — mudanças organizacionais, novos fornecedores, regulamentações imprevistas, rotatividade de pessoal. O registro deve ser revisado regularmente ao longo de todo o ciclo de vida do projeto.

2. Por que Usar o Processo Identificar as Partes Interessadas

Benefícios diretos

• Visibilidade completa do ecossistema: Saber quem são todos os envolvidos, interessados e impactados permite antecipar resistências, identificar aliados e planejar comunicações adequadas.
• Prevenção de surpresas políticas: Stakeholders não identificados são stakeholders que podem bloquear o projeto sem aviso. A identificação precoce transforma potenciais adversários em aliados gerenciáveis.
• Base para engajamento e comunicação: Sem saber quem são as partes interessadas, é impossível planejar o engajamento e a comunicação. Este processo é pré-requisito para todos os demais processos do domínio.
• Gestão de expectativas proativa: Cada stakeholder tem expectativas diferentes sobre o projeto. Identificá-los cedo permite alinhar expectativas antes que divergências se tornem conflitos.
• Identificação de riscos de stakeholders: Stakeholders com alto poder e interesse negativo representam riscos para o projeto. A identificação permite que esses riscos sejam registrados e gerenciados formalmente.
• Compliance e governança: Em muitos setores, a identificação formal de partes interessadas é requisito regulatório (construção civil, saúde, meio ambiente, projetos públicos).

O que acontece quando o processo é ignorado

• Bloqueios inesperados: Um gerente de área não consultado pode bloquear a alocação de recursos críticos. Um órgão regulador não identificado pode exigir conformidade tardia que muda o escopo.
• Comunicação inadequada: Sem saber quem precisa de informação, a equipe comunica demais para quem não importa e de menos para quem importa. O resultado é ruído para alguns e surpresa para outros.
• Resistência não gerenciada: Stakeholders resistentes ao projeto que não foram identificados continuam operando contra o projeto sem que ninguém tome ação preventiva.
• Requisitos descobertos tarde: Stakeholders identificados tardiamente trazem requisitos que deveriam ter sido capturados no planejamento. O retrabalho resultante impacta escopo, cronograma e custos.
• Perda de apoio político: Aliados potenciais que não foram identificados nem engajados não oferecerão suporte quando o projeto precisar — em gate reviews, disputas de prioridade ou escalações.

O princípio “Cultura Empoderada” do PMBOK 8 reforça: projetos acontecem em contextos organizacionais complexos. Ignorar as pessoas que fazem parte desse contexto é ignorar a realidade em que o projeto opera.

3. Entradas, Ferramentas e Técnicas, e Saídas (ITTO)

Entradas	Ferramentas e Técnicas	Saídas
Termo de abertura do projeto Plano de gerenciamento do projeto Documentos do projeto (registro de mudanças, registro de problemas, registro de requisitos) Acordos Fatores ambientais da empresa (FAE) Ativos de processos organizacionais (APO)	Opinião especializada Coleta de dados (questionários, brainstorming) Análise de dados (análise de stakeholders, análise de documentos) Representação de dados (matriz poder/interesse, matriz poder/influência, cubo de stakeholders) Reuniões	Registro das partes interessadas Solicitações de mudança Atualizações de documentos do projeto

Detalhamento das Entradas

Termo de abertura do projeto: O primeiro documento a ser analisado. Contém os stakeholders-chave já identificados durante a iniciação: patrocinador, gerente de projeto, cliente e áreas diretamente impactadas. Serve como ponto de partida — nunca como lista completa.

Plano de gerenciamento do projeto: Planos subsidiários (comunicação, recursos, engajamento) podem revelar stakeholders implícitos — por exemplo, se o plano de recursos menciona fornecedores específicos, esses fornecedores são stakeholders a serem registrados.

Documentos do projeto: O registro de mudanças pode revelar stakeholders que solicitaram mudanças. O registro de problemas pode identificar partes afetadas. O registro de requisitos mostra quem originou cada requisito — essas pessoas são stakeholders.

Acordos: Contratos com fornecedores, clientes e parceiros identificam stakeholders externos com obrigações e direitos formais sobre o projeto.

Fatores ambientais da empresa (FAE): Estrutura organizacional (quem pode ser afetado pela mudança), cultura (como as pessoas reagem a projetos), condições de mercado (concorrentes, reguladores) e aspectos geopolíticos (em projetos internacionais).

Ativos de processos organizacionais (APO): Templates de registro de stakeholders, lições aprendidas de projetos anteriores (quais stakeholders foram “esquecidos” e causaram problemas), e bases de dados organizacionais com informações de contatos e áreas.

Detalhamento das Ferramentas e Técnicas

Opinião especializada: Consulta a profissionais que conhecem o ambiente organizacional e o setor: gerentes seniores, consultores, profissionais de RH e gerentes de projetos anteriores semelhantes. Eles podem identificar stakeholders que não são óbvios na documentação.

Coleta de dados: Questionários direcionados a membros da equipe e gerentes de área (“Quem mais precisa saber sobre este projeto? Quem será impactado? Quem pode bloquear?”). Brainstorming com a equipe para gerar uma lista abrangente antes de filtrar.

Análise de dados — Análise de stakeholders: Para cada stakeholder identificado, analise: nível de poder/autoridade, nível de interesse no projeto, atitude (favorável, neutro, resistente), expectativas, necessidades de informação e impacto potencial no projeto.

Representação de dados — Matriz poder/interesse: A ferramenta mais usada para classificar stakeholders. Divide em quatro quadrantes:

• Alto poder / Alto interesse: Gerenciar de perto — são os stakeholders mais críticos
• Alto poder / Baixo interesse: Manter satisfeitos — podem ativar seu poder se insatisfeitos
• Baixo poder / Alto interesse: Manter informados — são aliados potenciais e fontes de feedback
• Baixo poder / Baixo interesse: Monitorar — demandam esforço mínimo mas não devem ser esquecidos

Reuniões: Sessões de identificação com a equipe do projeto, reuniões com gerentes de áreas impactadas e workshops de análise de stakeholders com facilitação estruturada.

Detalhamento das Saídas

Registro das Partes Interessadas: Documento que contém, para cada stakeholder: nome, papel/função, organização, informações de contato, nível de poder, nível de interesse, atitude atual (favorável/neutro/resistente), classificação na matriz poder/interesse, expectativas e requisitos, estratégia de engajamento inicial e informações adicionais relevantes.

Solicitações de mudança: A identificação de novos stakeholders pode revelar requisitos não capturados, restrições não previstas ou necessidades de comunicação que exigem mudanças no plano de gerenciamento ou na linha de base do escopo.

Atualizações: O registro de premissas pode ser atualizado com premissas sobre o comportamento de stakeholders. O registro de riscos pode receber novos riscos relacionados a stakeholders de alto poder e atitude resistente.

4. Como Aplicar o Processo Passo a Passo

Passo 1 — Inicie pelo Termo de Abertura e acordos

Analise o Termo de Abertura e todos os acordos contratuais. Extraia os stakeholders já mencionados: patrocinador, gerente de projeto, cliente, fornecedores contratados, áreas citadas. Crie a lista inicial.

Passo 2 — Expanda com brainstorming estruturado

Reúna a equipe do projeto e faça brainstorming usando categorias como guia:

• Quem aprova? (Sponsor, comitê, diretorias)
• Quem executa? (Equipe, fornecedores, consultores)
• Quem é impactado? (Áreas que mudam processos, equipes que mudam ferramentas)
• Quem pode bloquear? (Reguladores, sindicatos, gerentes de áreas com recursos disputados)
• Quem se beneficia? (Clientes internos, usuários finais)
• Quem financia? (Área financeira, patrocinador, investidores)

Dica prática: Use a técnica “quem mais?” repetidamente. Depois que a equipe achar que listou todos, pergunte “quem mais poderia ser afetado?” mais três vezes. Stakeholders esquecidos costumam surgir nessas rodadas finais.

Passo 3 — Consulte especialistas e fontes externas

Entreviste gerentes seniores, profissionais de RH (para identificar mudanças organizacionais previstas), departamento jurídico (para requisitos regulatórios) e gerentes de projetos anteriores similares (para stakeholders que surgiram inesperadamente).

Passo 4 — Classifique cada stakeholder na matriz poder/interesse

Para cada stakeholder identificado, avalie:

• Poder: Capacidade de influenciar decisões, alocar/retirar recursos ou bloquear o projeto (alto/médio/baixo)
• Interesse: Nível de preocupação ou envolvimento com o resultado do projeto (alto/médio/baixo)
• Atitude: Favorável (apoia o projeto), neutro (indiferente) ou resistente (opõe-se ao projeto)

Posicione cada stakeholder na matriz 2×2 (poder vs. interesse) para determinar a estratégia geral de engajamento.

Passo 5 — Documente no Registro de Partes Interessadas

Para cada stakeholder, registre no mínimo:

Campo	Descrição
Nome	Nome completo
Papel/Função	Cargo ou papel no contexto do projeto
Organização/Área	Departamento ou empresa
Poder	Alto/Médio/Baixo
Interesse	Alto/Médio/Baixo
Atitude	Favorável/Neutro/Resistente
Quadrante	Gerenciar de perto / Manter satisfeito / Manter informado / Monitorar
Expectativas	O que espera do projeto
Requisitos de comunicação	Que informação precisa, com qual frequência, em qual formato
Notas	Observações relevantes (alianças, conflitos, sensibilidades)

Passo 6 — Identifique riscos de stakeholders

Para cada stakeholder de alto poder com atitude resistente ou neutro-instável, registre um risco no registro de riscos. Exemplo: “Risco: Marcos Tanaka (Gerente de Operações, alto poder, resistente) pode não liberar sua equipe para os treinamentos, atrasando a fase de capacitação em até 4 semanas.”

Passo 7 — Estabeleça a cadência de revisão

Defina com que frequência o registro de stakeholders será revisado. Recomendação mínima: a cada fase do projeto. Em ambientes dinâmicos, revise mensalmente ou a cada sprint review.

5. Quando Aplicar o Processo

Cenários obrigatórios

• Na iniciação do projeto: A identificação inicial é feita durante ou imediatamente após a aprovação do Termo de Abertura.
• No início de cada fase: Novos stakeholders podem surgir quando o projeto entra em uma fase que impacta áreas diferentes.
• Quando ocorrem mudanças organizacionais: Reorganizações, fusões, aquisições ou mudanças de liderança exigem revisão do registro.

Cenários recomendados

• Após aprovação de mudança significativa no escopo: Mudanças de escopo podem impactar novas áreas e revelar novos stakeholders.
• Quando surgem novos fornecedores ou parceiros: Cada novo contrato traz novos stakeholders ao ecossistema.
• Quando um stakeholder existente muda de posição: Promoção, transferência ou saída de um stakeholder-chave exige atualização.

Gatilhos

• Um problema surge causado por alguém que não estava no registro de stakeholders
• A equipe descobre que uma decisão precisa da aprovação de alguém que nunca foi consultado
• Um novo regulamento entra em vigor e afeta o projeto
• A equipe recebe feedback ou reclamações de pessoas que não sabiam do projeto
• Houve reestruturação organizacional que mudou a cadeia de comando

6. Exemplos Práticos por Setor

Exemplo 1 — Implantação do PMO: Projeto Horizonte

Contexto: Ana Silveira, gerente de projetos da Horizonte Transportes, precisa identificar todas as partes interessadas do projeto de implantação do PMO. O projeto impacta todas as áreas da transportadora (280 funcionários, Campinas-SP), desde a diretoria até os motoristas que utilizam sistemas de gestão de frotas.

Como o processo foi aplicado:

1. Análise do Termo de Abertura: Ana extraiu os stakeholders já mencionados: Roberto Campos (CEO/Patrocinador), Marcos Tanaka (Gerente de Operações), Fernanda Lopes (Gerente Financeira), Diego Carvalho (Analista Sênior do PMO), Carolina Mendes (Consultora Externa/ProjectAdm). Total inicial: 5 stakeholders.
2. Brainstorming com a equipe: Em sessão de 90 minutos, a equipe expandiu a lista para 23 stakeholders. Categorias-chave identificadas: gerentes das filiais (Curitiba, Brasília, Porto Alegre), equipe de TI (responsável por integração do ProjectAdm com o ERP de frotas), sindicato dos motoristas (qualquer mudança em processos de gestão de frota afeta motoristas), RH (treinamentos e gestão de mudança), clientes corporativos-chave (impactados indiretamente por mudanças na gestão de entregas).
3. Consulta especializada: Ana entrevistou o gerente de TI, que revelou uma dependência não prevista: o fornecedor do sistema ERP (Totvs) precisaria ser envolvido para a integração com o ProjectAdm — mais um stakeholder externo com alto impacto técnico.
4. Classificação na matriz poder/interesse:
   • Alto poder / Alto interesse (Gerenciar de perto): Roberto Campos, Marcos Tanaka, Fernanda Lopes
   • Alto poder / Baixo interesse (Manter satisfeitos): Gerentes de filiais, Diretor Jurídico
   • Baixo poder / Alto interesse (Manter informados): Diego Carvalho, equipe de TI, equipe de RH
   • Baixo poder / Baixo interesse (Monitorar): Motoristas (impacto indireto), clientes corporativos
5. Riscos de stakeholders: Ana registrou 3 riscos: (a) Marcos Tanaka (alto poder, inicialmente resistente) poderia atrasar a liberação de sua equipe para treinamentos; (b) Sindicato dos motoristas poderia questionar mudanças em processos de gestão de frota; (c) Fornecedor do ERP poderia não priorizar a integração no prazo necessário.

Resultado: No mês 2, quando a Totvs informou que a integração exigiria uma atualização de versão do ERP (custo de R$ 25.000 e 3 semanas adicionais), Ana já tinha o fornecedor no registro de stakeholders com estratégia “gerenciar de perto”. A negociação foi rápida porque o relacionamento já estava mapeado e a comunicação já estava fluindo. Se a Totvs não estivesse no registro, a surpresa teria causado atraso significativo.

Exemplo 2 — Desenvolvimento de Software: Projeto ProjectAdm

Contexto: Eduardo Montes, gerente de projeto do ProjectAdm, precisa identificar os stakeholders de uma plataforma SaaS de gerenciamento de projetos em desenvolvimento (equipe de 5 pessoas, R$ 120.000, 12 meses).

Como o processo foi aplicado:

1. Análise inicial: Equipe core: Eduardo Montes (GP/SM), Henry Douglas (LT/PO), Marcus Webb, Julia Chen, Bruno Silva. Stakeholders internos óbvios: 5 pessoas.
2. Brainstorming expandido: A equipe identificou stakeholders que não eram óbvios inicialmente:
   • Early adopters / beta testers: 8 profissionais de projetos que se voluntariaram para testar a plataforma
   • Comunidade Project Together: Futuros usuários que acompanham o desenvolvimento via newsletter
   • Provedores de infraestrutura: Hosting provider (VPS em 72.60.143.184), serviço de email (Mautic), gateway de pagamento
   • Concorrentes indiretos: Monday.com, Asana, ClickUp — monitorar posicionamento
   • Reguladores: LGPD (dados de usuários brasileiros), termos de uso e política de privacidade
3. Classificação:
   • Gerenciar de perto: Henry Douglas (define o produto), early adopters (feedback crítico)
   • Manter satisfeitos: Provedores de infraestrutura, gateway de pagamento
   • Manter informados: Comunidade Project Together, equipe de suporte futuro
   • Monitorar: Concorrentes, reguladores (LGPD)
4. Riscos identificados: (a) Early adopters podem abandonar o beta se as entregas atrasarem; (b) Mudanças na LGPD podem exigir ajustes de arquitetura; (c) Gateway de pagamento pode mudar condições comerciais.

Resultado: No mês 6, quando um early adopter identificou um problema crítico de usabilidade que afetava a navegação principal, a equipe já tinha uma linha de comunicação direta estabelecida. O feedback foi integrado na Sprint seguinte, e o early adopter se tornou um dos primeiros clientes pagantes no lançamento — transformando um stakeholder “beta tester” em “cliente evangelista”.

7. Atalhos, Templates e Dicas

Templates recomendados

• Template de Registro de Stakeholders: Planilha com colunas: ID, nome, papel, organização, poder, interesse, atitude, quadrante, expectativas, comunicação requerida, notas.
• Template de Matriz Poder/Interesse: Diagrama 2×2 com quatro quadrantes rotulados (Gerenciar de perto, Manter satisfeito, Manter informado, Monitorar). Posicione stakeholders como pontos no diagrama.
• Template de Análise de Stakeholders (detalhado): Para stakeholders de alto impacto, um formulário com: posição atual, posição desejada, estratégia para mover, ações específicas, responsável, prazo.

Ferramentas digitais

• Miro / Mural: Para workshops colaborativos de mapeamento de stakeholders
• Excel / Google Sheets: Para o registro formal com filtros e classificação automática
• ProjectAdm: Para integração do registro de stakeholders com comunicações e plano de engajamento
• Stakeholder Circle / Mendelow’s Matrix: Para visualização avançada de stakeholders em projetos complexos

Dicas avançadas

• Pense em “stakeholders de stakeholders”: O patrocinador responde a alguém (board, investidores). O gerente de área é pressionado por sua equipe. Entender a cadeia de influência por trás de cada stakeholder revela dinâmicas ocultas.
• Não confunda “baixo interesse” com “irrelevante”: Um stakeholder com alto poder e baixo interesse pode parecer seguro — até que algo desperte seu interesse. Monitore-os sempre.
• Trate o registro como confidencial: Informações como “atitude resistente” ou “conflito com outro stakeholder” são sensíveis. O registro completo deve ter acesso restrito; versões públicas devem conter apenas informações não sensíveis.
• Atualize a cada mudança significativa: Nova fase, novo contrato, reorganização, crise — cada um desses eventos pode mudar o mapa de stakeholders radicalmente.
• Use a identificação como oportunidade de relacionamento: O ato de consultar alguém sobre o projeto (“Estou mapeando todos os envolvidos e gostaria de entender seu interesse”) já é, por si só, uma ação de engajamento.

8. Erros Comuns e Como Evitá-los

Erro 1 — Identificar apenas os stakeholders óbvios

Por que acontece: A equipe lista patrocinador, equipe e cliente — e para por aí. Stakeholders indiretos (áreas de apoio, reguladores, fornecedores de fornecedores, comunidade) ficam de fora.

Como evitar: Use categorias estruturadas (internos diretos, internos indiretos, externos contratuais, externos regulatórios, externos de mercado) e pergunte “quem mais?” sistematicamente para cada categoria. Consulte gerentes seniores e lições aprendidas de projetos anteriores.

Erro 2 — Fazer a identificação uma única vez e nunca revisitar

Por que acontece: A equipe trata a identificação como uma atividade de checkbox na iniciação. O registro é criado e arquivado. Novos stakeholders que surgem durante a execução nunca são formalmente adicionados.

Como evitar: Estabeleça revisão obrigatória do registro a cada fase, a cada mudança organizacional e a cada adição de novo fornecedor ou parceiro. Inclua “revisão do registro de stakeholders” na pauta de reuniões de status mensais.

Erro 3 — Classificar sem analisar profundamente

Por que acontece: A equipe preenche poder e interesse com base em impressão superficial. “O Marcos é gerente, então tem poder alto.” Na realidade, o poder de Marcos sobre este projeto específico pode ser limitado — ou pode ser muito maior do que o cargo sugere.

Como evitar: Analise o poder e o interesse no contexto específico do projeto, não do cargo. Um analista com controle sobre um sistema crítico pode ter mais poder real sobre o projeto do que um diretor de área não impactada.

Erro 4 — Não registrar stakeholders resistentes

Por que acontece: A equipe evita documentar que determinado stakeholder é “resistente” por medo de conflito político. O resultado: a resistência existe mas não é gerenciada — porque não está registrada.

Como evitar: Registre a atitude real de cada stakeholder (favorável/neutro/resistente) no registro. Se o registro for confidencial (como deve ser), a informação está protegida. Se a resistência não for documentada, não será gerenciada.

Erro 5 — Tratar todos os stakeholders com o mesmo nível de atenção

Por que acontece: A equipe não usa a matriz poder/interesse para diferenciar estratégias. Resultado: gasta-se tempo excessivo comunicando stakeholders de baixo impacto enquanto stakeholders críticos são subatendidos.

Como evitar: Use a classificação da matriz para definir estratégias diferenciadas. Stakeholders do quadrante “Gerenciar de perto” recebem atenção semanal. Stakeholders do quadrante “Monitorar” recebem comunicação mensal ou sob demanda. A diferenciação é eficiência, não discriminação.

9. Tailoring: Preditivo, Ágil e Híbrido

Ambiente Preditivo

• Identificação formal no início: Workshop de identificação estruturado, registro completo com todos os campos, classificação na matriz poder/interesse.
• Revisão por fase: O registro é revisado a cada gate review.
• Documentação detalhada: Registro com análise de posição atual vs. desejada para stakeholders-chave.

Ambiente Ágil

• Identificação contínua: Stakeholders são identificados e reavaliados a cada sprint review ou PI planning.
• Registro leve: Quadro visual (Kanban de stakeholders) ou lista simples no backlog de relacionamentos.
• Foco em feedback loops: Stakeholders são priorizados pela capacidade de fornecer feedback valioso para o produto.

Ambiente Híbrido

• Registro formal + revisão ágil: Registro completo criado no início; atualizado em cadência ágil (sprint review).
• Classificação por fase: Stakeholders podem mudar de quadrante entre fases — a matriz é atualizada a cada transição.

Resumo comparativo

Aspecto	Preditivo	Ágil	Híbrido
Registro	Documento formal detalhado	Lista leve, visual	Formal + atualizações ágeis
Classificação	Matriz poder/interesse formal	Priorização por feedback value	Matriz + priorização por feedback
Revisão	Por fase / gate review	A cada sprint review	Gate review + sprint review
Profundidade	Análise detalhada (posição atual/desejada)	Análise rápida (interesse/feedback)	Detalhada (key) + rápida (demais)

10. Interações com Outros Processos e Domínios

Processos que alimentam a identificação

Processo	Domínio	O que fornece
Iniciar Projeto ou Fase	Governança	Termo de abertura com stakeholders iniciais
Coletar Requisitos	Escopo	Novos stakeholders descobertos durante a coleta
Conduzir Aquisições	Recursos	Novos fornecedores e parceiros contratados

Processos que dependem da identificação

Processo	Domínio	O que recebe
Planejar o Engajamento das PI	Partes Interessadas	Registro de stakeholders como base para estratégias de engajamento
Planejar o Gerenciamento das Comunicações	Partes Interessadas	Lista de stakeholders e seus requisitos de comunicação
Gerenciar o Engajamento das PI	Partes Interessadas	Informações sobre atitudes e estratégias por stakeholder
Identificar Riscos	Riscos	Riscos de stakeholders (resistência, bloqueios, mudanças)

Interações com os Domínios

Partes Interessadas: Este processo é o fundamento de todo o domínio. Sem identificação, não há engajamento, comunicação nem monitoramento de stakeholders.

Governança: O Termo de Abertura fornece os stakeholders iniciais. O registro de stakeholders alimenta decisões de governança sobre quem aprovar, consultar e informar.

Escopo: Stakeholders são fontes de requisitos. A identificação tardia de um stakeholder pode revelar requisitos que mudam o escopo.

Riscos: Stakeholders resistentes ou de alto poder com interesse negativo são fontes de riscos que devem ser registrados e gerenciados.

Recursos: Novos fornecedores e parceiros são stakeholders que precisam ser identificados e gerenciados.

Finanças: Stakeholders financeiros (patrocinador, área financeira, investidores) têm requisitos específicos de informação sobre custos e orçamento.

11. Checklist de Aplicação Rápida

1. Todos os stakeholders mencionados no Termo de Abertura e nos acordos foram incluídos no registro?
2. A equipe fez brainstorming estruturado por categorias (internos, externos, regulatórios, beneficiários)?
3. Cada stakeholder foi classificado na matriz poder/interesse com base no contexto específico do projeto?
4. Stakeholders de alto poder com atitude resistente foram registrados como riscos no registro de riscos?
5. O registro contém informações de comunicação (o que precisa, quando e como) para cada stakeholder-chave?
6. A cadência de revisão do registro foi definida e está sendo seguida?
7. Especialistas e fontes externas foram consultados para identificar stakeholders não óbvios?

Regra prática: Se menos de 5 itens foram atendidos, a identificação de stakeholders está incompleta. E stakeholders não identificados são a fonte mais comum de surpresas que descarrilam projetos.

12. Faça agora com IA: o Processo 2 do PMBOK 8 Together

O PMBOK 8 Together é o curso gratuito que executa este processo no seu projeto: você responde no seu quadro, roda o processo e ele escreve o documento — preenchido, no modelo pronto. É o Processo 2 de 40.

O que este processo lê do seu quadro

• a lista Partes Interessadas
• a lista Mudanças

O que ele entrega

• Registro das partes interessadas
• Solicitação de mudança

Como rodar

1. Responda no seu quadro do projeto (ProjectAdm).
2. Rode o processo 2 — ele devolve o prompt pronto, com os seus dados, na área de transferência.
3. Cole na sua IA. Ela propõe; você decide.
4. Cole a resposta na Caixa de entrada do quadro e rode o processo de novo — agora ele escreve o documento.

Baixar o pacote do curso — gratuito e sem instalar nada. Primeira vez? Veja a instalação padrão (5 minutos). As 40 aulas, com certificado, você recebe inscrevendo-se na página do curso.

Para se aprofundar em cada saída

• Registro das partes interessadas
• Solicitação de mudança

Conclusão

O processo Identificar as Partes Interessadas é o fundamento de todo o gerenciamento de stakeholders — e, por extensão, de grande parte do sucesso do projeto. Não é possível engajar, comunicar ou gerenciar quem você não sabe que existe.

Os três pontos essenciais:

• Identificação é contínua, não pontual. O PMBOK 8 enfatiza: novos stakeholders podem surgir a qualquer momento. O registro deve ser revisado regularmente — a cada fase, a cada mudança organizacional, a cada novo contrato.
• A matriz poder/interesse é a ferramenta mais importante deste processo. Ela transforma uma lista genérica em um mapa estratégico que define onde investir tempo e atenção. Tratar todos os stakeholders igualmente é desperdiçar recursos com quem não precisa e subatender quem é crítico.
• Stakeholders não identificados são riscos não gerenciados. Cada stakeholder esquecido é uma potencial surpresa — bloqueio, requisito tardio, resistência invisível. A identificação abrangente é a melhor prevenção contra surpresas políticas.

Próximo passo concreto: Abra o registro de stakeholders do seu projeto atual. Quantos stakeholders estão listados? A última atualização foi quando? Há stakeholders com atitude “resistente” sem ação de mitigação? Se o registro está desatualizado ou incompleto, sua primeira tarefa é atualizá-lo — antes que um stakeholder esquecido lembre de você.

Veja todos os artigos do PMBOK 8 no Indice Completo

---

🇺🇸 Read this article in English

CTA Final

Gostou do artigo?

Project Management Institute (PMI). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Eighth Edition. Newtown Square, Pennsylvania, USA: Project Management Institute, 2025.

Cadastre-se para navegar sem anúncios e participar do Project Together →

Disclaimer:
Este artigo tem caráter informativo e educacional, com o objetivo de apresentar uma análise independente sobre o Guia PMBOK®. O conteúdo aqui publicado não reproduz nem substitui o material original do PMI e respeita integralmente seus direitos autorais. As marcas PMI e PMBOK® Guide são registradas pelo Project Management Institute. Para acesso ao conteúdo completo e oficial, adquira o guia pela Amazon ou baixe de forma gratuita em https://www.pmi.org/standards/pmbok se você é membro do PMI.

Como Associado da Amazon, a escritoriodeprojetos.com.br recebe por compras qualificadas. Os links para a Amazon nesta página são links de afiliado; o preço que você paga não muda.