Premortem de proyectos: agenda de reunión y ejemplo completado

Un premortem es una reunión en la que el equipo imagina que un proyecto ya ha fracasado y busca explicar qué llevó al resultado. Utiliza la inversión: partir del fracaso para investigar las condiciones que podrían producirlo antes de ejecutar el plan.

Una empresa ficticia va a cambiar su plataforma de atención al cliente. La demostración funcionó, hubo formación y se comunicó la fecha. Falta verificar si las solicitudes en curso conservarán el historial, el responsable y la próxima acción después del cambio.

Elige un fracaso que puedas examinar

La AHRQ describe el premortem como recurso para anticipar obstáculos a la implementación. Las causas propuestas son hipótesis que necesitan verificación.

Define qué resultado no deseado estás examinando. En el cambio de plataforma, podría ser perder la continuidad de las solicitudes abiertas. Decir solamente que el cambio fue un desastre deja espacio para temores que tratan de problemas diferentes.

Acuerda también el periodo. Una interrupción del primer día requiere preguntas distintas de una dificultad que aparece tras meses de uso. Si ambos importan, haz registros separados para no mezclar causas y medidas.

Agenda sugerida para una reunión de 45 minutos

Invita a quienes atienden a los clientes, configuran el sistema y deciden sobre la transición. Envía antes el plan y el criterio de fracaso. La distribución de tiempo es una propuesta de facilitación para este caso, no una duración exigida por la técnica.

Si la discusión revela que nadie puede describir el recorrido de una solicitud, detén la selección de riesgos y reconstruye ese recorrido. Votar una lista poco comprendida solo organiza la duda.

Escribir individualmente antes de conversar puede dar espacio a una observación que no surgiría después de escuchar a la dirección. Para que funcione, quien conduce la sesión debe recibir dudas sin exigir que el participante demuestre inmediatamente toda la hipótesis.

Sustituye temores amplios por mecanismos

“El equipo se resistirá” atribuye una disposición general a las personas. Una formulación más útil sería: quien recibe una solicitud no sabrá en qué sistema actualizarla porque no se han definido las reglas de transición.

Pregunta qué condición conecta la causa propuesta con el fracaso. ¿Hay una limitación de la herramienta? ¿Falta una decisión? ¿El problema depende de un caso excepcional o puede ocurrir en el uso habitual? Busca registros, demostraciones y personas que ayuden a comprobar la relación.

Una lista larga de riesgos no informa sobre su frecuencia ni gravedad. Distingue evidencia de posibilidad y anota las incertidumbres. La técnica puede hacer más visible un temor sin hacerlo más probable.

Elige comprobaciones que cambien el plan

La empresa podría migrar un conjunto de solicitudes abiertas y comprobar el historial, el responsable y la próxima acción. También podría simular un mensaje recibido durante la transición y seguir su recorrido hasta la atención al cliente.

Cada comprobación necesita un responsable y una consecuencia para el plan. Si no se conserva el historial esencial, quizá haya que aplazar el cambio o mantener una consulta segura al sistema anterior. El resultado depende de lo que se encuentre.

Compara el coste de esas medidas con las alternativas. Mantener dos sistemas puede preservar el acceso y generar actualizaciones contradictorias. Como al elegir herramientas, sigue el proceso completo y el esfuerzo necesario para salir de cada opción.

Ficha completada para el cambio de plataforma

El último riesgo distingue la presencia de datos de la capacidad de continuar el trabajo. Un archivo exportado puede existir y aún exigir una búsqueda manual que la operación no puede sostener.

Para priorizar, empieza por fallos que impiden atender una solicitud esencial y no tienen una recuperación demostrada. Después examina consecuencias relevantes que puedan comprobarse antes del cambio con poco esfuerzo. Las molestias reversibles pueden quedar en seguimiento, con un responsable definido. Este orden es un criterio de trabajo para el ejemplo, no una escala validada de probabilidad.

Al copiar la ficha a tu proyecto, conserva cuatro campos: fallo observable; comprobación pendiente; responsable y plazo; decisión si falla la prueba. La ficha de investigación puede guardar las observaciones y separar hechos de interpretaciones.

Registra lo que el ejercicio no resolvió

Un premortem depende del conocimiento y de la disposición de sus participantes. Puede omitir problemas, repetir creencias del grupo o concentrar la atención en una historia llamativa. Invita a alguien a buscar otra explicación para el mismo resultado.

Tras corregir una debilidad, examina lo que añade la corrección. Una aprobación adicional puede reducir un error y crear demoras. El plan revisado también necesita responsables, límites y condiciones de seguimiento.

Al terminar la reunión, cada elemento que bloquee la transición debe tener una comprobación programada. Si la respuesta no llega antes de la fecha del cambio, alguien tendrá que decidir expresamente si aplaza o acepta la exposición restante. Una lista de temores sin esa consecuencia no ofrece un criterio para autorizar el cambio.