Tecniche di gestione del rischio nella pianificazione dei progetti

Tecniche di gestione del rischio nella pianificazione dei progetti

Un registro dei rischi con un ambito mal definito scoperto alla fase di ingegneria di dettaglio non protegge il progetto: ne documenta il danno. La conseguenza è tangibile: , e .

Una gestione del rischio efficace non è un esercizio di conformità. È una disciplina ingegneristica strutturata che, se applicata correttamente, sposta le decisioni dalla gestione reattiva delle emergenze al controllo proattivo.

Contesto normativo e requisiti

Diversi framework regolano la pratica della gestione del rischio negli ambienti di progetto oil & gas:

• ISO 31000 stabilisce i principi generali e le linee guida per la gestione del rischio applicabili a qualsiasi organizzazione o progetto.
• IEC 62198 fornisce linee guida applicative per la gestione del rischio di progetto in vari settori, comprese le industrie di processo.
• IEC 61511 disciplina la sicurezza funzionale per i sistemi strumentati di sicurezza e richiede l'analisi dei pericoli e dei rischi come base per la determinazione del livello di integrità della sicurezza — un input diretto per i registri dei rischi di progetto.
• API RP 17N copre l'affidabilità, il rischio tecnico e la gestione dell'integrità per i sistemi di produzione sottomarini e fornisce un quadro strutturato per il processo decisionale informato dal rischio durante lo sviluppo del progetto.
• ISO/IEC 31010 fornisce un catalogo di tecniche di valutazione del rischio e una guida sulla selezione del metodo appropriato per una data situazione.

Qualora un progetto ricada sotto una giurisdizione normativa — UKCS, GoM, piattaforma continentale norvegese — l'autorità competente applicherà tipicamente la richiesta di un safety case formale o di un documento equivalente che attinga direttamente dalle valutazioni del rischio di progetto.

Il processo di gestione del rischio nelle fasi di progetto

Allineare il processo al ciclo di vita del progetto

La gestione del rischio deve essere suddivisa per fasi. L'applicazione di un unico registro dei rischi dal concept al commissioning senza punti di revisione strutturati è una modalità di fallimento comune. Ogni fase del progetto — selezione del concept, pre-FEED, FEED, progettazione dettagliata, approvvigionamento, costruzione, pre-commissioning — ha un profilo di rischio diverso, un diverso livello di certezza del design e un diverso costo per agire sui rischi identificati.

Nella selezione del concept, i rischi sono ampi e strategici: incertezza del giacimento, prontezza tecnologica, percorso normativo, allineamento dei partner. Nel FEED, i rischi diventano tecnici e commerciali: approvvigionamento di apparecchiature a lungo termine, gestione delle interfacce, condizioni del terreno, qualificazione dei fornitori. Nella costruzione, i rischi sono in gran parte legati all'esecuzione: competenza della forza lavoro, finestre meteorologiche, disponibilità di materiali, operazioni simultanee.

Metodi di identificazione del rischio

La scelta della tecnica di identificazione deve corrispondere alla fase del progetto e alla natura del pericolo:

L'HAZOP è spesso applicato in modo errato — eseguito troppo presto quando i P&ID sono immaturi, o troppo tardi quando le modifiche sono proibitivamente costose. Il trigger corretto è un set di P&ID congelato e di qualità IFC.

Valutazione del rischio: qualitativa vs quantitativa

Per la maggior parte dei rischi di progetto, una valutazione qualitativa ben strutturata che utilizzi una matrice conseguenza-probabilità è sufficiente e proporzionata. La matrice deve essere calibrata sul progetto: le categorie di conseguenza dovrebbero includere le dimensioni di sicurezza, ambientale, tempistica, costo e reputazione, ciascuna con descrittori definiti piuttosto che punteggi numerici arbitrari.

La valutazione quantitativa del rischio (QRA) è giustificata quando:

• Il progetto coinvolge configurazioni di processo nuove o complesse in cui la gravità delle conseguenze non può essere limitata qualitativamente.
• I requisiti normativi lo specificano — come è comune per le installazioni offshore, gli impianti GNL o i siti onshore densamente popolati.
• Un rischio è vicino al confine tollerabile/intollerabile e la decisione di procedere richiede una base numerica difendibile.

L'output di una QRA è affidabile solo quanto i dati e le ipotesi che la alimentano.

Strategie di risposta al rischio

Quattro strategie di risposta si applicano a qualsiasi rischio identificato. La scelta dipende dal livello di rischio, dal costo della risposta e dalla propensione al rischio del progetto:

Evitare — ristrutturare l'ambito o l'approccio del progetto per eliminare completamente il rischio. Applicabile quando il rischio è inaccettabilmente alto e non esiste una mitigazione credibile entro i vincoli di costo. Esempio: selezione di una tecnologia collaudata rispetto a una nuova quando la tempistica non può assorbire i test di qualificazione.

Mitigare — ridurre la probabilità o la conseguenza attraverso controlli ingegneristici, salvaguardie procedurali o modifiche progettuali. Questa è la risposta più comune e dovrebbe essere preventivata e assegnata a un responsabile specifico.

Trasferire — spostare la conseguenza finanziaria del rischio a una terza parte tramite termini contrattuali, assicurazioni o garanzie di performance. Il trasferimento non elimina il rischio; rialloca l'esposizione finanziaria. Il rischio tecnico rimane in capo al team di progetto.

Accettare — riconoscere il rischio e procedere senza mitigazione attiva, tipicamente perché il costo della mitigazione supera l'impatto previsto. I rischi accettati devono essere esplicitamente documentati e revisionati a ogni fase. L'accettazione passiva — in cui un rischio semplicemente non viene affrontato — è un fallimento della governance del progetto.

