Cómo facilitar un taller premortem

Los balances de proyecto descubren una y otra vez lo mismo: las señales de alarma estaban ahí desde el principio, y alguien no se sintió seguro para decirlas en voz alta. Un premortem consigue que esas advertencias se digan mientras todavía hay tiempo para actuar.

El método es sencillo de explicar y difícil de facilitar bien. Esta guía explica por qué funciona, cómo reunir al grupo adecuado, una agenda en cinco fases que puedes completar en 90 minutos y cómo asegurarte de que los resultados sigan importando el lunes siguiente, algo que la mayoría de las guías omite.

Qué es un premortem y por qué importa el mecanismo cognitivo

El psicólogo investigador Gary Klein desarrolló el premortem y lo presentó a un público directivo amplio en Harvard Business Review en 2007. Le da la vuelta al post mortem. Antes de que arranque el proyecto, pides al equipo que imagine que ya ha fracasado estrepitosamente y que, desde ahí, trabaje hacia atrás para explicar por qué.

El cambio de enfoque funciona gracias a un efecto cognitivo llamado retrospectiva prospectiva. A las personas se les da bastante mejor explicar hechos pasados que predecir los futuros, porque tratan el pasado como algo fijo y buscan las causas con más empeño. El artículo de Klein en HBR cita una investigación de 1989 de Deborah Mitchell, Jay Russo y Nancy Pennington que concluyó que la retrospectiva prospectiva, es decir, imaginar que un hecho ya ha ocurrido, aumenta en un 30% la capacidad de identificar correctamente las razones de resultados futuros.

El segundo mecanismo es social. En las reuniones de planificación habituales, sobre todo cuando un líder sénior se muestra muy implicado en el plan, la gente se guarda sus dudas para no parecer desleal u obstruccionista. En un premortem, el pesimismo es la tarea. Plantear preocupaciones es precisamente lo que el grupo ha venido a producir.

El sesgo optimista, la costumbre de subestimar costes y plazos, es un problema conocido en la planificación de proyectos, y un premortem lo contrarresta mediante la estructura de la sesión.

Imagina a un equipo de producto que hace un premortem antes de lanzar una nueva plataforma de software. En cuestión de minutos, un ingeniero júnior señala una dependencia de una API de terceros que nadie ha sometido a pruebas de carga. Todo el mundo daba por hecho que la API era estable; imaginar el fracaso revela que es un punto único de fallo. El equipo construye una alternativa antes del lanzamiento. Si después la API falla en la segunda semana, el equipo gestiona un incidente controlado en lugar de una crisis.

Cuándo programar un premortem

El momento importa más de lo que reconocen la mayoría de las guías de facilitación. La mejor ventana es cuando el plan ya está lo bastante detallado como para criticarlo y antes de que los recursos estén comprometidos del todo y aparezca la falacia del coste hundido. En la práctica, eso significa después de aprobar el acta de constitución del proyecto o el caso de negocio y antes del kickoff formal o de la liberación del presupuesto.

Si lo haces demasiado pronto, obtienes preocupaciones abstractas sobre problemas hipotéticos. Si lo haces demasiado tarde, las personas participantes ya están implicadas en que el plan salga bien. Calificarán los riesgos como improbables porque admitir lo contrario se siente como atacar su propio trabajo, no porque lo crean.

En programas más largos, los premortems también ayudan en las puertas de fase, por ejemplo en el paso de la fase de descubrimiento a la de entrega o antes de una decisión importante de seguir o no seguir. Ahí ponen a prueba los supuestos que se acumularon durante la fase anterior, que es una tarea distinta y útil.

Algunos proyectos hacen que un premortem merezca especialmente la pena: plazos ajustados con poco margen, equipos que trabajan juntos por primera vez, muchas dependencias externas, lanzamientos políticamente sensibles y cualquier iniciativa que se apoye en un supuesto que nadie ha probado en la práctica. Si se cumplen dos o más de estas condiciones, los 90 minutos están bien invertidos.

Reunir al grupo adecuado

Trata la lista de participantes como una decisión de facilitación. Es algo más que un trámite.

Las sesiones funcionan mejor con entre 6 y 12 participantes de tres grupos. El primero es el equipo central del proyecto, que conoce el plan en detalle y responde de la entrega. El segundo son stakeholders adyacentes a quienes el proyecto afectará sin que lo dirijan; ven riesgos que el equipo central tiene demasiado cerca para notarlos. El tercero es al menos una persona realmente ajena: un colega de otra área, alguien que se haya incorporado hace poco al equipo o alguien que represente a la clientela. Que esa persona no conozca el plan es útil, porque hace las preguntas que el equipo central dejó de hacerse hace meses.

