Técnicas de gestión de riesgos en la planificación de proyectos

Un registro de riesgos con un alcance deficiente descubierto en la fase de ingeniería de detalle no protege al proyecto: documenta el daño. La consecuencia es tangible: , y .

La gestión eficaz de riesgos no es un ejercicio de cumplimiento. Es una disciplina de ingeniería estructurada que, cuando se aplica correctamente, desplaza las decisiones de la extinción reactiva de incendios al control proactivo.


Contexto de normas y requisitos

Varios marcos regulan la práctica de la gestión de riesgos en los entornos de proyectos de petróleo y gas:

  • ISO 31000 establece los principios generales y las directrices para la gestión de riesgos aplicables a cualquier organización o proyecto.
  • IEC 62198 proporciona directrices de aplicación para la gestión de riesgos de proyectos en todos los sectores, incluidas las industrias de procesos.
  • IEC 61511 rige la seguridad funcional para los sistemas instrumentados de seguridad y requiere un análisis de peligros y riesgos como base para la determinación del nivel de integridad de seguridad, una entrada directa para los registros de riesgos del proyecto.
  • API RP 17N cubre la confiabilidad, el riesgo técnico y la gestión de la integridad para los sistemas de producción submarinos y proporciona un marco estructurado para la toma de decisiones informada por el riesgo durante el desarrollo del proyecto.
  • ISO/IEC 31010 proporciona un catálogo de técnicas de evaluación de riesgos y orientación sobre la selección del método adecuado para una situación determinada.

Cuando un proyecto cae bajo jurisdicción regulatoria (UKCS, GoM, plataforma continental noruega), la autoridad competente aplicable normalmente requerirá un caso de seguridad formal o un documento equivalente que se base directamente en las evaluaciones de riesgo del proyecto.


El proceso de gestión de riesgos en las fases del proyecto

Alinear el proceso con el ciclo de vida del proyecto

La gestión de riesgos debe realizarse por fases. La aplicación de un único registro de riesgos desde el concepto hasta la puesta en marcha sin puntos de revisión estructurados es un modo de fallo común. Cada fase del proyecto (selección de concepto, pre-FEED, FEED, diseño detallado, adquisiciones, construcción, pre-comisionamiento) tiene un perfil de riesgo diferente, un nivel diferente de certeza de diseño y un coste diferente para actuar sobre los riesgos identificados.

En la selección del concepto, los riesgos son amplios y estratégicos: incertidumbre del yacimiento, preparación tecnológica, vía regulatoria, alineación de los socios. En el FEED, los riesgos se vuelven técnicos y comerciales: adquisición de equipos de largo plazo, gestión de interfaces, condiciones del terreno, calificación de proveedores. En la construcción, los riesgos están relacionados en gran medida con la ejecución: competencia de la mano de obra, ventanas meteorológicas, disponibilidad de materiales, operaciones concurrentes.

Métodos de identificación de riesgos

La elección de la técnica de identificación debe coincidir con la fase del proyecto y la naturaleza del peligro:

Técnica Fase más adecuada Resultado principal
HAZID (Identificación de peligros) Concepto / pre-FEED Lista de peligros de alto nivel, cualitativa
HAZOP (Estudio de peligros y operabilidad) FEED / diseño detallado Pares causa-consecuencia, brechas en salvaguardas
Análisis What-If Concepto / FEED temprano Escenarios de riesgo amplios, rápido de ejecutar
Análisis Bow-Tie Desde FEED en adelante Mapeo de amenaza-barrera-consecuencia
FMEA / FMECA Diseño detallado Modos y efectos de fallo a nivel de equipo
Simulación de Monte Carlo Coste/cronograma de FEED Rangos probabilísticos de coste y cronograma

El HAZOP se aplica con frecuencia de forma incorrecta: se ejecuta demasiado pronto cuando los P&ID son inmaduros, o demasiado tarde cuando los cambios son prohibitivamente caros. El activador correcto es un conjunto de P&ID congelado y con calidad IFC.

