Project management e settore pubblico (parte 4^) Il ciclo di vita del progetto nel codice appalti

Premessa

Una delle modifiche più sensibili alla nuova edizione del codice degli appalti (D.lgs. 36/2023), in termini generali di project management, è stata l’abolizione di una delle cosiddette fasi del progetto ovvero di quella che nella precedente edizione del codice era denominata come progetto definitivo. Un progetto, come si è avuto già modo di commentare su queste colonne, è un’impresa temporanea ed unica costituita da un insieme di attività e processi, aventi il fine di realizzare uno o più obiettivi. Ció in termini di project management, ovvero della disciplina che si pone alla base di tali interventi, si distingue chiaramente dalla progettazione ovvero attività del “progetto tecnico”; termine che si dovrebbe adottare per distinguerlo da quello più generale di progetto organizzativo e gestionale. La progettazione, ad esempio tipica di ingegneria, architettura, altre discipline etc., è infatti distinta dal concetto più generale del progetto, quale insieme di attività e processi gestionali, che pianificano, dirigono e controllano le stesse attività tecniche.

Nella nostra lingua purtroppo i due termini coincidono, e quali sinonimi bisogna stare attenti a usarli e interpretarli bene. Ciò che invece non accade in lingua anglosassone, dove il termine project si riferisce al concetto più generale di progetto gestionale, nella sua più ampia accezione e che interessa il project management, mentre il termine design si riferisce al progetto di natura tecnica vera e propria, cioè ad attività e prodotti della progettazione. Guai in pratica in quella lingua a non fare distinzione dei termini, e tradurre impropriamente il nostro progetto tecnico o gli elaborati di progettazione con project! Peraltro entrambi i termini derivano dal latino, il primo project, da pro iacere, da cui lanciare avanti o proiettare, e quindi nel tardo latino passato significare anche erigere edifici; il secondo da signum da cui “disegnare”, cioè il nostro disegno propriamente detto, ovvero la rappresentazione con segni convenzionali o di un modello dell’opera da realizzare, nonché le tavole grafiche, relazioni tecniche etc., che oggi richiamano spesso i termini CAD e BIM[1]. Peraltro il termine design lo conserviamo nel nostro lessico per quel settore più creativo e artistico di più singolari attività (come il design industriale, gli oggetti di arredo, ecc.), mentre sempre in anglosassone resta concetto più generale, che comprende tutti gli aspetti della progettazione, ovvero la concezione e il modello di quanto si dovrà realizzare, dagli edifici agli oggetti ornamentali[2]. Da cui per concludere si ha il designer, in termini di disegnatore, progettista o nostro più artistico architetto e designer di moda: mentre si definisce project manager il responsabile del più generale progetto.

Per le grandi opere come le opere pubbliche o simili, è noto come la progettazione richiedi a sua volta numerosi tipi di attività, specializzazioni e discipline, e numerosi individui, progettisti, disegnatori e tecnici, fino alle centinaia se non migliaia, che dovranno essere tutti coordinati, integrati e gestiti per la produzione dei progetti tecnici e quindi per la realizzazione in generale dell’opera attraverso le successive fasi e altre attività di costruzione, verifiche, collaudi ecc. In particolare dalla fase di progettazione si passerà nella fattispecie come tutti sanno a quella, egregiamente definita dallo stesso codice, come esecuzione, che peraltro sottende in particolare la vera e propria “costruzione”, che più propriamente afferisce alle responsabilità più dirette dell’appaltatore, salvo che essere verificata e controllata in corso opera dalla direzione lavori, direzione di esecuzione del contratto e così via. Per cui si dovrebbe fare attenzione nei casi in cui lo stesso codice usi il termine “progetto” con diverso significato, come fase di progetto, sinonimo di appalto o ad esempio, propramente, come intervento divisibile in più lotti.

In questo quadro tre sono i concetti fondamentali che emergono e che ci aiutano a comprendere cosa sia e debba costituisca in generale materia del project management:

• l’impostazione e la pianificazione del progetto, in termini gestionali ed organizzativi e che riguarda tutto ciò che è necessario fare per realizzare l’opera o l’oggetto di contratto;
• la distinzione in un progetto fra la gestione e direzione, di più alto livello, e la costruzione, di livello più operativo in senso stretto;
• la necessità di organizzare e gestire l’intero progetto nel modo migliore e più consono alle espresse esigenze, i requisiti e relativa realizzazione.

