Riesgo probabilidad baja + impacto bajo → agregar a watch list y monitorear periódicamente sin asignar recursos activos.
Cuando un riesgo se materializa: cerrar en registro de riesgos → abrir como issue → activar plan de contingencia (trigger cumplido) → comunicar al sponsor.
Las oportunidades deben documentarse en el registro de riesgos, analizarse cualitativamente y presentarse al sponsor con recomendación. El director no modifica el alcance unilateralmente.
En ágil los riesgos se gestionan en el backlog. La vulnerabilidad debe registrarse como riesgo, asignarle prioridad y planificar respuesta en el próximo sprint.
B: la probabilidad cambió (nueva información del proveedor) → actualizar el registro. D: cuando un riesgo se materializa, se cierra en el registro y se abre como issue.
El impedimento del proceso de aprobación es un issue ágil activo (gestionarlo con el Scrum Master); el cambio del proveedor es un riesgo del componente predictivo (escalar al sponsor con análisis de impacto).
El propietario de riesgo monitorea el riesgo asignado y ejecuta el plan de respuesta. El director supervisa el proceso global. Son roles complementarios.
EMV más altos: R-02 (USD 36.000) y R-01 (USD 35.000). Priorizar por EMV maximiza la protección con recursos limitados.
El trigger no se cumple todavía. Primera acción: actualizar el registro con la nueva información (probabilidad ahora alta) y revisar el plan de respuesta existente.
Cláusula de penalidad en el contrato = transferencia: desplaza el impacto financiero al proveedor si el riesgo ocurre.
El director facilita que el equipo registre el impedimento, analice el impacto en sprints afectados y defina una respuesta antes de la siguiente planificación.
Transparencia obligatoria: informar los tres riesgos de alta exposición, su estado y la fecha estimada de finalización de los planes pendientes.
Reserva de contingencia: cubre riesgos conocidos; el director puede usarla. Reserva de gestión: cubre riesgos desconocidos; requiere aprobación del sponsor.
Estrategia de respuesta contingente según PMBOK 8 2.ª impresión (errata): B — solo se activa cuando se cumple el trigger; D — puede denominarse plan de contingencia o plan de reserva (fallback).
Programar talleres de capacitación reduce la probabilidad de que el riesgo ocurra = estrategia de mitigación.
El patrón recurrente que afecta la velocidad desde hace 3 sprints es un issue activo (no un riesgo). Gestionarlo como impedimento sistémico con el Scrum Master.
La transferencia cubre el impacto financiero pero no el impacto en cronograma. El retraso de 3 semanas debe abrirse como issue, evaluar impacto y comunicar al sponsor.
Activar plan de contingencia → cerrar riesgo en registro → abrir como issue → comunicar al sponsor → evaluar impacto adicional.
Para el riesgo de obra civil: análisis cuantitativo actualizado + EMV + opciones al sponsor. Para el módulo WMS: agregarla al backlog con priorización del Product Owner.
Trigger vencido sin materialización: evaluar si el riesgo sigue siendo relevante, considerar actualizar el trigger o cerrar formalmente, y documentar la decisión.
Documentar la oportunidad, presentar el análisis costo-beneficio al Product Owner y solicitar una decisión de priorización para el próximo sprint.
Para los riesgos sin propietario: actualizar registro, transferir conocimiento inmediatamente, revisar planes. Para el recorte presupuestario: analizar impacto y presentar opciones al sponsor.
B: los unknown unknowns se gestionan con reservas de gestión y resiliencia. D: la gestión de oportunidades es parte del proceso de gestión de riesgos según PMBOK 8.
Las demoras climáticas ya están ocurriendo = issue activo, no riesgo potencial. Abrir en el registro de issues, evaluar impacto y comunicar al sponsor con opciones.
Caso integrado: Modernización sistema de contratos, Ecuador.
El trigger no se ha cumplido todavía (faltan 10 días). Primera acción: actualizar el registro con probabilidad ahora alta, intensificar seguimiento y preparar el plan contingente para activación cuando el trigger se cumpla. La oportunidad (función de reportes automáticos) debe documentarse en el backlog y evaluarse con el Product Owner; no implementarse unilateralmente.