La trappola dell’unicità

“Bias dell’unicità” è la definizione tecnica che danno gli psicologi della tendenza di alcuni individui a credere di essere più insoliti di quanto in realtà non siano. Nel project management, il bias dell’unicità si manifesta attraverso la convinzione che i progetti siano unici e irripetibili. È una scelta parzialmente consapevole e deriva dall’idea che quando una cosa si presenta come unica e nuova ha maggiori probabilità di ricevere supporto e finanziamenti. Ma questo pregiudizio cognitivo è radicato anche nella professione del project management e nella letteratura sull’argomento. Lo statunitense Project Management Institute, per esempio, definisce il progetto “uno sforzo temporaneo intrapreso per creare un prodotto, un servizio o un risultato unico”. La britannica Association for Project Management lo definisce, analogamente, “uno sforzo unico e transitorio”. Il primissimo studio sui progetti come problema gestionale ne identificava la durata prefissata come “un aspetto peculiare del ruolo di project manager”. E nel suo celebre Development Projects Observed, un testo imprescindibile in materia, Albert O. Hischman dichiarava che ogni progetto da lui studiato rappresentava “una costellazione unica di esperienze e conseguenze”.

Per scoprire quanto sono realmente specifici quasi tutti i progetti, abbiamo analizzato i dati relativi a più di 1.300 progetti informatici attuati in 34 aziende, con dei budget che andavano da 77.000 a 4,5 miliardi di dollari. Poi ne abbiamo studiati approfonditamente 219, realizzati in Nordamerica, in Europa, in Medio Oriente, in Africa, in Asia e in Australasia, per capire se i responsabili erano convinti che i loro progetti fossero unici, e come incideva tale percezione sulla performance del progetto.

Quello che abbiamo scoperto ci ha fatto riflettere. La nostra analisi indicava che i manager sono decisamente inclini a convincersi che i loro progetti siano unici, anche se pochi lo sono davvero. Ciò li induce a credere di non aver niente da imparare da altri progetti, ma soprattutto, li spinge a sottovalutare il rischio e a sopravvalutare l’opportunità, e quindi a prendere decisioni scadenti. In particolare, più considerano “unico” un progetto, più è probabile che questo sfori il budget e che se ne debba prendere in considerazione la cancellazione. Siamo arrivati così alla conclusione che migliorare la performance di un progetto sia meno una questione di gestire le attività coinvolte e più di capire come prendono le decisioni i project manager.

In questo articolo, prima esamineremo la relazione tra unicità percepita e risultati effettivi, e poi dimostreremo quanto sia infondata la percezione di unicità. Dopodiché esporremo una teoria sulle ragioni che determinano il bias dell’unicità e forniremo ai manager dei consigli su come combatterlo.

Il costo del bias dell’unicità

Per quantificare l’effetto dell’unicità percepita sui progetti, abbiamo chiesto ai responsabili di ognuno dei 219 progetti che formavano il nostro campione di indicare, su una scala da 1 a 10, quanto erano d’accordo con l’affermazione “Questo progetto è unico, perciò è difficile confrontarlo con altri”. Il 27% degli intervistati ha espresso una valutazione da 7 in su.

Poi abbiamo messo alla prova l’associazione tra unicità percepita e performance, che abbiamo saggiato misurando i benefici prodotti e gli sforamenti sui costi e sui tempi preventivati. I risultati suffragavano la nostra ipotesi che la percezione di unicità avvertita dai project leader fosse correlata a una performance inferiore alle attese. Abbiamo scoperto che un incremento di un punto sulla scala da 1 a 10 si associava mediamente a un incremento di cinque punti percentuali nello sforamento dei costi. Voleva dire che nei progetti giudicati più unici – ossia classificati a livello 10 – gli sforamenti di costo erano più alti, in media, di 45 punti percentuali rispetto a quelli che ricevevano il rating minimo (1). Ancora più preoccupante, nel 37% dei progetti classificati a livello 10, lo sforamento dei costi era estremo – ossia superiore al budget di oltre il 75%.

