Identificar os Riscos — PMBOK 8: Guia Completo (2026)

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

Identificar os Riscos: Como Encontrar o que Pode Dar Errado (e Certo) Antes que Aconteça (PMBOK 8)

Imagine este cenário: o projeto está na semana 8 e tudo parece sob controle. Então, em 72 horas, três eventos simultâneos: o fornecedor de hardware anuncia atraso de 6 semanas por falta de componentes, a regulamentação do setor muda exigindo uma certificação que a equipe não tem, e o desenvolvedor sênior recebe uma proposta irrecusável e pede demissão. Nenhum desses eventos era imprevisível — todos tinham sinais. Mas ninguém os identificou formalmente, ninguém os registrou e ninguém planejou respostas. O projeto entra em crise evitável.

No PMBOK 8, o processo Identificar os Riscos é o Processo 36 (código 2.7.2.2) do Domínio de Riscos. Ele determina quais riscos individuais e quais fontes de risco geral do projeto existem, e documenta suas características. É o processo que transforma o “e se…” em um registro formal que pode ser analisado, priorizado e tratado.

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

Neste guia completo você vai encontrar:

• O que é o processo e a diferença entre riscos individuais e risco geral do projeto
• Por que usá-lo — e o custo de riscos não identificados
• ITTO completo
• Passo a passo prático
• Quando aplicar
• Exemplos práticos — Projeto Horizonte e Projeto ProjectAdm
• Atalhos, templates e dicas
• 5 erros comuns
• 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 os Riscos

Identificar os Riscos é o processo de determinar quais riscos podem afetar o projeto e documentar suas características. A identificação abrange tanto ameaças (eventos negativos) quanto oportunidades (eventos positivos que podem beneficiar o projeto).

No PMBOK 8, este é o Processo 36 (código 2.7.2.2), o segundo do Domínio de Riscos. Diferente de processos que são executados uma única vez, a identificação de riscos é um processo iterativo — novos riscos surgem e riscos existentes evoluem ao longo de todo o ciclo de vida do projeto.

O processo produz três saídas:

• Registro dos Riscos (Risk Register) — o repositório central de todos os riscos identificados, com descrição, categoria, status e owner
• Relatório de Riscos (Risk Report) — uma visão consolidada do perfil de risco do projeto, incluindo o nível de risco geral
• Atualizações de documentos do projeto — ajustes no registro de premissas, registro de lições aprendidas e outros

Risco individual vs. Risco geral do projeto

Aspecto	Risco Individual	Risco Geral do Projeto
Definição	Evento ou condição incerta que pode afetar um ou mais objetivos do projeto	Efeito da incerteza no projeto como um todo, decorrente da combinação de todos os riscos individuais
Exemplo	“O fornecedor pode atrasar a entrega do servidor em 3 semanas”	“O projeto tem probabilidade de 35% de exceder o prazo total”
Gerenciado por	Risk owner específico	Gerente de projeto + patrocinador
Documento	Registro dos Riscos	Relatório de Riscos

2. Por que Usar o Processo Identificar os Riscos

Benefícios diretos

• Antecipação: Riscos identificados podem ser analisados, priorizados e tratados ANTES de se materializarem. Problemas não identificados viram crises.
• Visão 360°: A identificação sistemática cobre todas as áreas do projeto — técnica, organizacional, externa, de recursos — reduzindo pontos cegos.
• Base para análise e resposta: Sem riscos identificados, não há o que analisar nem para o que planejar respostas. A identificação é o input de todo o resto.
• Identificação de oportunidades: Riscos não são apenas ameaças. Oportunidades identificadas podem ser exploradas para acelerar entregas, reduzir custos ou aumentar valor.
• Engajamento da equipe: O processo de identificação envolve toda a equipe, gerando propriedade coletiva sobre os riscos e responsabilidade compartilhada.
• Registro histórico: O registro de riscos é uma base de conhecimento que melhora a identificação em projetos futuros.

O que acontece quando o processo é ignorado

