Interface Management: il rischio che nessuno ha in carico

Il getto è fatto. Il solaio è curato, le casseforme smontate, la squadra già spostata sul piano successivo. E poi arriva la squadra impianti con le planimetrie in mano: i fori per le colonne montanti non ci sono, o non sono dove servono. Qualcuno tira fuori la carotatrice, qualcun altro apre un non conformity report, e tutti e due i capocantiere iniziano a cercare nelle email chi doveva mandare cosa a chi.

Non è un errore tecnico. Nessuno ha sbagliato un calcolo, nessuno ha letto male un disegno. È mancato un passaggio di consegna: un punto preciso, fisico o informativo, in cui la responsabilità doveva passare da un soggetto a un altro secondo i documenti di progetto. Quel punto ha un nome tecnico, interface point, e troppo spesso non ha un responsabile scritto da nessuna parte.

La scena è sempre la stessa, su opere diverse: il conflitto esplode a lavori fatti, mai prima. Perché prima nessuno aveva un motivo per accorgersene.

Cos’è davvero un’interfaccia (e perché non è gestione progetto generica)

Un’interfaccia non è una semplice dipendenza tra attività nel cronoprogramma. È il punto in cui due soggetti diversi — due subappaltatori, due discipline di progettazione, l’appaltatore e il committente, due pacchetti di lavoro con delivery team separati — devono scambiarsi un’informazione o un elemento fisico perché il lavoro di uno prosegua.

La differenza conta perché il cronoprogramma dice quando una cosa deve succedere, ma non dice chi deve consegnare cosa a chi, in quale formato, con quale livello di dettaglio. Due attività possono essere linkate correttamente nel programma e l’interfaccia può comunque fallire, perché nessuno ha definito il contenuto dello scambio.

Gli interface point tipici in un grande cantiere infrastrutturale sono tanti più di quanto sembri a prima vista: tracciati impiantistici verso strutture, opere civili verso armamento ferroviario, scavi verso sottoservizi esistenti, interfacce tra lotti costruttivi contigui, interfacce tra progettazione e fornitori di componenti speciali. Ognuno di questi è un potenziale punto cieco se non viene nominato esplicitamente.

L’interface agreement: lo strumento, non la burocrazia

Lo strumento con cui si formalizza un’interfaccia è l’interface agreement: un documento bilaterale che fissa cosa va consegnato, entro quando, in che formato, e cosa deve fare ciascuna delle due parti prima e dopo lo scambio. Non sostituisce il contratto, né le notifiche e le riserve: quelle vanno fatte nei modi e nei tempi che valgono per il proprio contratto, e una riga nel registro delle interfacce non è né una notifica né una riserva. Ma è il documento operativo a cui ci si appella quando qualcuno dice “non lo sapevo”, e vale anche contro chi lo firma: se le date dell’accordo sono diverse da quelle del proprio contratto, va chiarito per iscritto con la propria controparte quali valgono, prima di firmare.

Le modifiche approvate si registrano nell’interface control document, che descrive il punto di contatto in termini tecnici: quote, carichi, tolleranze, spesso con un disegno. Date di consegna, ritardi e responsabili si seguono nel registro delle interfacce. E se una modifica cambia costi o tempi di una delle parti, scriverla nell’interface control document o nel registro non basta per farsela riconoscere: passa dalla procedura di variante del suo contratto, con un ordine scritto di chi ha il potere di darlo, prima di eseguirla. Senza questo registro, ogni interface agreement firmato all’inizio del progetto diventa carta vecchia dopo tre mesi, perché nessuno lo aggiorna quando cambiano i subappaltatori o si rivedono le sequenze costruttive.

Primo errore: trattare l’interfaccia come un allegato tecnico. Spesso l’interface agreement viene scritto come se fosse una specifica tecnica, con il focus sul contenuto ingegneristico e nessuna menzione di scadenze o responsabilità. Serve l’opposto: il contenuto tecnico lo definiscono i documenti di progetto, l’interface agreement definisce il processo di scambio.

Secondo errore: firmarlo a lavori iniziati. Se l’interfaccia viene formalizzata quando le due squadre sono già in cantiere e il conflitto è già emerso, il documento serve solo a chiarire le responsabilità per la prossima volta, non a evitare il danno già fatto.