1. Il ciclo di vita di progetto

Il project management, oltre a chiarire “chi fa cosa”, dà un senso generale e un approccio metodologico a questi concetti e a tutta questa impostazione del lavoro. In tale quadro, uno dei concetti primari della materia è quello di definire sin dall’inizio e bene il cosiddetto ciclo di vita del progetto, ovvero l’ossatura, su base temporale, su cui il medesimo dovrà svolgersi per essere portato a termine con successo, oltre che nella mutua soddisfazione degli stakeholder, e nella fattispecie stazione appaltante e appaltatore.

Il ciclo di vita definisce nella sostanza il piano su base temporale del progetto e la sua più analitica scomposizione in fasi, momenti o punti intermedi di controllo (gate), obiettivi intermedi (target), traguardi (milestone), stati di avanzamento lavori (SAL) e altri vincoli e condizioni, dal cui rispetto si potrà garantire la conduzione e quindi il conseguimento degli obiettivi finali dello stesso progetto. Il ciclo di vita rappresenta inoltre il riferimento attraverso cui si pianificano, si controllano e si svolgono tutte le attività di un progetto, che per non essere un’opera (solo) creativa, richiederà un certo livello di precisione e di dettaglio.

Alcuni dei termini citati sono tipici del gergo: ad esempio gate (letteralmente “cancello”) designa un momento decisivo di controllo per il passaggio da una fase alla successiva, per cui cui anche “kill gate”, come dicono gli americani, quando da quel controllo si potrà decidere se inoltrarsi in fase successiva o terminare (letteralmente uccidere) il progetto. Ad esempio il caso della pandemia del Covid ci ha evidenziato fra gli articoli di giornale il tipico ciclo di vita del progetto di un vaccino o di altro farmaco, pure basato su un riconosciuto modello con fasi sequenziali, analogo come vedremo al codice degli appalti, e secondo i requisiti rigidamente imposti da quelle agenzie di controllo a livello europeo e nazionale (fasi di ricerca, sperimentazione in laboratorio su cavie, sperimentazione clinica, prima fase con un numero limitato di soggetti, poi decine di migliaia ecc.); per cui spesso se un progetto di nuovo farmaco non supera con esito positivo una fase, il progetto si cancella.

Il ciclo di vita in tutti i settori è in altri termini un fondamentale modello di riferimento di come andrà la cosiddetta “vita del progetto”, dal suo inizio alla fine.

Per tale motivo, il codice degli appalti, che da tempo pone un tale concetto fra i punti cardine per la gestione del contratto, è allineato a questi principi, avendo fatto evolvere nel tempo lo stesso modello, che rappresenta, almeno a livello più alto, un riferimento in termini essenziali nonché operativi di tutto il procedimento o iter progettuale.

Per la verità lo stesso codice non definisce in modo esplicito il ciclo di vita del progetto, bensì il collegato ciclo di vita digitale dei contratti pubblici (art. 21), con naturale interpretazione e ottica “codicista”, potendosi assumere una corrispondenza biunivoca fra i due termini (contratto e progetto), che in realtà non esplicita tutte le attività proprie della gestione progettuale in senso lato. Si pensi a tutte le attivitá interne che la stazione appaltante deve svolgere, in aggiunta al vero e proprio contratto.

In particolare negli anni, il ciclo di vita del codice è stato oggetto di frequenti modifiche, talvolta apparentemente di carattere formale. Così l’abolizione del “progetto preliminare”, e la sua “sostituzione” e introduzione del progetto di fattibilità tecnico-economica, o cosiddetto primo livello di progettazione; quindi l’abolizione come si è detto del progetto definitivo (secondo livello di progettazione) per giungere appunto al modello attuale, su due soli livelli, più oltre commentato.

