Entienda cómo estructurar la gestión de riesgos en proyectos de ingeniería, integrar respuestas con plazo, costes y contratos y apoyar la toma de decisiones.
¡Descúbrelo!
La gestión de riesgos en proyectos de ingeniería es el sistema utilizado para reconocer incertidumbres, comprender sus causas y consecuencias, definir respuestas, asignar responsabilidades e incorporar los efectos potenciales en las decisiones de alcance, plazo, costes, contratos, calidad, seguridad y operación.
El tema no se limita a completar una matriz de probabilidad e impacto. Una matriz puede clasificar exposiciones, pero no garantiza que los riesgos tengan responsables, respuestas financiadas, gatillos monitorizados, relación con el cronograma o influencia sobre el forecast.
En proyectos multidisciplinares, la gestión de riesgos debe conectar ingeniería, procurement, contratos, Project Controls, inspección, puesta en marcha, operación y gobernanza. El riesgo solo se vuelve gestionable cuando la organización puede responder: qué evento puede ocurrir, por qué puede ocurrir, qué objetivos se verían afectados, quién debe actuar, hasta cuándo existe una ventana de decisión y cómo verificar si la respuesta redujo la exposición.
ISO 31000:2018 presenta principios y directrices para integrar la gestión de riesgos en la gobernanza, la estrategia, la planificación y los procesos organizativos. IEC 31010:2019 orienta la selección y aplicación de técnicas de evaluación de riesgos en distintos contextos.
¿Qué es la gestión de riesgos en proyectos?
La gestión de riesgos es el conjunto coordinado de actividades utilizado para dirigir y controlar una organización en relación con las incertidumbres que pueden afectar sus objetivos.
En el contexto de proyectos de ingeniería, estas incertidumbres pueden representar amenazas u oportunidades relacionadas con:
- madurez de requisitos;
- condiciones de campo;
- interfaces multidisciplinares;
- licencias y autorizaciones;
- desempeño de proveedores;
- disponibilidad de recursos;
- productividad;
- tecnología;
- seguridad;
- contratos;
- inflación y mercado;
- integración de sistemas;
- puesta en marcha;
- operación y mantenimiento.
El riesgo no existe de forma abstracta. Debe estar relacionado con un objetivo, una causa, un evento y una consecuencia potencial.
Una descripción útil puede seguir esta estructura:
Debido a una causa o condición, puede ocurrir un evento, produciendo una determinada consecuencia sobre un objetivo del proyecto.
Ejemplo:
> Debido a la definición incompleta de las interfaces eléctricas del equipo importado, puede producirse una revisión tardía del diseño detallado, causando retrabajo, retraso en la fabricación de los paneles y aumento de costes.
Esta formulación es más útil que registros genéricos como “riesgo de retraso” o “proveedor”, ya que permite definir respuestas y gatillos específicos.
¿Qué problema de gestión resuelve el proceso de riesgos?
Los proyectos de ingeniería siempre operan con información incompleta. El problema no es eliminar la incertidumbre, sino impedir que permanezca invisible hasta convertirse en retraso, sobrecoste, no conformidad o conflicto contractual.
| Problema de gestión | Consecuencia | Respuesta del proceso de riesgos | Beneficio esperado |
| Premisas tratadas como hechos | Las decisiones se toman sobre una base frágil | Registro de incertidumbres, responsables y validaciones | Mayor transparencia sobre la madurez |
| Riesgos descritos de forma genérica | No es posible definir una respuesta objetiva | Estructura causa–evento–consecuencia | Mejor calidad del tratamiento |
| Matriz actualizada solo para informes | Las exposiciones no influyen en el plan | Integración con cronograma, costes y contratos | Gestión efectiva, no meramente documental |
| Responsabilidad atribuida al gerente | Los riesgos técnicos quedan sin un owner competente | Risk owner y action owner definidos | Responsabilidad clara |
| Respuestas sin presupuesto o plazo | Los planes no se ejecutan | Acciones vinculadas a recursos, fechas y criterios | Mayor viabilidad de las respuestas |
| Riesgos analizados de forma aislada | No se perciben los efectos combinados | Consolidación, dependencias y escenarios | Visión integrada de la exposición |
| Materializaciones tratadas como sorpresa | El forecast permanece optimista | Gatillos, indicadores y revisión periódica | Anticipación de consecuencias |
| Contingencia sin base | Las reservas son arbitrarias o insuficientes | Análisis cualitativo y cuantitativo | Mejor fundamentación de reservas |
| Contratos sin asignación coherente | Los riesgos se transfieren a partes incapaces de controlarlos | Estrategia contractual y matriz de responsabilidades | Menos reclamaciones e interfaces poco claras |
| Lecciones no preservadas | Los mismos riesgos se repiten | Acervo, materializaciones y eficacia de las respuestas | Mejora de proyectos futuros |
La gestión de riesgos transforma la incertidumbre en información estructurada para la toma de decisiones. No garantiza que no ocurran eventos negativos, pero aumenta la capacidad de evitarlos, reducir sus efectos o responder de forma preparada.
La matriz clasifica; la gobernanza decide y controla. Sin owners, respuestas, recursos, gatillos, niveles de autoridad e integración con el plan, el registro de riesgos permanece únicamente como evidencia documental.
Conozca la solución de Gobernanza de Proyectos, Programas y Portafolios.
¿Riesgo, problema, premisa, restricción y cambio son lo mismo?
No. Confundir estos conceptos perjudica el tratamiento y los registros.
| Concepto | Definición operativa | Ejemplo | Tratamiento principal |
| riesgo | evento futuro incierto que puede afectar objetivos | el proveedor puede retrasar la fabricación | prevención, mitigación, transferencia o aceptación |
| problema o issue | evento que ya ocurrió o condición actual | el proveedor informó un retraso de cuatro semanas | acción correctiva, recuperación y actualización del forecast |
| premisa | condición considerada verdadera para planificar | acceso al sitio disponible en agosto | validación, plazo y responsable |
| restricción | límite que condiciona el proyecto | desconexión permitida solo los domingos | incorporación al plan y control |
| cambio | alteración propuesta o aprobada en la referencia | nuevo requisito de redundancia | análisis de impacto y change control |
| decisión pendiente | elección necesaria para la continuidad | seleccionar arquitectura de comunicación | nivel de autoridad, fecha límite y alternativas |
| oportunidad | incertidumbre con efecto potencial favorable | anticipar fabricación por lote | explotar, mejorar, compartir o aceptar |
Un riesgo materializado deja de tratarse únicamente como riesgo. Debe incorporarse al proceso de problemas, cambios, contratos, cronograma y forecast, preservando el vínculo con el registro original.
Gestión de riesgos y matriz de riesgos: ¿cuál es la diferencia?
La Matriz de Riesgos en Proyectos de Ingeniería es una herramienta de clasificación. Cruza criterios como probabilidad e impacto para apoyar la priorización.
La gestión de riesgos es el proceso completo.
| Matriz de riesgos | Gestión de riesgos |
| representa la exposición en una cuadrícula | integra principios, procesos, personas, datos y decisiones |
| clasifica riesgos en un momento determinado | acompaña el ciclo de vida de la exposición |
| ayuda a priorizar | define respuestas, responsables y recursos |
| normalmente utiliza evaluación cualitativa | puede incluir análisis cuantitativo y escenarios |
| no controla acciones por sí sola | monitoriza gatillos, acciones y eficacia |
| puede ser un artefacto aislado | debe integrar cronograma, costes, contratos y gates |
El nuevo contenido no sustituye el artículo de la matriz. La matriz responde “¿qué exposición merece prioridad?”. El proceso responde “¿cómo comprenderá, tratará, financiará, monitorizará y decidirá la organización sobre esa exposición?”.
¿Qué principios sustentan una gestión de riesgos madura?
ISO 31000 orienta un enfoque integrado, estructurado, personalizado, inclusivo, dinámico y basado en la mejor información disponible.
En proyectos de ingeniería, estos principios pueden traducirse a la práctica de la siguiente manera:
| Principio | Aplicación práctica |
| integración | los riesgos participan en planificación, diseño, contratos, cambios y gates |
| estructura y alcance | se definen criterios, roles, frecuencia y registros |
| personalización | el proceso es proporcional al tamaño, fase y criticidad |
| inclusión | participan disciplinas, contratistas, operación y stakeholders relevantes |
| dinamismo | los registros cambian según la información, las fases y los eventos |
| mejor información disponible | se declaran fuentes, limitaciones e incertidumbres |
| factores humanos y culturales | se consideran incentivos, comunicación y comportamiento |
| mejora continua | las materializaciones y la eficacia alimentan el acervo |
La gestión madura no depende únicamente de la técnica. La cultura debe permitir que los riesgos se comuniquen sin que el registro se interprete como incapacidad o pesimismo del equipo.
¿Cómo funciona el proceso de gestión de riesgos?
Un proceso consistente puede organizarse en diez componentes integrados.
- Definir contexto y objetivos. Comprender qué debe protegerse o alcanzarse.
- Establecer criterios. Definir escalas, tolerancias, categorías, niveles de autoridad y reglas.
- Identificar riesgos y oportunidades. Registrar causas, eventos, consecuencias y objetivos afectados.
- Analizar. Estimar probabilidad, impacto, proximidad, velocidad y relaciones.
- Evaluar y priorizar. Comparar la exposición con los criterios y la capacidad de tratamiento.
- Planificar respuestas. Seleccionar estrategia, acciones, recursos, responsables y plazos.
- Integrar en el proyecto. Actualizar cronograma, costes, contratos, contingencias y decisiones.
- Monitorizar. Acompañar gatillos, acciones, exposición residual y cambios de contexto.
- Comunicar y escalar. Llevar los asuntos a la autoridad adecuada antes de perder la ventana de decisión.
- Registrar y aprender. Preservar resultados, materializaciones y eficacia de las respuestas.
Estos componentes no ocurren una sola vez. El proceso es iterativo y debe acompañar el ciclo de vida del proyecto.
¿Cómo definir contexto, objetivos y criterios?
Antes de identificar riesgos, el equipo necesita saber qué objetivos serán evaluados y qué límites orientan la decisión.
El contexto puede incluir:
- objetivos estratégicos y beneficios;
- alcance y requisitos;
- fase y nivel de madurez;
- modelo de contratación;
- stakeholders y autoridades;
- restricciones operativas;
- entorno regulatorio;
- criterios de seguridad;
- capacidad financiera;
- tecnología e interfaces;
- dependencias externas;
- horizonte de decisión.
Los criterios de riesgo deben establecer cómo evaluará la organización las consecuencias y probabilidades. Una escala genérica aplicada a cualquier proyecto puede generar clasificaciones sin significado.
| Dimensión de impacto | Cuestiones a considerar |
| seguridad | ¿existe potencial de accidente, exposición o pérdida de una barrera? |
| operación | ¿el activo puede quedar indisponible u operar por debajo del requisito? |
| plazo | ¿qué hitos, caminos críticos o ventanas se verían afectados? |
| costes | ¿cuál es el rango de impacto y qué reserva podría consumirse? |
| calidad | ¿existe riesgo de retrabajo, rechazo o desempeño inadecuado? |
| contrato | ¿pueden surgir reclamaciones, penalizaciones o disputas de responsabilidad? |
| medio ambiente | ¿existe riesgo de licencia, impacto u obligación adicional? |
| reputación | ¿pueden verse afectados stakeholders, comunidad o dirección? |
| beneficios | ¿puede el proyecto entregar menos valor del esperado? |
Probabilidad e impacto no son los únicos criterios posibles. Proximidad, velocidad, detectabilidad, persistencia e interdependencia pueden modificar la prioridad.
Apetito, tolerancia y límite de riesgo: ¿cómo diferenciarlos?
| Concepto | Aplicación gerencial |
| apetito de riesgo | nivel y tipo de riesgo que la organización acepta asumir para perseguir objetivos |
| tolerancia | rango de variación aceptable alrededor de un objetivo o criterio |
| límite o threshold | punto que activa escalamiento, decisión o respuesta obligatoria |
| capacidad de riesgo | exposición máxima que la organización puede soportar |
En proyectos de ingeniería, estos conceptos deben traducirse en reglas operativas. Por ejemplo: ningún riesgo de seguridad clasificado como crítico puede ser aceptado por el gerente del proyecto; los riesgos con impacto potencial superior a un valor definido deben someterse al comité; los hitos regulatorios con una probabilidad de retraso por encima del límite requieren un plan alternativo.
El apetito de riesgo no significa aceptar negligencia o incumplimiento. Las obligaciones legales, normativas y de seguridad tienen tratamientos y niveles de autoridad propios.
¿Cómo identificar riesgos en proyectos de ingeniería?
La identificación debe involucrar diferentes fuentes y perspectivas. Los workshops aislados al inicio del proyecto no son suficientes.
Las fuentes útiles incluyen:
- base de diseño y premisas;
- WBS y cronograma;
- estudios y levantamientos;
- interfaces entre disciplinas;
- matriz de requisitos;
- estrategia de contratación;
- documentos de proveedores;
- registro de cambios;
- no conformidades;
- lecciones aprendidas;
- visitas de campo;
- procesos de puesta en marcha;
- análisis de stakeholders;
- benchmarks de proyectos comparables.
La identificación puede estructurarse por categorías:
| Categoría | Ejemplos de riesgo |
| requisitos y alcance | requisitos conflictivos, exclusiones poco claras o interfaces no definidas |
| ingeniería | datos incompletos, incompatibilidades, revisión tardía o tecnología inmadura |
| procurement | proveedor único, plazo de fabricación, obsolescencia o logística |
| construcción | acceso, productividad, interferencias, movilización o condiciones del sitio |
| integración | protocolos, responsabilidades, interoperabilidad o secuencia de pruebas |
| contratos | asignación inadecuada, ambigüedad, reclamaciones u obligaciones del propietario |
| regulatorio | licencia, aprobación, inspección o cambio de requisito |
| operación | indisponibilidad, ventana de intervención o mantenibilidad |
| personas y recursos | competencia, disponibilidad, rotación o carga excesiva |
| información | revisión incorrecta, fuente no controlada o retraso de aprobación |
| seguridad y medio ambiente | barreras insuficientes, condición peligrosa o impacto ambiental |
| financiero y mercado | inflación, cambio de divisas, disponibilidad de capital o precio de insumos |
La estructura de categorías mejora la cobertura, pero no debe limitar el pensamiento. Los riesgos relevantes surgen con frecuencia en las interfaces entre categorías.
¿Cómo redactar un riesgo de forma útil?
Un buen registro debe evitar expresiones vagas.
| Registro débil | Registro mejorado |
| riesgo de plazo | debido a la aprobación tardía de los documentos del proveedor, la fabricación puede comenzar después de la fecha necesaria, afectando la entrega del equipo y el camino crítico |
| problema de diseño | debido a la ausencia de un levantamiento fiable, pueden producirse interferencias entre la infraestructura existente y las nuevas rutas, causando retrabajo y paralización del frente |
| proveedor | debido a la dependencia de un único fabricante, una indisponibilidad de producción puede comprometer el hito de instalación |
| cambio de alcance | debido a la validación incompleta de los requisitos operativos, pueden surgir nuevos requisitos después de la contratación, causando cambio, reclamaciones y retraso |
Además de la descripción, el registro debe contener:
- identificador;
- categoría;
- causa;
- evento;
- consecuencia;
- objetivos afectados;
- risk owner;
- probabilidad e impactos;
- exposición inherente;
- estrategia de respuesta;
- acciones y responsables;
- fechas y gatillos;
- coste de la respuesta;
- riesgo residual;
- estado e historial;
- vínculos con actividades, contratos y cambios.
¿Cómo analizar riesgos cualitativamente?
El análisis cualitativo compara riesgos mediante escalas definidas. Es adecuado para la priorización inicial y la gestión de un gran número de exposiciones.
Los criterios pueden incluir:
- probabilidad;
- impacto por objetivo;
- proximidad;
- velocidad de materialización;
- detectabilidad;
- persistencia;
- urgencia de la respuesta;
- grado de control;
- interdependencia;
- calidad de los datos.
Un riesgo con baja probabilidad pero consecuencia catastrófica no debe tratarse automáticamente como irrelevante. La regla debe reflejar las obligaciones, la capacidad y el apetito de riesgo de la organización.
La clasificación debe ir acompañada de una justificación. Los números sin premisas generan falsa precisión y dificultan la auditoría.
¿Cuándo utilizar análisis cuantitativo de riesgos?
El análisis cuantitativo es útil cuando las decisiones dependen de rangos de plazo, costes, contingencias o probabilidad de cumplimiento de objetivos.
Las técnicas posibles incluyen:
| Técnica | Aplicación | Resultado |
| análisis de sensibilidad | identificar variables que más influyen en el resultado | ranking de factores impulsores |
| escenarios | comparar combinaciones plausibles de eventos | rangos y consecuencias |
| árbol de decisión | evaluar alternativas con probabilidades y resultados | valor esperado y decisión estructurada |
| simulación de Monte Carlo | combinar incertidumbres de duración o coste | distribución de resultados y niveles de confianza |
| análisis de valor monetario esperado | estimar exposición financiera media | referencia para reservas y comparación |
| FMEA | evaluar modos de fallo, efectos y controles | priorización de modos de fallo |
| HAZOP | examinar desviaciones de proceso y consecuencias | riesgos operativos y salvaguardas |
| bow-tie | relacionar causas, evento central, consecuencias y barreras | visión de prevención y mitigación |
| árbol de fallos | descomponer combinaciones causales | probabilidad y lógica de fallo |
| árbol de eventos | explorar secuencias después de un evento iniciador | escenarios de consecuencia |
IEC 31010:2019 presenta orientación para la selección y aplicación de técnicas. La herramienta debe elegirse según la pregunta, la calidad de los datos y la criticidad de la decisión.
El análisis cuantitativo no corrige una WBS débil, un cronograma sin lógica o una estimación sin premisas. Los modelos sofisticados pueden limitarse a cuantificar inconsistencias con apariencia de precisión.
El riesgo debe modificar el plan cuando cambia la exposición. Si una incertidumbre relevante no influye en el cronograma, los costes, las contingencias, los contratos o el forecast, el proceso de riesgos está desconectado de la gestión del proyecto.
Vea cómo integrar riesgos, indicadores e informes ejecutivos de ingeniería.
Riesgo inherente, residual y secundario: ¿cuáles son las diferencias?
| Tipo | Significado |
| riesgo inherente | exposición antes de aplicar las respuestas planificadas |
| riesgo residual | exposición que permanece después de implementar las respuestas |
| riesgo secundario | nuevo riesgo creado por la propia respuesta |
| riesgo emergente | exposición nueva o poco comprendida que gana relevancia |
| riesgo agregado | efecto combinado de múltiples riesgos sobre un objetivo |
Ejemplo: contratar un proveedor alternativo puede reducir el riesgo de retraso, pero crear un riesgo secundario de incompatibilidad, curva de aprendizaje o aumento de costes.
La aprobación de la respuesta debe considerar el conjunto de efectos, no únicamente la reducción de la clasificación original.
¿Qué estrategias de respuesta pueden utilizarse?
Para las amenazas, las estrategias comunes incluyen:
| Estrategia | Significado | Ejemplo en ingeniería |
| evitar | modificar el plan para eliminar la exposición | sustituir una tecnología aún no probada |
| mitigar | reducir probabilidad o impacto | realizar un prototipo, levantamiento adicional o revisión independiente |
| transferir o compartir | asignar parte de la responsabilidad a otra parte capaz de gestionarla | seguro, garantía o contrato especializado |
| aceptar | reconocer la exposición y preparar una respuesta proporcional | mantener contingencia y plan de fallback |
| escalar | remitir a una autoridad fuera del alcance del proyecto | riesgo estratégico o regulatorio corporativo |
Para las oportunidades:
| Estrategia | Significado | Ejemplo |
| explotar | actuar para garantizar la ocurrencia | anticipar la adquisición cuando el beneficio está demostrado |
| mejorar | aumentar probabilidad o beneficio | ampliar pruebas que pueden permitir una reducción de alcance |
| compartir | involucrar a una parte con capacidad para capturar el beneficio | alianza tecnológica |
| aceptar | aprovecharla si ocurre sin inversión adicional | ganancia eventual de productividad |
La respuesta debe ser específica. “Monitorizar”, “acompañar” o “prestar atención” no son tratamientos suficientes cuando existe una acción preventiva posible.
Risk owner y action owner: ¿quién es responsable?
El risk owner es responsable de acompañar la exposición, evaluar cambios y garantizar que el riesgo reciba el tratamiento y escalamiento adecuados.
El action owner ejecuta una acción específica del plan de respuesta.
Estas responsabilidades pueden asignarse a personas diferentes.
| Rol | Responsabilidad |
| patrocinador | definir el apetito de riesgo, decidir exposiciones estratégicas y proporcionar recursos |
| gerente del proyecto | integrar riesgos en el plan y las decisiones |
| risk owner | responder por la exposición y su evolución |
| action owner | ejecutar una acción específica dentro del plazo |
| disciplina técnica | identificar, analizar y tratar riesgos de su especialidad |
| Project Controls | integrar efectos en el cronograma, costes, contingencias y forecast |
| contratos | tratar asignación, obligaciones, seguros, garantías y reclamaciones |
| PMO | definir el método, consolidar el portafolio, auditar y mantener benchmarks |
| Owner’s Engineering | revisar críticamente riesgos y respuestas en defensa del propietario |
| comité o gate owner | decidir sobre exposición residual, condicionantes y avance de fase |
La Matriz RACI en Proyectos de Ingeniería puede organizar preparación, análisis, recomendación, aprobación y ejecución.
¿Cómo integrar los riesgos en el cronograma?
El registro de riesgos no debe existir separado de la programación.
La integración puede incluir:
- actividades de respuesta;
- hitos de decisión;
- gatillos;
- fechas límite;
- ventanas de oportunidad;
- actividades expuestas;
- efectos potenciales sobre duraciones;
- contingencia de plazo;
- escenarios de recuperación;
- vínculos con el camino crítico.
Un riesgo de proveedor debe indicar la fecha a partir de la cual la entrega afectará el camino crítico. Un riesgo regulatorio debe tener hitos de presentación, plazo de análisis y plan alternativo.
La Curva S muestra tendencias acumuladas, pero el cronograma identifica dónde el riesgo puede modificar la secuencia y la finalización. El artículo sobre la Curva S en proyectos de ingeniería explica la relación entre baseline, avance real y forecast.
¿Cómo integrar los riesgos con costes y contingencias?
La gestión de costes debe distinguir:
| Elemento | Función |
| estimación base | coste del alcance planificado según las premisas |
| contingencia | provisión para incertidumbres identificadas dentro del alcance |
| reserva de gestión | provisión bajo autoridad de gestión para exposiciones no asignadas o cambios controlados |
| presupuesto autorizado | valor aprobado para ejecución y gobernanza |
| cambio potencial | impacto en evaluación aún no aprobado |
| forecast | coste probable considerando desempeño, cambios y riesgos |
El consumo de contingencia debe seguir criterios y niveles de autoridad. No es un margen libre para compensar ineficiencia o modificaciones de alcance no autorizadas.
Los riesgos pueden tener estimaciones del coste de la respuesta, impacto potencial y rango residual. Esta información apoya decisiones sobre prevención, aceptación y reservas.
La Gestión del Valor Ganado mide el desempeño de alcance, plazo y costes, mientras que el proceso de riesgos incorpora eventos futuros que aún no aparecen en los índices acumulados.
¿Cómo integrar los riesgos en los contratos?
Transferir una obligación en el contrato no elimina el riesgo del proyecto. Si el contratista no dispone de capacidad financiera, técnica u operativa para controlar la exposición, el propietario seguirá sujeto a las consecuencias.
La estrategia contractual debe evaluar:
- la parte con mayor capacidad para controlar el riesgo;
- disponibilidad y coste de transferencia;
- interfaces entre contratos;
- seguros y garantías;
- criterios de medición y aceptación;
- eventos compensables;
- responsabilidades sobre la información;
- obligaciones del propietario;
- cambios y reclamaciones;
- límites de responsabilidad;
- incentivos y penalizaciones.
La Gestión de Contratos, Alcance y Entregables debe relacionar los riesgos con obligaciones, evidencias y decisiones.
Una matriz contractual de riesgos puede apoyar la asignación entre las partes, pero no sustituye el registro gerencial del proyecto. El riesgo debe seguir monitorizándose independientemente de quién haya asumido la obligación formal.
¿Cómo se relacionan los riesgos con los cambios y los problemas?
El proceso necesita transiciones claras.
| Situación | Encaminamiento |
| riesgo aún incierto | mantener en el registro, monitorizar gatillos y ejecutar respuestas |
| riesgo materializado | abrir un issue y actualizar cronograma, costes y forecast |
| la materialización modifica el alcance | iniciar control de cambios |
| el evento deriva de incumplimiento | activar la gestión contractual |
| la respuesta exige presupuesto adicional | someter la decisión al nivel de autoridad correspondiente |
| el riesgo deja de ser relevante | cerrar con justificación y preservar el historial |
| surge un nuevo riesgo de la respuesta | registrar el riesgo secundario |
El vínculo entre los registros evita que un evento se trate simultáneamente como riesgo, cambio y problema sin reconciliación.
¿Cómo utilizan los stage-gates la información de riesgos?
El proceso de Stage-gate en proyectos de ingeniería verifica si el proyecto tiene la madurez y el riesgo residual aceptables para avanzar.
Un gate puede evaluar:
- riesgos críticos y sus respectivos owners;
- exposición residual;
- respuestas concluidas y pendientes;
- contingencias de plazo y coste;
- premisas aún no validadas;
- riesgos de contratación;
- madurez de requisitos;
- preparación operativa;
- barreras de seguridad;
- condicionantes y fechas límite.
La decisión no necesita exigir riesgo cero. Debe registrar qué exposiciones se aceptan, por quién, bajo qué condiciones y con qué mecanismos de monitorización.
¿Cómo construir y mantener el registro de riesgos?
El risk register debe funcionar como un objeto vivo de gestión, no como una hoja de cálculo archivada.
| Campo | Finalidad |
| ID y título | identificación única y comunicación objetiva |
| causa–evento–consecuencia | descripción estructurada |
| categoría | agrupación y análisis de patrones |
| objetivos afectados | alcance, plazo, costes, calidad, seguridad o beneficios |
| exposición inherente | condición antes de la respuesta |
| owner | responsable de la exposición |
| respuesta | estrategia seleccionada |
| acciones | actividades, responsables, recursos y plazos |
| gatillos | señales que exigen una decisión o actualización |
| exposición residual | condición después de la respuesta |
| vínculos | actividades, contratos, documentos, cambios y decisiones |
| estado e historial | evolución, materialización, cierre y justificaciones |
La gobernanza debe definir quién puede crear, modificar, aprobar, aceptar y cerrar riesgos. Los cambios relevantes de clasificación deben justificarse.
¿Con qué frecuencia deben revisarse los riesgos?
La frecuencia depende de la velocidad, criticidad y fase del proyecto.
| Nivel | Frecuencia posible | Foco |
| operativo | semanal o según eventos | gatillos, acciones vencidas y riesgos de corto plazo |
| gerencial | quincenal o mensual | exposición consolidada, forecast y decisiones |
| ejecutivo | mensual o por gate | riesgos críticos, contingencias y niveles de autoridad |
| portafolio | periódica | concentración, dependencias y capacidad corporativa |
| extraordinario | cuando ocurre un evento relevante | materialización, cambio de contexto o escalamiento |
Los riesgos no deben esperar a la reunión mensual cuando la ventana de respuesta termina antes.
¿Qué indicadores pueden medir la eficacia de la gestión de riesgos?
| Indicador | Pregunta respondida |
| riesgos críticos sin owner | ¿existen exposiciones sin responsabilidad asignada? |
| acciones vencidas | ¿se está ejecutando el plan de respuesta? |
| tiempo de escalamiento | ¿la gobernanza decide antes de perder la ventana de decisión? |
| materializaciones sin riesgo previamente identificado | ¿la identificación es eficaz? |
| variación entre impacto previsto y real | ¿el análisis está calibrado? |
| consumo de contingencia | ¿las reservas son suficientes y están bien gobernadas? |
| exposición residual | ¿las respuestas redujeron el riesgo? |
| riesgos reabiertos | ¿los cierres fueron prematuros? |
| concentración por categoría | ¿dónde existen patrones sistémicos? |
| oportunidades capturadas | ¿el proceso también genera valor positivo? |
El artículo sobre KPI e indicadores de desempeño presenta cómo definir fórmula, fuente, responsable, límite y decisión asociada.
Los indicadores no deben incentivar el ocultamiento. Reducir el número de riesgos registrados puede significar mejora, pero también subregistro.
¿Cómo utilizar Pareto, Ishikawa, PDCA y 5W2H en la gestión de riesgos?
| Necesidad | Método | Aplicación |
| identificar concentración de materializaciones | Pareto | localizar categorías que concentran pérdidas o retrasos |
| investigar causas sistémicas | Ishikawa y 5 Porqués | organizar hipótesis y profundizar mecanismos causales |
| seleccionar respuestas con capacidad limitada | matriz de priorización | comparar impacto, urgencia, esfuerzo y dependencias |
| estructurar la mejora del proceso | PDCA | planificar, ejecutar, verificar y estandarizar |
| detallar acciones | 5W2H | definir responsable, plazo, recursos y método |
| controlar la ejecución | workflow | registrar estados, aprobaciones y evidencias |
| verificar eficacia | KPI | medir exposición, desempeño y resultado de las respuestas |
La secuencia puede representarse así:
el registro identifica exposiciones → la matriz prioriza → Pareto localiza patrones → Ishikawa investiga causas → PDCA estructura la mejora → 5W2H organiza acciones → KPI verifica la eficacia.
¿Qué técnicas utilizar para cada tipo de riesgo?
| Situación | Técnicas posibles |
| priorización general | matriz de probabilidad e impacto, scoring y heat map |
| riesgos de proceso | FMEA, HAZOP y bow-tie |
| confiabilidad del sistema | árbol de fallos, árbol de eventos y análisis de barreras |
| alternativas de decisión | árbol de decisión, escenarios y valor esperado |
| plazo y costes | Monte Carlo, sensibilidad y análisis de rangos |
| riesgos de interfaz | workshops, matriz de interfaces y análisis de dependencias |
| riesgos contractuales | revisión de cláusulas, matriz de asignación y análisis de obligaciones |
| riesgos emergentes | horizon scanning, escenarios y monitorización de señales |
| causas de materializaciones | Ishikawa, 5 Porqués y análisis de causa raíz |
La técnica debe ser proporcional. Aplicar un método complejo a datos débiles puede consumir esfuerzo sin mejorar la decisión.
¿Cómo aplicar la gestión de riesgos a lo largo del ciclo de vida del proyecto?
| Fase | Riesgos predominantes | Decisiones apoyadas |
| estrategia y portafolio | alineación, beneficios, capital y capacidad | seleccionar, aplazar o cancelar iniciativas |
| viabilidad | alternativas, premisas, ubicación y licencias | elegir solución y rango de inversión |
| proyecto conceptual y básico | requisitos, tecnología, interfaces y estimaciones | aprobar la base técnica y la contratación |
| proyecto ejecutivo | compatibilización, detalle y constructibilidad | liberar adquisición y ejecución |
| adquisiciones | proveedor, fabricación, logística y documentos | contratar, diligenciar y aceptar el suministro |
| construcción | productividad, condiciones de campo, seguridad y recursos | priorizar frentes y planes de recuperación |
| integración y puesta en marcha | interoperabilidad, pruebas, defectos y preparación | energizar, operar o mantener condicionantes |
| cierre | documentación, garantía, pendientes y transferencia | aceptar, cerrar e incorporar al acervo |
El perfil de riesgos cambia. Un registro copiado entre fases pierde relevancia y crea un exceso de elementos sin una decisión asociada.
¿Cómo actúa la gestión de riesgos en Owner’s Engineering?
En Owner’s Engineering — Ingeniería del Propietario, la gestión de riesgos protege los objetivos del contratante mediante un análisis independiente.
La actuación puede incluir:
- revisión de los registros de riesgos de los contratistas;
- identificación de exposiciones omitidas;
- evaluación de la asignación contractual;
- análisis de respuestas y contingencias;
- validación de premisas;
- revisión de cronogramas y forecasts;
- evaluación de cambios y reclamaciones;
- análisis de preparación para gates;
- verificación de riesgos de puesta en marcha y operación;
- recomendación de decisiones y condicionantes.
El contratista responsable de la ejecución puede tener incentivos diferentes de los del propietario. Por ello, los riesgos, porcentajes, impactos y planes de recuperación deben ser desafiados técnicamente.
El propietario necesita una visión independiente de la exposición. La revisión crítica de riesgos, contingencias, cambios y planes de recuperación reduce la dependencia exclusiva de las evaluaciones producidas por los contratistas responsables de la ejecución.
Conozca la actuación de A3A en Owner’s Engineering — Ingeniería del Propietario.
¿Cómo alimentan los riesgos el acervo técnico y el benchmarking?
El cierre del proyecto debe preservar:
- riesgos identificados y no materializados;
- riesgos materializados;
- impactos previstos y reales;
- respuestas aplicadas;
- coste de las respuestas;
- tiempo de escalamiento;
- eficacia;
- riesgos secundarios;
- categorías recurrentes;
- desempeño de proveedores;
- premisas invalidadas;
- contingencia consumida;
- decisiones de gate.
Este acervo mejora estimaciones, cronogramas, contratos, criterios de contingencia y due diligence de proyectos futuros.
El benchmarking debe considerar contexto, fase, tamaño, tecnología, estrategia contractual y madurez. Comparar únicamente la cantidad de riesgos o el valor consumido de contingencia puede producir conclusiones incorrectas.
¿Cómo evaluar la madurez de la gestión de riesgos?
| Nivel | Características | Limitación principal |
| 1 — Reactivo | riesgos tratados después de la materialización | sorpresa y dependencia de individuos |
| 2 — Registrado | matriz y lista periódica | proceso predominantemente documental |
| 3 — Controlado | owners, acciones, criterios y revisiones activos | integración parcial con el proyecto |
| 4 — Integrado | riesgos conectados a plazo, costes, contratos, cambios y gates | necesidad de una gobernanza de datos consistente |
| 5 — Predictivo | escenarios, simulaciones, benchmarks y aprendizaje corporativo | riesgo de confianza excesiva en los modelos |
La madurez no significa registrar el mayor número de riesgos. Significa producir decisiones anticipadas y respuestas proporcionales con evidencias de eficacia.
¿Cómo implantar la gestión de riesgos en doce etapas?
- Defina objetivos y gobernanza. Establezca patrocinador, comités, niveles de autoridad, apetito y límites.
- Describa el contexto. Registre fase, alcance, premisas, restricciones y stakeholders.
- Cree criterios. Defina escalas, categorías, tolerancias y reglas de clasificación.
- Estructure los roles. Nombre risk owners, action owners y responsables de consolidación.
- Implante el registro. Estandarice causa, evento, consecuencia, vínculos e historial.
- Realice una identificación multidisciplinaria. Utilice documentos, workshops, campo, contratos y benchmarks.
- Analice y priorice. Combine evaluación cualitativa y cuantitativa según la necesidad.
- Planifique respuestas. Defina estrategias, acciones, recursos, plazos y exposición residual.
- Integre al proyecto. Actualice cronograma, costes, contratos, contingencias y gates.
- Establezca rutinas y gatillos. Defina frecuencia, escalamiento y decisiones obligatorias.
- Verifique la eficacia. Compare la exposición antes y después de las respuestas y acompañe las materializaciones.
- Preserve el conocimiento. Actualice el acervo, benchmarks, criterios y procesos corporativos.
La implantación puede comenzar por un proyecto crítico, pero debe evolucionar hacia estándares de PMO y portafolio cuando la organización gestiona múltiples proyectos.
Ejemplo aplicado a un proyecto multidisciplinar
Considere una ampliación industrial que incluye diseño de detalle, adquisición de equipos, adecuaciones civiles, instalaciones eléctricas, automatización y puesta en marcha.
El equipo identifica el riesgo:
Debido a la falta de confirmación de las corrientes de arranque y de la lógica de operación del equipo principal, puede producirse una revisión tardía de la alimentación eléctrica y de la automatización, provocando modificaciones en los paneles, retrasos de fabricación e impacto en la ventana de parada.
El riesgo está relacionado con:
- documentos del proveedor;
- diseño eléctrico;
- diseño de automatización;
- fabricación de paneles;
- ventana de parada;
- contrato de integración;
- gate de liberación para fabricación.
La evaluación inherente indica alta probabilidad y alto impacto en plazo y costes. El risk owner es el gerente de ingeniería. Las respuestas incluyen:
- adelantar la reunión técnica con el proveedor;
- emitir una lista de datos obligatorios;
- condicionar la aprobación documental a la integridad de la información;
- reservar espacio y capacidad en los paneles dentro de un límite definido;
- crear una alternativa de arranque en el estudio eléctrico;
- establecer una fecha límite antes del gate de fabricación;
- actualizar el cronograma y la contingencia.
El proveedor entrega parte de la información, pero persiste la incertidumbre sobre una secuencia operativa. Owner’s Engineering recomienda la aprobación condicional únicamente de los componentes no afectados. El gate bloquea la fabricación del tramo dependiente de la interfaz.
En las semanas siguientes, los datos se confirman y se selecciona la solución de arranque. El riesgo residual disminuye a medio. La respuesta costó menos que una posible revisión de los paneles y preservó la ventana de implantación.
El cierre registra la materialización evitada, el coste de la respuesta, el plazo de decisión y la necesidad de incluir los datos de arranque como requisito obligatorio en futuras contrataciones.
Errores comunes en la gestión de riesgos
Tratar la matriz como el proceso completo
Existe la clasificación, pero no hay owners, respuestas, recursos ni integración con las decisiones.
Registrar únicamente amenazas genéricas
Las descripciones vagas no permiten un análisis causal ni un tratamiento específico.
Utilizar probabilidad e impacto sin criterios
La puntuación depende de la percepción individual y no puede compararse de forma consistente.
Asignar todos los riesgos al gerente del proyecto
Las exposiciones quedan alejadas de las personas con autoridad y competencia para tratarlas.
Definir acciones como “monitorizar”
El registro no demuestra prevención, mitigación, gatillos ni un plan de contingencia.
No integrar los riesgos en el cronograma
La organización pierde la fecha límite para actuar antes del impacto.
Mantener el forecast sin riesgos conocidos
La proyección sigue siendo optimista a pesar de que existen eventos relevantes en evaluación.
Transferir riesgos por contrato sin evaluar capacidad
La parte que recibió la obligación no consigue controlar ni absorber la exposición.
Cerrar riesgos porque la clasificación disminuyó
Las acciones pueden no haberse completado o el riesgo residual puede seguir siendo relevante.
Penalizar a quien registra riesgos
El equipo empieza a ocultar incertidumbres y el proceso pierde calidad.
Cuantificar sobre datos débiles
Las simulaciones producen números sofisticados sin una base confiable.
No registrar oportunidades
El proceso se limita a pérdidas y deja de apoyar la generación de valor.
¿Cuándo contratar apoyo especializado en gestión de riesgos?
La contratación es especialmente relevante cuando:
- el proyecto posee múltiples disciplinas y contratos;
- los riesgos críticos no están integrados en el cronograma o los costes;
- las contingencias no tienen una base definida;
- existe una gran exposición regulatoria, operativa o tecnológica;
- el proyecto necesita análisis cuantitativo;
- los cambios y reclamaciones crecen sin una visión consolidada;
- el propietario necesita una revisión independiente;
- los stage-gates exigen evaluación de preparación;
- la organización quiere implantar estándares de PMO;
- existe necesidad de acervo y benchmarking;
- los proyectos presentan recurrencia de materializaciones.
| Modelo de contratación | Aplicación | Entregables típicos |
| diagnóstico de madurez | evaluar el proceso actual | assessment, brechas y roadmap |
| estructuración metodológica | crear criterios y gobernanza | plan de riesgos, categorías, escalas, RACI y workflows |
| facilitación de workshops | identificar y analizar exposiciones | registro estructurado y plan de respuestas |
| análisis cuantitativo | estimar rangos de plazo o costes | escenarios, sensibilidad y simulaciones |
| operación continuada | mantener activo el proceso | revisiones, indicadores, escalamiento e informes |
| auditoría independiente | revisar riesgos de contratistas | dictamen sobre exposición, respuestas y contingencias |
| apoyo a Owner’s Engineering | proteger los objetivos del propietario | análisis crítico, gates y recomendaciones |
| apoyo al PMO y al portafolio | consolidar múltiples proyectos | estándares, visión corporativa y benchmarking |
Los Servicios Continuados de Ingeniería Consultiva permiten mantener capacidad especializada a lo largo del ciclo del proyecto.
¿Cómo evaluar la consultoría a contratar?
La evaluación debe considerar:
- experiencia en proyectos y sectores comparables;
- dominio de ingeniería, contratos y Project Controls;
- conocimiento de técnicas cualitativas y cuantitativas;
- capacidad para integrar riesgos en el cronograma y los costes;
- metodología para facilitación y registro;
- independencia respecto de las partes evaluadas;
- acervo técnico y atribuciones profesionales;
- calidad de informes y recomendaciones;
- experiencia en Owner’s Engineering y stage-gates;
- gobernanza de datos y trazabilidad;
- capacidad de transferir conocimiento;
- uso contextualizado de benchmarking.
La propuesta debe informar alcance, equipo, dedicación, fuentes de datos, métodos, herramientas, entregables, frecuencia, premisas, exclusiones y criterios de aceptación.
¿Cómo apoya la tecnología a la gestión de riesgos?
Los sistemas pueden integrar riesgos con proyectos, contratos, documentos, acciones, cambios, indicadores y decisiones. La plataforma ENGiOS conecta estos objetos en una trazabilidad de gobernanza para empresas de ingeniería.
La tecnología puede apoyar:
- registro y versionado;
- workflows de análisis y aprobación;
- notificaciones de gatillos;
- acciones y plazos;
- vínculos con documentos y actividades;
- dashboards por nivel de gestión;
- consolidación de portafolio;
- historial de materializaciones;
- acervo y benchmarking.
Sin embargo, el software no define apetito, criterios, owners ni la calidad de las respuestas. Automatizar un proceso débil solo distribuye más rápidamente datos inconsistentes.
Consideraciones finales
La gestión de riesgos en proyectos de ingeniería es un sistema de gobernanza de la incertidumbre. Su propósito no es rellenar una matriz, sino anticipar eventos, estructurar respuestas e incorporar exposiciones a las decisiones antes de que la organización pierda capacidad de actuar.
Un proceso maduro conecta los riesgos con objetivos, alcance, cronograma, costes, contratos, cambios, gates y operación. Diferencia riesgo, problema, premisa y cambio; asigna owners; financia respuestas; monitoriza gatillos; actualiza forecasts; registra decisiones y verifica la eficacia.
La matriz de riesgos sigue siendo importante, pero funciona como un instrumento dentro de una arquitectura más amplia. El valor aparece cuando la organización puede responder: qué incertidumbre amenaza o favorece los objetivos, cuál es la ventana de decisión, quién tiene autoridad para actuar y cómo sabremos si la exposición se redujo realmente.
Referencias técnicas
[1] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 31000:2018 — Risk management — Guidelines. Geneva: ISO, 2018. Disponible en: https://www.iso.org/standard/65694.html.
[2] INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC 31010:2019 — Risk management — Risk assessment techniques. Geneva: IEC, 2019. Disponible en: https://www.iso.org/standard/72140.html.
[3] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 21502:2020 — Project, programme and portfolio management — Guidance on project management. Geneva: ISO, 2020. Disponible en: https://www.iso.org/standard/74947.html.
[4] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. IWA 31:2020 — Risk management — Guidelines on using ISO 31000 in management systems. Geneva: ISO, 2020. Disponible en: https://www.iso.org/standard/75812.html.
[5] PROJECT MANAGEMENT INSTITUTE. A Guide to the Project Management Body of Knowledge (PMBOK® Guide). 8.ª ed. Newtown Square: Project Management Institute, 2025. Disponible en: https://www.pmi.org/standards/pmbok.
[6] AACE INTERNATIONAL. Total Cost Management Framework: An Integrated Approach to Portfolio, Program, and Project Management. 2.ª ed. Morgantown: AACE International, 2019. Disponible en: https://web.aacei.org/resources/tcm.
Preguntas frecuentes
Es el proceso continuo de identificar, analizar, responder, monitorizar e integrar incertidumbres en las decisiones de alcance, plazo, costes, contratos, calidad y operación.
La matriz clasifica exposiciones según criterios como probabilidad e impacto. La gestión de riesgos incluye contexto, owners, respuestas, recursos, gatillos, monitorización, integración y gobernanza.
El riesgo es un evento futuro incierto. El problema es una condición o evento que ya ocurrió y exige acción correctiva, recuperación y actualización del plan.
Es la exposición que permanece después de implantar las respuestas planificadas. Debe evaluarse y aceptarse por la autoridad competente.
El risk owner debe tener competencia, información y autoridad para acompañar la exposición y garantizar el tratamiento y escalamiento. La ejecución de acciones específicas puede asignarse a action owners.
Cuando las decisiones dependen de rangos de plazo, costes, contingencias o probabilidad de cumplimiento. La técnica debe ser compatible con la calidad de los datos y la criticidad de la decisión.
Los riesgos deben vincularse a actividades, hitos, fechas límite, acciones, impactos, contingencias y forecasts, permitiendo evaluar consecuencias y actuar antes de la materialización.
Cuando existan múltiples contratos, exposiciones críticas, contingencias sin base, necesidad de análisis cuantitativo, implantación de PMO o revisión independiente por parte del propietario.
Materiales técnicos complementarios
1. Fundamentos de la gestión y estructura de riesgos
- Matriz de riesgos en proyectos de ingeniería
- Project Controls en proyectos de ingeniería
- Stage-gate en proyectos de ingeniería
- EDT/WBS en proyectos de ingeniería
- Matriz RACI en proyectos de ingeniería
2. Integración con desempeño, plazo y decisiones
- Gestión del Valor Ganado
- Curva S en proyectos de ingeniería
- KPI e indicadores de desempeño
- Matriz de priorización de proyectos
- Workflow y flujos de aprobación
3. Diagnóstico, tratamiento y verificación de eficacia
- Diagrama de Pareto en la gestión de proyectos
- Diagrama de Ishikawa y análisis de causa raíz
- PDCA aplicado a la mejora continua
- 5W2H aplicado a planes de acción
- Gestión de contratos en ingeniería
4. Soluciones para gobernanza e integración del proceso
- Gobernanza de Proyectos, Programas y Portafolios
- Implantación y Estructuración de PMO de Ingeniería
- Indicadores, Dashboards e Informes Ejecutivos
- Gestión de Contratos, Alcance y Entregables
- Gestión de Procesos, Workflows y Aprobaciones Técnicas
5. Plataforma, gestión y representación del propietario
- ENGiOS — Plataforma de Gestión para Empresas de Ingeniería
- Gestión de Proyectos
- Gerenciamiento de Proyectos
- Owner’s Engineering — Ingeniería del Propietario
- Servicios Continuados de Ingeniería Consultiva
6. Fuentes técnicas y referencias oficiales
