Project management e settore pubblico (parte 5^)

Il ciclo di vita del progetto nel codice appalti (2a)

Pier Luigi Guida

1. Le altre fasi di progetto

Nel ciclo di vita del progetto, a seguito della fase di programmazione, trattata in precedente articolo, il codice degli appalti definisce i contenuti e le norme generali delle fasi successive di progettazione:

• progetto di fattibilità tecnico-economica (anche abbreviato come PFTE)
• progetto esecutivo.

Come facilmente s’intende anche la progettazione si svolge in attività successive, allo scopo di giungere progressivamente o con stadi di approfondimenti successivi alla soluzione finale da realizzare, così come in generale avviene anche in altri ambiti di carattere creativo dell’attività umana. Ma mentre anche uno scultore o designer artistico seguirà un proprio metodo nel modellare e avvicinarsi in modo progressivo al prodotto finale, per i contratti pubblici è stato definito un processo standard di progettazione, che sino a qualche tempo fa prevedeva tre fasi o livelli, e dalla nuova edizione, con la soppressione della fase intermedia di progetto “definito”, a due soli livelli, come già sopra indicato (Art.41 del codice).

La questione ha dapprima certamente ingenerato incomprensioni e difficoltà fra gli esperti, come sempre avviene ad ogni tipo di cambiamento più o meno sensibile delle prassi di lavoro consolidate. La ragione di ciò può tuttavia ritenersi motivata dall’obiettivo del legislatore e della pubblica amministrazione di eliminare una fase quale stadio di carattere burocratico amministrativo, con l’ovvia finalità di ridurre i tempi totali del progetto, i cui dati di durata, dalle diverse indagini svolte e dalla storica evidenza, risultano spesso motivo di frustrazione; in particolare per l’incidenza con cui l’attività di natura burocratica e i gap temporali tra una fase e la successiva pesano sulla durata complessiva[1]. In verità il processo creativo di progettazione non può esimersi dal metodo generale di miglioramento progressivo verso l’obiettivo, per cui il nuovo modello dovrebbe essere influenzato solo nell’aspetto formale e contrattuale, senza intaccarne la sostanza.

Si deve aggiungere che specie in determinati settori, come la costruzione di opere pubbliche, appare influire nel presente momento storico anche l’evoluzione tecnologica di progettazione, tesa nel contempo a favorire questa “contrazione burocratica”, o comunque ottimizzare l’intero ciclo di vita, attraverso i cosiddetti metodi BIM (Building Information Modelling), che tramite nuovi strumenti tecnici e processi digitali di progettazione, effettivamente possono più facilmente gestire il passaggio dal progetto di fattibilità a quello esecutivo.

Nella sostanza infatti, come già detto, i diversi livelli di progettazione devono essere considerati quale strumento principale di gestione del rischio di progetto, e quindi è necessario operare secondo tale principio, anche nel nuovo modello a due livelli, evitando approcci puramente burocratici, ma facendo leva sulle competenze di tutti i soggetti interessati (RUP, progettisti, esperti di verifica e altri), segmentando e organizzando nel modo più opportuno ciascun livello.

L’abolizione stessa del progetto definitivo peraltro è stata per così dire anticipata dalle deroghe già introdotte fra le misure per accelerare l’attuazione del PNRR, dapprima per le grandi opere e in seguito anche per le altre, per cui il legislatore dava la possibilità di affidamento sulla base del progetto di fattibilità tecnico-economica[2]; pratica quindi consolidata nell’attuale edizione del codice.

Si rinvia al codice (Art.41 e allegato I.7) per completare la lettura dell’ambito, dei contenuti e dei prodotti richiesti dai singoli livelli di progettazione, cui si dovrebbero aggiungere i cosiddetti deliverable gestionali[3].

Inoltre mentre quanto fin qui esposto fa riferimento ai progetti cosiddetti di lavori, nel caso dei servizi il codice specifica, confermando la passata edizione, che qui la fase di progettazione dev’essere unica; verosimilmente ritendo che anche in tal caso ciò si traduca in una riduzione degli oneri burocratici e quindi della durata totale dell’intervento.

