Nel suo saggio 'Gaps in the mind' (pubblicato per la prima volta nell'ambito del Great Ape Project1), Richard Dawkins parla della tendenza dell'Uomo a dividere qualsiasi continuum in componenti arbitrarie e discrete.
Facendo un’analogia, egli osserva che "Siamo tutti d'accordo sul fatto che una donna di oltre 1,80 m (6 piedi) è alta e una donna di poco più di 1 metro e mezzo (5 piedi) non lo è. Parole come ‘alto’ e ‘basso’ ci inducono a forzare il mondo in classi qualitative, ma ciò non significa che il mondo sia realmente suddiviso in blocchi discontinui. Mi dovresti dire che una donna è alta un metro e settantanove (5,9 piedi) e chiedermi di decidere se chiamarla alta o no, io mi stringerei nelle spalle e direi: ‘È un metro e 79, questo non ti dice già ciò che devi sapere?'
Dawkins faceva questa considerazione nel contesto della nostra distinzione tra specie, in particolare le specie che evolvono in altre specie. Egli osserva che non c'è alcun punto in cui una madre di una specie partorisca una figlia di un'altra specie, i cambiamenti da una specie all'altra sono impercettibili e si trovano, per definizione, su un continuum. Egli chiama questa inclinazione a categorizzare ‘il pensiero discontinuo’.
"Tutto molto interessante se sei un biologo evoluzionista, ma cosa c'entra questo con la gestione dei progetti?" ci si potrebbe chiedere. Dunque, il nesso è tutto nella nostra preoccupazione di stabilire se dovremmo chiamare una determinata cosa progetto, programma o portfolio.
Storicamente, i termini progetto e programma erano ampiamente intercambiabili e non venivano usati per descrivere entità tra loro distinte. Le principali iniziative degli anni '40 e '50 nel campo della difesa - che furono all'origine di così tanti strumenti di programmazione ancora oggi in uso - erano variamente conosciute come ‘Il Progetto Manhattan Project’ e ‘Il Programma Polaris’ (e nemmeno un Business Change Manager all’orizzonte). Quindi l'acronimo PERT, che dà il nome ad una tecnica utilizzata in molti progetti, sta in realtà per Programme Evaluation and Review Technique (Tecnica di Valutazione e Revisione del Programma).
Una pietra miliare utile a comprendere la separazione dei termini è stata la pubblicazione nel 1992 di ‘An Introduction to Programme Management’ (Introduzione al Programme Management) da parte della CCTA (Central Computer and Telecommunications Agency). Questo testo si è evoluto nel "Managing Successful Programmes2" (MSP – Gestire Programmi di Successo) che conosciamo oggi ed è stato probabilmente strumentale alla creazione da parte del Project Management Institute (PMI), della ‘Guide to the Program Management Body of Knowledge3’ (PgMBoK – Guida al Corpo di Conoscenze della Gella Gestione dei Programmi). Questa è stata la prima rappresentazione formale del programma di cambiamento di business, che ora riconosciamo come un tipico esempio di programma invece che di progetto.
Questo alimenta felicemente il pensiero discontinuo e porta alla situazione in cui un forum online ha recentemente ospitato una discussione che inizia con la domanda: "Ho una grande iniziativa che sta prendendo vita all’interno del portfolio [sic], ci sono molte discussioni interne sull'opportunità di trattarla come un progetto o come un programma". La discussione proseguiva chiedendo se "qualcuno ha un buon metodo decisionale che utilizza con successo per prendere questo tipo di decisioni", vale a dire un insieme di criteri che aiuti a stabilire se questa iniziativa sia un progetto o un programma.
Come prevedibile, le risposte sono state le più svariate. Alcuni erano ligi alle definizioni convenzionali di progetto e programma, altri definivano i programmi secondo parametri più comunemente usati per i portfolio, e alcuni si chiedevano semplicemente "è davvero importante?"
Questo è l'esempio lampante della nostra tendenza a costringere il mondo che ci circonda in classi qualitative. L’assunto di partenza è che l'iniziativa sia per forza o un progetto o un programma, come se tra i due ci fosse uno spazio vuoto in cui non esiste nulla. Questo presuppone altresì che esista un modo deterministico per decidere se l'iniziativa sia un progetto o un programma.
Il fatto è invece che progetti, programmi e portafogli sono punti di una linea continua. Non c'è un punto preciso ed inequivocabile in cui un'iniziativa cessa di essere un progetto e improvvisamente diventa un programma. E nemmeno dove smette di essere un programma e improvvisamente diventa un portfolio (le prime edizioni di MSP contenevano persino qualcosa chiamato ‘un programma del portfolio’ - da non confondere con ‘il portfolio dei programmi’).
Quindi perché non eliminiamo tutta questa incomprensibile storia delle ‘3P’ e chiamiamo tutto semplicemente un progetto? Certo, a volte le classi qualitative possono essere utili. Posso guardare qualcuno e non sapere la sua altezza esatta, ma so che è alto. Posso quindi comunicare alcune informazioni qualitative utili senza l'uso di un metro a nastro.
Lo stesso vale per i termini progetto, programma e portfolio. Si tratta di scorciatoie utili per descrivere un tipo di iniziativa. Il pericolo con i termini qualitativi è però che sono anche soggettivi. La mia definizione di ‘alto’ potrebbe essere uguale alla tua per alcune persone, ma ci sono sempre quelle che dal mio punto di vista sono ‘piuttosto alte’ mentre tu le consideri ‘appena sopra la media’.
Se dunque può essere una abbreviazione utile parlare di progetti, programmi e portafogli esattamente come parliamo di persone basse, nella media e alte, queste espressioni non devono passare per categorie quantitative. Sfortunatamente questo è ciò che è accaduto P3 Management (Project, Programme and Portfolio Management). Sia Axelos nel Regno Unito che il PMI negli Stati Uniti pubblicano guide separate per ciascuno dei tre ‘tipi’ di iniziativa. Si può essere un project manager qualificato, un programme manager qualificato o un portfolio manager qualificato- e così l’illusione di tre entità separate continua a perpetuarsi.
C’è davvero bisogno di riconoscere la vera natura di questi termini qualitativi. È facile capire che basso e alto sono manifestazioni dell'altezza di qualcuno misurata in piedi e pollici, o in metri e centimetri, a seconda delle preferenze. Solo definendo l'altezza effettiva di qualcuno, piuttosto che la sua altezza qualitativa, siamo in grado di comprendere il concetto di continuità.
Ma qual è l'unità con cui viene misurata la linea continua del progetto, programma e portfolio? A mio giudizio è la 'complessità'.
In termini semplici, le iniziative a bassa complessità sono progetti. Con l'aumentare della complessità, possiamo scegliere di gestire l'iniziativa come un ‘progetto complesso’ o come un programma. Quando la complessità aumenta ulteriormente, parliamo di portfolio.
Sfortunatamente la complessità non è così facile da definire in termini di unità crescenti e molto è stato scritto su ciò che è complesso e ciò che non lo è. Per semplificare leggermente le cose, suggerisco che la complessità a cui dovremmo essere realmente interessati sia la ‘complessità dell’ambito’. Le distinzioni tra le strutture organizzative e le tecniche utilizzate nei progetti, programmi e portfolio sono tutte (direttamente o indirettamente) correlate alla complessità dell'ambito.
Posso fare un semplice esempio per spiegare come funziona. Secondo la convenzione (in base alle definizioni del tutto simili di PRINCE2 e MSP), i progetti consegnano risultati non benefici, mentre i programmi consegnano benefici tramite i risultati dei progetti che ne fanno parte. Questo è come funziona il pensiero discontinuo.
Un approccio basato sul concetto di linea continua direbbe: un'iniziativa che crea un singolo output da cui si ottiene un singolo beneficio attraverso un limitato cambiamento organizzativo non è molto complessa e può essere gestita come un progetto. Al contrario, un'iniziativa che produce 23 distinti output che hanno plurime relazioni con 14 benefici quantificati che richiedono complicati cambiamenti organizzativi è complessa e dovrebbe essere gestita come un programma. Naturalmente, questo non vuol dire che il valore economico del progetto a bassa complessità non sia (o non possa essere) in realtà più grande di quello del programma complesso. Le dimensioni non contano: è tutta una questione di complessità dell'ambito.
I termini progetto, programma e portfolio sono utili. Esattamente come lo sono i termini basso, nella media e alto. Ma dovremmo sempre ricordare che si tratta di espressioni qualitative che rappresentano solo la nostra scelta di mettere etichette distinte e separate in una linea continua di complessità dell’ambito.
Quindi, chiedersi "è un progetto, un programma o un portfolio?" è la domanda sbagliata. Le domande giuste sono: "Quanto è complesso l’ambito e come devo gestire tale complessità?" Se l'approccio di gestione risultante assomiglia a qualcosa che può essere utilmente chiamato gestione del progetto, allora il lavoro è un progetto, se è qualcosa che può essere utilmente chiamato gestione del programma, allora il lavoro è un programma, e lo stesso vale per i portfolio.
Se la nostra professione vuole progredire, dobbiamo promuovere il pensiero continuo al posto del pensiero discontinuo in tutti gli aspetti di ciò che facciamo.
-
Singer e Cavalieri (Eds), The Great Ape Project, St. Martin’s Griffin, New York.
-
Axelos (2014), Managing Successful Programmes (Successo Nella Gestione dei Programmi), TSO, Norwich
-
Project Management Institute (2013), The Standard for Program Management (Lo Standard per la Gestione dei Programmi), PMI, Philadelphia
Grazie a Project Management Europa per la traduzione
