Project management e settore pubblico (parte 2)

1. Competenze di project management

In un precedente articolo abbiamo introdotto il concetto di progetto ed altri termini che spesso intervengono in tema di project management. Abbiamo per esempio definito un progetto come un “processo”, termine di natura aziendale oltre che della cultura di qualità, quale insieme di attività correlate e coordinate fra loro, che a partire da un obiettivo, che sia oltremodo chiaro e specifico, portano alla realizzazione di un nuovo prodotto o servizio, sottolineando come lo stesso termine (processo) comprenda un significato più ampio e ricco di “procedimento”, e ironizzano sul fatto come questo non sia naturalmente da confondersi con dizione analoga, ricorrente in altri ambiti di carattere giuridico (processo amministrativo), come purtroppo avviene quando si portino i progetti pubblici (e non solo) in cause di giudizio. Peraltro il termine di processo, quale gestione di progetto, comparirà ancora e più volte in queste note, ponendosi alla base, nelle sue diverse declinazioni ed aree più ristrette, della disciplina stessa del project management. Si è inoltre accennato al problema delle competenze, e come queste siano necessarie per realizzare al meglio i progetti, nel nostro caso di carattere pubblico, ma più in generale di ogni tipo.

• Project management e competenze

“Competenza” è divenuto uno dei termini più comunemente usati e ricorrenti in materia, quando si desideri coprire di un manto risolutivo ogni attività o problema di lavoro che ci si presenta. Deriva peraltro dal latino “cum petere”, e rappresenta un concetto fondamentale di riferimento per ogni disciplina, professione o simili. Si potrebbe intendere come convergere insieme, “chiedere (per risolvere un problema) con” qualcuno, il quale a sua volta ci possa dare consigli, raccomandazioni e illuminare su temi su cui possiamo sentirci insicuri. Quindi gareggiare in modo sportivo e positivo, prima che divenire competizione in senso negativo.

I testi di project management e le rispettive norme in materia, hanno accolto e definito le competenze di gestione progetti, così come in altri campi, in tre classi significative: competenze metodologiche, tecniche (o di contesto), e comportamentali. Applicandole al project management possiamo dire che:

• le competenze metodologiche si riferiscono ai principi e criteri cardini su cui si fonda la disciplina della gestione progetti e che pertanto tutti i soggetti che ne sono interessati dovrebbero conoscere, o almeno averne una infarinatura;
• le competenze tecniche, o nella fattispecie di contesto, fanno riferimento all’area applicativa e più precisamente all’ambito di realizzazione (del prodotto) di progetto, per cui se si deve costruire un edificio piuttosto che un sistema informativo aziendale, si riconosce l’opportunità di una certa conoscenza del contesto o della materia, da parte di chi dovrà gestire il progetto medesimo;
• le competenze comportamentali fanno riferimento infine alle relazioni umane ovvero a quelle capacità e attitudini o compartimenti, che i francesi ben intendono come savoir-faire, e come noto interessano il management nella sua più generale espressione.

Ciò come si vede vale per tutte le discipline e le professioni, non limitandosi alla gestione progetti in senso stretto. Ma se questo è il modello espresso negli standard del settore, si dovrebbe verificare se e come lo stesso si applichi al tema in oggetto, come il project management pubblico.

Tutti sappiamo ad esempio che in questo campo è imperioso il codice dei contratti pubblici, il quale da un lato detta le norme generali per la realizzazione di un appalto o progetto di pubblico interesse, dall’altro si spinge a definire alcune prassi e metodi che, un po’ arditamente, potremmo anche interpretare nel nostro modello come aspetti di manuale di project management! Codice che andrebbe quindi riletto e interpretato in questa migliore prospettiva. Orbene delle tre categorie di competenze che abbiamo appena introdotto, il codice degli appalti si posiziona in tale schema fra le competenze che abbiamo definito (in senso lato) tecniche o più in generale di contesto, per la realizzazione di nuove opere di lavori e servizi. E se diremmo di natura tecnico-amministrativa, saremo meglio compresi. Non si parla qui cioè, perché stiamo prendendo il discorso dall’alto, delle competenze tecnico-scientifiche o di altra natura, o si assumono come dati, quelle competenze tecnico-scientifiche d’ingegneria, architettura, restauro, informatica o simili, senza le quali non si realizza pure alcun progetto.