Si può non concordare pienamente con tale disposto, perché anche per i progetti di servizi vi possono essere casi di certa complessità, che meritano di avere pure due livelli di progettazione; si consideri ad esempio la realizzazione di un certo sistema informatico o altri sistemi complessi di carattere innovativo e tecnologico. Anche in tal caso sarebbe buona prassi avere più di una fase di progettazione, specie quando il committente intenda riservarsi una prima fase di progettazione, di carattere interno e indipendente, ed assegnare la progettazione esecutiva e la costruzione del sistema all’appaltatore selezionato. Nulla tuttavia vieta che l’unica fase qui disposta dal codice possa strutturarsi in opportune sotto-fasi e milestone, per un opportuno controllo dell’intervento, essendo il project manager, ergo il RUP (responsabile unico di progetto) il primo attore dei necessari processi di adeguamento dell’intervento ai singoli casi e contesti (attività che si è già definita come tailoring).

Come si vede dal normale ciclo di vita progetto, suddiviso in fasi e qui per memoria ripetuto (Fig. 1), la progettazione esecutiva è seguita dalla fase di affidamento, che comprende tutto l’iter del bando, gara e selezione finale del concorrente cui verrà assegnato il contratto, secondo il processo generale del codice, ovvero secondo il modello di progetto integrato, che vede affidati a unico appaltatore sia il progetto esecutivo che i lavori di esecuzione.

Fig.1 – Ciclo di vita del progetto e relative fasi

Nondimeno lo stesso affidamento, quale attività negoziale il cui risultato è comunque la selezione del fornitore con cui si stipula un contratto, può esistere di fatto anche nelle fasi precedenti, quale in particolare PFTE e progetto esecutivo, quando si debba selezionare lo studio d’ingegneria o la società esterna cui affidare il rispettivo incarico. Da un punto di vista formale, anche ciò potrebbe in principio essere individuata come distinta fase di progetto, salvo che avere minori oneri e durata rispetto al caso di affidamento di esecuzione di un progetto complesso. Per semplicità di metodo, qui si conviene di includere tale affidamento quale prima sotto-fase del relativo progetto di fattibilità e/o esecutivo; tenendo presente che durante questo periodo potranno continuare in parallelo altre attività della stazione appaltante.

Come si comprende, la distinzione tra una sotto-fase o attività di progetto, eventualmente parallela ad atre, può risultare del tutto convenzionale e strumentale agli obiettivi e al modello gestionale proprio dell’intervento e della stazione appaltante. In modo analogo, nel corso di una fase di affidamento, potrebbe svolgersi l’attività negoziale per diversi e separati contratti. Quindi il modello di ciclo di vita del progetto, ovvero quello lineare-sequenziale (cioè come si è anche detto “a cascata”) e previsto dal codice, non dovrebbe rilevarsi come un vincolo del tutto assoluto, potendosi specializzare in relazione allo specifico progetto o fase del medesimo.

Si può concordare, nel caso di progetto o appalto integrato (Art. 44), circa la ratio del legislatore o della stazione appaltante che decida in favore della stessa l’opportunità di affidare ad un unico appaltatore sia il progetto esecutivo che la esecuzione, in base al criterio che ciò possa nel complesso migliorare l’intero approccio gestionale, migliorando l’efficienza totale dell’intervento e accelerare i tempi. D’altra parte si deve  tener conto dei casi specifici e di particolari requisiti e speciali competenze, non sempre assicurabili da un unico soggetto d’impresa. Resterà quindi responsabile la stazione appaltante di confezionare il capitolato con le dovute garanzie. In tale formula è peraltro naturale la maggiore responsabilità assunta in capo all’appaltatore, raggruppamento di imprese e simili; ma anche quella della stazione appaltante in merito al controllo dell’intervento e ai requisiti di dovute prestazioni e qualità da assicurare; specie quando il mercato offra un numero limitato di imprese specialistiche idonee a certi scopi, o comunque richieda al committente di svolgere una funzione di “system integrator” e connesso project management, avendone le competenze. Il tema, qui solo accennato, è di notevole peso ed interesse, richiedendo alla stessa stazione appaltante competenze di integratore di sistema, oltre che richiamare il codice per cui in tale decisione si deve tenere “sempre conto del rischio di eventuali scostamenti di costo nella fase esecutiva rispetto a quanto contrattualmente previsto” (art. 44).