Un proyecto dirigido a la ciudadanía muestra por qué. Imagina un equipo que se prepara para lanzar un portal web público y hace su premortem con desarrolladores, una responsable de políticas, un diseñador de contenidos y dos miembros de un panel consultivo ciudadano. Bien podría ser la representación ciudadana la que planteara el riesgo más importante de la sesión: el portal da por hecho que toda persona usuaria tiene una dirección de correo electrónico válida, pero el grupo destinatario (personas mayores que solicitan prestaciones) tiene menos probabilidades de tenerla. Ese riesgo no aparecería en ningún registro de riesgos técnicos, porque a nadie del equipo central se le ocurriría buscarlo.

En la práctica, los grupos multifuncionales encuentran una variedad más amplia de modos de fallo que los homogéneos. Una sala llena de ingenieros detecta bien los riesgos técnicos. Si añades a alguien de análisis financiero, aparecen riesgos de presupuesto; si añades a alguien de customer success, aparecen riesgos de adopción. Cuanto más variada sea la sala, más espacio de fallo cubre.

La jerarquía juega en contra de un premortem honesto. Si el patrocinador del proyecto está en la sala y se le ve apegado al plan, las personas participantes más júnior se autocensuran. Tienes dos opciones: hablar antes con las personas de mayor rango para que premien la discrepancia en lugar de mostrarse incómodas con ella, o hacer que el patrocinador se incorpore solo a la fase de síntesis, una vez identificados los fallos. Hay quien facilita y mantiene al patrocinador completamente fuera de la fase de generación, de modo que revise el resultado y no el proceso.

Una agenda en cinco fases

Un premortem de 90 minutos para un equipo de 8 personas transcurre así:

• Minutos 0-10: presentación. Comparte el plan; basta con un resumen. Después fija el marco de forma explícita: «Estamos a 12 meses de hoy. Este proyecto ha fracasado estrepitosamente. El lanzamiento salió mal, los stakeholders están descontentos y estamos intentando entender cómo hemos llegado hasta aquí». Un escenario concreto produce resultados concretos.
• Minutos 10-18: generación en silencio. Cada persona escribe por su cuenta causas de fracaso, una por nota adhesiva o tarjeta. Sin debate y sin compartir todavía.
• Minutos 18-45: cosecha por turnos. Cada persona comparte un elemento cada vez, dando vueltas hasta que todos los elementos distintos están en el tablero. Quien facilita va agrupando sobre la marcha.
• Minutos 45-65: priorización. El grupo vota con puntos o puntúa los elementos según gravedad y probabilidad, y selecciona los 5 a 8 principales.
• Minutos 65-90: responsables. Cada riesgo priorizado recibe una persona responsable con nombre, una acción de mitigación concreta y una fecha de seguimiento.

La generación en silencio es la fase que los equipos se saltan con más frecuencia, y saltársela es lo que más daño hace. La investigación de Andrew Van de Ven y André Delbecq en la década de 1970 sobre la técnica de grupo nominal (generación de ideas independiente y estructurada antes del debate en grupo) concluyó que produce más ideas que el debate abierto en grupo. También impide que la primera persona que habla en voz alta ancle a toda la sala. Sin ella, la lista de riesgos refleja la voz de más rango o la más segura de sí misma, en lugar de todo lo que el grupo es capaz de ver.

Si hay tiempo, añade un «pre-desfile» con un grupo más pequeño después del ejercicio de fracaso. El marco se invierte: «el proyecto superó todas las expectativas, a la clientela le encanta y estamos intentando entender qué hizo exactamente que tuviera éxito». Esto saca a la luz fortalezas ocultas y supuestos no expresados sobre cómo es un buen resultado. También evita que las personas participantes salgan con un ánimo puramente defensivo respecto a un proyecto al que van a dedicar meses.

Convertir los riesgos detectados en acciones con responsable

La forma más común en que fracasa un premortem es una larga lista de riesgos que se queda en un documento compartido y nadie vuelve a abrir. Las personas participantes ven entonces el ejercicio como puro teatro. Es totalmente evitable.

Cada riesgo priorizado sale de la sala con una persona responsable con nombre, una acción de mitigación concreta y una fecha para informar. «Vigilar esto» no es una acción. Una mitigación concreta suena así: «Construir una integración de API alternativa antes del [fecha], responsable: [nombre]» o «Celebrar una reunión de alineación de stakeholders con [persona] antes del [fecha], responsable: [nombre]».

Asigna cada riesgo a la persona más cercana a él. Un riesgo técnico corresponde a quien lidera la parte técnica; un riesgo de comunicación con stakeholders, a quien lidera la comunicación o el cambio. Cuando la responsabilidad recae por defecto en la persona de mayor rango de la sala, la rendición de cuentas se diluye y las acciones se estancan, así que cuestiona ese reflejo.