Nella qui definita area di competenze “tecniche” il citato codice, e altri di natura complementare o più settoriali, rappresentano infatti i testi di riferimento che tutti i soggetti che operano nello stesso campo devono letteralmente conoscere e seguire, e infatti il personale della pubblica amministrazione ne risulta spesso profondo conoscitore, non essendo comunque scevro dalle difficoltà e complessità del caso, che spesso anche gli esperti hanno occasione di evidenziare… Peraltro nello stesso codice si trovano termini e concetti di puro project management, perché altrimenti non potrebbe essere, se si vogliono far sposare le competenze tecniche con quelle di più alto livello, o come appunto le abbiamo definite, metodologiche. Ne sono esempio il cosiddetto cronoprogramma, o programma temporale del progetto, e numerosi riferimenti operativi relativi alla programmazione, progettazione ed esecuzione delle opere.

Peraltro il project management ha assunto negli ultimi decenni una vera e propria fisionomia di disciplina basata sul concetto di cosiddette “best practices”, ovvero le migliori pratiche che l’esperienza e gli esperti raccomandano di adottare nella realizzazione di progetti, che riguardano inoltre le competenze delle altre due aree, e peraltro risultino assenti dallo steso codice. Infatti si riconosce oggi che il project management è disciplina più generale costituita di metodologie, metodi, tecniche, strumenti, e per concludere competenze, grazie alle quali sarebbe possibile realizzare nel modo migliore, come spesso si dice con efficacia ed efficienza, un progetto.

Anche su questi termini andrebbe fatta un pò di chiarezza, essendo spesso usati in modo comune, alternativo o talvolta equivocati fra loro.

• Componenti del project management

La metodologia è espressione composta di ben tre voci di origine greca[1]. Rappresenta quindi all’origine l’insieme dei principi, potremmo dire anche dei valori, che caratterizzano una disciplina, aventi cioè caratteri fondanti e criteri di natura generale. Ad esempio il fatto che un progetto debba essere pianificato al meglio, specie sin dall’inizio ma quando occorre anche strada facendo, e debba basarsi sulla collaborazione di un gruppo o team affiatato e responsabile di persone, in modo poco burocratico, o quanto basti, potrebbero essere definiti principi metodologici, unitamente ad altre caratteristiche di conoscenza propri della materia, nonché riportate in tutti i manuali e le norme di interesse. Su cui intendiamo soffermarci in uno dei prossimi interventi.

I metodi[2] rappresentano una traduzione più pratica dei suddetti e più astratti principi, portandoci su di un terreno di lavoro più pratico e applicativo. Ad esempio dire che bisogna fare pianificazione non basta, ma bisogna avere modelli ed esempi più pratici di come realizzare un piano di progetto, se non pure uno strumento software di supporto. E il requisito che bisogna collaborare, deve essere accompagnato da una certa struttura organica (come si dice un organigramma) che ci dia i riferimenti di relazione fra i membri del team, le necessarie responsabilità o altre regole di base su come relazionarci ad altri, il cliente e, come oggi dice, i numerosi stakeholder[3]. L’organigramma, per inciso, in questo gergo si dice OBS (Organizational Breakdown Structure), ovvero struttura di scomposizione organizzativa del lavoro.

I metodi ci dicono in sostanza come applicare certi criteri ai contesti e alle organizzazioni specifiche in cui si opera. Ad esempio un’amministrazione pubblica può essere diversa da una start-up, e nella prima bisogna seguire certi procedimenti per impostare e mandare avanti un lavoro, mentre nella seconda si potrà essere più agili[4]. I metodi richiedono perciò, oltre che valori condivisi, comuni conoscenze e prassi di lavoro che tutti i soggetti partecipanti a un progetto devono conoscere. Mentre una metodologia può restare ad esempio di natura più generale, ed essere ad esempio adottata da più aziende, i metodi devono spesso calarsi e personalizzarsi in modo più specifico anche sulla singola azienda. Ad esempio, pur essendo dovuti tutti gli organismi pubblici a seguire il codice dei contratti, si osservano in realtà differenze anche sensibili a livello organizzativo fra gli stessi, derivanti dalla traduzione, prassi di ciascuna realtà ecc.

