Riesgos I: qué es un riesgo y cómo identificarlo
Gestionar un proyecto es decidir bajo incertidumbre. Esta lección enseña a nombrar esa incertidumbre con precisión: qué es (y qué no es) un riesgo, cómo se formula para que sirva, de dónde vienen y cómo se descubren antes de que sea tarde.
- Definir riesgo como efecto de la incertidumbre sobre los objetivos, incluyendo amenazas y oportunidades.
- Distinguir riesgo de problema, de causa y de incertidumbre en general.
- Formular un riesgo como causa → evento → consecuencia, con propietario.
- Recorrer las fuentes de riesgo (incluidas supply chain e IA) y aplicar técnicas de identificación como el premortem.
La gestión del riesgo es el bloque más largo del Tema 2 (diap. 6-46) y el primer objetivo del tema: "comprender la importancia de la gestión de riesgos y ser capaz de llevarla a cabo". Es el tipo de contenido que se pregunta aplicado: "formula este riesgo", "¿esto es un riesgo o un problema?", "¿qué técnica de identificación usarías?". Esta lección cubre diap. 6-19 y 41-44; la siguiente, análisis, respuestas y seguimiento. Los objetivos que fija el bloque (diap. 7) son exactamente los de estas dos lecciones: identificar y formular riesgos de forma útil; analizar probabilidad, impacto e incertidumbre; planificar respuestas y reservas; monitorizar como actividad continua; e incorporar riesgos tecnológicos, humanos, organizativos, de seguridad y de IA.
1. Qué es un riesgo
La definición del temario, tomada de ISO 31000 y del PMBOK 7:Tema 2, diap. 8. ISO 31000:2018, §3.1. PMBOK 7, dominio de desempeño de la Incertidumbre.
Cada palabra cuenta:
- Incertidumbre: no sabemos si ocurrirá, o cuánto. Si es seguro que ocurre, no es un riesgo: es un hecho que se planifica (o un problema, si ya ha pasado).
- Efecto: una desviación respecto a lo esperado. Puede ser negativa (amenaza) o positiva (oportunidad).
- Sobre los objetivos: si no afecta a ningún objetivo del proyecto (alcance, plazo, coste, calidad, valor, cumplimiento…), no es un riesgo del proyecto. Por eso necesitas tener los objetivos claros (lección 3) antes de gestionar riesgos.
Amenazas y oportunidades
El riesgo no es sólo "lo malo". Una oportunidad es una incertidumbre que, si ocurre, beneficia al proyecto: "el ayuntamiento podría liberar una API oficial de GPS en tiempo real antes del verano, lo que nos ahorraría construir nuestro propio sistema de ingesta (−4 semanas)". Ignorar los riesgos positivos es uno de los errores frecuentes de las diapositivas, y las oportunidades tienen sus propias respuestas (lección 13).Tema 2, diap. 28 y diap. 44.
Del riesgo a la incertidumbre
El PMBOK 7 amplía la mirada: la incertidumbre incluye los riesgos, pero también:
- Ambigüedad: no está claro qué significa algo o qué se quiere ("que la app sea accesible": ¿qué nivel? ¿para quién?). Se reduce con experimentos, prototipos, preguntas.
- Complejidad: muchas partes interconectadas cuyo comportamiento conjunto es difícil de prever (integrar GPS + horarios teóricos + incidencias en tiempo real). Se maneja descomponiendo, simulando, iterando.
- Volatilidad (ampliación, también en el PMBOK 7): cambios rápidos e impredecibles del entorno (precios cloud, disponibilidad de personas). Se maneja con reservas y alternativas.
Y una idea clave: gestionar riesgo no significa intentar eliminar toda incertidumbre. Eso es imposible y carísimo. Se trata de entender cuál importa, reducir la que conviene y aceptar conscientemente el resto.
Riesgo frente a otras cosas que se le parecen
| ¿Es incierto? | Ejemplo | |
|---|---|---|
| Riesgo | Sí, futuro | "El proveedor podría retrasar la API" |
| Problema (issue) | No, ya ocurrió | "El proveedor ha retrasado la API" |
| Causa / hecho | No, es cierto ahora | "Dependemos de un proveedor externo para la API" |
| Supuesto | Lo damos por cierto sin comprobarlo | "Suponemos que la API estará en la semana 3" (si es falso → riesgo) |
"Confundir riesgo con problema ya ocurrido" es otro error frecuente de las diapositivas. Y el error más sutil: escribir una causa como si fuera un riesgo ("riesgo: tecnología nueva"). Que la tecnología sea nueva es un hecho; el riesgo es lo que podría pasar por ello.
2. La gestión moderna del riesgo
Las diapositivas marcan un cambio importante:Tema 2, diap. 9. Fuentes: ISO 31000:2018; PMI (2021).
- Continua: no se hace una vez al principio ("identificar riesgos una sola vez" es un error frecuente).
- Integrada en decisiones, planificación y ejecución: un riesgo importante cambia el plan (p. ej., adelantar el prototipo de la integración GPS).
- Conectada con stakeholders, producto, arquitectura y operaciones: la diap. 43 dibuja los riesgos en el centro, unidos a requisitos, arquitectura, planificación y estimaciones, calidad y deuda técnica, stakeholders, operación y seguridad. Cualquier decisión en esas áreas crea, reduce o cambia riesgos.Tema 2, diap. 43.
El proceso: cuatro actividades en ciclo
El ciclo se repite durante todo el proyecto: en el seguimiento aparecen riesgos nuevos que vuelven a identificación. Fíjate en que es un PDCA (lección 11) aplicado a la incertidumbre.Tema 2, diap. 10.
Artefactos principales
- Registro de riesgos (estructura en la sección 5).
- Valoración / mapa de riesgos: la matriz probabilidad-impacto (lección 13).
- Planes de respuesta.
- Indicadores de riesgo (KRIs).
- Decisiones, responsables y fechas de revisión.Tema 2, diap. 11.
3. Formular un riesgo para que sirva
El objetivo de la identificación es descubrir incertidumbres que puedan afectar a los objetivos, y no basta con listar "cosas malas". Un riesgo se formula con una estructura:Tema 2, diap. 12-13.
El ejemplo de las diapositivas:
| Causa | Dependencia de un proveedor |
|---|---|
| Evento | El proveedor retrasa la API |
| Consecuencia | Se retrasa la integración y la entrega |
| Probabilidad | Alta |
| Severidad / impacto | Media |
Una plantilla útil en una sola frase (el "metalenguaje del riesgo" de David Hillson, citado en la bibliografía de las diapositivas):Ampliación. Hillson, D. (2009). Managing Risk in Projects, Gower.
Por qué esta estructura facilita analizar y tratar el riesgo: cada parte señala un tipo de acción distinto.
- Actuar sobre la causa → evitar (eliminar la dependencia: usar otra fuente de datos).
- Actuar sobre la probabilidad del evento → mitigar (pedir la API ya, con penalización contractual por retraso).
- Actuar sobre la consecuencia → mitigar el impacto o preparar contingencia (tener un simulador de la API para que la app avance; tener datos de horarios teóricos como respaldo).
Comparación: mal formulado frente a bien formulado
| Mal | Por qué | Bien |
|---|---|---|
| "Flutter" | Es una causa (un hecho), no un riesgo | "Debido a que el equipo no ha usado Flutter, la integración con el GPS nativo podría resultar más compleja de lo estimado, lo que retrasaría la app móvil 2-4 semanas" |
| "Retrasos" | Es una consecuencia genérica: ¿por qué? ¿cuánto? | "Debido a que el ayuntamiento debe aprobar cada diseño, la aprobación podría tardar más de 3 días por entrega, lo que alargaría cada iteración" |
| "El servidor se ha caído" | Es un problema, ya ha ocurrido | (Va al registro de problemas) |
| "Que salga todo mal" | Ni causa ni evento concreto; no se puede tratar | Descomponerlo en riesgos concretos |
Propietario desde el principio
Las diapositivas piden asignar propietario desde el principio. El propietario no es el culpable: es quien vigila las señales, impulsa las respuestas y actualiza el estado. Sin propietario, el riesgo "queda huérfano" y nadie lo vigila. (Se desarrolla en la lección 13.)Tema 2, diap. 31.
4. De dónde vienen los riesgos
Las diapositivas dan seis fuentes clásicas:Tema 2, diap. 14.
| Fuente | Ejemplo en TusBus |
|---|---|
| Tecnología y arquitectura | El cálculo de llegada en tiempo real no escala a 50.000 usuarios en hora punta |
| Personas y conocimiento | Sólo una persona sabe cómo funciona la ingesta de GPS (bus factor = 1, lección 16) |
| Organización y proveedores | El ayuntamiento cambia de concejal tras las elecciones y se pierde el sponsor |
| Requisitos y stakeholders | Las asociaciones vecinales piden accesibilidad que no estaba en el alcance |
| Planificación, estimaciones y dependencias | La estimación del backend se hizo en la boca ancha del cono (lección 10) |
| Seguridad, privacidad y cumplimiento | La geolocalización de usuarios exige una evaluación de impacto de protección de datos (lección 17) |
Esta lista funciona como taxonomía (o RBS, Risk Breakdown Structure, en terminología PMI): se recorre categoría por categoría para no dejarse áreas enteras sin mirar.
Nuevas fuentes especialmente relevantes
El temario insiste en fuentes que hace 15 años apenas se consideraban:Tema 2, diap. 15.
- Dependencias y software de terceros: un proyecto moderno tiene cientos de bibliotecas de código abierto.
- Cadena de suministro de software (supply chain): todo lo que interviene en construir y entregar el software.
- Servicios cloud y concentración de proveedores: si todo está en un único proveedor, su caída es tu caída.
- Vulnerabilidades y exposición operacional.
- Datos y modelos de IA.
- Uso de IA generativa durante el desarrollo.
- Uso de IA generativa por adversarios (ataques más baratos y sofisticados).
Riesgos de seguridad y supply chain
Basados en NIST SP 800-161 Rev. 1:Tema 2, diap. 18.
- Dependencias vulnerables o abandonadas. Ej. real: Log4Shell (dic. 2021), una vulnerabilidad crítica en la biblioteca de logging Log4j, presente en millones de sistemas Java que ni sabían que la usaban.
- Compromiso de proveedores o artefactos. Ej.: SolarWinds (2020), donde atacantes insertaron código malicioso en una actualización legítima del producto.
- Credenciales y secretos expuestos (claves de API subidas al repositorio).
- Ataques a CI/CD o repositorios. Ej.: la puerta trasera en xz-utils (2024), introducida por un "mantenedor" que se ganó la confianza del proyecto durante años.
- Riesgos de integridad y procedencia del software: ¿el binario que despliegas es realmente el que salió de tu código?Ejemplos: ampliación. Ver Log4Shell, XZ Utils backdoor.
Riesgos en proyectos con IA
Basados en el NIST AI RMF 1.0 y su perfil de IA generativa (NIST AI 600-1):Tema 2, diap. 19. NIST AI RMF.
- Calidad y representatividad de los datos: un modelo que predice llegadas entrenado sólo con datos de días laborables falla en festivos.
- Drift y cambios en el entorno: el modelo se degrada cuando cambia la realidad (nuevas líneas, obras).
- Alucinaciones / comportamiento no fiable.
- Privacidad, propiedad intelectual y datos sensibles.
- Seguridad de modelos y prompts (p. ej. inyección de prompts).
- Dificultad de evaluación y monitorización: es difícil saber si un modelo "funciona bien".
El ejemplo de las diapositivas, formulado con la estructura de esta lección:Tema 2, diap. 40.
| Riesgo (evento) | El asistente genera código inseguro |
|---|---|
| Causa | Confianza excesiva en la salida |
| Consecuencia | Vulnerabilidad introducida en producción |
| Mitigación | Revisión humana + análisis automatizado + tests de seguridad |
| KRI | Defectos/vulnerabilidades detectados en código generado |
5. Técnicas de identificación
Las seis técnicas del temario, y cuándo brilla cada una:Tema 2, diap. 16.
| Técnica | Cómo | Fuerte en |
|---|---|---|
| Brainstorming estructurado | Sesión del equipo generando riesgos, guiada por categorías | Cantidad y diversidad de ideas |
| Checklists y taxonomías | Recorrer una lista de riesgos típicos o la RBS | No olvidar categorías enteras |
| Entrevistas con expertos y stakeholders | Preguntar a quien sabe del dominio o se ve afectado | Riesgos que el equipo no ve (negocio, legales) |
| Premortem | "El proyecto ha fracasado, ¿por qué?" | Vencer el exceso de confianza |
| Revisión de arquitectura y dependencias | Analizar componentes, integraciones, terceros, puntos únicos de fallo | Riesgos técnicos y de supply chain |
| Lecciones aprendidas | Revisar qué falló en proyectos anteriores (lección 11) | Riesgos que la organización ya conoce |
El análisis premortem
Propuesto por el psicólogo Gary Klein.Tema 2, diap. 17. Klein, G. (2007), "Performing a Project Premortem", Harvard Business Review. hbr.org. Funciona así:
- Imaginar que el proyecto ha fracasado: "Es el día después de la feria. TusBus ha sido un desastre".
- Cada persona escribe, por separado, por qué ha fracasado: identificar retrospectivamente las causas.
- Se ponen en común y se convierten las causas plausibles en riesgos formulados.
¿Por qué funciona mejor que preguntar "qué podría salir mal"? Porque evita el sesgo de exceso de confianza: en la fase de arranque el equipo está ilusionado y nadie quiere parecer pesimista. Al dar por hecho el fracaso, se vuelve legítimo (incluso creativo) explicar sus causas, y salen cosas que nadie se atrevía a decir ("el concejal no tiene el apoyo del departamento de informática").
6. El registro de riesgos
La estructura recomendada:Tema 2, diap. 41.
| ID | Descripción · causa · consecuencia | P | I | Exp. | Propietario | Respuesta · acciones | KRI / trigger | Revisión | Estado |
|---|---|---|---|---|---|---|---|---|---|
| R-03 | Por depender del ayuntamiento, la API de GPS podría llegar tarde → retraso de la integración y la entrega | Alta | Media | Alta | Ana (JP) | Mitigar: solicitar ya + simulador de la API | API no disponible en sem. 3 | Semanal | En tratamiento |
Estados: abierto → en tratamiento → materializado → cerrado. "Materializado" significa que se ha convertido en problema (va también al registro de problemas y se activa la contingencia).
Y lo más importante: un buen registro no es un inventario burocrático. Cada riesgo importante debe conducir a una decisión: ¿qué hacemos? ¿quién lo hace? ¿cuándo? ¿cómo sabremos que la exposición ha cambiado?Tema 2, diap. 42.
Errores frecuentes
La lista completa de las diapositivas, que es casi una pregunta de examen en sí misma:Tema 2, diap. 44.
- Identificar riesgos una sola vez.
- Registrar riesgos sin propietario.
- Confundir riesgo con problema ya ocurrido.
- Usar matrices sin criterios definidos.
- No actualizar probabilidades/impactos.
- Ignorar riesgos positivos.
- Tratar riesgos técnicos como asunto exclusivo del equipo técnico (un riesgo técnico afecta a plazo, coste y negocio: el sponsor debe conocerlo).
- "Riesgo = algo malo que puede pasar": también incluye oportunidades.
- "El objetivo es eliminar toda la incertidumbre": es imposible; el objetivo es mejorar las decisiones bajo incertidumbre.
- "Usamos una tecnología nueva" como riesgo: es una causa; falta el evento y la consecuencia.
- "El propietario del riesgo es quien tendrá la culpa si ocurre": es quien lo vigila e impulsa las respuestas.
- "El premortem analiza un proyecto que ya ha fracasado": se hace al principio, imaginando el fracaso. El que se hace después es el postmortem.
Práctica
Clasifica cada frase de TusBus.
- "El equipo nunca ha trabajado con Flutter"
- "La integración con el GPS nativo podría llevar el doble de lo estimado"
- "La build de iOS lleva tres días fallando"
- "El ayuntamiento podría liberar una API oficial que nos ahorre semanas"
- "Damos por hecho que el ayuntamiento revisará cada entrega en 3 días"
¿Cuál de estas formulaciones de riesgo es la más útil?
- Riesgo tecnológico alto por la complejidad general del sistema de GPS
- Retrasos en el proyecto por problemas diversos con los proveedores
- Posibles fallos de seguridad debidos a la falta de experiencia previa
- Por depender del ayuntamiento, la API podría llegar tarde y retrasar la entrega
El equipo de TusBus está muy ilusionado y en la sesión de riesgos casi nadie propone nada. ¿Qué técnica es la más adecuada?
- Premortem: imaginar que el proyecto ha fracasado
- Checklist de riesgos típicos de proyectos de apps
- Análisis cuantitativo con simulación Monte Carlo
- Entrevista individual con el concejal patrocinador
¿Cuáles son riesgos de seguridad y supply chain según el temario?
- Una biblioteca de la que dependemos lleva dos años sin mantenimiento
- Una clave de la API de mapas está subida en el repositorio público
- El cliente podría pedir más funcionalidades durante el desarrollo
- Un atacante podría modificar el pipeline de CI para inyectar código
- El equipo podría estimar mal el tamaño de las historias de usuario
Verdadero o falso: "Un riesgo técnico, como la escalabilidad del backend, debe gestionarlo exclusivamente el equipo técnico, que es quien lo entiende".
- Verdadero
- Falso
¿Qué elementos del registro de riesgos recomienda el temario?
- Propietario
- KRI / trigger
- Persona culpable
- Fecha de revisión
- Estado
- Línea de código
Formula con la estructura causa → evento → consecuencia un riesgo para un proyecto en el que el equipo usa un asistente de IA para generar gran parte del código. Indica también una acción y un KRI.
Repaso espaciado · lecciones 3, 8, 11
"Suponemos que el proveedor entregará los servidores en enero." ¿Qué relación tiene un supuesto con la gestión de riesgos?
- Ninguna, los supuestos van en el charter y los riesgos aparte
- Un supuesto es un riesgo que ya se ha materializado en el proyecto
- Los supuestos sustituyen a los riesgos en los proyectos predictivos
- Si el supuesto resulta falso, afecta a los objetivos: es una fuente de riesgo
Un stakeholder con mucho poder y poco interés en el proyecto. Según la matriz poder/interés, ¿cómo se gestiona?
- Mantener satisfecho
- Gestionar de cerca
- Mantener informado
- Monitorizar
Para profundizar
Klein, G. (2007). "Performing a Project Premortem", Harvard Business Review (artículo corto, se lee en 5 minutos). Para el marco general: ISO 31000:2018 (definiciones de riesgo, gratuitas en la plataforma de consulta de ISO) y el PMBOK 7, dominio de Incertidumbre.
Escoge tu proyecto de prácticas y haz un premortem de 10 minutos: escribe 5 causas de fracaso y conviértelas en riesgos con la estructura causa → evento → consecuencia. Pídele a un asistente que critique tus formulaciones. Si dudas entre "riesgo o problema", pregúntate: ¿ya ha pasado?
Resúmenes imprimibles: Tema 2 · Aspectos transversales · Glosario.