Gestión de Riesgos y Mitigación

El Riesgo Que No Viste Venir

🔄 Repaso rápido: En la lección anterior, exploramos desglose de tareas y asignación de trabajo. Ahora construyamos sobre esa base.

A mitad de un lanzamiento de producto de 6 meses, el lead developer anuncia que se va a otra empresa. Sin cláusula de período de aviso en su contrato. Dos semanas y se fue. Con él se va conocimiento profundo del codebase, tres features críticos en desarrollo, y la confianza del equipo.

El PM entra en modo de pánico. Había planificado para caídas de servidores, sobrecostos y cambios de scope. ¿Pero perder a su lead developer? Nadie pensó en eso.

Excepto que debieron. La dependencia de personas clave es uno de los riesgos más comunes de proyecto. Aparece en toda checklist estándar de riesgos. Pero sin un approach sistemático para identificar riesgos, hasta PMs experimentados pasan por alto lo obvio.

La IA no elimina las sorpresas. Pero mejora dramáticamente tus probabilidades al extraer patrones de miles de proyectos para identificar riesgos que pasarías por alto.

Construyendo un Registro de Riesgos

Un registro de riesgos es el sistema inmunológico de tu proyecto:

“Crea un registro de riesgos comprehensivo para este proyecto: PROYECTO: [nombre]. TIMELINE: [duración]. EQUIPO: [tamaño y roles clave]. TECNOLOGÍA: [plataformas clave]. PRESUPUESTO: [rango aproximado]. Para cada riesgo: ID, descripción, categoría, probabilidad (1-5), impacto (1-5), severidad (P×I), trigger, mitigación, contingencia, dueño. CATEGORÍAS: Alcance, Schedule, Recursos, Técnico, Externo, Comunicación, Presupuesto, Calidad. Identifica al menos 15-20 riesgos. Rankea por severidad.”

Leyendo el Registro de Riesgos

Probabilidad (1-5):

• 1: Muy improbable (<10%)
• 2: Improbable (10-25%)
• 3: Posible (25-50%)
• 4: Probable (50-75%)
• 5: Casi seguro (>75%)

Impacto (1-5):

• 1: Insignificante (se absorbe sin cambios)
• 2: Menor (leve retraso o aumento de costo)
• 3: Moderado (impacto notable en schedule/presupuesto)
• 4: Mayor (retraso significativo u overrun)
• 5: Severo (fracaso del proyecto o pérdida de negocio)

Severidad = Probabilidad × Impacto

• 1-5: Bajo (monitorear)
• 6-14: Medio (planificar mitigación)
• 15-25: Alto (gestión activa requerida)

✅ Revisión rápida: Piensa en tu proyecto actual. ¿Cuál es el riesgo que más te preocupa? ¿Has escrito un plan de mitigación específico para él? Si la respuesta es “he querido pero no he tenido tiempo”, eso es exactamente lo que la IA resuelve.

Las Cuatro Estrategias de Respuesta

Triggers de Riesgo: Señales de Alerta Temprana

Para cada riesgo de alta severidad, define triggers observables:

1. Trigger temprano: Algo que notarías 2-4 semanas antes de que el riesgo se materialice
2. Trigger inmediato: Algo que significa que el riesgo está por pegar
3. Método de monitoreo: Cómo y cada cuánto verificar
4. Plan de respuesta: Qué hacer cuando se activa el trigger

Ejemplo: RIESGO: Lead developer se va a mitad del proyecto TRIGGER TEMPRANO: Developer rechaza eventos de equipo, actualiza LinkedIn TRIGGER INMEDIATO: Solicita reunión con HR MONITOREO: 1:1 semanales, encuestas de moral del equipo RESPUESTA: Activar plan de cross-training, contactar candidatos backup

Análisis Pre-Mortem

Una de las técnicas más poderosas: imagina que el proyecto fracasó, después trabaja hacia atrás para descubrir por qué.

“Conduce un análisis pre-mortem para este proyecto: [DESCRIPCIÓN + EQUIPO + TIMELINE]. Imagina que es [fecha de deadline] y el proyecto FRACASÓ — se entregó tarde, sobre presupuesto, y los stakeholders están insatisfechos. Trabajando hacia atrás, identifica: 1) las 5 razones más probables de fracaso, 2) para cada una: señales de alerta ignoradas, decisiones que llevaron al fracaso, qué se pudo hacer diferente, probabilidad (1-5), 3) para cada modo de fallo: qué podemos hacer HOY para prevenirlo.”

El pre-mortem es poderoso porque bypassa el optimismo de planificación. Cuando imaginas el proyecto teniendo éxito, no ves riesgos. Cuando imaginas que fracasa, los riesgos se hacen obvios.

Monitoreo Continuo de Riesgos

La gestión de riesgos no es un ejercicio de una vez. Corre una revisión semanal que actualice: cambios en probabilidad o impacto, triggers activados, riesgos aceptados materializándose en issues, nuevos riesgos para agregar, y riesgos que se pueden cerrar.

Root Cause Analysis (Cuando los Riesgos se Vuelven Issues)

Cuando algo sale mal, entiende por qué antes de arreglarlo. Usa el método de los “Cinco Por Qués” — pregunta “¿por qué?” repetidamente hasta llegar a la causa raíz. Después identifica: factores de proceso, factores de personas, factores de tecnología, factores externos. Define fix inmediato, prevención a largo plazo y lecciones aprendidas.

Ponlo en Práctica

Toma tu proyecto actual y corre un análisis pre-mortem con IA. Imagina que el proyecto fracasó espectacularmente. ¿Qué salió mal? Después construye un registro de riesgos con planes de mitigación para los top cinco modos de falla.

Conclusiones Clave

• Riesgos son eventos potenciales futuros; issues son problemas actuales — la gestión de riesgos es proactiva
• Severidad del riesgo = Probabilidad × Impacto — prioriza por severidad, no solo impacto o probabilidad
• Cuatro estrategias: Evitar, Mitigar, Transferir, Aceptar — elige según severidad y factibilidad
• Los triggers son señales de alerta temprana — define triggers específicos y observables para tus riesgos más altos
• El análisis pre-mortem revela riesgos que la planificación optimista pierde
• La gestión de riesgos es continua, no de una vez — corre revisiones semanales
• Root cause analysis después de issues previene recurrencia — pregunta “por qué” cinco veces

En la Siguiente Lección

En la Lección 5: Comunicación con Stakeholders y Reporteo, mantendremos a todos alineados sin ahogarnos en updates de status.