Se nel caso di un progetto integrato l’appaltatore abbia più possibilità di assicurare maggiore efficienza, e la stazione appaltante debba gestire un unico soggetto avendo unica responsabilità, riducendo gli oneri di comunicazione e di possibili contenziosi fra le parti (committente-progettisti-esecutori), non meno responsabile resta il soggetto appaltante, dovendo comunque assicurare la conformità del progetto esecutivo ai requisiti del PFTE, e assoggettando l’avvio della fase di esecuzione al completamento delle attività di verifica dello stesso progetto esecutivo[4].

Nel caso poi del sistema di contraente generale, per l’affidamento di cosiddetti servizi globali e importo non inferiore a 100 milioni di euro (artt. 203, 204), in particolare:

• il contraente generale è tenuto fra l’altro a redigere il progetto esecutivo, in conformità del progetto di fattibilità tecnico-economica redatto dal soggetto aggiudicatore, e a compiere le attività strumentali alla sua approvazione;
• l’ente concedente redige il progetto di fattibilità tecnico-economica e approva il progetto esecutivo e le sue varianti.

In tale quadro non può che sottolinearsi l’essenzialità, e indisponibilità a scendere a facili compressi da parte dello stesso PFTE, come caposaldo posto dal codice per realizzare ogni tipo d’intervento. Peraltro sul relativo termine – fattibilità -, non trattasi solo di evoluzione semantica dallo storico “progetto preliminare”, quanto di una vera e propria evoluzione verso un tipo di progettazione più completa e matura. Per cui il termine “fattibilità” non implicherebbe invero la risposta solo al problema se il progetto in questione sia fattibile o meno (cosa nella fattispecie più consona ad un più tradizionalmente inteso “studio” di fattibilità), quanto il fatto che il progetto rilasciato dimostri senza alcun dubbio né rischio significativo che lo stesso intervento sia davvero fattibile, cioè eseguibile e realizzabile. Ciò che risulta anche avvalorato dai prodotti che dal progetto definitivo si sono trasferiti allo stesso PFTE (all. I.7, sez.II). Per alcune parti del progetto ciò potrebbe non essere esente da rischi, con evidente e accresciuta responsabilità di gestione del committente e di altre condizioni di ordine contrattuale[5].

• La fase di esecuzione

Ultima in ordine temporale del classico ciclo di vita di progetto, è la fase che il codice definisce di esecuzione, in cui si realizza e si costruisce cioè l’opera.

Nei riguardi del lessico di project management, anche in tal caso il codice si esprime bene, allineandosi con debita traduzione al linguaggio agli standard internazionali, ove pure si parla di “execution”.

Infatti si deve qui distinguere fra esecuzione, quale vera e propria fase di project management del committente, e chiamare con altri termini l’attività propria dell’appaltatore, come ad esempio “costruzione” e simili. La distinzione non è da poco. Secondo l’intendimento e il principio generale in argomento – per cui il project management non fa, ma fa fare -, per esecuzione dovrebbe infatti intendersi l’attività gestionale propria della stazione appaltante e della rispettiva struttura (RUP, ufficio di supporto ecc.), al cui interno, e di carattere più operativo, restano le attività specifiche dell’appaltatore o fornitore, che possono essere condotte anche da molteplici soggetti.

Anche nel lessico degli standard internazionali la stessa distinzione è piuttosto chiara, distinguendo le attività di vera e propria gestione (cioè management) del progetto, da quelle cosiddette di delivery, termine che si può tradurre con “realizzazione”[6]. Infatti in lingua inglese il già richiamato termine delivery ha significato molto più estensivo di “consegna”, come spesso si traduce, e comprende tutto il processo di realizzazione, ivi inclusa la consegna finale del relativo prodotto o servizio[7]. Si richiama per completezza che le attività e i deliverable, ovvero i contenuti minimi, della fase di esecuzione sono declinati sempre nell’allegato I.7 (sez. III) del codice; mentre l’attività tecnico-gestionale propria di tale interfaccia, cioè fra gestione e costruzione di progetto, è per l’appunto la direzione lavori, o in altri termini esecuzione del contratto; per cui le stesse funzioni rivestono carattere sia gestionale sia per quanto occorre natura tecnico o più specialistica.

