Anche se la gestione dei progetti è in circolazione da secoli, penso che la maggior parte, se non tutti, i driver significativi del project management dei giorni nostri possano essere fatti risalire al 1979.
Alla fine degli anni '70 la gestione dei progetti era appannaggio principalmente delle industrie dell'edilizia e dell'ingegneria. Ci sono tre aspetto fondamentali da capire riguardo a quel periodo:
Il project management non era visto come una disciplina a se stante. I responsabili dei contratti edilizi lo consideravano semplicemente come l’insieme di cose che facevano per fare il proprio lavoro (e questo modo di vedere non è in realtà molto cambiato nei 38 anni successivi)
La pianificazione e la schedulazione – che rappresentavano il dominio dei pianificatori dedicati - non venivano eseguite dai project manager
L’Information Technology (IT), successivamente chiamata Data Processing (DP – Elaborazione dei Dati), era proprio agli albori ma aveva appena iniziato a provare e formalizzare i suoi metodi attraverso dei manuali come PROMPT e SSADM
Quindi cosa accadde nel 1979? – i computer diventarono desktop.
All'improvviso, la postazione di chi pianificava non era più legata all'ufficio ove era collocato il computer centrale. Essi potevano creare, analizzare e fare i report dei loro programmi in ore anziché in giorni. La pianificazione e la schedulazione assunsero un profilo molto più rilevante in un brevissimo lasso di tempo.
Le nuove società di software per personal computer trovarono un mercato già pronto in chi si occupava di pianificazione edilizia, ma iniziarono rapidamente a vendere al proprio settore industriale. La pianificazione e la schedulazione divennero di grande moda nei progetti di sviluppo software e insieme a questo nacque l'esigenza di formazione - e di formatori. Il luogo ovvio da cui attingere formatori era l'industria edilizia.
Nel corso degli anni '80 ci fu un boom del software per la pianificazione del progetto (utilizzando tecniche che traevano origine dai progetti infrastrutturali) e della formazione ad esso associata, che veniva erogata prevalentemente da ex pianificatori del settore edilizio. Quella che stava diventando l’industria dell’IT attinse molti dei suoi approcci e della cultura del project management dal settore edilizio.
Contemporaneamente, le organizzazioni stavano cercando di confrontarsi con la crescente dimensione e complessità dei progetti IT. I sistemi Simpact a metà degli anni '70 avevano creato PROMPT, che fu poi adottato dai dipartimenti governativi del Regno Unito nel 1983. Nel 1989 lo stesso era diventato PRINCE.
Gli anni '90 hanno visto altri tre sviluppi significativi.
Intorno al 1992, l'Agenzia Centrale per i Computer e le Telecomunicazioni del Regno Unito (CCTA) commissionò un altro progetto per esaminare i progetti complessi che comportavano cambiamenti di business. Questa volta fu PA Consulting a produrre la guida, che per prima ha coniato il termine "Gestione del Programma" nel contesto del cambiamento di business (anche se nel settore edilizio il termine programma è ancora sinonimo di "schedulazione" o "grafico a barre"). In seguito nel 1999 questa guida è divenuta Managing Successful Programmes (MSP – Gestire Programmi di Successo), sebbene in seguito ne siano state scorporate alcune parti per diventare “gestione del portfolio” – ancora un’altra distinta sotto-disciplina.
Sempre nel 1992, la Association for Project Management (APM) britannica produceva il suo primo ‘Corpo di Conoscenze’ nel tentativo di definire la ‘professione’ del project management. A questo è seguito nel 1996 il corpo di conoscenze del Project Management Institute (PMI) statunitense.
La CCTA stipulò un contratto con APM Group per l'avvio delle certificazioni PRINCE. La gamma di certificazioni messe a disposizione da parte di organismi professionali e di certificazione esplose.
Gli anni '90 hanno visto la crescita delle certificazioni nello stesso modo in cui gli anni '80 avevano assistito alla crescita dei software per la pianificazione. Ma soprattutto la crescita delle certificazioni ha alimentato la necessità di procedere ad una classificazione. Non si avevano più semplicemente certificazioni in ‘project management’, ma in specifici (‘ribattezzati’) sottoinsiemi di ciò che in precedenza era stato visto tutto come project management.
In genere, riguardavano progetti, programmi o portfolio; trattavano sia la conoscenza che il metodo; si occupavano anche di sotto-insiemi di conoscenza come il rischio o la schedulazione. Le indicazioni su come gestire i progetti (nell'accezione originale del termine) divennero sempre più settoriali.
L'alba del nuovo millennio ha assistito alla reazione del settore IT contro l’eredità degli approcci di tipo infrastrutturale applicati all'IT. Un progetto software finito non può essere previsto con la stessa facilità con cui può esserlo un ponte o un blocco di uffici e la rigida aderenza ai piani e alle specifiche originali non funzionava bene per i progetti software.
E così, nel 2001 vide la luce il Manifesto Agile. Sebbene riguardasse principalmente lo sviluppo del software all'interno di un framework di project management, crebbe rapidamente fino a svincolarsi dal proprio ‘genitore’ ed essere considerato Project Management Agile piuttosto che semplicemente Sviluppo Agile. Ne conseguì un’ulteriore suddivisione fra certificazioni di tipo agile e certificazioni di tipo waterfall (a cascata).
Nel frattempo, le divisioni delle Risorse Umane stavano cercando di affrontare l'esplosione della domanda di persone esperte di progetti. Si trattava di un mondo per loro sconosciuto, quindi come potevano sapere chi scegliere?. La risposta fu semplice: certificazioni.
Ad un certo momento di questo decennio l'attività di certificazione attraversò un punto di svolta molto significativo. Non era più un elemento di vantaggio avere una certificazione sul proprio CV, ma era sicuramente uno svantaggio non averne una.
La ‘banalizzazione’ della formazione era iniziata. I corsi iniziarono a vertere sulla conoscenza delle risposte ad un esame piuttosto che sul sapere come fare il lavoro. L'APM e il PMI capirono che esisteva un mercato per le persone che pensavano che anche una settimana fosse troppo lunga per ottenere una certificazione ‘significativa’, e così nacquero le certificazioni IC e CAPM. Nei primi anni '90 si è dato spazio alla ‘gamification’ (cioè l’apprendimento attraverso elementi tipici del gioco) nel tentativo di ottenere la certificazione.
Ora ci troviamo in un mondo di project management caratterizzato da interessanti conflitti:
Il PMI ha perso la battaglia per impedire all'APM di ottenere lo status di Chartered – perché tale status avrebbe conferito troppo potere ad APM -, ma allo stesso tempo ha portato aventi tramite il Congresso un progetto di legge per ottenere un'influenza più significativa per se stesso. È in corso una battaglia per la superiorità morale.
Alla tricotomia progetto/programma/portfolio si è aggiunta la dicotomia agile/waterfall. La disciplina sta diventando sempre più frammentata. In alcuni casi ciò sta portando alla formazione di vere e proprie ‘sette’ che possono essere in forte competizione fra loro
In un mondo dominato dai social media e da un’economia in cui le persone fanno affidamento sulla trasformazione della conoscenza in prodotti, c’è una cacofonia di opinioni male informate e di idee riciclate che devono creare una profonda confusione in chi sia affaccia per la prima volta alla professione.
Proprio come i costruttori hanno tentato di dire a chi si occupava di software come portare avanti i loro progetti 40 anni fa, ora i "predicatori di Agile" stanno cercando di applicare il metodo agile a tutto ciò che è al di fuori dell'IT.
I social media hanno un effetto amplificatore su tutti questi fattori.
Personalmente, credo che la professione abbia bisogno di essere ripensata.
Ad esempio, abbiamo bisogno di guardare la disciplina de project management in un modo più olistico. Non si tratta di etichettare le iniziative come progetti, programmi o portfolio; o come di tipo waterfall oppure di tipo agile.
Tutte queste iniziative sono per definizione uniche e quindi richiedono una combinazione unica di tutte queste sotto-discipline. Un futuro professionista competente deve comprendere tutte queste aree e quindi selezionare il sottoinsieme appropriato di strumenti per lo specifico lavoro che ha per le mani.
Le molteplici e piccole opportunità di formazione e sviluppo di cui fa uso la moderna forza lavoro devono avere un sistema di aggregazione in modo da poter dare vita a qualcosa di significativo. Le certificazioni basate sulla conoscenza devono essere viste semplicemente come il primo gradino della scala che porta ad essere un professionista competente.
Dobbiamo occuparci del bagaglio culturale che si traduce in studi sul fallimento dei progetti che dimostrano che, nonostante tutti gli sviluppi degli ultimi 40 anni, non è cambiato molto.
Naturalmente, gli strumenti necessari per ottenere questi cambiamenti li vedo disponibili attraverso Praxis. Per esempio:
realizzare ciò che l'Organizzazione Mondiale della Sanità (OMS) ha fatto per la chirurgia utilizzando il capability maturity model basato sulle liste di controllo;
produrre manager con un'ampia gamma di competenze, stemperando i confini tra progetto, programma, portfolio, agile e waterfall;
eliminare il falso fascino delle guide protette dal diritto d'autore (che spinge le persone verso una inflessibile ‘mentalità del libro’), rendendo aperta e libera la proprietà intellettuale (IP) che ne è alla base;
assicurare che la predetta proprietà intellettuale sia sufficientemente flessibile da poter essere applicata in contesti organizzativi diversi e a differenti stili personali, pur mantenendo la possibilità di produrre una certificazione coerente per tutti i suoi diversi adattamenti.
Solo cambiando la cultura della professione riusciremo a cambiare l'unica cosa che non è cambiata in 40 anni: le ragioni per cui i progetti falliscono.
Qualunque siano le vostre opinioni o il vostro genere preferito di project management, non vi è dubbio che i prossimi anni vedranno significativi cambiamenti culturali nella professione.
Grazie a Project Management Europa per la traduzione
Please consider allowing cookies to be able to share this page on social media sites.
Change cookie settings