Evaluación de riesgos: cualitativa frente a cuantitativa

Para la mayoría de los riesgos del proyecto, una evaluación cualitativa bien estructurada utilizando una matriz de consecuencia-probabilidad es suficiente y proporcionada. La matriz debe calibrarse para el proyecto: las categorías de consecuencias deben incluir dimensiones de seguridad, ambientales, de cronograma, de coste y de reputación, cada una con descriptores definidos en lugar de puntuaciones numéricas arbitrarias.

La evaluación cuantitativa de riesgos (QRA) está justificada cuando:

  • El proyecto involucra configuraciones de proceso novedosas o complejas donde la gravedad de la consecuencia no puede limitarse cualitativamente.
  • Los requisitos reglamentarios lo especifican, como es común para instalaciones costa afuera, instalaciones de GNL o sitios en tierra densamente poblados.
  • Un riesgo está cerca del límite tolerable/intolerable y la decisión de proceder requiere una base numérica defendible.

El resultado de un QRA es tan confiable como los datos y las suposiciones que lo alimentan.

Estrategias de respuesta al riesgo

Se aplican cuatro estrategias de respuesta a cualquier riesgo identificado. La elección depende del nivel de riesgo, el coste de la respuesta y el apetito de riesgo del proyecto:

Evitar — reestructurar el alcance o el enfoque del proyecto para eliminar el riesgo por completo. Aplicable cuando el riesgo es inaceptablemente alto y no existe una mitigación creíble dentro de las restricciones de coste. Ejemplo: seleccionar una tecnología probada en lugar de una novedosa cuando el cronograma no puede absorber las pruebas de calificación.

Mitigar — reducir la probabilidad o la consecuencia a través de controles de ingeniería, salvaguardas de procedimiento o cambios de diseño. Esta es la respuesta más común y debe ser presupuestada y asignada a un propietario específico.

Transferir — trasladar la consecuencia financiera del riesgo a un tercero a través de términos contractuales, seguros o garantías de cumplimiento. La transferencia no elimina el riesgo; reasigna la exposición financiera. El riesgo técnico permanece con el equipo del proyecto.

Aceptar — reconocer el riesgo y proceder sin mitigación activa, normalmente porque el coste de la mitigación supera el impacto esperado. Los riesgos aceptados deben documentarse explícitamente y revisarse en cada fase. La aceptación pasiva, donde simplemente no se aborda un riesgo, es un fallo de gobernanza del proyecto.


Riesgo del cronograma y gestión del margen de tiempo

El riesgo del cronograma se subestima con frecuencia porque los equipos de proyecto confunden una ruta crítica determinista con un pronóstico confiable. Un modelo de ruta crítica con margen cero en cada actividad principal no es un cronograma: es una aspiración optimista.

La simulación de Monte Carlo aplicada al cronograma del proyecto genera una distribución de probabilidad de las fechas de finalización basada en el rango de duraciones asignadas a las actividades individuales. El resultado (una curva de probabilidad acumulada) permite al equipo del proyecto seleccionar una fecha de finalización objetivo con un nivel de confianza adecuado en lugar de comprometerse con el escenario más optimista.

Las entradas clave para un modelo de riesgo de cronograma creíble incluyen:

  • Estimaciones de duración realistas de tres puntos (mínima, más probable, máxima) para cada actividad, desarrolladas por los líderes de disciplina responsables del trabajo.
  • Modelado explícito de eventos de riesgo: riesgos discretos que, si ocurren, añaden duración o crean bucles de retrabajo.
  • Correlación entre actividades relacionadas: los retrasos en la entrega de equipos, por ejemplo, afectan simultáneamente a múltiples actividades de instalación aguas abajo.

Escenario ilustrativo: Registro de riesgos de FEED de una conexión submarina

El siguiente es un ejemplo ilustrativo construido para demostrar la aplicación de las técnicas descritas. No representa un proyecto o incidente específico con nombre.