Un progetto si chiude infine di norma e in modo formale con le attività di collaudo. Anche queste potrebbero essere intese come una fase a sé (eventualmente come ultima) ovvero sotto-fase del progetto, avente il compito di chiudere anche le normali attività amministrative, certificazioni di regolare esecuzione ecc.

Tuttavia anche queste attività possono non essere fase temporale a sé nel modello qui esposto, ma essere definite meglio come un processo, attivabile quando occorre, potendosi avere ad esempio anche attività parziali di collaudo in corso d’opera, oltre che concorrere con l’attività di collaudo finale, altrimenti intesa come sotto-fase di esecuzione, a chiusura del progetto. Inoltre, in funzione dell’opera o del sistema realizzato, un’ultima fase di progetto potrebbe avere ad esempio ulteriori contenuti, come le attività di pre-esercizio o primo periodo di esercizio, il trasferimento agli utenti finali ecc.; compiti spesso altrettanto critici, sì da dover essere puntualmente programmati per garantire la conclusione con successo del progetto, nonché l’inizio della vita operativa; quando cioè la responsabilità primaria torna al committente, cliente o promotore dell’intervento. Anche in tale periodo possono essere necessari l’eventuale supporto e la partecipazione dei fornitori (servizi di manutenzione, e altri), prima di considerare concluso il vero e proprio contratto e il relativo ciclo di vita del progetto; quindi poterne decretare finalmente il termine e annunciare il primo giorno di esercizio o di vita corrente. In tale momento si perfeziona anche il passaggio di consegne, e si trasferisce di norma anche la responsabilità di gestione dalla stazione appaltante all’organizzazione cliente, o come si diceva, usuaria dell’opera.

• Considerazioni ulteriori sul ciclo di vita

La chiusura del ciclo di vita di progetto appena trattata, richiama in particolare un concetto su cui talvolta si usa impropria terminologia. Infatti il “ciclo di vita di progetto” non va confuso con il ciclo “a vita intera” dell’opera, o più brevemente “ciclo di vita”, pure spesso in tal modo riferito nel codice. Infatti il ciclo a vita dell’opera, oltre che comprendere il ciclo di vita del progetto, prosegue come vita corrente dell’opera in esercizio, lo svolgimento delle funzioni per cui era stata concepita, le attività di manutenzione, ecc., sino alla sua dismissione o alienazione. Trattasi come si intende di ben altro argomento, che non riguarda più il project, ma ad esempio il cosiddetto service management, il facility management o altre moderne espressioni entrate nel gergo degli ultimi anni. Ciò può essere anche il caso di una concessione, che prevede sia l’appalto di realizzazione che di gestione dell’opera. Ma come si comprende, anche in termini di responsabilità gestionali e nella fattispecie contrattuali. bisogna in generale attentamente distinguere la fine del progetto, dove formalmente termina il project management, dalle attività correnti che proseguono[8].

Altre considerazioni merita l’inizio del progetto, perché se è vero che lo stesso comincia con una fase iniziale o di avvio, formalmente individuata (nel nostro caso come programmazione), si può invero osservare che la concezione o l’idea di un progetto possano nascere già dapprima, e maturare almeno fino a un certo punto, prima che si formalizzi l’inizio vero e proprio dell’intervento. Infatti possono esistere ed essere numerose le attività di predisposizione e preparatorie di un progetto, prima che questo ufficialmente sia nato. In analogia alla vita prenatale del nascituro e il fatto che si predisponga ad esempio la culla già qualche tempo prima; così da creare un terreno e un ambiente favorevole, nonché certe precondizioni perché il progetto nasca bene ed abbia successo sin dall’inizio.

Un progetto è infatti fenomeno analogo, e come si dice può interessare attività anche critiche di “pre-avvio”, ancor prima cioè che sulla sua carta di identità si possa mettere la data di inizio di cui si diceva. Infatti diversi progetti, come si intuisce, possono nascere non bene, l’ambiente non è adeguatamente preparato, i tempi sono immaturi (se non al contrario superati) e così via.