I metodi sono cioè più prossimi a calarsi nella singola organizzazione e trasformarsi in politiche, procedure e manuali per realizzare certe attività, spesso integrati da altre norme definibile tecniche. Inoltre il settore pubblico, soggetto allo stesso codice, comprende in realtà un vasto spettro di attori, diffusi in tutto il territorio nazionale, ciascuno operante secondo specifiche procedure, anche in relazione al proprio assetto istituzionale (dagli enti di pubblica amministrazione alle società di diritto pubblico, soggette alla sezione dei settori speciali) ecc.; il livello di risorse strumentali può essere diverso e così via, diversità che d’altra parte possono essere assolutamente ragionevoli e giustificabili.

Il livello concettuale di metodo potrebbe essere quello che più si avvicina a quello di procedimento del progetto pubblico (benché quest’ultimo resti solo una parte del primo). Ad esempio in molte organizzazioni si riconosce l’opportunità di un manuale della qualità che traduce i principi generali della qualità in metodi, processi e attività propri dell’organizzazione. Una metodologia è concettualmente più vicina a una legge, talvolta da interpretare per essere applicata al meglio; un metodo più prossimo a un regolamento di attuazione (esempio comunque un po’ azzardato…). Spesso si parla di metodologia e metodo in senso equivalente, ma sarebbe bene mantenere l’originale distinzione. Almeno con questo linguaggio.

Le tecniche possono essere concepite come un’ulteriore trasformazione e “messa a terra” del lavoro da svolgere, ad esempio come soluzioni di carattere tecnologico degli stessi metodi. Per esempio dire che devono esistere degli archivi di dati o documenti, come lo è sempre stato, non è sufficiente al mondo d’oggi, se non in relazione più o meno implicita con l’esistenza di basi dati, sistemi informativi e tecniche informatiche che ne supportino la gestione, in termini di accesso, conservazione, sicurezza, reperimento delle informazioni e così via.

Le tecniche si trasformano infine in strumenti che, come dice il termine, sono i veri e propri attrezzi del mestiere che dobbiamo o alcuni per noi devono usare per realizzare il lavoro, con i dovuti requisiti di qualità, efficienza, sicurezza dei dati ecc. … Tornando all’esempio della pianificazione, tutti conosciamo il metodo del cronoprogramma, e molti ne conoscono anche la tecnica d’impiego; essendo questo un concetto che oltre ad essere termine di project management, nonché richiamato nel codice degli appalti, è diventato invero uno dei termini più usati anche dalla classe politica e nei relativi articoli di stampa; quando cioè si voglia intendere non già lo strumento in senso stretto, ma il principio del rispetto della pianificazione e dei tempi di un progetto, che in realtà non è fatto solo di questo! In realtà trattasi della tecnica del cosiddetto Gantt, dal nome di colui che per primo lo formalizzò ai primi del novecento[5]. La stessa tecnica diviene infine strumento quando ad esempio si utilizzi uno specifico software per applicarla in modo più puntuale e corretto, ovvero si traduca la programmazione temporale (“schedule”) di un progetto in un uno specifico insieme di attività elementari, tra loro opportunamente collegate da vincoli di sequenza, precedenza e altri. Si intuisce, come in tutte le cose, esistono diversi livelli di conoscenza per uno stesso concetto.

Ma tutto ciò non basta tuttavia per pianificare un progetto, se non ne abbiamo anche le competenze, di base o più o meno avanzate, secondo le necessità del caso, cioè se non siamo stati già esposti ad una introduzione conoscitiva sul metodo, se non abbiamo l’attitudine ad applicarlo, e se infine non lo abbiamo praticato almeno una volta, prima di poterne farne effettivo strumento di lavoro, insomma non se abbia la relativa esperienza.

• La matrice delle competenze

Uno schema ancor più generale delle competenze è quello che le classifica in:

• conoscenza
• abilità
• esperienza.

