Na reunião semanal, alguém diz: "temos um risco sério, o fornecedor atrasou a entrega". A frase parece correta, mas mistura duas coisas. Se o fornecedor já atrasou, não é risco, é problema, e pede uma ação de solução hoje. O risco seria o que esse atraso ainda pode provocar, como perder a janela de instalação do mês que vem. Entender a diferença entre risco e problema muda o que se faz com cada item, quem cuida dele e em que lista ele fica.
A confusão é comum porque os dois aparecem nas mesmas reuniões e, muitas vezes, no mesmo quadro. O resultado é um registro de riscos cheio de coisas que já aconteceram e uma lista de pendências cheia de coisas que talvez aconteçam. A seguir estão a diferença, um teste rápido para classificar, o caminho do risco que se concretiza e como montar o registro de problemas.
Formação relacionada
Gestão de Projetos 360° com PMBOK 8 e IA
Formação completa sobre o guia mais recente do PMI, com uso de inteligência artificial no dia a dia da gestão.
Diferença entre risco e problema: as definições
O PMBOK, guia do Project Management Institute (PMI), define risco como um evento ou condição incerta que, se ocorrer, tem efeito positivo ou negativo sobre um ou mais objetivos do projeto. Problema, que o guia chama de issue, é uma condição ou situação atual que pode afetar os objetivos do projeto. A palavra que separa os dois é tempo: risco está no futuro e é incerto; problema está no presente e já existe.
| Risco | Problema (issue) | |
|---|---|---|
| Quando | Ainda pode acontecer | Já está acontecendo |
| Certeza | Incerto, tem probabilidade | Certo, probabilidade de 100% |
| Pode ser positivo? | Sim, as oportunidades também são riscos | Não; um ganho que já aconteceu não é tratado como problema |
| Pergunta que responde | E se acontecer? | O que fazemos agora? |
| Ação típica | Prevenir, preparar, reservar | Resolver, contornar, decidir |
| Documento | Registro de riscos | Registro de problemas (issue log) |
| Quem acompanha | Dono do risco | Responsável pela solução |
Na gestão de riscos, toda a atenção está em agir antes, o que é explicado no guia de gestão de riscos em projetos. Na gestão de problemas, a atenção está em resolver rápido e evitar que o efeito se espalhe.
Um teste rápido para classificar
Faça três perguntas sobre o item:
- Isto já aconteceu? Se sim, é problema.
- Existe chance real de não acontecer? Se não existe, é problema, mesmo que o efeito ainda esteja no futuro. Uma lei já publicada que entra em vigor em março não é risco: é um fato que o plano precisa absorver.
- Isto é um efeito genérico ou um evento específico? "Atraso no cronograma" é efeito, não risco. Reescreva no formato causa, evento e efeito antes de classificar.
Alguns exemplos, numa implantação de sistema:
| Item | Classificação | Por quê |
|---|---|---|
| O banco pode mudar o layout do arquivo de retorno antes da entrada em produção | Risco | Incerto, futuro |
| O banco mudou o layout e a conciliação parou | Problema | Já aconteceu |
| A analista fiscal entra de licença-maternidade em abril | Problema (ou premissa a corrigir no plano) | Certo, data conhecida |
| A substituta da analista fiscal pode não dominar as regras de exceção | Risco | Incerto, decorre do fato acima |
| A prefeitura pode liberar o alvará antes do previsto | Risco (oportunidade) | Incerto e positivo |
Repare na terceira e na quarta linhas: um fato certo (a licença) gera um risco (a substituta não dominar as regras). Isso acontece o tempo todo.
Quando o risco vira problema
Um risco que se concretiza muda de lista e de natureza. O caminho tem cinco passos:
- O gatilho dispara. O sinal combinado aparece. Se o projeto definiu bons gatilhos, isso acontece antes de o efeito se instalar. Como escrever gatilhos observáveis está em gatilho de risco.
- A contingência é acionada. Se o risco tinha plano de contingência, ele entra em execução, pago pela reserva de contingência.
- O problema é aberto. O item entra no registro de problemas com responsável, prazo e ação.
- O risco é encerrado. No registro de riscos, ele recebe a situação "ocorreu" e o motivo. Não apague: o histórico alimenta as lições aprendidas.
- Novos riscos são avaliados. O problema pode gerar riscos novos. A equipe pergunta: o que este problema ainda pode provocar?
Quando o risco que se concretizou era crítico, a resposta precisa de mais estrutura. O artigo sobre plano de ação para riscos críticos mostra como organizar.
E se aparecer um problema que nunca esteve no registro de riscos? Ele é tratado do mesmo jeito, mas vale uma pergunta na revisão: por que não foi identificado? Problemas recorrentes fora da lista indicam que a identificação precisa ser refeita, como mostra o artigo sobre monitoramento de riscos.
O registro de problemas
O registro de problemas é mais simples que o de riscos, porque não precisa de probabilidade. Os campos essenciais:
| Campo | Exemplo |
|---|---|
| ID | P07 |
| Descrição | O banco alterou o layout do arquivo de retorno e a conciliação automática parou desde 03/04 |
| Origem | Risco R12 (ocorreu) |
| Impacto | Conciliação manual de cerca de 300 lançamentos por dia; risco de atraso no fechamento |
| Prioridade | Alta |
| Responsável | Líder técnico |
| Ação | Ajustar o leitor do arquivo e reprocessar os dias pendentes |
| Prazo | 10/04 |
| Situação | Em andamento |
| Escalado para | Patrocinador informado em 03/04 |
A prioridade do problema costuma usar urgência e impacto, e não a matriz de probabilidade, já que a probabilidade é certa. Problemas que o gerente não consegue resolver vão ao patrocinador no status report, na seção de decisões.
Risco e problema em outros tipos de projeto
O mesmo par aparece em qualquer projeto. Alguns exemplos para treinar o olhar:
| Projeto | Risco | Problema |
|---|---|---|
| Obra | A chuva prevista para março pode interromper a concretagem | Choveu e a concretagem da laje foi suspensa por três dias |
| Evento | O palestrante principal pode cancelar por conflito de agenda | O palestrante cancelou a dez dias do evento |
| Lançamento de produto | A homologação do órgão regulador pode atrasar | O órgão pediu documentação complementar e o prazo de análise reiniciou |
| Projeto público | A licitação pode ser impugnada | A licitação foi impugnada e o certame está suspenso |
E no ágil?
Em times que usam Scrum, a mesma distinção aparece com outros nomes. O impedimento levantado na Daily Scrum é um problema: algo que já está atrapalhando o trabalho e precisa ser removido. O risco é o que pode comprometer a meta da Sprint ou o produto mais adiante, e costuma virar item do backlog, como uma investigação técnica ou um teste antecipado. Misturar os dois faz o time tratar impedimentos como "riscos para acompanhar", e eles ficam parados.
Por que separar as duas listas
- Os ritmos são diferentes. Problema pede acompanhamento diário ou semanal; risco pede revisão quinzenal e atenção aos gatilhos.
- As pessoas são diferentes. O dono do risco acompanha a causa e o gatilho, como explica o artigo sobre o dono do risco; o responsável pelo problema executa a solução.
- A matriz fica limpa. Problema no registro de riscos aparece com probabilidade 5 e distorce o mapa de calor, escondendo os riscos de verdade.
- O aprendizado fica claro. Cruzar as duas listas mostra quantos problemas estavam previstos, o melhor indicador da qualidade da gestão de riscos.
Separe as listas hoje
Abra o registro de riscos do projeto e aplique as três perguntas a cada linha. O que já aconteceu vai para uma lista de problemas com responsável e prazo; o que é efeito genérico é reescrito no formato causa, evento e efeito. Para levar riscos e problemas ao patrocinador num mesmo documento, use o gerador de status report da Projeto Diário, que tem blocos separados para riscos e problemas e para as decisões necessárias e gera o relatório em Word.