In particolare lo standard di project management UNI ISO 21502, pure richiamato dal codice, pone particolare attenzione sulle attività di cosiddetta “mobilitazione”, ovvero quelle attività in grado di assicurare la partenza più fluida o spedita possibile dei lavori di cantiere, in senso lato. Si riporta ad esempio che nel mercato internazionale detta fase sia particolarmente “attenzionata” anche in termini contrattuali, imponendo all’appaltatore specifici requisiti e obiettivi di verifica dopo un limitato periodo dalla consegna dei lavori e l’apertura del cantiere, pena l’eventuale risoluzione del contratto.

Non si può dire in generale cosa debba intendersi come attività di pre-avvio di un progetto, dovendo tale compito riguardare il caso specifico, oltre che essere guidato dalle competenze e dall’esperienza in merito. Anche in tal caso potrebbe trattarsi di diversi compiti, fra cui: chiarimento degli obiettivi e dell’ambito progettuale, abbattimento dei rischi, assicurazione delle fonti finanziarie, “vendita” e promozione dell’idea, convincimento e coinvolgimento degli stakeholder, definizione di un accordo di programma ecc. Inoltre si dovrà distinguere la data in cui il progetto formalmente nasce, come si è detto, all’interno della stazione appaltante, e la data del primo contratto con un fornitore o soggetto esterno. In altri casi ancora più complessi, le attività di pre-avvio potrebbero costituire essere stesse un vero e proprio progetto ed essere gestite come tali. Per esempio, per progetti complessi, opere strategiche, interventi di finanza di progetto, concessioni con contraente generale, sviluppi di ricerca e sviluppo tecnologici e altri, può essere opportuno e necessario effettuare ricerche e studi di fattibilità, quale base del PFTE consolidato, che vanno pure gestiti in termini di project management.

Quindi il ciclo a vita intera di un’opera può avere in realtà un inizio, spesso informale. anche anteriore alla nascita vera e propria del progetto; e quindi, dopo il termine dello stesso ciclo di vita, proseguire come si è detto nel periodo di esercizio. In altri termini il ciclo di vita (intera) dell’opera comprende il ciclo di vita del progetto.

Si è anche detto che un modello di ciclo di vita può essere convenzionale o specifico di un dato settore o contesto, codice dei contratti a parte. Nel mondo delle costruzioni e nei settori industriali, esistono infatti diversi modelli di cicli di vita, più o meno simili fra loro. Per quanto qui interessa, potremmo ad esempio citare il ciclo di vita RIBA[9], promosso dall’istituto degli architetti inglesi. Lo stesso modello negli anni ha avuto una certa evoluzione e l’ultima versione è quella che si presenta in figura (Fig. 2). Prevede in sostanza otto fasi, più una possibile fase iniziale di esercizio, il cui significato è abbastanza comprensibile[10]; inoltre lo stesso modello, come si evince nelle relative pubblicazioni, risulta già sensibilmente influenzato dai metodi di progettazione digitali del BIM (in particolare con la definizione di una fase detta di “coordinamento spaziale”).

Figura 2 – Ciclo di vita di progetto secondo il modello RIBA

Per la verità potrebbe dirsi in generale che le attività professionali da svolgersi in un progetto, o progettazione, non dovrebbero essere tanto strettamente definite da un codice, quanto dettate dalle pratiche migliori e riconosciute nel comparto di interesse, tramite cosiddette “best practice” o buone tecniche riconosciute dello stato dell’arte. Certamente un codice può rappresentare un riferimento quale standard contrattuale, per proteggere in qualche modo e garantire il mercato rispetto a requisiti minimi di buone pratiche. Si è infatti detto che un ciclo di vita di progetto dovrebbe essere inteso come una linea guida, onde assicurare certi requisiti di qualità, nonché uno standard documentale e contrattuale di mercato, altrimenti difficilmente gestibile, anche in fase di gara di natura pubblicistica, ma d’altra parte oggetto di personalizzazione (“tailoring”) quando e per quanto occorre.

