A reunião de aprovação do lançamento vai bem. O plano foi revisado, o diretor gostou e o cronograma cabe no trimestre. Uma pessoa da equipe tem dúvidas sobre a integração, mas fica quieta: o projeto já parece decidido.
Seis meses depois, na análise do que deu errado, ela diz: “eu já desconfiava disso”. O pré-mortem leva essa conversa para antes do início, quando ainda dá para mudar o plano.
O que é a análise pré-mortem
O Premortem foi descrito por Gary Klein em um artigo de 2007 na Harvard Business Review. A analogia é com a medicina: uma autópsia explica por que o paciente morreu, mas chega tarde para ele. O pré-mortem acontece enquanto o projeto ainda pode ser salvo. Os participantes assumem que o projeto acabou de fracassar e geram razões plausíveis para isso (Klein, 2007).
Parece uma simples análise de riscos, mas muda a pergunta. “O que pode dar errado?” convida à defesa do plano. “Falhou, por quê?” pede uma explicação. Klein destaca o efeito social: a técnica torna seguro discordar para quem conhece bem o projeto e está preocupado com suas fraquezas.
| Técnica | Quando | Pergunta |
|---|---|---|
| Análise de risco | Antes | O que pode dar errado? |
| Pré-mortem | Antes | Falhou. Por quê? |
| Causa raiz | Depois | Por que falhou de fato? |
Na análise de causa raiz, investiga-se um problema observado, com evidências. No pré-mortem, levantam-se falhas plausíveis, e nenhuma delas é um fato.
Quando usar e quando evitar
Quando usar
- Lançamentos e migrações críticas
- Programas de IA e integrações entre sistemas
- Projetos com muitas dependências
- Quando o grupo parece concordar rápido demais
Quando evitar
- Projetos pequenos, baratos e reversíveis
- Quando o plano ainda não existe para ser analisado
- Quando nada mais pode mudar
- Em ambientes em que discordar é punido
Como conduzir
A sequência abaixo segue a descrição de Klein. Os tempos são uma sugestão, para uma sessão de pouco mais de uma hora:
- Convide quem executa. Inclua as pessoas que conhecem os detalhes, não só as que aprovam.
- Apresente o plano (10 min). Todos precisam partir da mesma versão.
- Anuncie o fracasso (2 min). “Estamos seis meses à frente. O projeto fracassou de forma espetacular.”
- Escreva em silêncio (10 min). Cada pessoa lista todos os motivos, sozinha, inclusive os que preferiria não dizer.
- Faça a rodada (20 min). Começando por quem lidera o projeto, cada pessoa lê um motivo por vez, até a lista acabar.
- Priorize (15 min). Separe o que merece ação do que merece apenas registro.
- Mude o plano (15 min). Defina ações, sinais e responsáveis. Se o plano não mudou, a sessão não terminou.
A escrita individual importa: ela evita que as primeiras opiniões, em geral as de quem tem mais poder, moldem a lista inteira. E a palavra “falhou” importa mais ainda, como mostram os estudos adiante.
Exemplo: o lançamento de um aplicativo
Uma rede de clínicas vai lançar um aplicativo de agendamento. A sessão parte da frase: “seis meses depois do lançamento, o aplicativo fracassou. Pouca gente usa, houve uma falha de segurança, o custo estourou, e quem instalou abandonou”. A lista gerou 31 motivos, que foram agrupados nestas causas:
| Causa | Impacto | Evidência |
|---|---|---|
| Agenda da clínica cai no pico | Alto | Forte |
| Vazamento de dados de saúde | Alto | Média |
| Cadastro longo faz desistir | Alto | Média |
| Recepção segue usando o telefone | Alto | Fraca |
| Custo de SMS acima do plano | Médio | Forte |
| Loja de aplicativos rejeita a versão | Baixo | Fraca |
A priorização leva em conta o impacto, a evidência e a capacidade de resposta:
- Agir antes de começar: impacto alto com evidência forte, ou dano grave. Entram a agenda no pico e o vazamento de dados.
- Testar: impacto alto com evidência incompleta. Entram o cadastro e a recepção.
- Registrar e acompanhar: o restante, com um sinal definido.
Cada risco prioritário vira um item do plano:
- Agenda cai no pico. Sinal: erros acima de 1% no teste de carga. Ação: testar com o dobro do pico esperado antes de lançar. Responsável: quem lidera a tecnologia. Contingência: o agendamento por telefone continua ativo por 90 dias.
- Vazamento de dados. Sinal: achados críticos na revisão de segurança. Ação: revisão externa antes do lançamento e dados mínimos no cadastro. Responsável: segurança.
- Cadastro longo. Sinal: menos de 60% concluem o cadastro no teste. Ação: testar com dez pacientes reais e cortar campos. Responsável: produto.
O plano mudou em três pontos, e isso é o que importa. A lista, sozinha, não reduz nenhum risco.
O que as evidências mostram
Os estudos sobre a técnica são poucos, e uma revisão resume bem: a literatura acadêmica é escassa (Collins, s.d.).
- A origem do número de 30%. Klein cita Mitchell, Russo & Pennington (1989) para dizer que imaginar um evento como já ocorrido melhora em 30% a capacidade de identificar corretamente as razões de resultados futuros. Segundo a revisão de Collins, o estudo mediu a quantidade de razões, não a qualidade. É um achado mais modesto do que a frase famosa sugere.
- O que parece pesar é a certeza. No primeiro experimento desse estudo, colocar o evento no passado ou no futuro teve pouca influência. O que mudou as explicações foi o evento ser certo ou incerto. Daí a importância de dizer “falhou”, e não “pode falhar”.
- Menos confiança. Veinott, Klein & Wiggins (2010) compararam formas de criticar um plano com 178 universitários. O pré-mortem reduziu mais a confiança no plano. Vale notar que os participantes eram estudantes, e que menos confiança não é o mesmo que uma decisão melhor.
- Riscos de mais qualidade. Gallop, Willy & Bischoff (2016) designaram 101 gestores e engenheiros experientes para grupos de brainstorming ou de pré-mortem. Os grupos de pré-mortem identificaram mais riscos de qualidade e propuseram mudanças melhores. A comparação foi com outra técnica, em um único caso histórico.
A conclusão prudente é que vale a pena fazer: é barato e tem algum apoio. Só não vale prometer mais do que os estudos sustentam.
Como usar uma LLM
Uma LLM pode ampliar a lista com modos de falha de outras áreas, como segurança e dados, e organizar o resultado em um registro de riscos. Faça a sessão humana primeiro, porque só quem está no projeto conhece as falhas específicas, e a lista do modelo pode ancorar o grupo.
Conduza um pré-mortem do projeto [projeto].Objetivo e critérios de sucesso: [descrever].Plano atual: [fases e dependências].Restrições e riscos já conhecidos: [descrever].
Imagine que, daqui a [prazo], o projeto falhou de maneira relevante.Liste causas plausíveis sob perspectivas de tecnologia, produto,usuários, segurança, dados, operações, pessoas e negócio.Para cada uma, proponha sinais precoces, ação preventiva, responsável,plano de contingência e teste que possa reduzir a incerteza.Diferencie modos de falha prováveis de possibilidades remotas.Saída esperada: registro de riscos com sinais de alerta e mitigação.
Antes de confiar na resposta:
- Compare com a lista humana. O valor está no que o modelo acrescenta, não no que repete.
- Corte o genérico. Se um risco serviria para qualquer projeto, ele ainda não é útil.
- Priorize com dados seus. Probabilidades citadas pelo modelo são palpites.
- Sanitize o contexto. Planos, fornecedores e falhas conhecidas de segurança não devem ir para ferramentas públicas.
Combine com outros frameworks
- 5 Porquês: investiga problemas que já aconteceram; o pré-mortem atua antes da execução.
- Planejamento de cenários: explora mudanças no ambiente; o pré-mortem assume que o plano falhou.
- Análise do campo de forças: mapeia as barreiras de uma mudança antes do início.
- Teste de hipótese: reduz a incerteza dos riscos que têm pouca evidência.
- Método do caminho crítico: mostra quais dependências podem atrasar o prazo.
Referências
- Collins, J. The premortem. Em Course notes on behavioural economics and corporate decision making, capítulo 30. Link
- Gallop, D., Willy, C. & Bischoff, J. (2016). How to catch a black swan: Measuring the benefits of the premortem technique for risk identification. Journal of Enterprise Transformation, 6(2), 87–106. DOI
- Klein, G. (2007). Performing a Project Premortem. Harvard Business Review, setembro. Link
- Mitchell, D. J., Russo, J. E. & Pennington, N. (1989). Back to the future: Temporal perspective in the explanation of events. Journal of Behavioral Decision Making, 2(1), 25–38. DOI
- Veinott, B., Klein, G. & Wiggins, S. (2010). Evaluating the effectiveness of the PreMortem technique on plan confidence. Proceedings of ISCRAM, Seattle.