La norma di Project Management UNI ISO 21502 e codice appalti

1. Perché le norme di project management?

Anche il project management, quale disciplina di gestione progetti, ha razionalizzato il suo corpo di conoscenze in specifici documenti, quali norme o standard di riferimento, che rappresentano per i professionisti e gli operatori di settore delle linee guida di cosiddette “best practice”, da mettere in atto allorché s’intenda realizzare progetti in modo per quanto possibile razionale ed efficiente. Ciò vale in particolare quando trattasi di utilizzare ingenti risorse pubbliche e quando i progetti siano complessi e impegnativi. Ma anche i cosiddetti progetti medio-piccoli richiedono la dovuta perizia e attenzione. Non trattasi, come peraltro già esposto in queste colonne, di norme o regole di natura “scientifica”, ma di buone o delle migliori “pratiche” di carattere generale che, in base all’esperienza e alle competenze maturate nel campo e distillate in specifici documenti, si ritiene possano assicurare un certo successo ai progetti intrapresi. Beninteso che gli stessi abbiano alla partenza idonee fondamenta e certe precondizioni di avvio, peraltro ampiamente raccomandate dalla stessa disciplina.

Come per altre materie infatti, quando la comunità internazionale raggiunge un generale accordo su quanto costituisce i migliori o riconosciuti modi di azioni, metodi e comportamenti per affrontare determinati problemi, in condizioni di lavoro più o meno simili, e tali esperienze siano codificate in standard o linee guida riconosciute di altrettanto valore comune, è verosimile che i risultati previsti di un progetto siano raggiungibili, o meglio conseguibili con la dovuta o sufficiente efficacia ed efficienza. L’efficacia riguarda il raggiungimento soddisfacente degli obiettivi, l’efficacia il fatto che gli stessi siano conseguiti al minor costo e con le risorse disponibili. Ciò non nega assolutamente il principio che in questo percorso molto dipenderà dalle competenze e dalle capacità personali dei manager, dei gestori e di quanti altri siano responsabili degli stessi progetti, come peraltro si riconosce in tutte le discipline e le professioni; infatti, ciascuno dovrà personalizzare il proprio progetto secondo le condizioni e le particolarità del caso – come si dice in gergo fare “tailoring”-; ma si riconosce che si debbano avere anche le opportune conoscenze per condurre al meglio il proprio lavoro, e se si vuole, accelerare le proprie competenze e la crescita del proprio percorso professionale.

Già in precedenza in queste colonne ci si è proposti di evidenziare che:

• il project management non è disciplina individuale, ma di tutta la o le organizzazioni che concepiscono, finanziano, promuovono e gestiscono progetti, ciascuna nell’ambito del proprio ruolo;
• le competenze del cliente e committente risultano altrettanti importanti, se non superiori a quelle di coloro, appaltatori e fornitori, che devono realizzare e consegnare i risultati dei progetti;
• deve esistere un linguaggio comune di conoscenze di project management, oltre che di competenze e di valori riconosciuti, per portare a termine i progetti quale impresa “comune” di cliente e fornitore, quale appunto il caso dei progetti del settore pubblico; di cui in particolare il contratto d’appalto, come già peraltro evidenziato, rappresenta modo e strumento di realizzazione, certo importante, ma non sostitutivo del concetto più generale e fondamentale di progetto[1].

Degli stessi concetti e “ipotesi di lavoro” si è fatto interprete, peraltro, il nuovo codice dei contratti pubblici, nei diversi principi introdotti nella parte iniziale dell’ultima edizione, oltre che avere più esplicitamente introdotto concetti, specifici termini e citato le stesse norme di project management; forse ancora poco note e, si dovrebbe intendere, in fase di progressiva acquisizione e adozione da parte degli stakeholder interessati, quali stazioni appaltanti e operatori economici. Norme che, infatti, sono richiamate in alcuni punti del citato codice, in particolare in all. I.7, allorché si prevede che:

• Il DIP (documento di indirizzo alla progettazione), oltre ai contenuti stabiliti, può contenere, in materia di digitalizzazione dei processi e di modellazione informativa, ulteriori riferimenti alla fase esecutiva, anche con riferimento alla pianificazione e gestione della realizzazione prevista dalla norma UNI ISO 21502:2021 e dalla norma UNI ISO 31000 (art. 3, c.3);
• Per i lavori complessi (..) è inoltre predisposto, sulla base del computo metrico estimativo di cui all’articolo 31, un modello di controllo e gestione del processo di realizzazione dell’intervento attraverso l’utilizzo della metodologia di cui alla norma UNI ISO 21500 relativa alle strutture analitiche di progetto (art. 30, c.4)

• Le norme della Serie UNI ISO 21500

Nonostante la gestione dei progetti sia nata con lo sviluppo dell’innata capacità dell’uomo di realizzare opere, si fa risalire a Gantt (inizi del ‘900) la nascita del moderno project management, e la letteratura sia stata prodiga in materia sin dagli anni ’60 del secolo scorso, è dagli ’80 che si sono infatti sviluppati standard riconosciuti a livello internazionale, quali cosiddetti “corpi di conoscenze” in argomento[2]. È solo tuttavia nel 2008 che l’ISO, l’organizzazione degli standard internazionali, ha promosso la nascita di una nuova serie di norme di project management, ovvero la serie ISO 21500, dalla sigla della prima norma di riferimento, pubblicata nel 2012. Nel 2021, dopo una certa evoluzione, sono state rese disponibili nuove edizioni, quali testi appunto citati nel nostro Codice nonché recepiti dal nostro corpo di norme nazionali, sotto l’egida UNI[3].

Per completezza di scenario la cosiddetta serie 21500 comprende un gruppo di norme che riguardano diversi aspetti della materia, di project management detta in senso lato, di cui:

• la norma UNI ISO 21500 rappresenta la capostipite, e riguarda una introduzione alla stessa serie e un inquadramento generale alla materia,
• la norma UNI ISO 21502 riguarda il project management vero e proprio e la gestione progetti strictu sensu, oggetto specifico delle presenti note.

Tale premessa si giustifica in Tabella 1, che rappresenta l’elenco attuale delle norme, sui temi specifici, peraltro oggetto di progressiva estensione; mentre in Figura 1 si fornisce uno schema di sintesi. In particolare, i concetti di programma e portfolio di progetti sono già stati illustrati in precedente articolo [3]. Inoltre, dovrebbe ritenersi che, quando il Codice nel suddetto richiamo (art.30) cita la UNI ISO 21500, in realtà meglio dovrebbe interpretarsi come “serie di norme UNI ISO 21500”, essendo il precedente richiamo (art. 3) più formalmente corretto.

Argomento	Numero	Anno edizione
Conteso e concetti Project management Governance Portfolio management Programme management Work Breakdown Structure (WBS) Valore appreso (Earned Value) Vocabolario	UNI ISO 21500 UNI ISO 21502 UNI ISO 21505 UNI ISO 21504 UNI ISO 21503 UNI ISO 21511 UNI ISO 21508 UNI ISO/TR 21506	2021 2021 2021 2016 2021 2021 2021 2025

Tabella 1- Serie di Norme “UNI ISO 21500”

Figura 1- Schema della famiglia di norme ISO 21500 (fra cui si evidenzia quella oggetto dell’articolo)

La UNI ISO 21502 è stata redatta con il contributo dei rappresentanti di numerosi paesi, fra cui il nostro, che partecipa al tavolo o comitato tecnico ISO TC 258, tramite rappresentanti di uno specifico comitato dell’UNI, che partecipa anche ai lavori sulle altre norme.

• L’evoluzione della norma UNI ISO 21502

Lo standard in oggettoincorpora una certa tendenza, sviluppata negli ultimi anni nel campo normativo della gestione progetti, che favorisce un approccio metodologico meno direttivo e stringente per le organizzazioni coinvolte nella realizzazione progetti; in edizione precedente (2012) basato su un modello per “processi”, che si è evoluto tuttavia in un modello orientato alle cosiddette “pratiche” di progetto, come si espliciterà in seguito.