Si dovrebbe tener presente che le predette conclusioni si basano sull’unicità percepita. Come abbiamo scoperto, le percezioni non corrispondevano necessariamente alla realtà.

Esistono veramente dei progetti unici?

La risposta sintetica è no. In effetti, tutte le volte che ci siamo imbattuti in un progetto che pensavamo fosse unico, abbiamo poi riscontrato che non lo era.

Ecco un esempio: nel 2004, il funzionario pubblico incaricato di dismettere le centrali nucleari della Svezia aveva bisogno di una stima attendibile del costo di quel lavoro, che sarebbe durato decenni, e di quanto sarebbe costato stoccare in sicurezza le scorie nucleari, un lavoro che sarebbe andato avanti per secoli. Il governo svedese avrebbe chiesto all’industria nucleare di contribuire a un fondo destinato a coprire i costi, e voleva capire quanto raccogliere.

Il funzionario ha contattato uno di noi, Bent Flyvbjerg, per avere dei consigli. Bent non pensava di potergli essere d’aiuto: all’epoca, in effetti, non aveva dati sulla dismissione delle centrali nucleari. Nessun altro Paese aveva mai attuato prima un programma del genere. (Successivamente, dismettere le centrali nucleari è diventato più comune). Quel progetto sembrava veramente unico. Ma il funzionario aveva letto un articolo che aveva scritto Bent sui costi e sui rischi di costo dei progetti che comportano la mobilitazione di strade, ponti, tunnel e linee ferroviarie per il trasporto di infrastrutture. Proponeva di usare i dati forniti da Bent come “base di partenza” e di assumere che i rischi reali di costo per la dismissione delle centrali nucleari fossero più elevati. Il governo svedese avrebbe potuto chiedere all’industria nucleare di effettuare dei versamenti iniziali calcolati sulla “base di partenza” per poi adeguare la stima e i versamenti man mano che acquisiva maggiori conoscenze sul decommissioning. Bent si è reso conto di essere caduto nella trappola dell’unicità assumendo che il responsabile di un progetto senza precedenti come la dismissione delle centrali nucleari non avesse nulla da imparare da altri progetti, e non ha mai dimenticato quella lezione.

I manager che gestivano i progetti IT del nostro campione di aziende stavano commettendo lo stesso errore? Noi abbiamo analizzato i 59 progetti valutati da 7 in su in termini di unicità percepita e abbiamo confrontato la loro portata funzionale, le loro descrizioni e le loro date di inizio con quelle di altri 6219 progetti contenuti in un altro database, più vasto. Abbiamo scoperto che in realtà per tutti i 59 progetti, inclusi quelli valutati 9 o 10 in termini di presunta unicità, ne era già stato attuato uno simile nella stessa organizzazione o nello stesso settore. In altre parole, nessuno di quei progetti si poteva considerare unico. Per esempio, cinque dei 59 erano progetti di verifica della compliance in ambito bancario. Noi abbiamo stabilito non solo che ognuna delle banche in questione aveva portato a termine sforzi analoghi in precedenza, ma anche che lo stavano facendo contestualmente tutte le altre banche nelle rispettive giurisdizioni.

Abbiamo concluso pertanto che molti altri progetti ritenuti unici in realtà non lo sono, e che unicità percepita e unicità effettiva non sono correlate. Abbiamo scoperto altresì che l’unicità percepita è ciò che conta per la performance del progetto, perché quando i manager pensano che non ci sia nulla da imparare da altri progetti, il mancato apprendimento finirà inevitabilmente per danneggiare i loro.

Come si crea il bias dell’unicità

Il nostro studio fa pensare che il bias sia legato a certe caratteristiche del progetto. L’unicità percepita era generalmente correlata alla complessità del progetto, alla sua sensibilità politica, al numero delle variabili ignote e alla misura in cui cambiavano i suoi requisiti. Ma nessuna di quelle caratteristiche aveva di per sé un effetto statisticamente significativo, dunque non poteva spiegare sforamenti estremi sul piano dei costi. Dal punto di vista statistico, il bias dell’unicità era la causa degli sforamenti, e nonostante le correlazioni, non dipendeva dalla complessità, dalla sensibilità, dall’incertezza o dai requisiti di un progetto.