• Surpresas evitáveis: A maioria dos “eventos inesperados” em projetos era previsível — alguém na equipe sabia que poderia acontecer, mas ninguém perguntou nem registrou.
• Reação em vez de prevenção: Sem identificação, a equipe reage a cada problema como se fosse único e imprevisível — quando na realidade, 80% dos riscos são recorrentes em projetos similares.
• Sem base para reservas: Sem riscos identificados, não há justificativa para reservas de contingência. O orçamento não tem buffer.
• Oportunidades perdidas: Sem identificação de oportunidades, o projeto perde chances de entregar mais valor, mais rápido ou com menos custo.

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

Entradas	Ferramentas e Técnicas	Saídas
Plano de Gerenciamento do Projeto (plano de riscos e todos os subsidiários) Documentos do projeto (registro de premissas, estimativas de custo e duração, registro das partes interessadas, cronograma, EAP) Acordos (contratos) Documentação de aquisições Fatores ambientais da empresa (EEFs) Ativos de processos organizacionais (OPAs)	Opinião especializada Coleta de dados (brainstorming, checklists, entrevistas) Análise de dados (análise de causa raiz, análise de premissas e restrições, análise SWOT) Habilidades interpessoais e de equipe (facilitação) Listas de riscos (prompt lists)	Registro dos Riscos Relatório de Riscos Atualizações de documentos do projeto

Detalhamento das Entradas

Plano de Gerenciamento do Projeto: O plano de riscos define as categorias (RBS), as escalas e a metodologia de identificação. Os planos subsidiários (escopo, cronograma, custos, recursos) são fontes de riscos — cada plano tem premissas e restrições que geram incertezas.

Documentos do projeto: O registro de premissas é uma mina de riscos — cada premissa não confirmada é um risco potencial. Estimativas de custo e duração contêm incertezas que geram riscos. A EAP revela complexidade técnica e interdependências.

Acordos e documentação de aquisições: Contratos com fornecedores contêm riscos: cláusulas de penalidade, dependências de terceiros, SLAs, condições de cancelamento.

EEFs: Condições de mercado, regulamentação, eventos geopolíticos, benchmarks setoriais publicados, riscos do setor.

OPAs: Registros de riscos de projetos anteriores (fonte mais rica de riscos recorrentes), lições aprendidas, checklists de riscos setoriais, bases de dados de riscos.

Detalhamento das Ferramentas e Técnicas

Opinião especializada: Consulta a profissionais com experiência no domínio técnico, no tipo de projeto ou no setor. Especialistas externos podem identificar riscos que a equipe interna não percebe por estar “muito perto” do problema.

Coleta de dados:

• Brainstorming: Sessão estruturada com a equipe para gerar uma lista abrangente de riscos. Regras: sem críticas durante a geração, quantidade antes de qualidade, todas as ideias são válidas. Depois, consolida e categoriza.
• Checklists: Listas predefinidas de riscos comuns por tipo de projeto ou setor. Eficientes para não esquecer riscos recorrentes, mas limitadas — não capturam riscos únicos do projeto.
• Entrevistas: Conversas individuais com stakeholders-chave, especialistas e membros da equipe. Capturam riscos que pessoas não mencionariam em grupo (por exemplo, riscos políticos ou interpessoais).

Análise de dados:

• Análise de causa raiz: Para cada risco identificado, investiga a causa subjacente. Pode revelar que múltiplos riscos aparentes têm a mesma causa raiz — tratando a causa, elimina-se vários riscos.
• Análise de premissas e restrições: Revisa sistematicamente cada premissa e restrição do projeto e pergunta: “O que acontece se isso não for verdade?” Cada resposta é um risco potencial.
• Análise SWOT: Examina Forças, Fraquezas, Oportunidades e Ameaças do projeto como um todo — identificando riscos positivos (oportunidades) e negativos (ameaças).

Habilidades interpessoais (facilitação): A capacidade de conduzir sessões de identificação de forma que todos participem, incluindo pessoas introvertidas, júniores ou que temem retaliação por apontar problemas. O facilitador cria segurança psicológica para que riscos “impopulares” sejam mencionados.

Listas de riscos (prompt lists): Listas genéricas de categorias de risco que servem como estímulo para a equipe. Exemplos: PESTLE (Político, Econômico, Social, Tecnológico, Legal, Ambiental), TECOP (Técnico, Ambiental, Comercial, Operacional, Político) ou a RBS do projeto.

4. Como Aplicar o Processo Passo a Passo

Passo 1 — Prepare a sessão de identificação