Il concetto di “pratica” identifica un certo tipo e numero di attività elementari, il cui svolgimento deve essere assicurato dall’organizzazione, lasciando a quest’ultima il compito di organizzare, in dettaglio, i metodi, i processi e le procedure necessarie a conseguire i rispettivi risultati. Il concetto è sostanzialmente simile, sebbene più astratto, di quello di processo, più in generale recepito da altri standard, come la più nota UNI EN ISO 9001, posta a base dell’omonima certificazione di qualità delle organizzazioni. Nonostante la differenza possa spesso apparire più formale che sostanziale, oltre che dedicata ai più eserti, tale criterio intende consentire alle organizzazioni e a coloro che praticano il project management, una certa autonomia nel definire propri standard operativi, ovvero più specifici del settore di lavoro e del tipo di progetti interessati. Ciò rispetta il fatto che la gestione progetti, dovendo ricoprire un ampio spettro di interventi, dalle grandi infrastrutture ad altre e più diffuse applicazioni (quale ad esempio il settore informatico e altri), deleghi alla singola organizzazione la definizione di un livello applicativo di maggior dettaglio, di cui restino responsabili gli stessi operatori e utenti delle norme tecniche. Di tale livello è ad esempio espressione un modello di “processi”, in cui si definiscono input e output per ciascun processo.

Per quanto detto, il documento UNI ISO è abbastanza esplicito allorché raccomanda che:

• resta compito delle organizzazioni definire propri metodi e processi per le attività di progetto
• è necessario compiere le necessarie e opportune attività di personalizzazione (di pratiche e processi) per il singolo progetto (principio del “tailoring”).

Si deve inquadrare dunque in detti criteri l’adozione di questa norma, operando il dovuto allineamento con processi e procedure propri nella fattispecie del settore pubblico, sia di carattere generale (codice dei contratti) sia specifici della singola stazione appaltante oltre che del singolo progetto.

La UNI ISO 21500 resta quindi un documento relativamente flessibile, in modo analogo alla corrente filosofia di altri standard, salvo la possibilità di verificarne l’applicazione e il coinvolgimento delle organizzazioni a seguirne i requisiti; non dovendosi trattare, come sempre, l’adozione di tali norme come la risposta formale a quanto recita il documento, quanto farne piuttosto strumento idoneo di lavoro e di miglioramento.

Entrando nello specifico dei contenuti della norma in oggetto, ed escludendo alcune sezioni introduttive, dedicate ai termini e definizioni, la stessa si compone di quattro sezioni principali, rispettivamente dedicate a:

• concetti di project management

• requisiti per formalizzare il project management

• pratiche di project management integrato

• pratiche di gestione di un progetto.

Il documento costituisce quindi uno standard di alto livello della disciplina del project management, nè focalizzato su tecniche e strumenti, che non ha come focus il solo project manager, ma più in generale tutte le organizzazioni e imprese che gestiscono progetti, nonché altri stakeholder come senior manager, dirigenti e altri enti e unità, che ad esempio possano emettere a loro volta standard più specifici, in relazione ad esempio a propri processi e prassi di lavoro.

• Concetti di project management

In tale quadro lo standard riconosce che il project management non vive da “solo” nelle organizzazioni, ma deve inquadrarsi in un modello gestionale che potrebbe e dovrebbe di fatto ritrovarsi nei diversi contesti, in termini più o meno formalizzati. A tal fine si presenta in Figura 2 lo schema attraverso cui la norma presenta un quadro di riferimento generale del contesto di project management, in questo si riconoscono:

• i diversi piani dell’ambiente del progetto, relativi cioè ad ambiente esterno, organizzazione, cosiddetta governance e realizzazione del progetto in senso stretto,
• le entità attraverso cui si realizzano gli interventi, progetti in senso stretto, nonché programmi e portfolio di progetti,
• i prodotti o risultati in termini di obiettivi, come di seguito esplicitato,
• il ciclo virtuoso, che dai risultati del progetto porta ai benefici, quindi il rinnovarsi di obiettivi, strategie e-business case per nuove iniziative[4].

Figura 2 – Schema generale di contesto del project management (fonte UNI ISO 21502)

Nel ribadire la differenza fra progetti e attività correnti (cosiddette “operations”), nello standard si osserva che gli “obiettivi di progetto possono essere realizzati da una combinazione di deliverable, output, outcome e benefici, in dipendenza del contesto del progetto e della direzione impressa dalla governance”. Si evidenzia, cioè, una progressiva evoluzione dei risultati di un progetto, attraverso cui:

• dai cosiddetti “deliverable”, ovvero ciò che si deve rilasciare al livello più elementare in termini di prodotti e componenti parziali, ma anche di documenti gestionali,
• si passa agli “output”, cioè veri e prodotti finali riconoscibili o accettabili ad esempio dal cliente;
• quindi da questi agli “outcome”, traducibili come risultati finali del progetto o risultati di cambiamento per l’organizzazione cliente;
• i quali si possono tradursi in veri e propri benefici finali.

La suddetta classificazione dei (più generalmente detti) risultati di progetto, può infatti risultare utile nel definire gli obiettivi da conseguire, avere impatto sull’ambito contrattuale ovvero fare in altri casi chiarezza fra responsabilità cliente e fornitore, oltre che in termini possibilmente economici. Non basta ad esempio realizzare un ponte o una nuova scuola perché un progetto abbia successo, ma è necessario che l’investimento apporti quei “cambiamenti” di diversa natura nonché i benefici previsti. È inoltre intuibile come in progetti definibili complessi o chiavi-in-mano, la maturazione di risultati finali e benefici non può spesso prescindere da specifiche e parallele attività che l’organizzazione cliente deve in proprio attuare; o altri casi in cui gli stessi contratti di progetto o appalti possano includere attività di transizione, passaggio in esercizio o un primo periodo operativo, in cui i ruoli di cliente e fornitore debbano essere chiaramente espressi allo scopo di conseguire i benefici attesi dal generale intervento. In altri casi, quali ad esempio interventi di riqualificazione energetica di complessi edilizi e impianti, il successo dell’intervento può dimostrarsi solo dopo un certo periodo di esercizio, ed essere soggetto ad esempio a clausole premianti in relazione alla verifica dei risultati.

Trova perciò posto nello standard quanto in letteratura inglese si era già da tempo definita come catena di valore del progetto, in termini di deliverable > output > outcome > benefici.

Un esempio può meglio chiarire. Nella realizzazione di un impianto di generazione energetica, un deliverable può essere il rilascio di un documento (ad esempio il progetto esecutivo) o una parte già realizzata dello stesso impianto; l’output rappresenta l’impianto completo e accettato in esercizio; l’outcome il cambiamento nonché il nuovo modello operativo dell’uso efficiente dell’energia; infine, i benefici, quale valore reale e misurato nel tempo del flusso dei risparmi conseguiti rispetto alla situazione originale.

Nell’includere in modo più esplicito i benefici fra i possibili obiettivi di progetto, rispetto ad altri standard, si amplia verosimilmente l’ottica e l’ambito stesso di un progetto, rilevando il carattere strategico e differenziando ancora una volta il progetto completo da un più semplice contratto di appalto. Nonché si impegna il cliente a verificare che i risultati finali dell’intervento siano conseguiti, ovvero ad attuare a tal scopo eventuali azioni integrative[5].

Nell’UNI ISO 21502 si è peraltro evoluta la stessa definizione di project management, il quale – recita il testo – “integra le pratiche, comprese nel presente documento, aventi il fine di dirigere, avviare pianificare, monitorare, controllare il progetto, gestire le risorse assegnate e motivare gli individui coinvolti nel progetto per consentire di realizzarne i benefici. Il project management si dovrebbe realizzare attraverso un insieme di processi e metodi che si dovrebbero progettare come sistema, e comprendere le pratiche necessarie allo specifico progetto”. Oltre a quanto osservato, come si vede è stata data una maggiore enfasi, rispetto a una precedente edizione, agli aspetti motivazionali delle risorse umane.

• Stakeholder e competenze

Specifici punti d’interesse riguardano la rappresentazione del diagramma degli stakeholder, in Figura 3, e le competenze del personale di progetto. Queste ricordiamo comprendono le competenze tecnico- metodologiche, cioè inerenti gli aspetti gestionali del vero e proprio project management, le competenze comportamentali (anche dette “soft skills”), e le competenze cosiddette di business o del contesto ovvero dell’area applicativa specifica del singolo progetto.