Ma da dove veniva quel pregiudizio cognitivo? Una possibilità concreta è che derivasse dalla tendenza a ritenere che ciò che è unico per una persona sia unico per tutti. Per esempio, la California non ha mai costruito prima una linea ferroviaria ad alta velocità perciò, in quel senso, le iniziative intraprese recentemente per costruirne una tra Los Angeles e San Francisco si potrebbero considerare uniche. Ma ci sono tantissimi precedenti al di fuori della California: decine di reti analoghe sono state realizzate in tutto il mondo, producendo dati e lezioni che sarebbero preziosissimi per la California in termini di stima dei costi, definizione delle tempistiche, gestione degli appalti, programmazione degli acquisti, previsione dei ricavi e valutazione dell’impatto ambientale.

La nostra ricerca sembra confermare che le persone tendono maggiormente a credere che un progetto sia unico se non hanno alcuna esperienza personale di qualcosa di simile. Considerate quello che ci è accaduto con il chief information officer di una grande azienda logistica globale che ha preso parte allo studio. Quando abbiamo illustrato i risultati dell’azienda, il CIO ha citato un progetto descritto dai suoi manager come assolutamente unico, e valutato perciò 10 sulla nostra scala. Quando ha chiesto loro quale fosse esattamente, è venuto a sapere che si trattava dell’installazione di un software standard per l’automazione della supply chain e dei depositi nella Repubblica Ceca. Ciò l’ha sorpreso perché l’azienda aveva già installato quel pacchetto in quasi mille unità produttive dei suoi clienti. Ha telefonato immediatamente al project manager ceco per capire cosa stesse succedendo, e si è sentito rispondere che il progetto era unico dato che si trattava della prima volta che il software in questione sarebbe stato usato nella Repubblica Ceca.

La trappola dell’unicità affonda le sue radici in quella che il Premio Nobel Daniel Kahneman chiamava “prospettiva interna”. Quando i manager ne sono vittime, evitano inconsciamente di raccogliere dati e recepire indicazioni attendibili che potrebbero aiutarli, e costruiscono budget e tempistiche basandosi unicamente sulle loro convinzioni e sulle loro esperienze personali. Può essere rischioso: le ricerche comportamentali dimostrano abbondantemente che quando agiscono in questo modo, i decision maker tendono a sottostimare non solo il rischio medio ma anche la probabilità di conseguenze rare e catastrofiche. Un altro Premio Nobel, Richard Feynman, ha scoperto che era esattamente la dinamica da cui era scaturita la tragedia della navicella spaziale Challenger: la visione interna del rischio di volo che caratterizzava la NASA, specie tra i suoi top manager, era così ristretta da spingere l’agenzia a sottostimare enormemente le possibilità di un’esplosione, causando la tragica perdita della navicella con tutti e sette gli astronauti che aveva a bordo.

Adottate una prospettiva esterna

La cura per il bias dell’unicità è considerare sempre che qualcuno, da qualche parte, ha già intrapreso un progetto simile al vostro, adottando quella che Kahneman chiamava “prospettiva esterna”. Prima di iniziare a mettere assieme il vostro progetto, perciò, chiedete ad altri membri della vostra azienda se hanno visto qualcosa di simile in precedenza, perché è probabile che, come abbiamo appena visto nel caso dell’azienda logistica, qualcuno di loro abbia fatto qualcosa di comparabile.