Terzo errore: nessun responsabile nominato per persona. “Il subappaltatore impianti” non è un responsabile. Serve un nome, una funzione, un referente che risponde se la consegna non arriva in tempo.

Dove si individuano le interfacce: dal contratto, non dal cantiere

Il momento giusto per mappare gli interface point non è durante l’esecuzione, è nella fase contrattuale. Il committente lo fa in gara, definendo le interfacce tra i lotti e tra i soggetti che parteciperanno all’opera. L’appaltatore lo fa nei contratti di subappalto, individuando dove il proprio scope si tocca con quello di altri subappaltatori o con le forniture dirette del committente.

Questo è anche il motivo per cui la gestione delle interfacce si lega strettamente a come sono scritti i contratti di subappalto: se le clausole di coordinamento e di scambio documentale sono vaghe, ogni interface agreement successivo parte già zoppo. Ne ho parlato più nel dettaglio in questo articolo sulle clausole che non possono mancare nei contratti di subappalto.

I fattori che aumentano il rischio di interfacce mal gestite sono riconoscibili: scope poco definito fin dal contratto, un numero elevato di subappaltatori che lavorano in sequenza o in parallelo sulle stesse aree, più centri di progettazione che lavorano su discipline diverse senza un coordinamento BIM maturo, componenti speciali progettati da fornitori terzi con tempi e formati propri, norme di progettazione e software diversi tra i soggetti coinvolti. Su una grande opera infrastrutturale, difficilmente ne manca anche solo uno.

Cosa dicono i dati, con tutti i limiti che hanno

Il Construction Industry Institute ha confrontato i costi di 37 progetti, in gran parte industriali, divisi per livello di gestione delle interfacce. I 10 con un livello alto, cioè un processo strutturato e maturo e non solo qualche accordo scritto, hanno chiuso con una crescita media dei costi del 4%; i 27 con un livello basso, del 18%. Lo studio stesso segnala che la differenza non è statisticamente significativa su un campione così piccolo: è un’indicazione di tendenza, non una prova.

C’è però un secondo dato che a chi fa cost control interessa più della media: tra i progetti a livello alto non si sono registrati casi fuori scala, mentre tra quelli a livello basso alcuni progetti hanno avuto scostamenti anomali. Anche qui il campione è piccolo e non permette conclusioni definitive. Ma la differenza pratica è questa: uno scostamento prevedibile lo metti in un forecast e lo gestisci, uno scostamento fuori scala ti ribalta la commessa senza preavviso. Ho scritto altrove di cosa significhi davvero una cost variance negativa e delle verifiche da fare il giorno dopo averla vista.

Lo stesso studio nota che, nella maggior parte dei progetti con gestione formale, il processo era stato avviato nelle fasi iniziali del progetto, non durante l’esecuzione. Partire presto paga di più. Ma se sei già in esecuzione e non hai nulla di formalizzato, la scelta non è tra “farlo bene dall’inizio” o “niente”: è tra iniziare adesso o continuare a scoprire le interfacce con la carotatrice. Si parte in rincorsa, ma si parte.

Un sistema, non un documento isolato

Gestire le interfacce non significa produrre un registro in più da aggiornare una volta al mese e archiviare. Significa costruire, fin dai contratti, una mappa di chi consegna cosa a chi, dare a ogni interfaccia un responsabile coerente con i rischi che il contratto gli assegna, e aggiornare quella mappa ogni volta che cambia una sequenza costruttiva o un soggetto coinvolto. È un esercizio simile, nella logica, a tenere vivo un risk register invece di scriverlo una volta e dimenticarlo: ne ho parlato in questo articolo sul perché un rischio scritto non è un rischio gestito.

Non è burocrazia: è collaborazione strutturata. Chiede di parlarsi prima che il problema diventi un conflitto da gestire a lavori fatti. Le interfacce in un grande progetto ci sono sempre, che tu le mappi o no. L’unica domanda che conta è se qualcuno le ha in carico prima che il getto sia fatto.

Nel tuo progetto, il responsabile delle interfacce tra appaltatori è scritto nel contratto, o salta fuori solo quando il conflitto è già esploso?