Infatti, in modo più o meno esplicito, definiamo come competente, eccezioni a parte, un professionista che ne abbia l’originale titolo di studio, dimostri le dovute abilità ed abbia la necessaria esperienza, cui si affidi un certo lavoro per doverlo compiere in modo atteso o verosimilmente idoneo. Secondo altri riferimenti, si possono avere variazioni sul tema, che non ne stravolgono comunque la sostanza. Il particolare, secondo le norme di qualificazione professionale adottate dall’UNI[6], al posto della terza voce si trova la cosiddetta capacità, come dimostrazione dell’individuo ad assumere certe responsabilità e idoneità a svolgere compiti in autonomia e nelle condizioni reali di lavoro. Un tale approccio potrebbe essere più generale e sostanziale della pura esperienza, che indirettamente associa la maturazione di almeno un certo numero di anni o di età professionale in un certo campo, quale condizione necessaria, ma non sempre sufficiente. Orbene questi aspetti di competenze si possono incrociare con quelle prima dette, relative nella fattispecie al project management, allo scopo di dare un profilo più completo dell’individuo, nonché uno schema più generale del corpus di competenze in argomento.

In pratica, si potrà applicare ciascuna voce di questa seconda terna di concetti, ad ognuna della terna di competenze già in precedenza indicate; ne risulta, come dicono i matematici, una matrice “3×3” delle competenze, come si riporta in Figura 1. È in realtà un modello, come la tabellina delle moltiplicazioni che s’impara alle elementari, applicabile in senso generale a casi più generali di valutazione.

Posizione ideale Figura 1

L’ultima riga riveste ancora un particolare interesse. Come dicono gli inglesi “last but not least”[7], possiamo mettere più a fuoco le competenze comportamentali, che completano e valorizzano la persona e la figura di ogni professionista. Trattasi cioè di un insieme di caratteristiche personali tipiche di attività di management, ovvero di sapersi relazionare e gestire, come impropriamente si dice, le risorse umane. Anche in tal caso si possono individuare in tali competenze, caratteristiche di conoscenza, avendo cioè razionalizzato ed essere stati esposti a corsi specifici in materia[8]; abilità, tipiche dell’individuo oltre che di natura caratteriale e sociale, soggette anch’esse a percorsi di miglioramento e sviluppo; infine l’ineluttabile esperienza, maturata sul campo e in ambienti tipici di lavoro e quindi progetti via via più complessi.

Competenze	Conoscenze	Abilità	Esperienza
Metodologiche	Metodi e strumenti di project management	Attitudini e motivazione personali	Svolgimento di attività nei ruoli di sponsor, project manager o altri, in team di progetti
Contestuali	Applicazione al contesto o area applicativa	Capacità personali di applicazione	Caratteristiche esperienziali, conoscenza dell’ambiente
Comportamentali	Studio delle soft skills	Attitudini personali e caratteriali	Capacità acquisite e maturate con l’esperienza

Figura 1. Schema di sintesi delle competenze di project management

Le stesse competenze sono anche riportate in letteratura come “soft skills”, letteralmente abilità o competenze “soffici”, che si pongono come complementari alle cosiddette “hard skills”, ovvero quelle “dure”, con cui si definiscono le altre (competenze metodologiche e tecniche), che in genere richiedono capacità di calcolo, logico-analitiche e simili. Uno degli aspetti di maggiore interesse del moderno project management è quello di aver sensibilizzato e tradotto in termini di standard questi aspetti, se si vuole di comune buon senso nonché riconosciuti a livello internazionale.

Per dare un pò di concretezza, applichiamo ad esempio lo stesso modello alle competenze sempre al cronoprogramma (sic!), in cui si provi cioè a mettere a frutto, in modo del tutto indicativo, i concetti su esposti. Torniamo cioè all’esempio di un cronoprogramma (Gantt) di progetto, cercando di applicarlo allo schema generale su indicato; per cui può compilarsi la tabella di esempio in Figura 2.

Posizione ideale Figura 2

In questa si vede come ciascun elemento (riquadro di competenza) risulti toccato da certe competenze di attività fra loro correlate, e come possibili mancanze possano verosimilmente evidenziarsi nella pratica, davanti ai casi più complessi.

Un diagramma Gantt, oltre che essere infatti disegnato e calcolato, rappresenta in generale la sintesi di notevoli conoscenze e dati variamente acquisiti ed elaborati del progetto, oltre che essere spesso oggetto ovvero il risultato di notevole negoziazione con i diversi stakeholder o talvolta numerose parti interessate del progetto. E quando in generale non si abbiano tutte le competenze necessarie, è pratica naturale che ci si avvalga di esperti per colmare i vuoti mancanti ovvero delle competenze dell’intero team.