In merito alla prevista uscita del nuovo codice, si ricorda che l’abolizione del progetto definitivo coinvolgeva la stessa l’ANAC, che in particolare era chiamata ad esprimersi in merito[11]. Già con riferimento al precedente codice, l’ANAC ravvisava che “Nelle more del completamento del quadro normativo di riferimento (…omissis…) la norma consente, inoltre, l’omissione di uno o entrambi i primi due livelli di progettazione, purché il livello successivo contenga tutti gli elementi previsti per il livello omesso, salvaguardando la qualità della progettazione”. Quindi “È opportuno chiarire che, quando la stazione appaltante omette livelli di progettazione, non sopprime gli stessi, ma li unifica al livello successivo che, come espressamente prescritto dal comma 4 dell’articolo 23[12], deve contenere tutti gli elementi previsti per il livello omesso, al fine di salvaguardare la qualità della progettazione. La stazione appaltante, quindi, è onerata della determinazione e della pubblicazione dell’elenco dettagliato delle prestazioni richieste, relative ai singoli livelli di progettazione, da cui potranno essere escluse, in caso di omissione di livelli progettuali, le sole prestazioni già eseguite, approvate e rese conoscibili a tutti i concorrenti”. Si riconosceva infine che “Nel calcolo dell’importo a base di gara, le stazioni appaltanti devono considerare, altresì, che alcune particolari prestazioni potrebbero ripetersi in maniera sostanzialmente identica nelle varie fasi progettuali, richiedendo soltanto modesti approfondimenti nelle fasi successive. In tali casi occorre, quindi, considerare che la remunerazione della prestazione professionale per ciascuna fase progettuale potrebbe comportare una sovrastima della parcella”.

Si poteva ritenere peraltro che un tale approccio, con semplice rinvio alla fase successive di attività ancora non svolte, ovvero la determinazione delle singole voci di parcella[13], potesse non essere esaustivo, e infatti con l’entrata in vigore del nuovo codice si è voluta riprendere la questione, e meglio specificare le voci che debbano rientrare nel PFTE, a monte, e quelle invece di competenza del progetto esecutivo, a valle; dando ulteriori specificazioni nel caso trattasi di progetto integrato.

Ma forse nemmeno un tale approccio, oltre che comprensibilmente corretto, potrebbe essere ottimale dal punto di vista della gestione di qualsiasi tipo di progetto, dovendosi assicurare nel modo migliore e nelle diverse circostanze il rischio di questo, e dovendosi affidare alle stazioni appaltanti e al RUP-project manager la definizione più idonea dei singoli casi, nonché gestire nel modo appropriato, anche tramite le attività di verifica, le questioni di interfaccia tra una fase o livello progettuale, e il successivo. Tutto ciò nel rispetto del principio, già ribadito dall’ANAC nella stessa nota in precedenza citata, dell’unitarietà del progetto e del relativo sviluppo senza soluzione di continuità.

La relativa flessibilità con cui si dovrebbe applicare il normale ciclo di vita progetto previsto dal codice, appare infine evidente allorché si debba impostare un progetto secondo le forme contrattuali più innovative, quali il dialogo competitivo e il partenariato per l’innovazione. In tal caso infatti il ciclo di vita di progetto potrebbe non essere completamente definibile all’inizio del procedimento, e vi potrebbero essere una o più fasi PFTE seguite da più fasi di progettazione esecutiva, prima di dare il via alla realizzazione ad esempio di un sistema prototipo. In tal caso il modello di ciclo di vita sequenziale potrebbe sostituirsi con altri modelli, di carattere più iterativo, più tipici dei contesti di sviluppo e innovazione.

• Conclusioni

Nel presente contributo si è cercato di chiarire la chiave di lettura che si deve dare al concetto di ciclo di vita di progetto, così importante per dare una struttura efficiente a tutta la pianificazione e gestione del progetto secondo il codice dei contratti.

In merito in particolare all’abolizione del ex-livello intermedio di progettazione o progetto definito, si può osservare che secondo il vigente modello, rispetto alla precedente edizione, sono previsti:

• un “appensantimento” (qui espresso in termini positivi) del progetto di fattibilità tecnico-economica;
• un incremento dell’impegno (in termini complementari) del previgente progetto esecutivo; anche favorendo, nel caso di progetto integrato, una strategia di maggiore responsabilizzazione dell’appaltatore, come gestore del complesso progettuale e dei lavori di esecuzione;
• la verosimile esigenza di un contemporaneo approfondimento delle attività di responsabilità proprie della stazione appaltante, circa i prodotti da realizzare in fase di programmazione (quadro esigenziale, eventuale documento di alternative progettuali e documento di indirizzo alla progettazione);
• una puntuale pianificazione e attività sartoriale o di tailoring dell’intervento.

Su questi aspetti si dovranno in particolare considerare i ritorni di esperienza di tale nuova impostazione.

Il modello del ciclo di vita con due livelli di progettazione non può che esaltare le responsabilità e la professionalità proprie degli operatori del settore delle costruzioni, in primis le stazioni appaltanti, in particolare nell’impostazione di pre-avvio e nella fase programmazione o attività prodromiche del progetto, sempre più essenziali per avviare e mettere le giuste fondamenta ai progetti di lavori di natura più complessa, nonché nella gestione tipica delle fasi di progettazione e più in generale nei progetti di servizi. È nota ad esempio la critica del poco “tempo” assegnato alle attività di progettazione nel caso delle gare, quasi a volerne compensare in parte le durate di attività di natura amministrativa. Nel contempo anche le attività note come verifica e validazione possono dover essere riorganizzate e allineate al medesimo ciclo di vita.

Dal punto di vita degli appaltatori, progettisti ed esecutori, il nuovo modello impone paralleli adeguamenti, in particolare verso una versione più unitaria, coordinata e integrata del progetto, specie con la congiunta introduzione di tecniche e strumenti della metodologia BIM, che possono introdurre nel settore maggiori efficienze e produttività, quindi una riduzione dei tempi complessivi di intervento. La stessa metodologia può inoltre consentire di modulare diversi livelli di dettaglio della progettazione fra le diverse discipline, quindi facilitare la suddivisione dei compiti e dei rischi fra le due fasi (PFTE ed esecutiva).

Il tipo di modello di ciclo di vita su esposto non può che rappresentare quindi una linea guida generale per la gestione del progetto, che dovrà restare comunque soggetto a una specifica attività di cosiddetto “tailoring” e di specificazione nei singoli a casi d’intervento, a cura del RUP project manager, modulando gli approfondimenti delle attività in relazione alle singole criticità e facendo leva sul BIM, per cogliere le flessibilità dello strumento in relazione alle diverse parte e rischi specifici del progetto.

In questo quadro un approccio di project management, conforme ai livelli di complessità del progetto, non può che risultare positivo, sia nelle fasi di progettazione che in quelle di esecuzione, facendo leva sulla professionale competenza sia della stazione appaltante che dei fornitori, aumentando il livello di trasparenza e di mitigazione dei rischi di progetto nonché la qualità di comunicazione fra i soggetti interessati. Allorché si abbia bisogno o si senta la necessità di evidenziare particolari aspetti del progetto, è opportuno usare il metodo della suddivisione in sotto-fasi e milestone, non così esplicitate nel codice, essendo pratiche più operative e di mestiere proprie del project manager. Ciò può valere anche quando si possano porre questioni di sovrapposizione di attività di natura tecnica e gestionale-amministrativa. Con l’opportuna chiarezza anche in termini di responsabilità contrattuale, qualora si ravveda la necessità di specifici approfondimenti di certe attività più critiche e complesse, il buon senso vorrebbe di anticiparle in parte in fase precedente, e richiedere i necessari approfondimenti e verifiche in fase successiva, osservando che l’obiettivo non è tanto quello di chiudere una fase, quanto organizzare un progetto che dia l’assicurazione di poter essere fattibile, cantierabile e realizzato entro i tempi, il budget e la qualità previsti, unitamente a rischi opportunamente mitigati e resi accettabili, prima di inoltrarsi in attività e fase successive.

Il piano del ciclo di vita del progetto, ai dovuti livelli di dettaglio, non deve quindi rappresentare una forma di rispetto amministrativo e burocratico, quanto figurare tra le forme più idonee di comunicazione e collaborazione fra tutti i soggetti interessati.

Autore

