¿Qué es un premortem?
Muchos proyectos fracasan de formas que alguien del equipo podía haber previsto.
La fecha límite se pasa porque una dependencia nunca se confirmó.
El lanzamiento se atasca porque nadie era dueño del paso de revisión.
Un premortem es una reunión sencilla diseñada para sacar a la luz esos problemas previsibles antes de que ocurran, y toma alrededor de una hora.
Entonces, ¿deberías hacer uno antes de iniciar un proyecto?
A menudo sí, especialmente cuando el proyecto tiene una fecha fija, varias personas involucradas o consecuencias reales si falla.
Esta guía explica qué es un premortem, cuándo vale la pena esa hora y cómo realizarlo con tu equipo.
Un premortem es una estrategia de gestión de proyectos donde el equipo piensa en lo que podría suceder en un proyecto, bueno o malo, y hace un plan antes de que empiece.
El nombre invierte la idea del postmortem, la revisión que los equipos hacen cuando un proyecto termina.
En lugar de preguntar qué salió mal después, lo preguntas por adelantado, cuando todavía puedes hacer algo al respecto.
El Team Playbook de Atlassian describe el ejercicio como una preparación para cada giro y vuelta.
Significa imaginar qué podría hacer que el proyecto pierda su fecha límite, y también qué podría mantenerlo a tiempo.
Ese enfoque de dos lados importa.
Un buen premortem no es una sesión de pesimismo.
Saca a la luz riesgos y fortalezas juntos, para que sepas qué proteger además de qué corregir.
El formato es deliberadamente ligero.
La versión de Atlassian necesita unos diez minutos de preparación, sesenta minutos de reunión y entre tres y once personas.
Puedes hacerlo en persona con una pizarra y notas adhesivas, o a distancia con un documento compartido y una videollamada.
Cuándo un premortem vale la hora
No todo proyecto necesita una sesión formal de riesgos.
Bocetar un proyecto individual en una servilleta probablemente no la necesita.
El ejercicio rinde frutos cuando la incertidumbre y los costos de coordinación son altos.
Considera hacer uno cuando:
- El proyecto tiene una fecha límite fija atada a algo fuera de tu control, como un evento, una ventana de lanzamiento o un compromiso con un cliente.
- Varias personas o equipos deben entregar piezas que dependen entre sí.
- Ya has fallado en proyectos similares y quieres evitar repetir el patrón.
- El equipo es nuevo trabajando junto y aún no conocen los puntos ciegos de cada uno.
- Partes interesadas fuera del equipo tienen supuestos que nadie ha dicho en voz alta.
Si ninguno de esos casos aplica, una conversación más corta puede ser suficiente.
El punto no es el ritual.
El punto es salir de la reunión con riesgos nombrados, fortalezas nombradas y acciones con responsables.
Premortem frente a reunión de arranque
La gente suele preguntar si un premortem reemplaza a una reunión de arranque o kickoff.
No lo hace.
Las dos reuniones responden preguntas distintas.
Un kickoff alinea al equipo sobre qué van a construir, quién hace qué y cuándo.
Un premortem pone a prueba ese plan preguntando qué podría romperlo y qué podría sostenerlo.
En la práctica funcionan bien juntos.
Haz primero el kickoff para que todos compartan la misma imagen del plan.
Luego haz el premortem contra ese plan, mientras todavía hay tiempo de cambiarlo.
Si solo puedes elegir uno para un proyecto pequeño y de bajo riesgo, el kickoff suele ir primero, porque un premortem necesita un plan concreto al cual reaccionar.
Si estás evaluando si un kickoff es necesario, ayuda ver la decisión planteada por separado.
Nuestra guía sobre si necesitas una reunión de arranque de proyecto recorre esa elección antes de empezar.
Cómo hacer un premortem, paso a paso
Las instrucciones publicadas por Atlassian dividen la hora en segmentos cortos y cronometrados.
Aquí está el flujo, con los tiempos que ellos documentan.
1. Prepara el tablero (unos cinco minutos)
Configura un espacio compartido antes de la reunión.
Para equipos remotos, es un documento de colaboración como un tablero de Trello o una página de Confluence.
Para equipos presenciales, funciona una pizarra o una hoja grande de papel con notas adhesivas y marcadores.
Agrega columnas con preguntas como:
- ¿Qué podría hacer que perdamos nuestra fecha límite?
- ¿Qué mantendrá nuestro proyecto a tiempo?
- ¿Qué necesita este proyecto que no tenemos?
- ¿Qué ya tenemos que este proyecto necesita?
- ¿Qué lecciones has aprendido de proyectos pasados?
- ¿Qué te preocupa? ¿Qué te entusiasma?
Puedes personalizar las preguntas.
Atlassian sugiere preguntas creativas, como preguntar qué quita el sueño a un rol específico.
También recomienda agregar estimaciones de costo o tiempo a los riesgos donde tengas esos datos cuantitativos.
2. Prepara el terreno (unos cinco minutos)
Abre la reunión pidiendo al equipo que considere qué podría salir mal en este proyecto, y qué podría salir bien.
Mantén la discusión enfocada solo en este proyecto.
Ese alcance mantiene la conversación concreta en lugar de derivar en quejas generales.
3. Lluvia de ideas en silencio (unos diez minutos)
Da a todos diez minutos para escribir respuestas en el documento compartido o en notas adhesivas bajo cada pregunta.
La escritura silenciosa importa.
Evita que la voz más fuerte fije la agenda y permite que los miembros más callados saquen a la luz riesgos que otros no habían pensado.
4. Agrupa ideas similares (unos cinco minutos)
Trabajen juntos para fusionar ideas similares en listas.
Diez notas adhesivas que describen la misma dependencia faltante son en realidad un solo riesgo, y agrupar lo hace visible.
5. Voten las amenazas (unos cinco minutos)
Pide a los asistentes votar por los elementos que representan la mayor amenaza para el proyecto.
Atlassian da a cada persona tres votos, que pueden repartir entre tarjetas o acumular en una.
Los equipos presenciales pueden usar puntos sobre las notas adhesivas.
6. Voten las fortalezas (unos cinco minutos)
Repite la votación para los elementos que van bien en el proyecto, las claves del éxito.
Esta es la mitad del ejercicio que los equipos omiten, y es un error omitirla.
Saber qué está sosteniendo el proyecto te dice qué proteger cuando aparezcan compensaciones más adelante.
7. Discutan los elementos principales (unos veinticinco minutos)
Mueve los tres temas con más votos a una columna de discusión.
Empezando por arriba, pon un temporizador de diez minutos por tarjeta y define al menos una acción para mitigar cada riesgo.
Atlassian sugiere preguntar cómo se ve lo opuesto del riesgo, imaginar el éxito y planear hacia él.
Asigna un responsable y una fecha límite a cada acción, porque las acciones con dueño tienen muchas más probabilidades de completarse.
8. Recapitula y comprométanse (unos cinco minutos)
Cierra recapitulando las acciones a las que el equipo se compromete, cada una con responsable y fecha límite.
Luego maneja el seguimiento: guarda la discusión y las acciones en un lugar donde el equipo y las partes interesadas puedan encontrarlas.
Agrega las acciones a tu tablero de proyecto para seguir su avance, y revisa el documento periódicamente para que los riesgos sigan visibles mientras el proyecto avanza.
Un ejemplo trabajado de una tarjeta de discusión
Para hacer concreto el resultado, aquí hay un escenario ilustrativo de lo que puede producir un riesgo discutido.
Supongamos que un equipo pequeño planea una reconstrucción de sitio web con un calendario fijo.
Durante la votación, la tarjeta 'el contenido del cliente llega tarde' gana la mayoría de los votos de amenaza.
En la discusión de diez minutos, el equipo pregunta cómo se ve lo opuesto: contenido que llega lo bastante temprano para diseñar alrededor de él.
La acción es pedir al cliente un borrador del contenido al inicio del calendario.
El líder del proyecto es el responsable, con un seguimiento al final de ese primer tramo.
Ese es un cambio pequeño y barato al plan, hecho antes de que el calendario quedara fijo.
Es un ejemplo ilustrativo, no un resultado reportado por un cliente, pero muestra la forma de un buen resultado: un riesgo nombrado, una acción con dueño, una fecha.
Errores comunes que conviene evitar
- Omitir la votación de fortalezas. Solo los riesgos te dejan a la defensiva; las fortalezas te dicen qué proteger.
- Generar riesgos sin acciones. Una lista de preocupaciones no cambia nada. Cada tarjeta discutida necesita al menos una acción con responsable.
- Dejar que una persona domine. La lluvia de ideas silenciosa y la votación existen precisamente para evitarlo.
- Hacerlo demasiado tarde. Un premortem funciona mientras el plan aún puede cambiar. Después de que los compromisos están cerrados, tiende a volverse una sesión de quejas en lugar de una herramienta de planeación.
- Nunca revisar el documento. Los riesgos evolucionan. Atlassian recomienda revisiones periódicas para que el equipo siga consciente de ellos.
Variantes para equipos pequeños y distribuidos
No necesitas un equipo grande ni una hora sincrónica.
Atlassian documenta dos variantes que vale la pena conocer.
Para equipos distribuidos en distintas zonas horarias, envía el documento con una fecha límite.
Así la gente puede responder de forma asincrónica, marcar temas para discutir e inscribirse en tareas.
Para equipos Scrum, una versión condensada puede ejecutarse durante la planeación del sprint.
Así todo lo que pudiera impedir el sprint se discute antes de hacer los compromisos.
Fundadores solos y freelancers pueden adaptar la misma lógica.
Responde tú mismo las preguntas del tablero, luego pide a una persona externa, un colega o mentor, que agregue sus respuestas antes de decidir qué actuar.
El valor viene de la mirada externa, no del número de personas.
Dónde encajan los premortems con otras planificaciones tempranas
Un premortem es una de varias verificaciones baratas que vale la pena hacer antes de que empiece el trabajo.
Se combina naturalmente con mapear las dependencias de las que tu proyecto depende.
Las dependencias ocultas están entre los riesgos más comunes que un premortem saca a la luz.
Nuestra guía sobre mapear dependencias antes de iniciar un proyecto cubre eso en detalle.
También se combina con aclarar quién es dueño de qué.
Muchos riesgos votados resultan ser brechas de propiedad disfrazadas, donde todos asumían que alguien más estaba manejando una tarea.
La guía sobre mapear roles y responsabilidades antes de un proyecto ayuda a cerrar esa brecha.
Y como una de las preguntas estándar del tablero pregunta qué lecciones has aprendido de proyectos pasados, vale la pena revisar esas lecciones antes de la reunión.
Nuestro artículo sobre analizar proyectos pasados antes de iniciar uno nuevo muestra cómo extraerlas.
La decisión, en resumen
Haz un premortem cuando el proyecto tiene apuestas reales, dependencias compartidas o un historial de fracasos similares, y cuando el plan aún puede cambiar.
Omite, o reduce a una conversación corta, cuando el trabajo es pequeño, individual y fácil de deshacer.
Si haces uno, sigue el flujo documentado: prepara el tablero de preguntas, haz lluvia de ideas en silencio y vota amenazas y fortalezas.
Discute los tres principales con temporizadores, y sal con acciones con responsable y fecha.
En nuestra opinión, una hora de imaginación honesta antes de que empiece el trabajo es una forma de bajo costo de detectar problemas mientras aún son baratos de corregir.
En nuestra opinión, un premortem no previene todos los fracasos. Previene los fracasos que alguien ya veía venir y nadie dijo en voz alta.
Referencias de fuente: www.atlassian.com.
Da el siguiente paso con Ideoreto.
Usa las ideas de esta guía como punto de partida para tu próximo proyecto.
Regístrate en Ideoreto para empezar.