Si dovrebbe invero rilevare che il Codice, nel definire questi livelli di “progetto”, usa termini in generale acquisiti nel lessico del project management; quando tuttavia gli stessi si intendano propriamente come “fasi gestionali” dell’intero progetto, e non già solo come produzione dei relativi elaborati o prodotti di progettazione; confondendo cioè, come spesso avviene nel linguaggio comune, il processo e le attività, con il prodotto compiuto, che comunque resta obiettivo essenziale del lavoro. Saper realizzare il film, non é la pellicola che andiamo a vedere al cinema. Ma come detto, spesso non si dà purtroppo il giusto peso e significato ai termini, e si sottovalutano ad esempio le attività di natura organizzativa e gestionale da compiere, per realizzare l’oggetto o res del contratto, e si corre il rischio di non dare a le risorse necessarie al lavoro, alle capacità e alle competenze di natura gestionale[3]. La figura 1 cerca di esprime questi concetti.

Figura 1 – Concetti di progetto e progettazione

In particolare, un progetto può essere quindi un “progetto di progettazione”, quando l’oggetto da compiere è il vero e proprio complesso di elaborati e modelli necessari quali riferimento di costruzione dell’opera, e questo debba essere composto di una o di più fasi di progettazione, in cui dev’essere opportunamente suddiviso l’insieme del lavoro. Secondo il buon principio del “divide et impera”, avvicinarsi cioè alla soluzione finale attraverso momenti di specificazione progressiva.

È naturale ad esempio come una società o studio di progettazione avranno per missione quella di compiere progetti, oltre che assisterli in fase di costruzione; mentre per una stazione appaltante (pubblica o privata) la progettazione non puó che costituire a sua volta una fase dell’intero processo, il cui contenuto è l’esecuzione di un “servizio” (peraltro in termini, a noi non graditi, quasi riduttivi nel lessico del codice). Servizio che infatti può comprendere ben altre e diverse attività, più di quanto lo stesso termine possa semplicemente rappresentare.

Quando tratta di progettazione, la natura e l’oggetto o ambito principale del progetto, con dizione inglese la stessa attività si definisce, con comprensibile allocuzione, “design management”, e con design manager il rispettivo responsabile; termine che sempre più spesso appare anche nel nostro paese. Talvolta questo si usa anche per indicare il cosiddetto progettista “integratore” o di sistema, avente appunto il compito di integrare e coordinare più discipline tecniche, e al quale si debbano richiedere sia competenze di estrazione tecnica, sia di fatto anche competenze gestionali, quindi di project management[4]. In effetti figure di designer manager possono incontrarsi in vario modo nelle maggiori organizzazioni e specie nei progetti definibili più complessi, anche se quest’ultimo concetto (complessità) é del tutto relativo.

Si può dunque avere il design manager quale definizione di ruolo alternativo a quella di project manager, o come ruolo aggiuntivo a quello di project manager, ovvero di intermediazione fra responsabilità gestionali dell’intero progetto, e quelle di progettazione, specie di carattere multidisciplinare. In altri casi, come in un progetto di appalto, il designer manager potrà essere ad esempio un ruolo ricoperto da soggetto esterno o dall’appaltatore, tale da rispondere ad esempio al project manager o RUP (responsabile unico del progetto intero), nonché qualificarsi egli o ella stessa come project manager all’interno dell’organizzazione dello stesso appaltatore[5]. In altri casi può corrispondere al ruolo che in certi ambiti e settori si definisce anche “project engineer”.

Pertanto, al fine di comprendere come il ciclo di vita si attagli all’organizzazione, si dovrà necessariamente scendere più in dettaglio nei diversi casi, per comprendere cioè, come sempre, ruoli e funzioni, chi fa che cosa e relative responsabilità. Come si vede non è sempre anglofilia che ci porta a dover introdurre ogni tanto termini anglosassoni, quanto l’opportunità di rifarsi a concetti e modelli organizzativi nei paesi in cui sono stati per primi introdotti, o almeno formalizzati, e quindi diffusi sul mercato internazionale, con cui molte delle nostre imprese già lavorano, o prima o poi devono interagire e confrontarsi.

• Il ciclo di vita del progetto nel codice degli appalti

Nel vigente codice degli appalti l’espressione ciclo di vita del progetto (già procedimento) come detto non appare esplicitamente riportata, anche se abbastanza chiaramente si evince, sia con riferimento al ciclo di vita dei contratti, sia essendo dedicate alle singole fasi di progetto specifici articoli del codice[6]. Nello stesso testo, il ciclo di vita in oggetto viene infatti convenzionalmente suddiviso nelle fasi di:

• programmazione
• progetto di fattibilità tecnica-economica
• progetto esecutivo
• affidamento
• esecuzione.

Figura 2. Ciclo di vita del progetto secondo il Codice appalti. Nel caso di progetto integrato, l’affidamento a unico appaltatore delle fasi di progetto esecutivo e lavori di esecuzione avviene dopo il progetto di fattibilità tecnico-economico. Nel caso di servizi e fornitura è prevista una sola fase di progettazione.

Lo schema relativo è riportato in figura (Fig.2). Si osservi che in questo si omette per semplicità la fase di “pubblicazione”, più tipica del processo procedimentale, o comunque qui concepita come integrata ad esempio nell’affidamento. Inoltre nel caso di progetto integrato[7], lo stesso affidamento, qui in generale rilevato appunto come fase, per l’importanza amministrativa, la durata e il “peso” relativo specie dei maggiori contratti, si deve anticipare nel suddetto schema a prima del progetto esecutivo, dovendosi affidare qui all’appaltatore prescelto sia il progetto esecutivo che i lavori di esecuzione.

Lo stesso schema in figura appare inoltre semplificato non avendo indicato in modo esplicito pure le attività di affidamento dei servizi di progettazione, allorché commissionati all’esterno, e che si possono quindi comprendere nelle rispettive fasi.

Si osservi che la definizione del ciclo di vita di un progetto, e in particolare le denominazioni delle singole fasi, può essere convenzionale, salvo che rappresentare un modello soggetto a ulteriori dettagli, esplicitazione dei contenuti e interpretazioni proprie del settore o della realtà aziendale in cui si operi. In generale, a parte le linee del codice in parola e altri requisiti dettati dal committente in capitolato, anche in contrattualistica privata o nel mercato internazionale, la sua ulteriore specificazione è compito di norma del project manager, che unitamente ad altre attività avrà il compito di adattarlo e di personalizzarlo allo specifico intervento, cioè fare come si dice “tailoring” [8]

La fase di “programmazione di progetto”, meglio invero ora specificata che nell’edizione precedente del codice, si deve in altri termini interpretare come l’insieme del lavoro, quali atti, documenti e altre attività di progetto, di natura preparatoria e sostanziale, necessari a costituire le basi – si potrebbero dire porre solide fondamenta – perché il progetto possa essere positivamente impostato, avviato e compiuto nelle fasi successive. In parallelo ad altri standard di project management, può essere definita in generale anche fase di “avvio”.

La programmazione di progetto non è peraltro da confondersi con la programmazione, anche e più esplicitamente definita nel codice, di carattere più generale, richiesta alla stessa stazione appaltante, e nella fattispecie denominata “programmazione triennale”, in cui cioè si definiscono l’insieme degli appalti, lavori e servizi che si prevede di attivare nel rispettivo triennio. Per cui si potrebbe comprendere la programmazione di progetto su indicata come parte o componente di quella triennale, quando ne occorrano le condizioni.

Nella programmazione di progetto come si riporta in figura, devono essere in particolare prodotti i documenti fondamentali indicati quali:

• quadro esigenziale
• documento di fattibilità delle alternative progettuali (ove ritenuto opportuno)
• documento di indirizzo alla progettazione.

Quest’ultimo in particolare deve porre le basi a tutta la seguente pianificazione e attività di progetto, sia di natura gestionale che tecnica.

La programmazione di progetto rappresenta cioè una fase nel cui momento di inizio un determinato progetto prende vita, risulta formalmente approvato dall’ente promotore e/o finanziatore, il finanziamento ne è garantito (secondo atti e procedure previste), e il RUP ne risulta nominato. Inoltre è questa una fase in cui sia possibile rilevare con certezza l’inizio o la “data di nascita” del progetto, come possibilmente iscriverla sulla sua carta d’identità, come ciascuno di noi la trova sul proprio documento.

Identificare con certezza operativa la data di inizio di un progetto, in termini di project management è fondamentale, perché ad esempio nell’industria significa che da tale momento la responsabilità di gestirlo passa al project manager, nonché al relativo sponsor, come si definisce in metodologia la persona o l’entità organizzativa a cui riporta lo stesso project manager, e a cui si affida la responsabilità direzionale o strategica di più alto livello dell’intervento.

