Project management e settore pubblico: Dal procedimento al progetto
(Parte Prima)
Premesse
Il termine “procedimento”, introdotto nel nostro diritto amministrativo, e quello di “progetto”, di cui sempre più si sente parlare in materia di pubblica amministrazione, sono spesso usati come sinonimi, tanto che l’uno viene spesso sostituito dall’altro, nel comune parlare quando si tratti di opere o servizi pubblici, che più in generale rientrano nel Codice degli appalti. Analogamente “servizi” e “appalti” vengono anche spesso scambiati per… progetti. In realtà ci sono differenze fra i diversi concetti, e spesso è bene porvi la dovuta attenzione, pena il rischio di improprie interpretazioni, che possono anche avere impatti in termini gestionali e di conduzione dei relativi interventi.
Queste note mirano a fare chiarezza sui termini in argomento, anche al fine di porre nella giusta luce diversi concetti e tendenze che hanno l’obiettivo di introdurre modernità ed efficienza nella gestione della cosa pubblica, oggi sempre più oggetto di “efficientamenti”, in relazione a tendenze più generali del mercato nonché confronti – si dice “benchmarking” – con il settore privato e con altre realtà, anche al di fuori del nostro Paese.
La materia che da tempo interessa il problema di gestire in modo sempre più efficiente i procedimenti, ergo progetti pubblici, come meglio si dirà, è stata peraltro accompagnata negli ultimi anni dalla questione se il RUP, responsabile unico del progetto, sia o debba essere “arruolato” come project manager, in virtù dell’aspirazione a vederne sviluppate o migliorate le capacità gestionali.
La diatriba se il RUP fosse o potesse (anche) definirsi project manager, è andata peraltro avanti per diversi decenni, almeno fino a quando nel 2016 l’ANAC, con storica delibera a integrazione della nuova edizione del Codice, sdoganasse finalmente il tabù che il funzionario o dirigente RUP della nostra pubblica amministrazione potesse fregiarsi anche di un titolo che ormai è riconosciuto in tutto il mondo, senza particolari distinguo fra progetti pubblici e privati[1]. Peraltro in diversi paesi, come la Gran Bretagna e di stampo anglosassone, in cui non vige il diritto amministrativo, almeno come lo s’intende in Italia, non si impedisce di realizzare opere e servizi pubblici; dovendo porsi il problema di come si possano gestire al meglio certe attività, con le dovute garanzie e l’efficienza che merita la cosa pubblica; in altri termini evitare che l’istituto gestionale diventi fine a sé stesso, e non diventi invece, ameno in certi casi, lo strumento poco adatto a realizzare nuove opere e servizi, ovvero non del tutto appropriato a gestire certi tipi di interventi.
Sono infatti note le recenti evoluzioni che ha subito il nostro Codice degli appalti, specie negli ultimi anni e nelle successive edizioni e integrazioni, all’affannosa ricerca di adeguarsi alle esigenze e ai tempi, se non essere finanche oggetto di certe spinte politiche per l’eliminazione. Problema sarebbe al meno in questi termini mal posto, perché si dovrebbe porre prima la questione di eliminare lo stesso diritto amministrativo…. Peraltro ipotesi di assoluta semplificazione, trascurando che anche nei paesi che non hanno un codice degli appalti come il nostro, esistono comunque altri, se non più voluminosi manuali e documenti di riferimento, che quand’anche non abbiano la stessa natura di carattere pubblicistico o di atto legislativo, svolgono di fatto la stessa funzione.
Può invece sostenersi che il Codice degli appalti, integrato dallo storico regolamento, sia esso stesso un manuale di project management, anche se ciò non si sa né lo interpreta sotto questa luce, con tutti i miglioramenti, integrazioni e modifiche che vi andrebbero fatti. Peraltro, quando svolgiamo corsi di project management e fra i discenti ci sono dottori in legge, questi sono fra i più interessati al tema, come se si riuscisse a trovare le tessere mancanti del mosaico; essendo certo noto come la cultura multidisciplinare e multiculturale sono essenziali in questo campo.
Rileviamo che progetti pubblici o privati non sono concettualmente diversi, avendo alla base la stessa definizione, filosofia e costruzione logica, e rifuggiamo anche da coloro che osservano che un progetto pubblico sia diverso da quello privato, per i cosiddetti vincoli del codice. Diremmo invece in principio che non sono tali vincoli né il codice degli appalti né le procedure ecc. che fanno di per sé la differenza, quanto il modo di interpretarli ed applicarli; cioè più in generale il sostrato e la cultura di base, ovvero l’ambiente generale che l’intelligenza umana o il buon senso avranno il compito di piegare, governando gli strumenti disponibili, e non al contrario farsi da questi soggiogare. Certo, più facile a dirsi che a farsi, in assenza di ambienti e cultura idonei, occorrendo leadership, tempo, pazienza, strategie, nuovi strumenti e metodo.
Da sempre l’uomo, da quando si ha traccia delle sue opere, realizza progetti. Si deve quindi ritenere che il “progetto” sia nato prima del “procedimento”; quindi il primo abbia per così dire natura e un posto concettuale nella scala dei valori superiore al secondo. In pratica il procedimento nasce dal progetto, e il procedimento ne debba ereditare i valori e non viceversa, come alcuni potrebbero pensare… In altri termini il procedimento di origine amministrativa è “uno” degli strumenti gestionali che aiutano a realizzare un progetto, e neppure il solo, come alcuni potrebbero ritenere. Per cui la disciplina di gestione del progetto, in altri termini il project management – che si non si dovrà scrivere né in corsivo né maiuscolo – in verità sa più di latino che di anglosassone; e comprende come aspetto particolare e contestuale la gestione del procedimento. In quest’ottica il codice degli appalti e collegato regolamento (o quel che ne sarà) sono a ben vedere strumenti e manuali di “secondo livello” di project management; per cui, come si direbbe per le leggi, i principi di quest’ultimo sarebbero prelevanti sui primi, e quando ciò non avviene, o addirittura si vincola a fare il contrario, sarebbe sintomo che qualcosa non va nel verso giusto. Spesso ciò riguarda solo il buon senso, come ci diceva un RUP di notevole esperienza.
2. L’origine del termine
Il termine progetto deriva dal latino “pro iacere”, o abbreviato “proícere”, cioè gettare avanti, lanciare, proiettare, quindi nella lingua più tarda passato a significare anche erigere edifici. Management non è neppure inventato dagli anglosassoni, ma la versione più accreditata è quella di manu agere, cioè condurre con mano (i cavalli), da cui in particolare maneggio. È noto come gli inglesi siano amanti delle corti toscane, ed è verosimile che i nobili di quel paese abbiano dapprima importato il termine in casa loro, quindi lo abbiano riesportato in tutto il mondo dai primi del novecento in poi, tramite l’omonima produzione letteraria in materia, appunto di management, mentre nel nostro paese l’ultimo scrittore in materia resterà il Machiavelli, come argutamente citato da alcuni. Pertanto noi abbiamo tutto il diritto a parlare di project management e project manager, termini anche entrati ufficialmente nel nostro lessico in virtù della normativa in materia.
È interessante osservare come il termine “progetto” rappresenti all’origine un predicato, cioè un verbo che indica un’azione e una dinamica, che dice già tutto. Gli esperti o gli analisti di organizzazione oggi direbbero che un progetto è un particolare processo, cioè insieme di attività correlate e coordinate fra loro, finalizzate a un certo obiettivo. Si ritrova la stessa radice, ma con senso più generale e linguaggio più aziendale che procedimento; oltre il fatto che usare tale termine in testi legislativi potrebbe procurare qualche imbarazzo. Quindi progetto esprime concetto plastico e dinamico, piuttosto che rappresentare un concetto statico o cosa materiale, come sarebbe invece il “prodotto” di progetto. Purtroppo nella nostra lingua c’è stata involuzione, e il termine progetto indica comunemente anche, se non il più delle volte, quanto realizzato o da realizzare dal (processo di) progetto (!), e non il come e il sistema gestionale che ne sovrintende l’insieme delle attività.
Quando in italiano diciamo “portami il progetto” di una casa, intendiamo l’insieme degli elaborati tecnici che costituiscono il prodotto delle attività di progettazione, e non l’insieme delle attività, di coordinamento, gestione ecc., che ne hanno reso possibile o ne permetteranno l’esecuzione. Invece in inglese il termine è rimasto puro, e project indica appunto le attività che consentono la realizzazione in generale di qualsiasi opera; mentre l’attività tecnica e più specialistica di progettazione, è detta rigorosamente design. Ma guai in inglese a confondere, come facciamo noi, i due termini.
Pensiamo che questa involuzione semantica sia uno dei motivi per cui la cultura del project management, almeno in termini letterari e metodologici, non si sia sviluppata nel ‘900 in modo adeguato nel nostro paese, unitamente ad altri fattori, allorché il termine ha cominciato a diffondersi a livello internazionale (anni trenta e successivi), epoca peraltro in cui il nostro linguaggio era tutt’altro disposto a recepirlo.
Un altro fattore di reticenza alla cultura del project management, pensiamo sia una generale sottovalutazione degli aspetti gestionali rispetto a quelli tecnici, essendo la nostra cultura più olistica, creativa e tendente meno alla specializzazione di quella anglosassone, dove all’aumentare della complessità del lavoro sia stato più agevole separare la funzione di gestione (management) da quelle propriamente tecniche; ovvero saremmo meno disposti ad essere diretti da altri, pena la perdita della nostra indipendenza e creatività.
Ma quando il lavoro e i progetti diventano complessi, separare il processo gestionale o direzionale dal prodotto, diventa un passo obbligato, e chi coordina deve avere il tempo sufficiente per pensare al fine di rendere più efficiente la gestione e il lavoro degli altri; da cui il paradigma scolastico e più generale del management, comprensivo di attività di pianificazione, organizzazione, esecuzione, controllo e altre.
Significativo quanto espone in merito un manuale del CIOB (istituto inglese delle costruzioni, analogo a un nostro ordine professionale) circa l’origine della gestione progetti [2]: “La funzione del project management è applicabile a tutti i progetti. Tuttavia, nei progetti piccoli e meno complessi il ruolo di project manager può combinarsi con quello di altra disciplina, come ad es. il leader del gruppo di progettazione (design). Per progetti più complessi, le relative competenze devono essere assunte da una specifica funzione di project management”.
2. Procedimento o progetto?
Del progetto si hanno più definizioni. La più generale è quella che lo distingue dalle cosiddette attività di natura corrente e ripetitiva (in gergo anche dette “operations”), mentre un progetto ha un obiettivo unico e singolare, diverso dagli atri, nonostante vi possano essere analogie con progetti simili nello stesso settore o area applicativa. Un altro carattere fondamentale è l’avere il progetto una durata ben determinata, con una data di inizio e una di fine; salvo eventuali ripianificazioni…, comunque strettamente controllate. Fra le altre definizioni si possono citare quella assolutamente sintetica della norma UNI ISO 21502[3], come “impegno temporaneo per raggiungere uno o più obiettivi definiti”. Una definizione più articolata è quella mutuata dal dall’Istituto Italiano di Project Management (ISIPM) secondo cui “un progetto è un’imresa complessa, unica e di durata determinata, volta al raggiungimento di un obiettivo prefissato mediante un processo continuo di pianificazione, esecuzione e controllo di risorse differenziate e con vincoli interdipendenti di costi, tempi, qualità”, e aggiungiamo qui, rischi”.[4]
Nella questione di definire un progetto, spesso lo stesso concetto si trova sostituito o sovrapposto, con altre definizioni o casi di riferimento, spesso presenti nel comune linguaggio o nel volgare parlare anche degli esperti. Di ciò la Figura 1 vuol dare una rappresentazione.
Figura 1 – Progetto e diverse definizioni
Riprendiamo il procedimento. Oltre che essere termine di valore pubblicistico, riguarda nella fattispecie il procedimento amministrativo, che nel nostro ordinamento giuridico è una sequenza ordinata di atti finalizzata all’emanazione di un provvedimento amministrativo, ovvero nell’omonimo diritto un particolare tipo di atto dispositivo, che si caratterizza per produrre effetti sulle situazioni giuridiche di soggetti terzi. È pertanto termine di carattere amministrativo molto più generale, sostanzialmente finalizzato nel presente discorso al contratto e relativa gestione per la realizzazione di un’opera o servizio pubblico; il quale può riguardare progetti, propriamente detti, e “non progetti”, avendovi specifico rilievo gli atti burocratico-amministrativi. Lungi da noi, usare il termine burocratico in senso negativo o dispregiativo, avendo la burocrazia statale origini pregevoli, e tuttora aspetti e valori positivi. Si richiama che nel significato corrente il termine di procedimento (amministrativo) è regolato principalmente dalla legge n. 241/1990 “Nuove norme in materia di procedimento amministrativo e di diritto di accesso ai documenti amministrativi” (aggiornata dal DL 77/2021), e di seguito integrato dalla costituzione della figura del RUP (responsabile unico procedimento), previsto dalla Legge 11 febbraio 1994, n. 109, per l’attuazione di ogni singolo intervento di lavori pubblici, per le fasi di progettazione, affidamento ed esecuzione. Ma non tutti gli “interventi” sono progetti[5]. Ad esempio un contratto di manutenzione o suo rinnovo non rappresenta un progetto in senso proprio. Poiché lo stesso servizio (di cui riprenderemo il termine), cioè inerente attività di pura manutenzione, è infatti classificabile come attività ripetitiva e corrente, quindi esclusa da quelle di progetto; salvo che non si introducano miglioramenti, sostanziali modifiche o valore aggiunto, ad esempio pianificare un processo di manutenzione di nuovo tipo o un caso di manutenzione straordinaria, che vada più approfonditamente studiata e progettata.
Il suddetto concetto di procedimento è quindi termine da un lato più restrittivo di progetto, come si intuisce, e come si espliciterà di seguito, per le più ampie competenze in generale richieste dalla metodologia di project management, dall’altro più ampio, includendo atti e oggetti che progetti non sono.
L’appalto è come noto un particolar modo di eseguire o meglio far realizzare un lavoro. Se ne tralascia per comune conoscenza la definizione (rinviabile al Codice civile) e tutte le sue conseguenze e questioni applicative. Ma è un appalto un progetto? Anche in tal caso vale la limitazione detta sopra, per cui non tuti gli appalti hanno caratteristiche di progetto. Verosimilmente tutta l’attività per affidare un qualsiasi appalto, specie se di notevole impegno e innovazione, potrebbe essere un progetto, ma in seguito può cessare di esserlo e le relative attività affidate all’appaltatore rientrare in quelle di servizi più comuni e ricorrenti. Anche l’appalto è di norma oggetto di un contratto, costituendo uno dei petali dello pseudo quadrifoglio in figura.
Il contratto peraltro ha le stesse aree di estensione e limitazioni dei concetti già visti, salvo sovrapporsi e integrare gli stessi per ragioni di carattere amministrativo, legale e altro, quale definizione dell’ambito, corrispettivi, modalità di controllo dell’esecuzione ecc.
Ma un progetto può non essere sempre oggetto di contratto, o almeno di contratto formale, come lo si intende nel Codice degli appalti (da cui anche l’espressione del Codice dei contratti pubblici). Infatti un progetto può essere di tipo “interno”, quando ad esempio un ufficio di un ente prende in carico e s’impegna a realizzare un progetto a beneficio di altri uffici o dello stesso dipartimento, salvo un accordo più o meno… informale fra le parti interessate. Questa visione non è ad esempio compresa nello stesso codice; ma i relativi progetti possono avere non minore impatto e importanza. Si pensi ad un intervento di riorganizzazione, miglioramento dei processi di lavoro ecc., che sono tutti importanti progetti, e fino a quando non richiedano contratti esterni, non abbiano ancora nominato il RUP. Eppure anche in tal caso si dovrebbe parlare, secondo i principi di qualità, di contratti o accordi interni cliente-fornitore che giustifichino o siano giustificati dalla realizzazione di un certo progetto.
Commessa. Nel mondo delle costruzioni e nelle imprese industriali è infine comune il termine “commessa”, che anche in tal caso viene usato spesso come sinonimo di progetto; ma chi scrive si straccia le vesti! Anche commessa infatti ha alla base un rapporto di natura commerciale tra cliente e fornitore, di cui il primo anche in tal caso affida al secondo l’esecuzione di un lavoro. Tant’è che si usa il termine “capo commessa”, invece che “capo progetto”, ma molto meglio project manager. La stessa commessa ha i limiti delle voci precedenti e secondo vale più per il fornitore, che acquisisce l’incarico, che per il cliente. Non ha senso infatti per quest’ultimo, come una stazione appaltante, parlare di… capo-commessa. Anche una commessa può non riguardare la realizzazione di un progetto, ma ad esempio la fornitura di una certa quantità di materiali, per cui può identificarsi nel caso più semplice con un ordine commerciale. Inoltre nel caso delle costruzioni, realizzazione di impianti ecc. acquista più precisi significati in termini economici e scritture in bilancio. Per chi desidera approfondire, deve farsi riferimento alla linea guida dei dottori commercialisti, OIC n.23, che ne fornisce compiuta definizione e i “dettagli d’uso” [6]. Infatti lo stesso documento recita che un “un lavoro in corso su ordinazione (o commessa) si riferisce a un contratto, di durata normalmente ultrannuale, per la realizzazione di un bene (o una combinazione di beni) o per la fornitura di beni o servizi non di serie, che insieme formino un unico progetto, ovvero siano strettamente connessi o interdipendenti per ciò che riguarda la loro progettazione, tecnologia e funzione o la loro utilizzazione finale. I lavori su ordinazione sono eseguiti su ordinazione del committente secondo le specifiche tecniche da questi richieste” (…).
“o la fornitura di più beni o servizi pattuiti come oggetto unitario”.
Ne deriva che anche la commessa, o lavoro (in corso) su ordinazione, è un tipo specifico di progetto e non può, come termine particolare, identificare il tutto. Peraltro chiamare il tutto con la parte, o viceversa, è un fenomeno comune di linguaggio, che spesso può andar bene, ma talvolta induce in errore. (Fra parentesi, diciamo che conoscere un pò di project management aiuta a parlar meglio in tema ovvero usare meglio il lessico della disciplina).
I cosiddetti lavori in corso sono una voce ben conosciuta dai contabili (alias rimanenze), che appunto hanno specifico significato nel trattamento nelle voci di bilancio relative ai corrispondenti progetti specie di commesse pluriannuali; riguardando nello specifico l’imputazione dei costi e dei ricavi ai vari esercizi con l’avanzamento dei lavori. Quindi si deve ai contabili, direttori amministrativi, commerciali e altri, una tale invasione di campo nel linguaggio dei progetti! Caso giustificabile, per l’ovvia importanza che rivestono gli aspetti economici nei progetti, ma solo aspetto parziale; essendo i costi e il budget solo una voce e specifica competenza di project management. Altre essenziali competenze riguardano infatti la gestione delle risorse umane, stakeholder, rischio, qualità del prodotto realizzato ecc., come si vedrà in ulteriori note di questa serie dedicata al project management nel settore pubblico.
Autore
Pier Luigi Guida, ingegnere, svolge attività professionale nel project management da oltre trent’anni. Dirigente di società pubblica di rilevanza nazionale del settore trasporti, è 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.
[1] ANAC, Nomina, ruolo e compiti del responsabile unico del procedimento per l’affidamento di appalti e concessioni. Delibera n. 1007 del 11/10/2017 (versione aggiornata del n. 1096 del 26 ottobre 2016, Linee guida n. 3).
[2] CIOB (Chartered Institute of Building), Code of Practice for Project Management for construction and development, 3^ Ed., Blackwell.
[3] UNI ISO 21502 Gestione dei progetti, dei programmi e del portfolio. Guida alla gestione dei progetti. UNI, Ente nazionale di normazione, www.uni.com.
[4] Mastrofini E, (a cura di), ISIPM. Guida alle conoscenze di gestione progetti. FrancoAngeli.
[5] L’ulteriore declinazione della figura RUP è stata ripresa dal nuovo Codice degli appalti D. Lgs. 50/2016, a seguito del quale è stata emanata la linea guida ANAC già citata.
[6] OIC- Organismo Italiano di Contabilità. Principi Contabili. Lavori su ordinazione, 2016.
www.mediappalti.it