Los resultados duran más cuando las conclusiones pasan directamente a los documentos de gobernanza que el proyecto ya tiene: el registro RAID (Risks, Assumptions, Issues, Dependencies: riesgos, supuestos, problemas y dependencias), el brief del proyecto o el acta del equipo. Una forma de hacerlo: quien facilita hace que cada riesgo se introduzca en el registro RAID en una pantalla compartida antes de que nadie se vaya, cada uno con su responsable y la fecha límite de su mitigación. En el siguiente stand-up semanal, el registro RAID es el primer punto de la agenda. Si algunos de los riesgos principales se materializan durante el proyecto, ya tienen responsables y planes, lo que reduce mucho la probabilidad de que se conviertan en incidentes críticos.

Errores de facilitación que conviene evitar

Además de saltarse la generación en silencio y dejar los riesgos sin responsable, hay dos errores difíciles de ver hasta que los has cometido.

El primero es dejar que la sesión derive hacia las soluciones mientras el grupo todavía está identificando fallos. En cuanto alguien dice «podríamos arreglarlo con…», la atención pasa de encontrar problemas a defender arreglos, y la lista deja de crecer. Interrúmpelo directamente: «Todavía no estamos resolviendo. Seguimos buscando qué podría salir mal».

El segundo es el premortem de falsa tranquilidad, en el que el grupo enumera los riesgos con cuidado pero acuerda calificarlos todos como improbables para evitar la incomodidad. Parece una sesión de trabajo, y por eso cuesta detectarlo. La señal delatora es una lista en la que todos los elementos puntúan 2 sobre 5 en probabilidad. Haz que las personas participantes califiquen los riesgos individualmente antes de que el grupo compare las puntuaciones, o nombra la dinámica: «Nuestro trabajo ahora mismo es que esta lista sea lo más alarmante posible. La calibración de probabilidades viene después».

Ambas cosas dependen de la seguridad psicológica. La investigación de Amy Edmondson en unidades de enfermería hospitalarias concluyó que las unidades con mejor liderazgo y mejores relaciones de trabajo notificaban más errores, muy probablemente porque allí la gente se sentía más segura para admitirlos. Lo mismo ocurre con los premortems: una sala en la que la gente se siente segura para expresar preocupaciones incómodas produce una lista de riesgos más honesta y, por tanto, más útil.

Combinar el premortem con la planificación de escenarios y los tres horizontes

Un premortem examina a fondo un único escenario de fracaso, y esa es a la vez su fortaleza y su límite. En proyectos que se enfrentan a una incertidumbre estratégica real, en los que el propio futuro está en disputa, combinarlo con la planificación de escenarios amplía lo que cubre.

Usa primero la planificación de escenarios para encontrar las incertidumbres clave que hay detrás de los distintos futuros, lo que normalmente te da de 2 a 4 escenarios plausibles. Después haz un premortem para cada escenario de alto riesgo. Los riesgos que aparecen en varios escenarios van primero, porque se mantienen pase lo que pase. Los que aparecen en un solo escenario dependen de ese futuro y pueden vigilarse en consecuencia.

El marco de los tres horizontes añade otro ángulo. Los premortems sobre el Horizonte 1 (optimizar las operaciones actuales), el Horizonte 2 (desarrollar capacidades emergentes) y el Horizonte 3 (apuestas transformadoras) producen tipos de riesgo distintos. Los riesgos del Horizonte 1 suelen ser operativos y a corto plazo, los del Horizonte 2 tienen que ver con carencias de capacidades y costes de transición, y los del Horizonte 3, con supuestos equivocados sobre lo que exigirá el futuro. Etiquetar los riesgos por horizonte durante el premortem añade profundidad estratégica al resultado sin alargar la sesión.

Workshop Weaver da soporte a los tres métodos, con plantillas y guías de facilitación diseñadas para funcionar juntas. Si tu premortem forma parte de un ciclo de planificación más amplio, usa allí los recursos de planificación de escenarios y de los tres horizontes junto con esta guía.

Tu primer premortem

Elige un proyecto próximo (el lanzamiento de un producto, un giro estratégico, un equipo nuevo) y programa un premortem de 90 minutos antes del kickoff. Las cinco fases, por orden: presentar el plan y fijar el marco de fracaso, generar riesgos en silencio, cosechar por turnos, priorizar mediante votación y asignar responsables con fechas.

Un premortem es menos pesimista de lo que parece. Encuentra los problemas que todavía puedes resolver mientras hay tiempo para resolverlos. Las señales de alarma casi siempre están ahí, y el método las saca a la luz antes del balance final.