Pier Luigi Guida, ingegnere, svolge attività professionale nel project management da oltre trent’anni. Dirigente di società pubica di rilevanza nazionale, con funzione di referente di progetto (RUP), è stato program manager anche in campo internazionale per progetti cofinanziati dalla Commissione Europea. Autore di numerose pubblicazioni, opera nel campo della consulenza, formazione e training cooperativo. Docente di Mediaconsult dei corsi in materia, è membro del consiglio scientifico ISIPM (Istituto Italiano di Project Management) e direttore scientifico della prima rivista italiana del settore (“il Project Manager”). Ha le qualificazioni Prince2, PMP, PgMP, e certificazione di project manager riconosciuta Accredia; svolge attività di assessor e coordina il Gruppo di lavoro UNI che ha curato i lavori delle norme UNI ISO 21500 e 21502. È autore del testo recente Il project management secondo le norme UNI ISO 21500 e 21502 (FrancoAngeli).

_________________________________

---

[1] In materia di analisi dei tempi di durata delle opere pubbliche si vedano ad esempio i rapporti del Ministero dello Sviluppo Economico (www.agenziacoesione.gov.it/dossier_tematici/i-tempi-delle-opere-pubbliche/), il rapporto della Banca D’Italia (2018) (www.bancaditalia.it/pubblicazioni/qef/2019-0538/index.html?dotcache=refresh) e il saggio di Michele Corradino (“È normale, lo fanno tutti…”, ed. Chiarelettere, 2016).

[2] Riferimenti sono i vari decreti “semplificazione” PNRR, quindi in particolare L. n. 108 del 29/7/2021 e L. n.41 del 21/4/2023.

[3] Si definiscono “deliverable gestionali” prodotti in generale di natura documentale, necessari a supportare le vere e proprie attività di project management, quali piani, report e simili, la cui definizione resta a cura del project manager.

[4] “L’esecuzione dei lavori può iniziare solo dopo l’approvazione, da parte della stazione appaltante, del progetto esecutivo, il cui esame è condotto ai sensi dell’articolo 42 (Verifica)” (Art. 44, c.5). In termini accademici, si potrebbe sollevare la questione di certa rigidezza di un tale modello strettamente sequenziale, mentre in altri contesti si possano ammettere forme di attività parallele di esecuzione, da avviare prima che la progettazione esecutiva risulti tutta completata e verificata. Nel caso di contratti dell’industria impiantistica e sul mercato internazionale è normale ad esempio avere cicli di vita lineari ma con fasi ampiamente sovrapposte, cosiddetti contratti EPC (Engineering Construction Procurement), tipici di general contract, oltre che la possibilità di avere “deroghe” per parti di fase anche parzialmente sovrapposte, non critiche o non vincolanti il prosieguo dei lavori, al fine di contenere i tempi complessivi dell’intervento (pratica anche definibile di “fast tracking”, letteralmente mettere su corsia veloce o di sorpasso certe attività di progetto).

[5] Un caso è costituito ad esempio dalle attività relative a relazione geologica e indagini geognostiche, che l’ordine dei geologi si manifestava contrario allo stesso modello, che lasciava solo in tale fase le relative attività.

[6] Evitando, come propongono alcuni, il termine “consegna”, che potrebbe non avere senso compiuto ed essere riduttivo nella nostra lingua.

[7] Nella stessa lingua si parla ad esempio di “health service delivery”, intendendo il complesso del servizio della salute o sanità; mentre servizio di “consegna della salute” avrebbe poco senso.

[8] Peraltro un intervento di concessione come detto dovrebbe meglio definirsi in gergo di project management come un “programma”, includendovi sia il progetto che altre attività.

[9] Royal Institute British Architects. Tale modello è anche detto “Plan of Work” (PoW).

[10] Le stesse fasi possono leggersi come: definizione strategica, documento iniziale, progetto concettuale, (progetto di) coordinamento spaziale, progetto tecnico (esecutivo), costruzione, chiusura e trasferimento al cliente.

[11] Comunicato del presidente, 11 maggio 2022, in merito al calcolo dell’importo a base di gara per l’affidamento di servizi di architettura e ingegneria, nel caso di omissione dei livelli di progettazione ecc.

[12] Versione del codice pro tempore.

[13] Ministero della Giustizia, DM 17 giugno 2016