Instabilità nei progetti EPC

Un sistema che parte prima di essere definito

Nel settore EPC, ritardi e sforamenti di costo vengono ancora interpretati come deviazioni rispetto a un piano iniziale ritenuto solido, quasi fossero anomalie generate da errori tecnici, inefficienze operative o problemi di coordinamento. È una lettura che continua a sopravvivere perché consente di isolare le responsabilità e di trattare ogni criticità come un episodio separato. Nella pratica, però, soprattutto in ambito oil & gas, il problema è più profondo e riguarda il modo stesso in cui prende forma l’instabilità nei progetti EPC.

Sempre più spesso il procurement viene anticipato rispetto alla maturità progettuale reale, non per scelta strategica ma perché i tempi di consegna, la disponibilità dei componenti e la pressione sul time-to-delivery non lasciano alternative. Questo significa che molte decisioni vengono prese quando il progetto non è ancora completamente definito e che l’esecuzione inizia su una base che, di fatto, è ancora in evoluzione.

Il risultato è un sistema che non costruisce a partire da una configurazione stabile, ma che continua a ridefinirsi mentre viene realizzato. In questo contesto, il ritardo non rappresenta necessariamente un fallimento del progetto: molto spesso è la conseguenza inevitabile di una struttura che accetta deliberatamente di procedere in condizioni di incompletezza.

Quando una modifica si propaga nel sistema

Un caso ricorrente riguarda la progettazione di sistemi gas sviluppati sulla base di specifiche preliminari di componenti critici come PCV o PSV. In fase iniziale le caratteristiche tecniche vengono considerate sufficienti per procedere, spesso perché è necessario bloccare rapidamente forniture con lead time elevati. Successivamente, però, le condizioni operative cambiano, il cliente aggiorna i requisiti oppure il fornitore modifica la configurazione disponibile. A quel punto il problema non riguarda semplicemente la sostituzione di un componente.

La modifica si propaga all’interno del sistema e costringe a rivedere dimensionamenti, layout, interfacce e verifiche tecniche in una fase in cui il progetto è già avanzato. Questo tipo di situazione non rappresenta un’eccezione ma una dinamica strutturale. Le modifiche non derivano necessariamente da errori di progettazione; derivano dal fatto che il progetto procede mentre molte delle sue condizioni fondamentali non sono ancora consolidate.

In questo scenario, parlare di “errore” diventa riduttivo, perché il sistema stesso accetta implicitamente che alcune decisioni verranno corrette lungo il percorso. Si instaura una sorta di equilibrio tacito tra gli attori coinvolti: si procede anche sapendo che alcune interfacce resteranno aperte, che alcune responsabilità saranno parzialmente distribuite e che parte della complessità verrà inevitabilmente trasferita nelle fasi successive.

Dove nasce l’instabilità nei progetti EPC

L’instabilità reale nasce soprattutto nella relazione tra engineering e procurement, molto prima della costruzione. Da una parte il procurement ha bisogno di anticipare decisioni per garantire disponibilità e tempi compatibili con le richieste del mercato; dall’altra l’engineering non dispone ancora di un quadro sufficientemente stabile per chiudere il progetto in modo coerente. Questo disallineamento genera un perimetro tecnico sufficiente per avviare le attività, ma non abbastanza robusto da evitare revisioni continue.

La complessità non viene eliminata: viene spostata nel tempo. Quando riemerge durante l’esecuzione, il suo impatto è più costoso, più lento da gestire e più difficile da coordinare. Questo stesso disallineamento trasforma anche la natura del coordinamento tra attori. Storicamente i progetti complessi hanno sempre richiesto mediazione tra discipline, fornitori e responsabilità differenti, ma oggi il coordinamento avviene mentre il sistema stesso continua a cambiare.

Non si tratta più soltanto di allineare persone o processi: si tratta di mantenere coerenza tra decisioni che possono perdere validità nel giro di poche settimane. Più aumenta il numero degli attori coinvolti, più cresce la possibilità che modifiche locali producano effetti a catena difficili da controllare.

Un modello che si adatta ma non evolve

Nonostante questo scenario, il modello operativo resta sostanzialmente invariato. Le grandi organizzazioni continuano a lavorare secondo strutture top-down e logiche contrattuali rigide, che faticano ad adattarsi alla velocità con cui oggi cambiano supply chain, disponibilità tecnologica e condizioni di mercato. Il sistema non evolve realmente; tende piuttosto a forzare adattamenti caso per caso per assorbire l’instabilità generata dal contesto.

In questo scenario, il vero vantaggio competitivo non consiste nell’eliminare completamente il rischio, obiettivo ormai irrealistico, ma nel riconoscere in anticipo dove il progetto tenderà a perdere coerenza. L’esperienza accumulata su progetti simili permette di individuare pattern ricorrenti: componenti critici che generano colli di bottiglia, interfacce che richiederanno revisioni, specifiche destinate a cambiare durante l’esecuzione.

Non significa prevedere il futuro in modo deterministico, ma leggere le instabilità sistemiche prima che diventino problemi espliciti. Questo cambia anche il ruolo dell’ingegneria, che non può più limitarsi alla sola esecuzione tecnica ma deve diventare capacità di interpretare e governare relazioni, vincoli e incoerenze distribuite lungo tutto il ciclo di vita del progetto.

Oltre il concetto di ritardo

Alla luce di tutto questo, il concetto stesso di ritardo assume un significato diverso. Quello che viene percepito come ritardo è spesso la conseguenza inevitabile di un sistema che sceglie deliberatamente di partire prima di essere completamente coerente, perché il tempo è diventato il vincolo dominante rispetto a qualsiasi altra variabile.

Finché questa logica rimarrà invariata, i progetti continueranno a svilupparsi in condizioni di definizione parziale, trasferendo complessità lungo l’esecuzione e correggendosi continuamente in corso d’opera. Non è un sistema che non funziona: è un sistema costruito per funzionare in questo modo.