Considere un proyecto de conexión submarina en FEED. El registro de riesgos identifica un elemento de largo plazo (un módulo de control submarino de un único proveedor calificado) como un riesgo de adquisición crítico para el cronograma. La evaluación cualitativa inicial sitúa este riesgo en la celda de alta consecuencia y probabilidad moderada de la matriz del proyecto.

El equipo del proyecto aplica un análisis Bow-Tie: la amenaza es el retraso en la fabricación del proveedor; las barreras incluyen la colocación temprana de la orden de compra, los pagos por hitos contractuales y un programa de inspección del proveedor. La consecuencia, si las barreras fallan, es un retraso en la fecha del primer petróleo.

La estrategia de respuesta seleccionada es la mitigación combinada con la transferencia parcial: la orden de compra se coloca al finalizar el FEED con daños y perjuicios contractuales por entrega tardía, y el modelo de cronograma se desarrolla para incluir un evento de riesgo discreto que representa un escenario de retraso del proveedor. El resultado de Monte Carlo confirma que la fecha de finalización del proyecto al nivel de confianza requerido requiere una contingencia de cronograma adicional más allá de la ruta crítica determinista.

Esta contingencia se financia explícitamente en la estimación de costes de sanción del proyecto, no se absorbe en una línea de contingencia general que oculta el factor específico.


Lista de verificación para la gestión de riesgos del proyecto

Utilice lo siguiente en cada revisión de fase (gate review) del proyecto:

Calidad del registro de riesgos

  • [ ] Todos los riesgos tienen un responsable definido, no un equipo o disciplina
  • [ ] Las calificaciones de consecuencia y probabilidad utilizan la matriz calibrada específica del proyecto, no valores genéricos predeterminados
  • [ ] Los riesgos aceptados están documentados explícitamente con su justificación
  • [ ] El registro ha sido actualizado desde la fase anterior

Cobertura de identificación

  • [ ] Se ha completado el HAZID o equivalente y los hallazgos se reflejan en el registro
  • [ ] Los equipos de largo plazo de entrega y los artículos de proveedor único se capturan como riesgos del cronograma
  • [ ] Los riesgos de interfaz (entre contratistas, entre proyecto y operaciones) se enumeran explícitamente
  • [ ] Se incluyen los riesgos de la ruta de aprobación regulatoria

Riesgo del cronograma

  • [ ] Se han preparado estimaciones de tres puntos para las actividades de la ruta crítica
  • [ ] Se ha realizado una simulación de Monte Carlo y la fecha de finalización objetivo se establece con un nivel de confianza definido
  • [ ] No se depende del margen de tiempo (float) como amortiguador de riesgo principal

Acciones de respuesta

  • [ ] Cada riesgo de calificación alta tiene una acción de mitigación documentada con una fecha de finalización
  • [ ] Los costos de mitigación se incluyen en la estimación de costos del proyecto
  • [ ] Los mecanismos de transferencia (contratos, seguros) están confirmados, no asumidos

Gobernanza

  • [ ] El registro de riesgos ha sido revisado por el patrocinador del proyecto
  • [ ] Los riesgos que se acercan al límite tolerable/intolerable han sido escalados para una revisión independiente

Conclusión

La gestión de riesgos en la planificación de proyectos es efectiva solo cuando es continua, adecuada para la fase y propiedad del equipo de ingeniería en lugar de delegarse a una función de control de proyectos. Las herramientas — HAZID, HAZOP, bow-tie, Monte Carlo — están bien establecidas. Los modos de falla están igualmente bien establecidos: identificación tardía, matrices genéricas, riesgos sin responsable y registros que se actualizan para las revisiones de fase y luego se archivan.

El siguiente paso inmediato para cualquier equipo de proyecto que revise su enfoque actual es auditar el registro de riesgos frente a la lista de verificación anterior y hacer una pregunta directa para cada riesgo de alta calificación: ¿quién es el responsable, cuál es la acción de mitigación y está esa acción financiada y programada? Si la respuesta a cualquier parte no está clara, el riesgo no se gestiona, se registra.