Pre-Mortem de Proyecto

Describe un proyecto y Joy corre un pre-mortem: imagina que el lanzamiento ya fracasó, trabaja hacia atrás para sacar a la luz los modos de fallo probables, los ordena por probabilidad e impacto, y te da una señal de alerta temprana y una solución concreta para cada uno, para que cierres las brechas antes de construir.

Para Líderes de L&D Gerentes de Programa y Proyecto RR.HH. y People Ops Líderes de Operaciones
Prompt de ejemplo para el asistente de Joy

Haz un pre-mortem de nuestro [nuevo despliegue de capacitación de cumplimiento que lanza en el T3] y señala los mayores riesgos.

Así puede verse

Un ejemplo ilustrativo: tu resultado dependerá de tus fuentes, datos y peticiones.

Haz un pre-mortem de nuestro nuevo despliegue de capacitación de cumplimiento que lanza en el T3 y señala los mayores riesgos.

Asumí que el despliegue ya había fracasado y trabajé hacia atrás, usando tu plan del proyecto y la retro del despliegue del año pasado en el Knowledge Center para basar cada riesgo. Aquí está la lectura ordenada, con los dos que destacan señalados.

Pre-Mortem — Despliegue de Capacitación de Cumplimiento del T3

Proyecto: Despliegue de Capacitación de Cumplimiento del T3 · Método: pre-mortem (asume que falló, trabaja hacia atrás) · Riesgos evaluados: 6

Imaginé que es fin del T3 y el despliegue salió mal, luego trabajé hacia atrás desde ese fracaso usando tu plan del proyecto, la retro del despliegue del año pasado y el mapa de stakeholders en el Knowledge Center. Seis modos de fallo explican la mayoría de las formas en que podría salir mal. Puntué cada uno como probabilidad × impacto en una escala de 1–5, así que el puntaje de riesgo va de 1 a 25. Dos están muy por delante del resto: baja finalización antes de la fecha límite (20) y contenido desactualizado frente a la regulación actual (16). Ahí es donde pondría tu atención primero.

Puntaje de riesgo por modo de fallo (probabilidad × impacto, 1–25)

Baja finalización antes de la fecha límite20
Contenido desactualizado vs regulación16
Falta de respaldo de gerentes15
Retrasos de localización12
Problemas de acceso a LMS/SSO9
Fatiga de encuestas6

Baja finalización antes de la fecha límite — puntaje 20. Probabilidad alta (5), impacto alto (4). La retro del año pasado muestra la finalización estancándose cerca del 61% a dos semanas del cierre, y esta cohorte es más grande. Si la cifra de la semana dos está por debajo de aproximadamente 50%, trátalo como el fracaso ya en curso. La solución es escalonar la asignación por equipo con un checkpoint duro a mitad de trimestre y darle a cada gerente una lista semanal de finalización de sus propios reportes.

Contenido desactualizado frente a la regulación actual — puntaje 16. Probabilidad alta (4), impacto alto (4). La política fuente se revisó por última vez antes del cambio de norma más reciente, así que el curso podría enseñar un requisito superado. La señal que hay que vigilar es que no haya visto bueno de cumplimiento en el guion final; la solución es una revisión legal y de cumplimiento con fecha antes del congelamiento del build en lugar de después del lanzamiento.

El ranking completo, con una señal de alerta temprana y una mitigación concreta para cada uno, está abajo.

RiesgoProbabilidadImpactoSeñal de alerta tempranaMitigación
Baja finalización antes de la fecha límiteAltaAltoFinalización de la semana dos por debajo de aproximadamente 50%Escalonar la asignación por equipo con un checkpoint duro a mitad de trimestre, y darle a los gerentes una lista semanal de finalización de sus propios reportes
Contenido desactualizado frente a la regulación actualAltaAltoSin visto bueno de cumplimiento en el guion finalConseguir una revisión legal y de cumplimiento con fecha del contenido antes del congelamiento del build, no después del lanzamiento
Falta de respaldo de gerentesAltaMedioGerentes que no reenvían la nota de kickoff a sus equiposInformar primero a los gerentes y entregarle a cada uno un guion de dos líneas más la lista de su propio equipo
Retrasos de traducción y localizaciónAltaMedioArchivos localizados sin regresar para el congelamiento del buildFijar el texto fuente temprano y correr la localización en paralelo con el build, no después de él
Problemas de acceso a LMS y SSOMediaMedioFallos de inicio de sesión del grupo de prueba en stagingCorrer una prueba de humo de SSO con un pequeño grupo piloto a dos semanas del cierre
La fatiga de encuestas sesga la retroalimentaciónMediaBajoRespuesta a la encuesta post-curso por debajo de aproximadamente 20%Mantener la encuesta en tres preguntas e integrarla al final del último módulo

Si endureces dos cosas antes de construir, que sean el plan de finalización y el visto bueno de cumplimiento — juntos cargan los dos puntajes más altos. Los cuatro más bajos (respaldo de gerentes en 15, retrasos de localización en 12, acceso a LMS y SSO en 9, y fatiga de encuestas en 6) cada uno merece una mitigación pero no debería frenar el lanzamiento.

¿Quieres que convierta el riesgo principal en una lista de responsables y acciones, o que redacte el plan de mitigación completo para uno de estos riesgos?

De la página en blanco a una lista de riesgos ordenada

