Que no se te rompa el jarrón: una docena de técnicas para identificar riesgos

A los tres meses de empezar el proyecto, un proveedor clave anuncia que deja de fabricar un componente del que depende tu diseño. Después, alguien de compras comenta que el proveedor llevaba un año dejándolo caer. Nadie se lo había preguntado.

Muchos registros de riesgos se escriben en una sola reunión, a cargo del jefe de proyecto y de memoria. Recogen los riesgos que todo el mundo esperaba, como un retraso en una entrega o una desviación del presupuesto, y se dejan los que solo alguien de fuera de la sala podría haber nombrado.

Identificar riesgos consiste en encontrar y describir los sucesos que podrían afectar a los objetivos del proyecto antes de que ocurran, para que cada uno pueda evaluarse y recibir una respuesta.

No hay ninguna fórmula que produzca una lista completa. Lo que sí hay es un conjunto de técnicas: la norma IEC 31010:2019, el estándar internacional sobre técnicas de evaluación del riesgo, describe más de cuarenta. Este artículo recoge doce que un equipo de proyecto puede aplicar sin un especialista en riesgos, agrupadas según dónde buscan los riesgos.

Combina varias, porque cada una encuentra riesgos que a las demás se les escapan. Las técnicas ordenan la conversación; quien identifica los riesgos es tu equipo.

Las doce técnicas de un vistazo

Técnica	Útil sobre todo para	Esfuerzo	Quién participa
DAFO	Un primer repaso amplio	Bajo	Equipo y dirección
Tormenta de ideas	Muchas ideas, rápido	Bajo	Todo el equipo
SWIFT	Planes y procesos	Medio	Equipo y facilitador
Análisis de escenarios	Proyectos largos	Medio	Equipo y dirección
Checklists	Trabajo rutinario	Bajo	Jefe de proyecto
Análisis de incidentes	Fallos que se repiten	Medio	Quien lo vivió
Observación directa	Primeros avisos	Bajo	Todo el equipo
Árbol de fallos	Un suceso que temes	Alto	Expertos técnicos
Pajarita	Riesgos graves y controles	Medio	Equipo y gestor de riesgos
Entrevistas	Escuchar a personas clave	Medio	Una persona cada vez
Encuestas	Llegar a mucha gente	Bajo	Un grupo amplio
Delphi	Juicio experto	Alto	Panel de expertos

Talleres que sacan los riesgos del equipo

1. Análisis DAFO

El DAFO (debilidades, amenazas, fortalezas y oportunidades) es una herramienta general de gestión más que una técnica de riesgos en sentido estricto. Lo conoce casi todo el mundo, así que funciona bien como ejercicio para arrancar.

Su valor está en la amplitud. Las debilidades internas del proyecto suelen apuntar a amenazas externas, y la columna de oportunidades recuerda al equipo que algunos sucesos inciertos merecen que se vaya a por ellos.

2. Tormenta de ideas

La tormenta de ideas, o brainstorming, es una de las formas más habituales de identificar riesgos: un grupo propone posibles problemas en voz alta y una persona que hace de facilitador los apunta donde todos puedan verlos. Tiene tres variantes principales:

• Tormenta de ideas libre. Cada cual dice las ideas según se le ocurren y se apoya en lo que proponen los demás. Es rápida, pero las voces más seguras de sí mismas tienden a acaparar la sesión.
• Tormenta de ideas estructurada. El facilitador da la palabra por turnos para que todos aporten, sea cual sea su cargo o su carácter, a costa de algo de espontaneidad.
• Tormenta de ideas en silencio. Cada persona escribe sus ideas en notas adhesivas o en un tablero compartido, y después se ponen en común y se agrupan. Va bien en equipos con miembros más callados.

La sesión deja una lista que alguien tiene que pasar después al registro de riesgos. Si tu equipo usa un asistente de IA conectado a través del servidor MCP de ITM Platform, el asistente puede crear esos riesgos en el proyecto con tus propios permisos. En Servidor MCP se explica la configuración y qué puede leer y escribir un asistente.

3. SWIFT

La técnica estructurada “¿Y si…?” (SWIFT, por sus siglas en inglés) es un taller guiado. El facilitador recorre con el equipo un plan o un proceso paso a paso y repite una y otra vez la misma pregunta: ¿y si el entorno de pruebas no está listo?, ¿y si la migración de datos tarda el doble?

Suele partir de una tormenta de ideas. Cada riesgo que sale se examina después con sus causas probables, sus consecuencias y los controles que ya existen, lo que además deja ver cómo dependen unos riesgos de otros.

4. Análisis de escenarios

El análisis de escenarios describe unos pocos futuros verosímiles y sigue lo que cada uno haría con el proyecto: un socio clave se retira, la demanda se duplica, cambia una normativa a mitad de camino. Mientras SWIFT examina sucesos aislados, un escenario combina varios cambios en una sola imagen.

Encaja en proyectos largos, en los que es más probable que el contexto cambie. Para cada escenario, el equipo acuerda qué efecto tendría y qué conviene preparar.

Aprender de lo que ya ha pasado

5. Listas de comprobación (checklists)

Una lista de comprobación de riesgos reúne los riesgos que aparecieron en proyectos anteriores parecidos, y el equipo la revisa punto por punto. Las organizaciones suelen construirlas a partir de las lecciones aprendidas, a veces agrupadas por origen: técnico, comercial, organizativo y externo.

Para trabajos conocidos y repetidos, las listas son rápidas y exhaustivas. Solo contienen lo que alguien ya ha visto, así que se les escapa lo nuevo. Úsala como punto de partida y pregúntate qué es distinto esta vez.