Se non riuscite a trovare precedenti diretti, suddividete il progetto in moduli e sottoprocessi, che poi potrebbero risultare comparabili con quelli di altri progetti. Un project leader di una grande banca internazionale ci ha detto che molti dei suoi team avevano creduto che i loro progetti – specie dei grossi programmi di cambiamento dell’infrastruttura informatica – fossero unici, ma dopo averli scissi in compiti e approcci specifici, hanno avuto la possibilità di sfruttare esperienze derivate da altri progetti. Come ci ha spiegato, «Se state sviluppando un manuale applicativo per l’avvio di una migrazione, dovreste parlare con persone che hanno già gestito delle migrazioni in passato. O se state tentando di stimare i lead time per l’ambiente di sperimentazione di un nuovo progetto, chiedete ai responsabili di altri progetti e ai team che li hanno portati avanti quali esperienze hanno avuto con i lead time per acquisire una prospettiva esterna, e usatela per mettere in discussione la prospettiva interna del vostro team».

Se non riuscite a trovare precedenti analoghi all’interno della vostra organizzazione, allargate ulteriormente la ricerca. A un convegno indetto da McKinsey per gli IT leader a cui eravamo presenti, uno dei partecipanti, la cui azienda era stata coinvolta nell’invenzione e nella realizzazione della messaggistica mobile, ha dichiarato che si trattava di un processo veramente unico: ci erano volute solo alcune settimane per sviluppare l’app di creazione e invio degli SMS e nessuno, né all’interno né all’esterno del progetto, aveva capito realmente cosa avesse inventato il team. All’inizio, l’adozione era stata lenta. Il progetto sembrava secondario. Nessuno avrebbe potuto prevedere il boom di utilizzatori che ne sarebbe seguito, e non c’era nessun altro precedente specifico. Dunque la messaggistica mobile era unica in quel senso, o almeno così affermava il leader, e all’inizio eravamo d’accordo in tanti.

Successivamente, però, altri hanno preso la parola e hanno precisato che la messaggistica mobile non era priva di precedenti. Varie tecnologie di comunicazione si potevano considerare sue antenate, tra cui il telegrafo, la radio, il telefono, il fax e le prime versioni di Internet, come ARPANET. Uno studio sistematico sulla diffusione di questi e altri nuovi strumenti di comunicazione avrebbe dato agli inventori della messaggistica mobile un’idea delle incertezze e della curva di crescita a forma di S – caratterizzata da una partenza lenta e da una forte accelerazione successiva – che avrebbero verosimilmente incontrato. Qualcuno ci aveva pensato? No, perché tutti consideravano la messaggistica mobile sia unica sia poco importante, e quindi nessuno era motivato a cercare delle analogie.

Quando scoprite dei precedenti da prendere come riferimento, state molto attenti a come processate le informazioni che ne ricavate. Anche quando assumono una prospettiva esterna, i project manager che fanno previsioni e prendono decisioni possono cadere preda di altri bias che li spingono a sottovalutare i rischi. Per fortuna, ci sono metodi di previsione e valutazione del rischio che aiutano a eliminare o a ridurre i pregiudizi cognitivi. I principali sono:

Forecasting basato sulla categoria di riferimento. Significa cercare di prevedere il futuro guardando a cosa è accaduto in situazioni analoghe. Nel project management, si tratta di confrontare i possibili risultati del vostro progetto in termini di costi, rispetto dei tempi e altri indicatori di performance, con la performance di tutti i progetti dello stesso tipo sulle stesse dimensioni. In altre parole, per valutare la probabilità di uno sforamento del 10% sui costi del vostro progetto, andate a vedere con quale frequenza si è verificato uno sforamento del 10% nell’intera categoria dei progetti comparabili. Questo approccio è stato applicato per la prima volta per un grosso progetto infrastrutturale allo studio in Scozia, e oggi viene usato in centinaia, se non migliaia, di progetti sia nel settore privato sia nel settore pubblico.

Forecasting basato sulla somiglianza. Uno strumento complementare e più focalizzato fonda le previsioni sulla performance di un sistema o di un progetto nel tempo sulla performance pregressa di un sistema analogo che operava in condizioni comparabili. La previsione basata sulla somiglianza aiuta i manager a identificare risultati inattesi e variazioni delle condizioni operative effettive. Si può applicare in molti contesti, specie in macroeconomia, dove gli esperti sono convinti che attingere a dati relativi a situazioni analoghe a quella in cui ci si trova attualmente produca previsioni più accurate che prendere come riferimento un dataset più generale.

