Simulador de premortem para proyectos de TI

Los equipos explican mejor un fracaso ocurrido que uno hipotético. El premortem aprovecha esa asimetría: da por hecho que el proyecto falló y pide reconstruir cómo ocurrió. Con ese giro, la duda deja de ser una objeción personal y pasa a ser información útil para el plan. La técnica la popularizó el psicólogo Gary Klein.

El prompt separa los síntomas de las causas de fondo, que es donde la mayoría de las listas de riesgo se queda corta. Un retraso en el cronograma es un síntoma; la causa puede ser un patrocinador que no decide, un proveedor sin capacidad real o una integración subestimada. Esa distinción determina qué acción tomar.

El resultado alcanza nivel consultivo porque el rol de auditor de proyectos, las restricciones sobre presupuesto y capacidad de la organización y el marco de la región de operación obligan a respuestas verificables, no a advertencias genéricas. Cada riesgo termina en una acción, un responsable y una señal medible.

Eres un auditor senior de proyectos de transformación tecnológica, con experiencia en comités de inversión y en el rescate de implementaciones que fracasaron por causas que nadie nombró a tiempo.

Tu tarea es realizar un premortem del proyecto descrito abajo: asume que ya fracasó al cabo del horizonte indicado y reconstruye, con rigor, las razones más probables, para que el comité decida si aprueba, ajusta o escalona la inversión.

Sigue esta secuencia:
Primero, redacta en dos líneas la versión del fracaso: qué se esperaba y qué terminó ocurriendo.
Segundo, genera entre ocho y diez causas posibles de fracaso, sin censurar las incómodas.
Tercero, agrúpalas por tema y distingue en cada una el síntoma de la causa de fondo.
Cuarto, califica cada causa por probabilidad e impacto en una escala de uno a cinco.
Quinto, identifica los supuestos del plan que deben ser ciertos para que el proyecto funcione y señala los más frágiles.
Sexto, define para las cinco causas más críticas una acción preventiva, un responsable por cargo y una alerta temprana medible.
Séptimo, cierra con una recomendación: aprobar, ajustar el alcance, escalonar la inversión o no proceder.

Usa la siguiente información:
Proyecto evaluado: migración del sistema central de gestión de pólizas a una plataforma en la nube, con integración al canal de corredores.
Sector de la organización: seguros generales, con operación en Colombia y Ecuador.
Inversión aprobada o solicitada: 4,8 millones de dólares en dos años.
Horizonte para evaluar el fracaso: 18 meses después de la aprobación.
Patrocinador y equipo responsable: la vicepresidenta de Operaciones es la patrocinadora; el equipo es de 14 personas, dirigido por el gerente de TI, con dedicación parcial del área técnica de seguros.
Proveedores o terceros involucrados: un integrador regional contratado a precio cerrado y el proveedor del software de pólizas.
Supuestos principales del plan: el proveedor entrega el módulo de comisiones en el mes seis; los corredores adoptan el nuevo portal en tres meses; la migración de 1,2 millones de pólizas se hace con menos de 2 % de inconsistencias.

Presenta el resultado en cuatro partes: la versión del fracaso en dos líneas, una tabla con las cinco causas más críticas, con causa de fondo, síntoma, probabilidad, impacto, acción preventiva, responsable y alerta temprana, los supuestos frágiles en un párrafo breve y la recomendación final en otro.

Limita las acciones a lo que una organización mediana puede ejecutar con su presupuesto y su personal actuales, no inventes cifras que el usuario no haya entregado, marca como supuesto cualquier dato que debas estimar y ajusta las referencias regulatorias o contractuales al entorno de la región de operación durante el año en curso. Escribe en tono ejecutivo, directo y sin dramatismo.

Versión del fracaso: a los 18 meses, la migración se detuvo tras el segundo ciclo de pruebas, con nueve meses de retraso y un sobrecosto de 1,6 millones de dólares. Operaciones siguió usando el sistema anterior para las pólizas de mayor volumen y los corredores no adoptaron el portal.

Supuestos más frágiles: la entrega del módulo de comisiones en el mes seis depende de una sola persona del integrador, y la adopción del portal en tres meses no tiene respaldo en ninguna experiencia previa de la organización. El supuesto de menos de 2 % de inconsistencias carece de una prueba que lo sustente.

Recomendación: escalonar la inversión. Aprobar la primera fase, plataforma y datos, por 2,6 millones de dólares, y liberar la segunda fase, comisiones y portal, cuando el prototipo de comisiones y la migración de prueba superen los umbrales definidos.

Consejo de Implementación

Ejecute el premortem con el equipo del proyecto antes de la reunión de aprobación y pida a cada persona que escriba sus causas por separado antes de conocer las de los demás. Itere el resultado pidiéndole a la IA que profundice en las dos causas con mayor puntaje. Comparta el informe con el patrocinador y con el responsable de riesgos, y convierta las alertas tempranas en puntos fijos del comité de seguimiento.