Rischio di schedulazione e gestione del float

Il rischio di schedulazione è spesso sottovalutato perché i team di progetto confondono un percorso critico deterministico con una previsione affidabile. Un modello di percorso critico con float zero su ogni attività principale non è un programma — è un'aspirazione ottimistica.

La simulazione Monte Carlo applicata al cronoprogramma del progetto genera una distribuzione di probabilità delle date di completamento basata sull'intervallo di durate assegnate alle singole attività. L'output — una curva di probabilità cumulativa — consente al team di progetto di selezionare una data di completamento target a un livello di confidenza appropriato invece di impegnarsi nello scenario più ottimistico.

Gli input chiave per un modello di rischio di schedulazione credibile includono:

• Stime di durata realistiche a tre punti (minima, più probabile, massima) per ogni attività, sviluppate dai responsabili di disciplina che gestiscono il lavoro.
• Modellazione esplicita degli eventi di rischio — rischi discreti che, se si verificano, aggiungono durata o creano cicli di rilavorazione.
• Correlazione tra attività correlate — i ritardi nella consegna delle apparecchiature, ad esempio, influenzano simultaneamente più attività di installazione downstream.

Scenario illustrativo: Registro dei rischi FEED per un tieback sottomarino

Quello che segue è un esempio illustrativo costruito per dimostrare l'applicazione delle tecniche descritte. Non rappresenta uno specifico progetto o incidente nominato.

Si consideri un progetto di tieback sottomarino in fase FEED. Il registro dei rischi identifica un elemento a lungo termine — un modulo di controllo sottomarino da un unico fornitore qualificato — come un rischio di approvvigionamento critico per la schedulazione. La valutazione qualitativa iniziale colloca questo rischio nella cella ad alta conseguenza e moderata probabilità della matrice di progetto.

Il team di progetto applica un'analisi bow-tie: la minaccia è il ritardo nella produzione del fornitore; le barriere includono l'emissione anticipata dell'ordine di acquisto, i pagamenti contrattuali per milestone e un programma di ispezione del fornitore. La conseguenza, se le barriere falliscono, è un ritardo nella data del primo olio.

La strategia di risposta selezionata è la mitigazione combinata con il trasferimento parziale: l'ordine di acquisto viene emesso al completamento del FEED con penali contrattuali per ritardata consegna, e il modello di schedulazione viene aggiornato per includere un evento di rischio discreto che rappresenta uno scenario di ritardo del fornitore. L'output Monte Carlo conferma che la data di completamento del progetto al livello di confidenza richiesto richiede un contingency di tempo aggiuntivo oltre il percorso critico deterministico.

Questo contingency è finanziato esplicitamente nella stima dei costi di sanzione del progetto — non assorbito in una linea di contingency generale che maschera il driver specifico.

Checklist per la gestione dei rischi di progetto

Utilizzare quanto segue ad ogni revisione di fase (gate review) del progetto:

Qualità del registro dei rischi

• [ ] Tutti i rischi hanno un responsabile definito, non un team o una disciplina
• [ ] Le valutazioni di conseguenza e probabilità utilizzano la matrice calibrata specifica del progetto, non valori predefiniti generici
• [ ] I rischi accettati sono documentati esplicitamente con la relativa motivazione
• [ ] Il registro è stato aggiornato rispetto alla fase precedente

Copertura dell'identificazione

• [ ] L'HAZID o equivalente è stato completato e i risultati sono riportati nel registro
• [ ] Le apparecchiature a lungo termine di consegna e gli articoli da fornitore unico sono acquisiti come rischi di pianificazione
• [ ] I rischi di interfaccia (tra appaltatori, tra progetto e operazioni) sono elencati esplicitamente
• [ ] I rischi relativi al percorso di approvazione normativa sono inclusi

Rischio di pianificazione

• [ ] Sono state preparate stime a tre punti per le attività del percorso critico
• [ ] È stata eseguita una simulazione Monte Carlo e la data di completamento target è indicata a un livello di confidenza definito
• [ ] Il margine di flessibilità (float) non è considerato come buffer di rischio primario

Azioni di risposta

• [ ] Ogni rischio con valutazione elevata ha un'azione di mitigazione documentata con una data di completamento
• [ ] I costi di mitigazione sono inclusi nella stima dei costi di progetto
• [ ] I meccanismi di trasferimento (contratti, assicurazioni) sono confermati, non presunti

Governance

• [ ] Il registro dei rischi è stato revisionato dallo sponsor del progetto
• [ ] I rischi che si avvicinano al limite tollerabile/intollerabile sono stati inoltrati per una revisione indipendente

Conclusione

La gestione del rischio nella pianificazione del progetto è efficace solo quando è continua, appropriata alla fase e di proprietà del team di ingegneria piuttosto che delegata a una funzione di controllo progetto. Gli strumenti — HAZID, HAZOP, bow-tie, Monte Carlo — sono consolidati. Le modalità di guasto sono altrettanto consolidate: identificazione tardiva, matrici generiche, rischi senza responsabile e registri che vengono aggiornati per le revisioni di fase e poi archiviati.

Il passo immediato per qualsiasi team di progetto che stia rivedendo il proprio approccio attuale è verificare il registro dei rischi rispetto alla checklist sopra e porre una domanda diretta per ogni rischio con valutazione elevata: chi ne è il responsabile, qual è l'azione di mitigazione e tale azione è finanziata e pianificata? Se la risposta a una qualsiasi parte non è chiara, il rischio non è gestito — è solo registrato.