Talvolta nei corsi rivolti a personale dell’amministrazione pubblica ci permettiamo di chiedere: “- Quando è iniziato il vostro progetto?”, ma la risposta non sempre appare immediata. In particolare si può far coincidere tale data con quella di nomina del RUP o l’acquisizione del cosiddetto CUP (codice unico di progetto), ma possono esserci altre convenzioni. La rilevanza è che da quel momento si deve anche stabilire la durata e quindi la data di fine progetto; e dallo stesso momento i suoi responsabili dovranno tener conto del tempo, quindi della durata a finire, e purtroppo degli eventuali ritardi.

Nell’industria delle imprese che operano come si dice a commessa, l’inizio del progetto può ad esempio stabilirsi con la data di apertura nel sistema contabile del conto di commessa, per cui dallo stesso momento il project manager è autorizzato a sostenere spese, addebitare costi, i membri di progetto imputare le proprie ore di lavoro ecc., nell’ipotesi l’azienda abbia un idoneo sistema di contabilità industriale.

La stessa data potrebbe essere anche posteriore alla data amministrativa del contratto originale, acquisito dalla direzione commerciale, ivi compresa la data del termine contrattuale. Dal punto di vista del project management (o manager) è quindi importante che da tale momento abbiano o possano aver luogo anche altre attività operative del progetto, in quanto eventuali o ulteriori tempi o ritardi amministrativi, comunque da contemplarsi nel piano, non potranno che pesare sulla tempistica.

Ciò illumina di ulteriore luce la differenza fra il progetto di stazione appaltante e il contratto con un appaltatore, che può avere tutt’altro significato e costituire invece progetto (o fase di progetto) per quest’ultimo.

Quindi, se un progetto deve avere ha una propria data di inizio e una di fine, rispettive date di inizio e di fine devono averle tutte le fasi che lo compongono, non potendo esserci in principio periodi di buco o gap temporali fra una fase e la successiva. Un tale modello di ciclo di vita più semplice e standard, come appunto in generale quello da codice degli appalti, è il cosiddetto modello di tipo lineare, sequenziale o a cascata (“waterfall”)[9]. In tal modo, tutte le fasi sono consecutive e l’inizio di una fase successiva coincide con la fine della fase che precede.

Le prassi di project management prevedono altri modelli di cicli di vita, software ecc., ma al momento non sono qui oggetto di approfondimento.

Perché, ci si potrebbe chiedere, un ciclo di vita e la necessità di organizzarne il lavoro in fasi o periodi più limitati di tempo? La questione è banale, anche se talvolta non ha la dovuta attenzione, Ciò avviene in tutti i casi di vita, così come nei sistemi socio-tecnici, in cui si distinguono convenzionalmente diverse fasi o periodi, e ognuno è caratterizzato da certe proprietà, attività da svolgere ecc. Ma nel project management un modello di ciclo di vita rappresenta anche il primo e fondamentale modo per controllarne il rischio.

Quale cliente o sponsor si sentirebbe di affidare in fase unica un lavoro pluriennale o che abbia lunga durata? Con tutto il relativo budget, e senza ulteriori punti di controllo e verifiche intermedi? Nel caso infatti non si definisca o si pianifichi a dovere il ciclo di vita di un progetto, può significare ineluttabilmente non poterlo gestire o controllare bene in corso d’opera; in una frase, aumentarne il rischio (quando va bene), e chiuderlo anzitempo, senza successo o con gravi ritardi (quando va male).

Poiché il progetto non rilascia l’opera o il prodotto tutto alla fine, nel corso di ciascuna fase del ciclo e in particolare al termine della stessa, il progetto dovrà rilasciare prodotti intermedi, in generale detti deliverable, che rappresentano le consegne parziali del progetto, sino alla consegna del deliverable o prodotto finale. Dato un certo tipo di ciclo di vita, è perciò compito del project manager personalizzarlo ulteriormente, per le esigenze del singolo progetto o contratto.

