2025-05-01 Contratti & Claims
C’è una domanda che si sente raramente nelle fasi iniziali di un progetto, ma che determina quasi tutto quello che viene dopo: con quale modello contrattuale stiamo strutturando questa commessa?
Nella maggior parte dei casi la risposta è automatica: Design-Bid-Build, perché si è sempre fatto così, perché lo richiedono le procedure interne, perché la normativa pubblica spinge in quella direzione. Il problema non è la risposta in sé — è che spesso arriva senza una domanda vera.
Il delivery method non è un tecnicismo da lasciare all’ufficio contratti. È una scelta che distribuisce rischi, tempi e responsabilità tra tutti gli attori del progetto. Sceglierlo per abitudine significa portarsi a casa i problemi che quel modello genera — anche quando esistevano alternative più adatte.
Il contratto ha un ciclo di vita: non comincia alla firma
Il contratto non nasce quando viene firmato. Nasce molto prima, e si chiude molto dopo.
In fase di Discovery — raccolta dati, definizione dello scope, analisi dei vincoli e del rischio — i contractor che entrano già qui possono influenzare le priorità progettuali. Non è sempre possibile, ma quando lo è, cambia la qualità di tutto quello che viene dopo.
Nel Pre-award si fanno, o non si fanno, le domande giuste: documentazione di gara, modelli di prezzo, condizioni contrattuali. Una clausola ambigua in questo stadio non è un dettaglio: è un claim potenziale. Molte dispute nascono da ambiguità che nessuno ha voluto affrontare perché sembrava prematuro.
L’Award/Kickoff è spesso trattato come una formalità. Non lo è. È il momento in cui si costruisce la governance operativa del progetto: chi fa cosa, quali sono le milestone, chi ha quale responsabilità. Un kickoff serio non è un evento simbolico con qualche slide.
Durante l’Execution, il contratto deve stare sul tavolo, non in un cassetto. Ogni modifica gestita al volo, ogni accordo verbale non tracciato formalmente, è un claim che si accumula.
Il Closeout è la fase più sottovalutata. È qui che si consolidano o si perdono i margini: documentazione as-built, lesson learned, liquidazione delle partite aperte. Chi la trascura scopre spesso che i soldi che pensava di avere guadagnato non ci sono più.
I cinque modelli a confronto
Ognuno risponde a priorità diverse — non c’è un modello migliore in assoluto.
Design-Bid-Build (DBB) — il modello tradizionale: prima si completa la progettazione, poi si va a gara, poi si costruisce. Il cliente mantiene il massimo controllo, ma i tempi sono lunghi e il rischio di conflitto tra progettista e impresa è strutturale. Uno ha progettato, l’altro deve costruire, e gli interessi non sempre coincidono. È il modello dominante nel settore pubblico e in tutto quello che è normato.
Design & Build (DB) — progettazione e costruzione sotto un unico contratto, un’unica responsabilità, tempi più brevi perché le due fasi si sovrappongono. Il punto critico: il cliente deve sapere con chiarezza cosa vuole prima di firmare. Se le specifiche sono vaghe, il rischio si trasferisce nell’esecuzione — e le sorprese costano.
EPC (Engineering, Procurement, Construction) — il modello chiavi in mano. Il contractor garantisce tempi, costi e performance. Adatto a infrastrutture complesse dove il cliente vuole concentrarsi sul risultato, non sul processo. Il prezzo di questa certezza è che il contractor incorpora nel prezzo un premio per i rischi che si assume.
IPD (Integrated Project Delivery) — tutti gli stakeholder — cliente, progettisti, costruttori, fornitori — condividono rischi e benefici fin dall’inizio. Richiede fiducia e trasparenza reale, non di facciata. Si avvicina alla logica Lean. Funziona bene in Nord America per progetti ospedalieri e scolastici. In Italia è ancora poco diffuso.
CM at Risk (Construction Management at Risk) — il construction manager entra in fase di progettazione, contribuisce alla constructability, e poi garantisce un prezzo massimo (GMP, Guaranteed Maximum Price). Combina flessibilità in fase di sviluppo con controllo dei costi in fase esecutiva.
Come si sceglie
Non esiste un modello universalmente superiore. La scelta dipende da alcune variabili concrete.
La prima è la complessità tecnica. Un progetto con specifiche di performance difficili da definire in anticipo mal si adatta a un EPC: il contractor si troverà a gestire l’incertezza, e quella incertezza finirà nel prezzo o nelle varianti.
Poi ci sono i tempi. Se le tempistiche non sono negoziabili, DB e CM at Risk permettono di sovrapporre progettazione ed esecuzione. Il DBB ha sequenze rigide che non si comprimono.
La distribuzione del rischio è un’altra variabile. Con l’EPC passa al contractor, con il DBB resta al cliente. Non è una questione di qualità del modello: è una questione di chi ha la capacità di gestire quel rischio — e a che prezzo.
Il livello di controllo che vuole mantenere il cliente incide su risorse, interfacce e coinvolgimento interno. L’EPC libera dalla gestione quotidiana, ma richiede un brief iniziale preciso. Se le specifiche sono vaghe, i problemi arrivano comunque — solo più tardi.
Infine, la cultura organizzativa. L’IPD richiede una maturità relazionale che non si improvvisa. Il DBB funziona bene dove le procedure sono rigide e la tracciabilità è prioritaria. Non si cambia modello senza cambiare i comportamenti attorno.
Un esempio concreto
Su un magazzino logistico di oltre 30.000 m² con tempistiche non negoziabili, la scelta è caduta sul Design & Build. Progettazione ed esecuzione in parallelo, governance verticale, interlocutore unico.
La lezione principale non è stata tecnica — è stata operativa. Le specifiche iniziali devono essere chiare prima di firmare, non dopo: ogni ambiguità nel brief diventa una discussione costosa durante l’esecuzione. La comunicazione deve essere snella e diretta. E il rispetto reciproco tra le parti non è un’aspirazione: è una condizione necessaria perché un DB funzioni davvero.
Con specifiche vaghe e un rapporto contrattuale conflittuale, lo stesso modello avrebbe prodotto risultati opposti.
A valle di qualunque delivery method, la gestione dei subappalti è il terreno dove si gioca concretamente il margine di progetto. Come funziona la contabilità passiva come presidio tecnico lo spiego in Contabilità passiva: non è pagare le fatture, è controllare il progetto.
Nel tuo prossimo progetto, la scelta del delivery method è stata una decisione consapevole o il risultato di un’abitudine?
Tratto dall’EP.12 del podcast Costruzioni Competenze.
Condividi l'articolo