Figura 3 – Schema rappresentativo degli stakeholder di progetto

• Governance e organizzazione di progetto

Fra i concetti di carattere generale della norma meritano di essere sottolineati la governance e l’organizzazione di progetto.

Con “governance” di progetto si intendono nello specifico:

• le politiche e le regole generali attraverso cui si decide se e come avviare nonché come gestire un progetto
• i ruoli e l’organizzazione di progetto
• il ciclo di vita del progetto,

punti che commentiamo brevemente.

La governance di progetto, termine peraltro entrato nell’uso in svariati contesti, riguarda come s’intuisce l’insieme dei principi, politiche, prassi e metodi da seguire su cui basare le attività; in realtà è termine più esteso di quanto potrebbe sembrare, non riguardando solo i livelli più alti decisionali, ma si spinge per esempio sino ad elementi più operativi e di competenza del project manager. Il particolare fondamentale per l’avvio di ogni nuova iniziativa è il cosiddetto business case, cioè lo studio e il relativo documento che giustifica l’inizio e la realizzazione di un progetto, in termini essenziali di benefici, costi e, spesso negletti, rischi. Il business case è concepito per essere un documento vivo, che intende accompagnare l’intera vita del progetto e al quale restano soggette le possibili decisioni di modifica o cambiamenti che possono insorgere nel corso del medesimo. Buona pratica sarebbe che il business case sopravviva al progetto stesso, almeno sino a documentarne come evidenziato i benefici di quanto realizzato.

Una descrizione relativamente ampia è data dalla norma all’organizzazione e ai ruoli di un progetto, come nello schema in Figura 4. In particolare, qui viene esplicitata l’esistenza di una cosiddetta “sponsoring organization”, ovvero il promotore o committente di più alto livello del progetto; questo esprime il vero e proprio “sponsor” di progetto, ovvero la persona o l’entità organizzativa responsabile della sua realizzazione; ai lati dello sponsor figurano il project board o comitato guida, quando lo stesso sponsor non ne faccia già parte, e una cosiddetta funzione di project assurance. Allo sponsor riporta il project manager e infine da questi dipendono gli workpackage leader. Trattasi quindi di quattro livelli organizzativi, che si dovrebbero riscontrare in ogni progetto, anche se non tutti “obbligatori”, salvo sponsor e project manager.

Figura 4 – Modello di organizzazione di progetto (UNI ISO 21502)

Nello sponsor si identifica quindi il responsabile strategico o di più alto livello di un progetto; dal quale ne dipendono il successo e i risultati finali (più pertanto che dal project manager, peraltro scelto e nominato dal primo). Il termine di sponsor deriva immutato dal latino e contrariamente a una certa involuzione linguista ha valore e significato di garante del progetto; si deve a tutti gli effetti qualificare come figura interna all’organizzazione che realizza il progetto, e non già, come alcuni potrebbero intendere, come figura esterna, quale cliente o committente. Il ruolo di sponsor peraltro può coincidere con una persona o, come detto, entità organizzativa, quale appunto un comitato di direzione.

Il responsabile operativo del progetto è in modo ineluttabile il project manager, in tal caso certo una persona; che può avvalersi di altri “workpackage leader” quali responsabili dell’esecuzione dei singoli workpackage di cui è suddiviso il lavoro. Si osserva che “workpackage”, letteralmente pacchetto di lavoro, abbreviato WP, è il termine entrato nel gergo che designa all’origine (e formalmente) la parte elementare in cui si suddivide tutto il lavoro o l’ambito del progetto; ma progressivamente è venuta a significare più generale anche una parte più alta e di suddivisione gestionale dello stesso[6]. Peraltro, la norma prevede che il project manager possa ricoprire il ruolo di uno, di più o tutti questi, in relazione all’impegno organizzativo

Nonostante siano definizioni diverse dalla prassi comune – si osservi che la norma ha origine e deve valere anche a livello internazionale – un esempio di mappatura con il settore pubblico è abbastanza naturale. L’organizzazione sponsor può essere un ministero, che assegna i fondi e delega una stazione appaltante (quale un dipartimento interregionale delle opere pubbliche) a realizzare un’opera; quest’ultima designa il project manager – RUP; responsabile unico di progetto -, e questi può avvalersi a sua volta di responsabili di procedimento per singole fasi del progetto. Come si vede, l’organizzazione tipo della norma è del tutto conforme al nostro codice degli appalti, anche in virtù della sua ultima edizione.