Con lo stesso criterio di controllo di cui sopra, è intuitivo per esempio suddividere una fase in più sotto-fasi. secondo le esigenze, le criticità e il lavoro da compiere; per cui ciascuna sotto-fase sarà a sua volta caratterizzata da specifiche attività e quindi consegne o relativi deliverable. Inoltre è prassi indicare sui programmi di progetto, i cosiddetti Gantt o cronoprogrammi, le cosiddette milestone, altro nome di origine latina (pietre miliari), coincidenti con particolari punti di controllo o di altri eventi significativi di progetto, quali ad esempio: la fine di una certa fase o sotto fase, la consegna di un determinato deliverable, la verifica di una certa condizione, un collaudo e simili. Si ricordi che con deliverable si designano sia componenti del servizio o parti d´opera in costruzione, sia documenti gestionali, cioè propri del project management, come un piano e simili.

Dati certi punti chiave, in cui stazione appaltante e fornitore devono incontrarsi, è peraltro possibile intuire come per un certo progetto potranno figurare, anche in modo diverso, milestone e dettagli sul cronoprogramma dell’appaltatore, rispetto a quello contrattuale proprio della stazione appaltante; nel primo ci potrebbero essere certi dettagli e inoltre certi dettagli che la seconda non ha interesse di vedere; dovendo comunque i due programmi convergere in determinati punti di controllo. Una milestone comune può essere ad esempio costituita dalla data di un SAL, in cui alla stazione appaltante si richiede di riconoscere il lavoro maturato e quindi rilasciare i pagamenti dovuti, anche in base a quanto previsto in contratto.

Si intuisce che non esistono regole generali per definire sotto-fasi e milestone, essendo questo un compito quanto mai importante che solo l’esperienza, le analisi tecniche e le condizioni di rischio potranno risolvere da parte del project manager, dell’impresa e di tutti coloro che dovranno prestare la propria collaborazione alla pianificazione del progetto. In definitiva, sebbene il modello di ciclo di vita del codice possa rappresentare una struttura vincolante, nulla vieta che secondo buone prassi di project management lo si debba specializzare secondo ulteriori livelli di dettaglio, quanto ció si reputi necessario ed opportuno per la gestione più efficace e trasparente del progetto. Riteniamo che questo non sempre sia un aspetto ancora trattato a dovere, o almeno con l’attenzione che merita.

Il ciclo di vita del progetto è quindi la base rispetto a cui vengono elaborati i cronoprogrammi richiesti nelle diverse fasi del progetto e quindi, con i requisiti indicati, dall’appaltatore, con metodologia di successiva approssimazione e in tutti i casi lo richieda la eventuale ripianificazione del progetto.

Il codice degli appalti, oltre a definire il modello del ciclo di vita suesposto, declina gli ulteriori contenuti di attività e deliverable specifici delle singole fasi, in modo da dare linee guida standard e vincoli di contenuti minimi per l’esecuzione del contratto. Sempre in ottica generale, detti contenuti non possono che rappresentare punti di carattere generale da rispettare, valendo in ogni caso le condizioni e i requisiti di maggior dettaglio, da specificare in modo opportuno nei documenti di progetto (già elaborati in fase di programmazione), quali ulteriori vincoli contrattuali e di capitolato speciale.

In una parte seguente dell’articolo, ci proponiamo di concludere la discussione su altre fasi e considerazioni in argomento.

---

[1] CAD: Computer Aided Design (appunto) e BIM: Building Information Modelling, cioè metodi e tecniche assistiti dal computer e in generale processi e sistemi digitali.

[2] Peraltro per disegnare o semplicemente tracciare linee da disegno, si usa in inglese “to draw” e “drawing”.

[3] In fondo non vorremmo essere qualunquisti nel dire che le difficoltà che oggi incontra il nostro Paese dinanzi la sfida del PNRR risentano più di quest’ultimo carattere che di pure capacità tecniche.

[4] Competenze di disciplina e di organizzazione che non sono quindi da confondere con quelle esclusive di project manager.

[5] Caso di progetto integrato, come oltre richiamato

[6] In particolare art 41 e altri.

[7] Art. 44, cioè ove l’appaltatore sia affidatario di contratto sia del progetto esecutivo che di quello di esecuzione.

[8] Espressione che deriva da “tailor”, sarto, che richiama tutte le attività che il project manager deve operare quasi in modo sartoriale per il progetto specifico.

[9] Waterfall o “a cascata”, così definito in analogia alle cascate delle ville rinascimentali, aventi tratti di condotta in leggera pendenza per cui l’acqua dopo aver fluito su di un tratto si versa su quello successivo.