Cosa può nascondersi dunque dietro un semplice cronoprogramma (!), in ottica di gestione progetti. Ciò potrebbe farci capire come anche un semplice strumento, da tutti invocato, e non sempre propriamente utilizzato, può diversamente arricchirsi, e la fonte legislativa non sia sufficiente a comprenderne il significato, se non idoneamente integrata in un opportuno quadro metodologico di project management. Spesso tuttavia nelle gare di appalto e nella pratica si vedono cronoprogrammi, o Gantt, non del tutto giustificabili e lacunosi. Absit iniura verbis!

Competenze	Conoscenze	Abilità	Esperienza
Metodologiche	Criteri di stesura del programma temporale. Calcolo del percorso critico (durata del progetto).	Attitudini e approccio analitico. Predisposizione ed apprendimento del metodo e casi specifici d’uso.	Sviluppo di casi di programmi temporali di progetti in esperienze attuali di lavoro.
Contestuali	Applicazione alle fasi di progetto (secondo il codice dei contratti)	Attitudine allo svolgimento di pratiche di pianificazione e controllo unitamente ad altre discipline del progetto.	Realizzazione di cronoprogrammi in casi di progetti analoghi e via via più complessi.
Comportamentali	Studio di tecniche di interviste, ascolto attivo, gestione dei meeting, negoziazione, ecc.	Attitudine all’applicazione di tecniche relazionali nel corso di pianificazione e controllo (gestione di modifiche).	Gestione di team e stakeholder in meeting di pianificazione e controllo progetti.

Figura 2. Esempio di applicazione della matrice di competenze (cronoprogramma)

A questo punto dovrebbe risultare piuttosto evidente, quando si parli di competenze del personale incaricato di gestire progetti, quali riferimenti debbano seguirsi per avviare progetti e programmi ben fondati, non solo sulle disponibilità di budget e altre condizioni, ma anche sulle competenze delle risorse umane coinvolte – dirigenti, RUP, loro collaboratori e funzioni di supporto. Da ciò non risultano escluse le stesse stazioni appaltanti, come unità nel loro insieme, per cui in gergo si dovrebbe meglio parlare di “maturità” organizzativa di project management, secondo altri modelli della disciplina disponibili in letteratura; ma anche dal lato dei fornitori e appaltatori. Altrimenti con chi e con quale linguaggio dovrà relazionarsi lo stesso RUP?  Riprenderemo il discorso in un prossimo intervento.

Mentre consegniamo queste note alla Rivista apprendiamo che è stato approvato dal Consiglio dei ministri il nuovo codice dei contratti pubblici. L’oggetto dell’articolo ha natura metodologica e naturalmente non viene toccato dalla nuova edizione del codice che anzi riprende ed estende uno dei temi trattati (in particolare il cronoprogramma) rispetto alla precedente edizione.

L’autore sarà lieto di riprendere su questa Rivista quesiti o chiarimenti sugli argomenti esposti nella presente serie di articoli o comunque attinenti i temi qui trattati.

Autore

Pier Luigi Guida, ingegnere, svolge attività professionale nel project management da oltre trent’anni. Dirigente di società pubica 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] Con i caratteri del nostro alfabeto, metà, odos e logos, interpretabile come discorso o filosofia sul metodo, cioè strada da seguire (per raggiungere la meta).

[2] Che pertanto escludono formalmente il logos o la filosofia dalla propria definizione.

[3] Sulla cui (incerta) etimologia al momento si risparmia il lettore. Il significato più corrente è quello di tutte le “parti interessate” di un progetto.

[4] Altro termine sempre più usato, specie dopo la trasformazione del lavoro imposta o accelerata dal COVID, ma spesso usato anche in modo improprio. Ci ripromettiamo di riprendere l’argomento del project management agile in un prossimo intervento.

[5] Henry Gantt (1861-1929), socio di quel famoso Frederick Taylor, padre dell’approccio di management che si diffuse ai primi del ‘900 e da lui prese il nome (taylorismo).

[6] Ente nazionale di normazione. www.uni.it.

[7] cioè ultime cose in ordine di esposizione ma non certamente le ultime in ordine di importanza

[8] Trattasi come si comprende di materia specialistica dei corsi di istruzione in scienze umane e sociali oltre che di altri percorsi formativi in tema di coaching, team building ecc.