Casi todos los equipos hacen un post-mortem cuando un proyecto sale mal. Muchos menos hacen la reunión que podría haberlo salvado: un pre-mortem, antes de empezar a trabajar. Son dos caras de la misma moneda. El pre-mortem imagina que el proyecto ya ha fracasado y se pregunta por qué. El post-mortem mira un proyecto que ya ha terminado y se pregunta qué pasó de verdad.
En esta guía verás los dos: qué es cada uno, cómo se hace y las veinte preguntas que usamos en ambos. Que las preguntas sean las mismas al principio y al final es la clave. Cuando el proyecto termina, puedes ver qué problemas viste venir, cuáles viste venir y te pasaron igualmente, y cuáles no se le ocurrieron a nadie.
Pre-mortem y post-mortem, de un vistazo
| Pre‑mortem | Post‑mortem | |
|---|---|---|
| Cuándo | Con el plan ya escrito, antes de empezar a trabajar | Después de entregar, o tras un hito o un incidente importante |
| Punto de partida | “Ha pasado un mes desde la fecha límite y el proyecto ha fracasado.” | El proyecto tal y como fue en realidad |
| La pregunta | ¿Por qué fracasó? | ¿Qué pasó y por qué? |
| Quién participa | Quienes van a hacer el trabajo y quien es responsable del plan | El equipo y las personas que vivieron el resultado |
| Qué obtienes | Una lista de riesgos ordenada y cambios en el plan | Lecciones y acciones para el próximo proyecto |
| Cuánto dura | Una hora, más o menos | De una a dos horas, más el tiempo de reunir los datos |
¿Qué es un pre-mortem?
Un pre-mortem es una reunión de planificación en la que el equipo da por hecho que el proyecto ya ha fracasado y averigua por qué. Lo describió el psicólogo Gary Klein en “Performing a Project Premortem”, en el número de septiembre de 2007 de Harvard Business Review.
El truco está en cómo se plantea. Si preguntas “¿qué podría salir mal?”, te llevas un par de reparos educados, porque nadie quiere parecer negativo con un plan que el equipo acaba de aprobar. Si dices “ha fracasado, dime por qué”, encontrar problemas pasa a ser el objetivo, y quienes tenían dudas por fin tienen un motivo para decirlas. Klein cita un estudio de 1989 de Deborah Mitchell, Jay Russo y Nancy Pennington: imaginar que algo ya ha ocurrido, lo que llamaron prospective hindsight (retrospectiva prospectiva), aumenta un 30% la capacidad de identificar correctamente los motivos de lo que pasará.
Cómo hacer un pre-mortem
- Elige el momento. Hazlo cuando el plan ya esté escrito pero antes de empezar a trabajar: lo bastante tarde para tener algo concreto que revisar y lo bastante pronto para poder cambiarlo.
- Invita a quienes van a hacer el trabajo. Saben dónde flojea el plan. Si un cliente u otro departamento puede hundir el proyecto, trae también a alguien que los conozca bien.
- Plantea la escena. Pon una fecha posterior a la entrega y describe el fracaso sin rodeos: “Es marzo. La nueva web salió con seis semanas de retraso y por encima del presupuesto, y el cliente está hablando con otras agencias.”
- Primero, cada uno por su cuenta. Da cinco minutos para que cada persona apunte, en silencio, todos los motivos que se le ocurran. Escribir antes de hablar evita que la primera voz, o la de más rango, marque el rumbo.
- Haz una ronda. Cada persona lee un motivo cada vez, hasta que todos estén en la lista común. Todavía no se discute nada; solo se apunta.
- Prioriza. Entre todos, marcad los motivos que son a la vez probables y graves. La mayoría de los equipos se quedan con tres a cinco que merece la pena atajar.
- Cambia el plan. Cada riesgo elegido se convierte en un cambio con responsable y fecha: una fecha límite más temprana para los textos, una segunda persona que apruebe, una reunión de seguimiento con el cliente. Guarda la lista donde vuelvas a verla en cada hito.
¿Qué es un post-mortem?
Un post-mortem es una revisión que se hace cuando termina un proyecto, para entender qué pasó y qué cambiar la próxima vez. Según el equipo, también se llama retrospectiva, sesión de lecciones aprendidas o revisión posterior a la acción. No es solo para los fracasos: un proyecto que salió bien también deja lecciones, y de esas es más fácil hablar.
Lo que hace que un post-mortem funcione es que no busca culpables. El libro de Site Reliability Engineering de Google, que trata los post-mortems como una práctica central, dice que para no buscar culpables de verdad un post-mortem debe centrarse en identificar las causas que contribuyeron al incidente, sin acusar a ninguna persona ni a ningún equipo. También recuerda que esta cultura nació en la sanidad y la aviación, donde un error puede ser mortal. Si la gente espera que la culpen, defiende sus decisiones en lugar de explicarlas, y la reunión no aprende nada.
Cómo hacer un post-mortem
- Hazlo pronto. En la semana o las dos semanas siguientes a la entrega, mientras la gente aún recuerda por qué tomó las decisiones que tomó.
- Reúne los datos antes. Prepara la cronología antes de la reunión: fechas previstas frente a fechas reales, presupuesto frente a gasto y las decisiones que cambiaron el rumbo. Si el proyecto se llevó en Redbooth, sus listas de tareas, fechas de entrega y comentarios ya recogen buena parte de esa historia.
- Empieza por la regla de oro. Di en voz alta que el objetivo es arreglar el proceso, no averiguar de quién fue la culpa.
- Repasa primero la lista del pre-mortem. Qué riesgos evitasteis, cuáles pasaron igualmente y qué no previó nadie. Esa comparación es la medida más honesta de lo bien que planifica el equipo.
- Recorre las cuatro categorías de abajo, tanto lo que salió bien como lo que no.
- Termina con acciones, no con observaciones. Cada una tiene un responsable y un sitio donde el próximo proyecto la vaya a encontrar, como su plan o su pre-mortem.
Las 20 preguntas para las dos reuniones
Agrupamos las preguntas en cuatro categorías: planificación, ejecución, resultados y comunicación. Son las mismas en las dos reuniones; solo cambia el tiempo verbal. En el pre-mortem preguntas por qué no conseguiréis el objetivo principal, y en el post-mortem, por qué no lo conseguisteis.
Planificación
- Plan del proyecto: ¿Qué le falta al plan? ¿Qué partes son imprecisas?
- Recursos: ¿Hemos calculado y repartido bien las personas, el presupuesto y las herramientas?
- Plazos: ¿Las fechas límite son realistas y están ligadas a objetivos concretos? ¿Hay margen para retrasos inesperados?
- Tareas: ¿Están planificadas todas las tareas necesarias, con sus dependencias y entregables bien definidos?
- Documentación: ¿Documentamos lo bastante bien las decisiones y el trabajo?
Ejecución
- Retrasos: ¿Cómo podemos gestionar mejor los retrasos inesperados?
- Flujo de trabajo: ¿Dónde se atasca el trabajo al pasar de una persona a otra?
- Personas: ¿Cómo dejamos claros los papeles y las responsabilidades, y los mantenemos?
- Tareas: ¿Qué hace que las tareas cuesten de sacar adelante en el día a día?
- Dirección: ¿En qué entorpece la dirección el trabajo?
Resultados
- Objetivo principal: ¿Por qué no conseguiremos (no conseguimos) el objetivo principal?
- Objetivos secundarios: ¿Por qué no conseguiremos (no conseguimos) los demás?
- Calidad: ¿En qué se quedará (se quedó) corto el trabajo respecto a la calidad prometida?
- Resultados externos: ¿Por qué está descontento el cliente? ¿Qué falla en cómo medimos el éxito con él?
- Resultados internos: ¿Qué falla en cómo medimos el éxito dentro del equipo?
Comunicación
- Canales: ¿Qué inconvenientes tienen las vías principales por las que nos comunicamos?
- Equipo: ¿Qué dificultades tendrán (tuvieron) los miembros del equipo para comunicarse?
- Responsables: ¿Qué dificultades tendrán (tuvieron) los responsables para comunicarse?
- Reuniones: ¿Qué falla en cómo hacemos las reuniones?
- Partes interesadas: ¿Dónde se romperá (se rompió) la comunicación con clientes y otras partes interesadas?
Responde con hechos, no con veredictos. “El plan era malo” no ayuda a nadie. “El plan no dejaba tiempo para la revisión legal del cliente, que tardó nueve días” sí.
Ejemplo: el relanzamiento de una web, antes y después
Así encajan las dos reuniones en un proyecto inventado: un equipo de marketing que relanza la web de su empresa y tiene ocho semanas para hacerlo.
El pre-mortem. En el arranque, el equipo imagina que es el día del lanzamiento y la nueva web no está publicada. Entre los motivos que apuntan:
- Las páginas de producto esperaban textos de tres departamentos, y llegaron tarde.
- Legal revisó la nueva página de privacidad en la última semana y pidió cambios.
- Nadie se encargaba de las redirecciones de las URLs antiguas, y el tráfico desde buscadores cayó tras el lanzamiento.
- El CEO vio el diseño por primera vez en la semana 7.
Cada uno entra en el plan como una tarea con responsable: los textos, listos dos semanas antes del cierre; la revisión legal, reservada para la semana 4; un mapa de redirecciones para la persona de desarrollo, y una revisión del diseño de quince minutos con el CEO en la semana 2.
El post-mortem. La web sale con una semana de retraso. Al repasar primero la lista del pre-mortem, el equipo ve que:
- Se evitó: las redirecciones estaban listas el día del lanzamiento, la revisión legal cupo en la semana 4 y los comentarios del CEO llegaron a tiempo para aplicarlos.
- Se previó, pero pasó igualmente: los textos de un departamento llegaron tarde de todos modos, porque su responsable estaba de vacaciones y nadie la sustituía.
- No lo previó nadie: las licencias de las fotos de la nueva portada no se aprobaron hasta la semana del lanzamiento.
Las acciones salen solas: cada entregable tendrá un suplente, y “recursos y licencias” será un punto fijo del próximo pre-mortem.
Haz los dos en Redbooth con la plantilla gratuita
Nuestra plantilla Project Post-mortem Analysis lleva estas veinte preguntas a un espacio de trabajo de Redbooth: una lista de tareas por categoría y una tarea por pregunta. La plantilla está en inglés.
Una forma de usarla a lo largo del proyecto:
- En el arranque, abre la plantilla, haz clic en Create Workspace y haz el pre-mortem en el nuevo espacio de trabajo. Necesitas haber iniciado sesión en Redbooth; si aún no tienes cuenta, créala antes. Apunta cada motivo como subtarea de la pregunta a la que responde, y lleva los riesgos que decidáis atajar al espacio de trabajo del proyecto como tareas con responsable y fecha de entrega.
- Durante el proyecto, conserva el espacio de trabajo. Un vistazo en cada hito te dice si los riesgos más importantes siguen bajo control.
- Al final, vuelve a abrirlo para el post-mortem. Junto a cada respuesta del pre-mortem, añade lo que pasó de verdad y, después, las acciones para el próximo proyecto.
Como el espacio de trabajo se queda, el pre-mortem del siguiente proyecto puede empezar con las lecciones del anterior en lugar de con una página en blanco.
Errores que dejan las dos reuniones en nada
- Hacer el pre-mortem con el plan ya cerrado. Si no se puede cambiar nada, la gente deja de señalar problemas.
- Dejar que hable primero quien tiene más rango. Los demás ajustan su lista a la suya. Primero, cada uno por su cuenta.
- Buscar culpables. El siguiente post-mortem será más corto, más diplomático y más vacío.
- Acciones sin responsable. “Tenemos que comunicarnos mejor” no es una acción.
- No volver a leer el último post-mortem. Unas lecciones que nadie lee en el siguiente arranque no son lecciones. Pon el último post-mortem como primer punto del orden del día del siguiente pre-mortem.
Preguntas frecuentes
¿Un pre-mortem es lo mismo que un análisis de riesgos?
No, aunque lo alimenta. Un registro de riesgos recoge y sigue los riesgos conocidos durante todo el proyecto. Un pre-mortem es una sola reunión pensada para sacar a la luz los riesgos que nadie ha escrito todavía, sobre todo los que a la gente le cuesta mencionar. Lo que salga puede pasar después al registro.
¿En qué se diferencia un post-mortem de una retrospectiva?
Sobre todo en el alcance. Los equipos ágiles hacen una retrospectiva al final de cada sprint, para ajustar su forma de trabajar sobre la marcha. Un post-mortem repasa un proyecto entero, o un incidente concreto, cuando ya ha terminado. Las preguntas se parecen.
¿Cuánto debe durar cada reunión?
Para la mayoría de los pre-mortems basta con una hora. Un post-mortem suele necesitar entre una y dos horas, más el tiempo de preparar la cronología.
¿Hay que hacer un post-mortem cuando el proyecto sale bien?
Sí. Un éxito también tiene causas, y saber cuáles puedes repetir es tan útil como saber qué evitar. Además, es la forma más fácil de que los post-mortems se conviertan en costumbre y no en castigo.
Empieza por el próximo proyecto de tu lista: reserva una hora antes del arranque y copia la plantilla en un espacio de trabajo para guardar las respuestas.