Antes da sessão, reúna materiais:

• RBS do projeto (categorias de risco)
• Registro de premissas (cada premissa é um risco potencial)
• Registros de riscos de projetos anteriores similares
• Checklists setoriais (se disponíveis)
• EAP, cronograma e estimativas (para identificar riscos técnicos e de cronograma)

Passo 2 — Conduza o brainstorming estruturado

Reúna a equipe, stakeholders-chave e especialistas. Conduza a sessão em 3 rodadas:

1. Por categoria da RBS: Percorra cada categoria e pergunte: “Que riscos existem nesta área?”
2. Por premissa: Revise cada premissa do registro e pergunte: “E se isso não for verdade?”
3. Livre: Pergunte: “Que outros riscos vocês veem que não foram mencionados?”

Passo 3 — Conduza entrevistas individuais

Para stakeholders seniores e especialistas externos, conduza entrevistas individuais de 20-30 minutos. Perguntas-chave:

• “O que mais te preocupa neste projeto?”
• “Que problemas você viu em projetos similares?”
• “Que oportunidades podemos estar perdendo?”
• “Que riscos a equipe pode não estar vendo?”

Passo 4 — Analise premissas e restrições sistematicamente

Para cada premissa e restrição documentada, formule o risco correspondente usando o formato metalinguístico: “Dado que [causa/premissa], pode ocorrer [evento de risco], o que resultaria em [impacto no projeto].”

Passo 5 — Documente no Registro dos Riscos

Para cada risco identificado, registre:

• ID: Identificador único (R001, R002…)
• Descrição: Causa + evento + impacto (formato metalinguístico)
• Categoria: Conforme a RBS
• Tipo: Ameaça ou oportunidade
• Fonte: Como foi identificado (brainstorming, entrevista, checklist, premissa)
• Risk owner: Pessoa responsável por monitorar e responder
• Status: Aberto, em análise, com resposta planejada, materializado, encerrado

Passo 6 — Elabore o Relatório de Riscos inicial

Consolide os riscos em uma visão de alto nível:

• Número total de riscos por categoria
• Número de ameaças vs. oportunidades
• Distribuição por domínio afetado (escopo, prazo, custo, qualidade)
• Avaliação preliminar do nível de risco geral do projeto

Passo 7 — Planeje a identificação contínua

A identificação não é um evento único. Defina:

• Frequência de revisão do registro (semanal, quinzenal, por sprint)
• Gatilhos para sessões de identificação extraordinárias (mudança de escopo, novo stakeholder, evento externo)
• Canais para reportar novos riscos a qualquer momento (formulário, canal Slack, item no backlog)

5. Quando Aplicar o Processo

Cenários obrigatórios

• Durante o planejamento inicial: A primeira identificação abrangente deve ocorrer como parte do planejamento.
• Ao longo de todo o projeto: Novos riscos surgem conforme o projeto avança. A identificação é contínua.
• Antes de cada fase: O perfil de riscos muda entre fases — o que era risco na fase 1 pode não ser na fase 3, e vice-versa.

Gatilhos para sessão extraordinária

• Mudança significativa de escopo aprovada
• Novo stakeholder com alta influência entra no projeto
• Evento externo significativo (regulamentação, mercado, fornecedor)
• Risco crítico se materializa (pode gerar riscos secundários)
• Mudança tecnológica ou de abordagem

6. Exemplos Práticos por Setor

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

Contexto: Ana Silveira conduz a identificação de riscos para o Projeto Horizonte na Horizonte Transportes.

Como o processo foi aplicado:

1. Sessão de brainstorming (3 horas): Participantes: Ana, Diego Carvalho, Carolina Mendes, Marcos Tanaka e Fernanda Lopes. Ana usou a RBS como guia. Na categoria “Organizacional”, o grupo identificou: resistência dos gerentes operacionais ao PMO (Marcos Tanaka confirmou que “vários colegas veem o PMO como burocracia”), competição de prioridades no pico operacional (dezembro-fevereiro = alta temporada de transporte), e rotatividade dos analistas juniores (“ganhamos pouco, eles podem sair”). Na categoria “Técnica”: incompatibilidade do ProjectAdm com o sistema de rastreamento de frotas, e curva de aprendizado da plataforma maior que o esperado.
2. Entrevista com Roberto Campos (CEO): Roberto identificou um risco que ninguém da equipe mencionou: “Se perdermos o contrato da Petrobras no Q2, o orçamento de todos os projetos internos será cortado em 30%.” Esse risco externo/financeiro tinha probabilidade real e impacto devastador — e só foi identificado porque Ana entrevistou o CEO individualmente.
3. Análise de premissas: Ana revisou as 12 premissas do registro. A premissa “Os 40 colaboradores estarão disponíveis para treinamento no mês 4” gerou o risco: “Dado que o mês 4 coincide com o pico de entregas da filial de Curitiba, pode ocorrer indisponibilidade de 30% dos colaboradores para treinamento, o que resultaria em atraso de 3-4 semanas na adoção da plataforma.”
4. Oportunidades identificadas: Carolina Mendes identificou uma oportunidade: “Se a Horizonte participar do case study do ProjectAdm, pode obter 20% de desconto nas licenças — economia de R$ 6.720 em 12 meses.” Diego identificou outra: “Se treinarmos os operadores de frota como key users, teremos embaixadores em cada filial — acelerando a adoção em 2-3 semanas.”
5. Registro final: 28 riscos identificados: 21 ameaças + 7 oportunidades. Distribuição por categoria: Organizacional (11), Técnico (7), Recursos (5), Externo (5).

Resultado: O risco do contrato da Petrobras (identificado na entrevista com o CEO) se mostrou real — o contrato foi renegociado com redução de 15% no Q2. Graças à identificação prévia, Ana já tinha uma resposta planejada: reduzir o escopo da fase 3 (treinamento avançado) de 40 para 25 colaboradores, mantendo o orçamento dentro dos limites aprovados. Sem a entrevista individual, esse risco teria sido uma surpresa catastrófica.

Exemplo 2 — Desenvolvimento de Software: Projeto ProjectAdm

Contexto: Eduardo Montes conduz a identificação de riscos para o Projeto ProjectAdm com a equipe remota.

Como o processo foi aplicado:

1. Brainstorming virtual (2 horas via Miro): Eduardo usou um board no Miro com 4 colunas (uma por categoria da RBS). Cada membro adicionou post-its silenciosamente por 15 minutos (evitando viés de ancoragem), depois discutiram e agruparam. Na categoria “Técnico”: risco de performance do banco de dados com alto volume de dados, dependência de APIs de terceiros (4 integrações planejadas), vulnerabilidades de segurança em bibliotecas open-source. Na categoria “Equipe”: Marcus Webb tentado por outras ofertas (alocação parcial facilita), Julia Chen sobrecarregada com outro projeto, Bruno Silva indisponível no mês 6 (férias).
2. Análise de premissas: A premissa “A API do gateway de pagamento manterá compatibilidade com a versão atual por 12 meses” gerou o risco: “Dado que o gateway de pagamento já anunciou depreciação de v2 para dezembro/2026, pode ocorrer necessidade de migração para v3 no mês 10, o que resultaria em 2 sprints de retrabalho (120 horas).”
3. Checklist de projetos SaaS: Eduardo usou um checklist de riscos comuns em projetos SaaS (baseado em lições aprendidas de startups): compliance com LGPD, escalabilidade de infraestrutura, disponibilidade (SLA 99.5%), segurança de dados, vendor lock-in em cloud, e churn rate pós-lançamento. Três riscos adicionais foram identificados via checklist que o brainstorming não captou.
4. Oportunidades: Henry Douglas identificou: “Se lançarmos o módulo de templates PMBOK 8 antes da concorrência, podemos capturar 15% do mercado early-adopter.” Eduardo identificou: “Se fecharmos parceria com uma certificadora PMP, podemos oferecer PDUs integrados — diferencial competitivo significativo.”
5. Registro final: 34 riscos identificados: 26 ameaças + 8 oportunidades. Top 3 por impacto potencial: saída de Marcus Webb, vulnerabilidade de segurança, e depreciação da API de pagamento.

Resultado: A identificação da depreciação da API de pagamento permitiu que Henry iniciasse a migração para v3 no sprint 8 — proativamente, em paralelo com desenvolvimento normal. Se descoberto no mês 10 (quando a depreciação seria anunciada publicamente), o impacto seria de 2 sprints completos perdidos.