Pre-Mortem de Proyecto le da la vuelta al post-mortem. Describes el proyecto, y Joy asume que ya fracasó, luego trabaja hacia atrás para nombrar las formas específicas en que eso podría pasar. Ordena cada modo de fallo por probabilidad e impacto, señala la señal de alerta temprana que hay que vigilar, y la empareja con una mitigación concreta, para que las brechas sean visibles mientras todavía puedes actuar sobre ellas.

  1. Describe el proyecto

    Dile a Joy qué vas a lanzar, cuándo y para quién. Apúntala hacia el plan del proyecto, las retros pasadas y el mapa de stakeholders en tu Knowledge Center para que los riesgos se basen en tu contexto real.

  2. Pide el pre-mortem

    Pídele a Joy que asuma que el proyecto fracasó y trabaje hacia atrás. Usa el comando /analyze o simplemente describe lo que necesitas. Saca a la luz los modos de fallo probables y puntúa cada uno por probabilidad e impacto.

  3. Revisa los riesgos ordenados

    Joy devuelve una tabla de riesgos ordenada con una señal de alerta temprana y una mitigación para cada uno, además de una gráfica de los puntajes de riesgo para que los dos primeros sean obvios. Cuestiónala o agrega contexto y vuelve a ordenar.

  4. Llévalo a tu plan

    Copia la tabla de riesgos y las mitigaciones en tu documento del proyecto, tu deck de kickoff o tu bitácora RAID. Joy saca los riesgos a la luz; tú decides para cuáles construir salvaguardas.

  5. Conviértelo en un solo clic para tu equipo

    Guarda esta petición como un comando personalizado en el asistente que tu equipo ya usa, para que cualquiera pueda ejecutarla en un solo paso.

Hazla tuya

Trabaja Hacia Atrás Desde El Fracaso

En lugar de una lista de verificación de riesgos genérica, Joy asume que el proyecto fracasó y razona hacia atrás sobre las formas específicas en que pudo pasar, para que la lista sea sobre tu proyecto, no cualquier proyecto.

Ordenado Por Probabilidad E Impacto

Cada riesgo recibe una calificación de probabilidad e impacto y un puntaje de 1–25, para que la prioridad sea obvia a simple vista en lugar de una lista plana que discutir.

Señales De Alerta Temprana

Cada riesgo viene con la señal concreta que hay que vigilar, para que sepas cuándo un riesgo se está convirtiendo en el fracaso mientras todavía hay tiempo de actuar.

Una Solución Para Cada Riesgo

Joy empareja cada riesgo con una mitigación específica que puedes dejar directamente en el plan, no un vago 'monitorear de cerca'.

Antes De Un Despliegue De Políticas

Córrelo en una nueva política o cambio de proceso para sacar a la luz los riesgos de adopción y comunicación antes de anunciarlo.

Antes De Una Migración De Sistema

Apúntalo hacia una migración de LMS o plataforma para atrapar los riesgos de acceso, datos y tiempos antes del cutover.

En La Planeación Del Programa

Pon a prueba el plan de L&D del próximo año antes de comprometer el presupuesto, para que los supuestos frágiles salgan temprano.

Antes De Un Empujón De Certificación

Somete a estrés una fecha límite de certificación o cumplimiento para ver dónde se concentran los riesgos de finalización y contenido.

Preguntas Frecuentes

¿Qué es un pre-mortem de proyecto?

Un pre-mortem es un ejercicio de planeación en el que imaginas que un proyecto ya fracasó y trabajas hacia atrás para nombrar las razones. Saca a la luz los riesgos antes que una revisión de riesgos normal porque asumir el fracaso hace más fáciles de ver los puntos débiles. Joy corre el ejercicio sobre tu proyecto y devuelve una lista ordenada de modos de fallo con señales de alerta y soluciones.

¿En qué se diferencia de un post-mortem?

Un post-mortem ocurre después de que un proyecto termina y explica qué salió mal. Un pre-mortem ocurre antes de construir, mientras todavía puedes cambiar el plan. Esta receta corre el pre-mortem, para que las brechas salgan lo bastante temprano como para cerrarlas.

¿Es un dashboard de riesgos en vivo que tengo que mantener?

No. Es un análisis bajo demanda. Lo corres cuando ayuda (antes del kickoff, antes del congelamiento del build, antes del lanzamiento) y Joy lee el plan actual y devuelve una lectura fresca. No hay un tablero permanente que mantener al día.

¿Cómo decide Joy qué riesgos importan más?

Joy califica cada riesgo en probabilidad e impacto y los multiplica en un puntaje de 1–25, luego ordena la lista por ese puntaje. La gráfica y la tabla muestran las calificaciones para que veas el razonamiento, ajustes los supuestos y le pidas a Joy que vuelva a ordenar.

¿Joy puede ayudarme a actuar sobre los riesgos?

Sí. Joy puede redactar una lista de responsables y acciones para el riesgo principal, o un plan de mitigación más completo para cualquier riesgo, como texto en el chat. Tú lo copias en tu documento del proyecto, bitácora RAID o deck de kickoff. Joy redacta el plan; no asigna responsables ni le da seguimiento al trabajo por ti.

¿Listo para encontrar el fracaso antes de que él te encuentre a ti?

Únete a la lista de espera y sé de los primeros en probar este flujo de trabajo cuando JoySuite se lance.