Peraltro, l’organizzazione tipo della norma ha natura del tutto generale e interpretabile secondo diverse ottiche, potendosi ad esempio avere la corrispondenza di un workpackage con una fase o singolo contratto di progetto, oltre che potersi espandere su più livelli. Secondo tale modello alcuni, ad esempio, identificano il ruolo di direttore lavori come workpackage leader (fase di esecuzione) che riporta al RUP [5]. Al di sotto dello stesso modello organizzativo può espandersi l’organizzazione del o dei diversi fornitori del progetto, salvo il fatto che questi dovrebbero replicare al proprio interno una simile struttura[7].

Prima di lasciare il presente schema, si ponga l’attenzione sulla funzione qui definita come assicurazione di progetto, che secondo la norma riguarda le “azioni sistematiche e pianificate, necessarie a fornire la confidenza all’organizzazione sponsor e allo sponsor che il progetto sarà verosimilmente in grado di raggiungere i suoi obiettivi”. Detta funzione, che non va peraltro confusa con quella più specifica di assicurazione della qualità, individua piuttosto un ruolo di supporto e consultivo di livello alto del progetto, e che a tutti effetti può indentificarsi con il Collegio Consultivo Tecnico (CCT), anche introdotto nel nostro Codice (art. 215); un ulteriore parallelo con lo standard internazionale, dalla cui pratica all’estero deriva peraltro anche la citata funzione[8].

Infine, nello schema si osserva che il project manager può essere affiancato dal qui definito project office, la cui funzione, nel completare il parallelo con il linguaggio del nostro settore pubblico, può del tutto coincidere con la funzione di supporto al RUP.

In un prossimo contributo ci proponiamo di completare gli altri punti elencati della UNI ISO 21502.

Bibliografia

[1] UNI ISO 21502:2021. Gestione dei progetti, dei programmi e del portfolio – Guida alla gestione dei progetti. Ente italiano di normazione.

[2] UNI ISO 21500:2021. Gestione dei progetti, dei programmi e del portfolio – Contesto e concetti. Ente italiano di normazione.

[3] Guida P.L., Project management e settore pubblico: Dal procedimento al progetto, Mediappalti, Marzo 2023.

[4] Guida P.L., Norme di project management (e non solo), Mediappalti, Settembre 2024.

[5] Di Bonito G., RUP, Responsabile di fase, Direttore lavori e Workpackage Manager: riflessioni sulle figure introdotte dal Codice dei contratti pubblici e dalla UNI 21502, il Project Manager, n.61/2025, FrancoAngeli

---

[1][1] Principi già trattati in altri contributi di questa serie Project management e settore pubblico della Rivista, in bibliografia [3] e seguenti.

[2] I termini norma e standard sono adottai nel presente testo in modo equivalente.

[3] I testi originali sono richiamati in [1,2], il tema più generale delle norme è stato trattato in [3], in Bibliografia al termine dell’articolo.

[4] Business case è documento di seguito meglio definito.

[5] Si dovrebbe menzionare come la cosiddetta realizzazione dei benefici rappresenta secondo altri standard uno dei punti distintivi di un programma, mentre ora si riconosce che gli stessi possono rientrare fra gli obiettivi almeno di certi progetti. Purtroppo, non è prassi generale che tale aspetto venga curato al termine di un progetto, perdendo la misura dei benefici e la “contabilità” teoricamente a vita intera dell’opera o dei nuovi servizi realizzati

[6] L’insieme degli workpackage, opportunamente strutturato in livelli gerarchici, costituiscono quanto si definisce anche la WBS (work breakdown structure) del progetto.

[7] Per cui ad esempio un project manager di un’impresa appaltatrice diviene workpackage manager nel modello di stazione appaltante ecc.

[8] IL CCT è entrato nel nostro ordinamento specie allo scopo di “prevenire le controversie o consentire la rapida risoluzione delle stesse”, nonostante la funzione espressa nella norma abbia un respiro più generale.