7. Atalhos, Templates e Dicas

Templates recomendados

• Template de Registro dos Riscos: Planilha com colunas: ID, descrição (causa-evento-impacto), categoria, tipo (ameaça/oportunidade), probabilidade, impacto, score P×I, risk owner, resposta planejada, status, data de identificação, última revisão.
• Template de Relatório de Riscos: Dashboard com: total de riscos por categoria, distribuição ameaças/oportunidades, top 10 riscos por score, tendência (riscos novos, fechados, materializados), nível de risco geral.

Dicas avançadas

• Use o formato metalinguístico: “Dado que [causa], pode ocorrer [evento], o que resultaria em [impacto].” Esse formato força clareza — um risco vago como “problemas com o fornecedor” vira “Dado que o fornecedor tem histórico de atrasos em períodos de alta demanda, pode ocorrer atraso de 3-4 semanas na entrega do equipamento X, o que resultaria em atraso do marco de integração e custo adicional de R$ 15.000 em stand-by da equipe.”
• Entreviste stakeholders seniores individualmente: Riscos políticos, estratégicos e financeiros raramente aparecem em brainstormings coletivos. Entrevistas individuais com o CEO, CFO e diretores revelam riscos que ninguém mais conhece ou ousaria mencionar em público.
• Revise o registro de premissas linha por linha: Cada premissa é um risco potencial. “Premissa: a equipe de TI terá 2 desenvolvedores disponíveis em maio” → Risco: “E se não tiver?”
• Não se limite a ameaças: Reserve pelo menos 20% da sessão de identificação para oportunidades. Projetos que só gerenciam ameaças perdem chances de entregar mais valor.
• Use checklists como complemento, não como substituição: Checklists capturam riscos recorrentes, mas não capturam riscos únicos do seu projeto. Use checklists depois do brainstorming, não em vez dele.

8. Erros Comuns e Como Evitá-los

Erro 1 — Identificar riscos apenas uma vez, no início

Por que acontece: A equipe faz uma sessão de identificação no planejamento e nunca mais revisita.

Como evitar: A identificação é contínua. Inclua “novos riscos” como pauta fixa na reunião semanal de status. A cada sprint review ou gate review, conduza uma mini-sessão de identificação de 15-20 minutos.

Erro 2 — Registrar riscos vagos

Por que acontece: Riscos como “problemas técnicos” ou “atrasos” são registrados sem especificidade. São tão genéricos que não podem ser analisados nem tratados.

Como evitar: Use o formato metalinguístico: causa + evento + impacto. Se não é possível especificar, o “risco” provavelmente é uma categoria inteira que precisa ser decomposta em riscos específicos.

Erro 3 — Não identificar oportunidades

Por que acontece: A cultura de “gestão de riscos = evitar problemas” faz com que a equipe foque exclusivamente em ameaças.

Como evitar: Reserve uma rodada específica da sessão de identificação para oportunidades: “O que pode dar certo que não estamos esperando? Que eventos positivos podemos explorar?” Exemplos: fornecedor oferece desconto, tecnologia nova simplifica o trabalho, regulamentação favorável entra em vigor.

Erro 4 — Limitar a identificação à equipe técnica

Por que acontece: Apenas a equipe de projeto participa da identificação. Stakeholders, patrocinadores, usuários e fornecedores são excluídos.

Como evitar: Inclua stakeholders-chave e especialistas externos. Cada perspectiva revela riscos diferentes. O patrocinador vê riscos estratégicos e financeiros; o fornecedor vê riscos de supply chain; o usuário vê riscos de adoção.

Erro 5 — Não designar risk owners

Por que acontece: Riscos são identificados e registrados, mas ninguém é responsável por monitorá-los.

Como evitar: Todo risco deve ter um risk owner. Se ninguém é responsável, ninguém monitora. “Risco de todos” é risco de ninguém.

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

Ambiente Preditivo

• Sessão formal de identificação no planejamento + revisões em cada gate review
• Registro dos Riscos como documento formal mantido pelo GP
• Entrevistas com stakeholders e especialistas externos
• Checklists setoriais e análise SWOT completa

Ambiente Ágil

• Riscos identificados continuamente em sprint planning e retrospectivas
• Riscos como itens do backlog (impedimentos potenciais)
• Equipe coletivamente responsável pela identificação
• Board visual de riscos (information radiator)