6. Análisis de incidentes

Algunos riesgos que nadie identificó acabarán apareciendo durante el proyecto. Cuando ocurra, analiza por qué pasó y qué efecto tuvo en el proyecto, y deja constancia de ambas cosas.

Ese registro sirve de base para detectar riesgos futuros y para actualizar tus listas de comprobación. Si el mismo tipo de incidente vuelve una y otra vez, busca una causa más profunda.

7. Observación directa

La observación directa no sigue ningún procedimiento formal y, aun así, suele dar el primer aviso. Quienes hacen el trabajo son normalmente los primeros en notarlo: un proveedor que tarda más en contestar, un componente que falla más en las pruebas, una parte interesada que deja de ir a las revisiones. Haz que sea fácil y normal que lo cuenten, y trata esos avisos como riesgos candidatos.

En una cartera de proyectos, la observación también puede extenderse a los datos. PMPilot, el asistente de IA integrado en ITM Platform, responde preguntas en lenguaje natural sobre los datos de los proyectos, y uno de sus ejemplos documentados es “¿Qué proyectos están en problemas pero no tienen indicadores de riesgo?”. La respuesta señala riesgos que probablemente existen pero que nadie ha registrado. En Análisis de datos con PMPilot se describen las preguntas que puede responder.

Seguir las causas y las consecuencias de un riesgo

8. Análisis de árbol de fallos

El análisis de árbol de fallos parte de un suceso no deseado, que se coloca en lo alto del diagrama, y va bajando por sus causas con la forma de un árbol invertido. Cada nivel responde a la misma pregunta: qué podría provocar lo que está en el nivel de arriba.

Los niveles más profundos llegan a las causas de las causas. Una puesta en producción tardía puede deberse a una integración que se retrasó, y esta a una especificación de interfaz de la que nadie se hacía cargo. Cada rama es un riesgo en sí misma, y las causas raíz son las que merece la pena atacar.

9. Análisis de pajarita

El análisis de pajarita, o bow tie, coloca un riesgo en el centro del diagrama. A la izquierda se abren en abanico las causas que podrían desencadenarlo, de forma parecida a un árbol de fallos, y a la derecha sus posibles consecuencias. Entre unas y otras se sitúan los controles: los controles preventivos, en el lado de las causas, evitan que el riesgo llegue a producirse, y los controles de mitigación, en el lado de las consecuencias, limitan el daño si se produce.

El diagrama deja a la vista los huecos, como una causa sin ningún control preventivo. Una secuencia práctica es identificar primero los riesgos con una tormenta de ideas y dibujar después una pajarita para cada uno de los más graves.

Consultar a las personas una a una

10. Entrevistas estructuradas

En una entrevista estructurada haces las mismas preguntas preparadas a personas de distintos puestos y niveles, con margen para repreguntar. A solas, la gente plantea preocupaciones que en grupo se guardaría, y tú puedes tirar del hilo cuando una respuesta abre una línea que no esperabas.

11. Encuestas

Una encuesta lleva la misma idea por escrito a muchas más personas. Se apoya sobre todo en preguntas cerradas, de modo que las respuestas son fáciles de comparar en un grupo grande, a cambio de perder la profundidad de una entrevista. Úsala cuando las personas que podrían saber algo de los riesgos son muchas o están repartidas, y comenta en persona las respuestas que lo merezcan.

12. Método Delphi

El método Delphi reúne el juicio de un grupo de expertos sin juntarlos. Cada experto responde a un cuestionario de forma independiente y anónima. Un facilitador resume las respuestas y devuelve ese resumen al grupo, y los expertos revisan su opinión durante varias rondas hasta que sus posiciones se acercan.

El anonimato impide que la voz con más cargo o más capacidad de persuasión arrastre el resultado. El coste es el tiempo, porque varias rondas pueden llevar semanas, así que Delphi encaja en cuestiones de mucho peso.

Cuando ya tienes la lista

La identificación produce una lista de riesgos candidatos, y cada uno necesita después una evaluación y una respuesta. Hasta dónde llegar lo decide el apetito de riesgo del cliente: un cliente que acepta cierta incertidumbre en los plazos a cambio de un precio más bajo querrá tratar menos riesgos que otro con una fecha de lanzamiento cerrada.

En ITM Platform, cada riesgo identificado tiene su propia ficha con una clasificación, una probabilidad y un impacto, que determinan su nivel en una matriz de riesgo configurable. La ficha también recoge un responsable del riesgo, un plan de mitigación, un plan de contingencia y las tareas a las que afectaría, y el riesgo puede escalarse a incidencia si llega a materializarse. En Gestión de riesgos e incidencias se explica cada campo.

Para ver qué podrían provocar los riesgos identificados en conjunto, la simulación de Montecarlo asigna una distribución de probabilidad a cada riesgo y a cada estimación incierta, y ejecuta miles de iteraciones que muestran el abanico de posibles fechas de fin o costes. No encuentra riesgos nuevos, pero sí muestra cuáles de los que has encontrado pesan más sobre la fecha de fin o el presupuesto.

Siguientes pasos

• Prueba ITM Platform y registra los riesgos de tu próxima sesión de identificación, cada uno con su probabilidad, su impacto y sus planes de respuesta.
• 6 pasos para controlar el riesgo trata lo que viene después de la identificación, desde el análisis hasta la planificación de la respuesta y el seguimiento.
• Mira cómo se conectan los agentes de IA a ITM Platform mediante MCP y trabajan con proyectos, tareas y riesgos según tus permisos.