Premortem. In questi esercizi di analisi preventiva dei rischi, i partecipanti presumono che si possa produrre un determinato risultato e spiegano perché. Per esempio, prima di avviare un progetto si può supporre che verrà completato con dieci mesi di ritardo sulla scadenza prefissata e poi spiegare perché. I premortem incorporano quello che gli psicologi comportamentali chiamano “visione prospettica”, un concetto che ha cominciato a emergere nella letteratura manageriale sulla scia di un articolo rivoluzionario pubblicato nel 1989 da Deborah Mitchell, Edward Russo e Nancy Pennington. I premortem sono un mezzo molto efficace per far venire a galla possibili problemi. La ricerca del 1989 indica che la visione prospettica può migliorare il processo decisionale e anche rendere le persone molto più proattive.

Audit del rumore. Daniel Kahneman, Andrew Rosenfield, Linnea Gandhi e Tom Blaiser hanno descritto questa tecnica in un articolo pubblicato su HBR Italia a ottobre 2016, intitolato “Rumore: le decisioni incoerenti sono un enorme costo nascosto per molte aziende”. L’idea è che i decisori umani vengono influenzati non solo dai bias ma anche dal “rumore” – fattori scorrelati e irrilevanti per la decisione da prendere. L’audit del rumore li aiuta a misurare gli effetti di quei fattori. Consiste nel presentare a una pluralità di decisori una serie di situazioni ipotetiche simili, per poi chiedere loro di prevederne i risultati. Per esempio, potreste chiedere a un gruppo di giudici di prevedere le sentenze per una serie di imputazioni analoghe. L’obiettivo è capire come variano le sentenze previste per ciascun giudice su quella casistica e come variano sull’intero gruppo dei magistrati. Il livello di rumore è tipicamente la deviazione standard delle previsioni tra i casi e tra i previsori: se è alta, allora i giudici devono rivedere il loro modo di decidere le cause. Lo strumento si può applicare per aiutare i project manager a stabilire se si lasceranno influenzare da fattori irrilevanti nel prendere decisioni critiche, per esempio, sull’acquisto di servizi o sull’assunzione di collaboratori.

Questi metodi, e la loro efficacia, sono ben documentati nella letteratura manageriale. Chiunque voglia eliminare il bias dell’unicità e altri preconcetti che distorcono il processo decisionale – ossia chiunque voglia gestire processi e organizzazioni con successo – dovrebbe prendere confidenza con essi.

È facile capire perché le persone pensano che i loro progetti siano unici. È un approccio mentale che deriva da quello che Kahneman chiamava “pensiero veloce” che, per gli esseri umani, è una modalità mentale di default. Il pensiero veloce risparmia ai project planner e ai project manager lo sforzo considerevole di stabilire a quale categoria di progetto appartiene una nuova iniziativa, quali sono i valori medi ed estremi per quella categoria, come quei valori si traducono in rischio e come quel rischio si potrebbe attenuare. Ma pochissimi progetti, per non dire quasi nessuno, sono unici – quale che sia la loro complessità. Se non ne prendete atto e non investite nell’identificazione di progetti analoghi, e nell’apprendimento che possono offrire, il vostro progetto si realizzerà quasi certamente in ritardo e con un grosso sforamento di budget, e produrrà benefici inferiori alle attese.

BENT FLYVBJERG è professore emerito alla Said Business School dell’Università di Oxford. È un senior research fellow al St. Anne’s College dell’Università di Oxford e Professor in Major Program Management alla IT University of Copenhagen. ALEXANDER BUDZIER è fellow in Management Practice in Information Systems alla Said Business School. M.D. CHRISTODOULOU è senior statistician presso il dipartimento di Statistica dell’Università di Oxford. M. ZOTTOLI è statistician presso il dipartimento di Statistica dell’Università di Oxford.