Ambiente Híbrido

• Identificação formal para riscos estratégicos (por fase)
• Identificação contínua para riscos operacionais (por sprint)
• Registro integrado com visões diferentes para cada público

Aspecto	Preditivo	Ágil	Híbrido
Sessão principal	No planejamento	Sprint a sprint	Planejamento + sprint a sprint
Participantes	Equipe + stakeholders + especialistas	Equipe ágil completa	Misto conforme o tipo de risco
Documento	Registro formal	Backlog / board visual	Registro formal + backlog

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

Processos que alimentam a identificação de riscos

Processo	Domínio	O que fornece
Planejar o Gerenciamento dos Riscos (Processo 35)	Riscos	RBS, escalas, metodologia, papéis
Todos os processos de planejamento	Todos os domínios	Premissas, restrições, estimativas — fontes de riscos
Iniciar Projeto ou Fase	Governança	Riscos iniciais de alto nível e registro de premissas

Processos que dependem da identificação

Processo	Domínio	O que recebe
Realizar Análise de Riscos (Processo 37)	Riscos	Registro dos Riscos — os riscos a serem analisados
Planejar Respostas (Processo 38)	Riscos	Riscos priorizados que exigem respostas
Monitorar os Riscos (Processo 40)	Riscos	Registro e relatório de riscos como baseline de monitoramento

Interações com os Domínios

Todos os domínios: Riscos podem surgir de qualquer área — escopo (requisitos instáveis), cronograma (estimativas incertas), recursos (indisponibilidade), partes interessadas (mudança de expectativas), finanças (custos variáveis).

Governança: O registro de premissas (saída da iniciação) é uma das entradas mais ricas para identificação de riscos. Cada premissa não confirmada é um risco.

11. Checklist de Aplicação Rápida

1. Foi conduzida uma sessão estruturada de identificação com a equipe, stakeholders-chave e especialistas?
2. Todas as premissas e restrições foram revisadas como fontes de riscos potenciais?
3. Os riscos estão documentados no formato metalinguístico (causa + evento + impacto)?
4. Oportunidades foram identificadas (não apenas ameaças)?
5. Cada risco tem um risk owner designado?
6. O Relatório de Riscos foi elaborado com visão consolidada (total, categorias, tendências)?
7. A identificação contínua está planejada (pauta fixa em reuniões, canal para reportar novos riscos)?

Regra prática: Se menos de 5 destes itens foram atendidos, a identificação de riscos está incompleta. Comece pela revisão sistemática do registro de premissas — é a fonte mais rápida e confiável de riscos específicos do projeto.

12. Faça agora com IA: o Processo 17 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 17 de 40.

O que este processo lê do seu quadro

• a lista Riscos e Premissas

O que ele entrega

• Registro dos riscos
• Relatório de Riscos

Como rodar

1. Responda no seu quadro do projeto (ProjectAdm).
2. Rode o processo 17 — 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 dos riscos
• Relatório de Riscos

Conclusão

Identificar os Riscos é o processo que transforma incertezas vagas em riscos documentados que podem ser analisados, priorizados e tratados. Sem ele, a gestão de riscos não começa.

Os três pontos essenciais:

• A identificação é contínua, não pontual. Novos riscos surgem ao longo de todo o projeto. Uma sessão no início não é suficiente — inclua “novos riscos” como pauta fixa em cada reunião de status.
• Use o formato metalinguístico: causa + evento + impacto. “Problemas com o fornecedor” não é um risco — é uma preocupação vaga. “Dado que o fornecedor tem histórico de atrasos em alta demanda, pode ocorrer atraso de 3 semanas na entrega do servidor, o que resultaria em atraso do marco de integração” é um risco que pode ser analisado e tratado.
• Entreviste stakeholders seniores individualmente. Os riscos mais impactantes (estratégicos, financeiros, políticos) raramente aparecem em brainstormings coletivos. Entrevistas individuais revelam o que ninguém mencionaria em público.

Próximo passo concreto: Abra o registro de premissas do seu projeto. Para cada premissa, pergunte: “E se isso não for verdade?” Cada resposta é um risco que provavelmente não está no seu registro de riscos. Documente agora.

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.