Perché crediamo sempre di essere più veloci di quanto siamo
Due settimane. È quasi sempre questa la stima che diamo quando ci viene chiesto in quanto tempo finiremo un progetto nuovo. Poi le settimane diventano quattro, poi sei, e a fine bimestre c'è una riunione in cui qualcuno chiede come sia stato possibile sbagliare di tre volte. Non è successo a un team incompetente. Succede ai team più seri, in tutti i settori, con regolarità statistica. Sottostimiamo i tempi non per pigrizia, ma perché immaginiamo sempre lo scenario migliore.
Il fenomeno ha un nome preciso, planning fallacy, e una bibliografia di mezzo secolo. Lo studio del bias è cominciato con Daniel Kahneman e Amos Tversky negli anni Settanta e da allora è stato replicato in contesti che vanno dallo sviluppo software alla ristrutturazione di case private fino ai grandi appalti pubblici. La conclusione è sempre la stessa, e arriva spesso accompagnata da numeri che fanno male. In media i progetti reali durano dal trenta al settanta per cento in più della stima iniziale. Tre tecniche, applicate insieme, riducono lo scarto. Non lo annullano, ma lo rendono gestibile.
Conoscere i nostri sistemi di valutazione per evitare gli errori 22 min
Pensieri lenti e veloci
Partire dalla storia e non dall'ottimismo
La prima tecnica è quella che Kahneman chiama reference class forecasting, previsione per classe di riferimento. In Pensieri Lenti e Veloci lo psicologo israeliano racconta un episodio del proprio passato che è diventato un classico nella letteratura sulla stima dei progetti. Negli anni Settanta partecipa a un gruppo di lavoro accademico incaricato di scrivere un manuale scolastico. Dopo un anno di lavoro, Kahneman chiede a ciascuno dei colleghi di stimare quanto tempo manchi alla consegna. Le risposte si concentrano tra i diciotto e i trenta mesi. A quel punto chiede al membro più esperto del gruppo, un educatore che aveva partecipato in passato a progetti analoghi, una domanda diversa. Quanti gruppi simili hai visto, e quanti hanno consegnato? In quanto tempo? La risposta è scomoda. Circa il quaranta per cento dei gruppi non aveva mai consegnato; quelli che ce l'avevano fatta avevano impiegato dai sette ai dieci anni. Il gruppo ignorò questa informazione, e ci mise otto anni a finire il manuale.
Per stimare bene un progetto bisogna partire dai dati di progetti simili, non dalla previsione che fa la nostra testa. L'errore non riguarda le abilità di chi stima, ma il modo in cui la mente costruisce la previsione. Visualizza i passaggi di questo progetto specifico, immagina che tutti funzionino come previsto, somma i tempi e produce un numero. È quello che Kahneman chiama vista interna, ed è strutturalmente ottimista perché esclude tutto ciò che non riesce a immaginare in anticipo. La vista esterna parte invece dalla classe di riferimento, cioè da progetti analoghi conclusi in passato, e accetta che il progetto attuale appartenga a quella distribuzione anche quando sembra speciale.
Operativamente significa una cosa concreta. Prima di stimare un progetto X è utile fare una lista di cinque o dieci progetti simili che si conoscono per esperienza diretta o indiretta, calcolarne la durata reale media, e usare quel numero come ancora. Se la stima costruita attività per attività restituisce un valore molto più basso della media storica, è quasi sempre quella stima a sbagliarsi, non la storia.
Conoscere i nostri sistemi di valutazione per evitare gli errori 22 min
Pensieri lenti e veloci
Stimare in tre scenari e tenere il buffer fuori dalla scadenza
La seconda tecnica nasce in ambito ingegneristico ma ha applicazioni trasversali. Si chiama stima a tre punti, o stima PERT dal programma Polaris della Marina americana degli anni Cinquanta. Per ogni macro-attività si producono tre numeri, lo scenario ottimistico, quello realistico e quello pessimistico. La stima ponderata si ricava con la formula che somma l'ottimistico, quattro volte il realistico e il pessimistico, dividendo il totale per sei. Il risultato non è una previsione magica, è un numero che incorpora esplicitamente l'incertezza invece di nasconderla dietro una falsa precisione.
Una stima realistica si costruisce su tre scenari, e il buffer non va negoziato via. Il problema operativo arriva subito dopo. Il buffer, cioè la differenza tra la stima realistica e quella pessimistica, ha una vita breve dentro le organizzazioni. Viene riassorbito quasi automaticamente, perché chi guarda il piano dall'esterno tende a interpretarlo come margine di sicurezza eccessivo da tagliare per fare bella figura con il committente. Il risultato è che il buffer scompare, e quando il progetto incontra il primo imprevisto reale non c'è più nulla a cui attingere.
Cyril Northcote Parkinson aveva osservato il fenomeno in un saggio del 1955 per The Economist, sintetizzandolo in una formula diventata legge popolare. Il lavoro si espande fino a riempire il tempo disponibile alla sua esecuzione. Se la scadenza dichiarata coincide con la stima realistica più il buffer, il buffer viene consumato indipendentemente dalla difficoltà reale del lavoro. La soluzione pratica è separare i due numeri. Si comunica al committente la scadenza realistica e si tiene il buffer come margine interno gestito da chi guida il progetto. Nessuno sa che esiste, ma è lì quando serve.
Affrontare le sfide nella gestione dei progetti software 22 min
The Mythical Man-Month
Aggiornare la stima ogni volta che cambia il perimetro
La terza tecnica è la più difficile da accettare, perché contraddice il modo in cui pensiamo alla pianificazione. Una stima va trattata come un processo continuo, che si aggiorna a ogni cambio di perimetro. Il principio più famoso che lo dimostra arriva da The Mythical Man-Month di Frederick Brooks, raccolta di saggi del 1975 firmata da uno dei padri dell'ingegneria del software, già responsabile del progetto del sistema operativo IBM OS/360. Brooks lavorò sul programma più ambizioso del decennio e ne ricavò una legge che porta il suo nome. Aggiungere persone a un progetto in ritardo lo farà ritardare ancora di più.
Aggiungere risorse a un progetto in ritardo lo farà ritardare ancora di più, perché ogni modifica al perimetro è una nuova stima. La ragione è meccanica. Quando si inseriscono nuove persone in un team a metà progetto, le persone già operative devono fermarsi per fare onboarding, le linee di comunicazione tra i membri crescono in modo quadratico rispetto al numero di teste coinvolte, e il coordinamento assorbe una quota crescente di tempo. Il guadagno marginale di una persona in più diventa negativo oltre una certa soglia. Brooks lo aveva osservato sul software, ma lo stesso effetto è documentato in costruzioni, eventi e lanci di prodotto.
L'implicazione pratica va oltre la regola specifica sul personale. Ogni volta che cambia un elemento sostanziale del perimetro, sia che si tratti di persone aggiunte, sia di nuove funzionalità richieste, sia di dipendenze esterne emerse strada facendo, la stima precedente diventa carta straccia. La tentazione è difenderla, perché abbandonarla significa ammettere uno scivolamento. La soluzione professionale è il contrario. Mettere in calendario checkpoint regolari, di solito settimanali per progetti brevi e mensili per progetti lunghi, in cui la stima viene rivista alla luce di quello che si è imparato dall'ultimo aggiornamento. Una stima difesa per orgoglio è una promessa che esplode tardi, mentre una stima rivista con onestà è uno strumento di lavoro.
Affrontare le sfide nella gestione dei progetti software 22 min
The Mythical Man-Month
Una stima è un'ipotesi che si verifica nei fatti
Le tre tecniche non si escludono, si combinano. La prima fissa un'ancora storica che impedisce di partire dall'ottimismo cieco. La seconda costruisce un range che incorpora l'incertezza e protegge il buffer dalla negoziazione. La terza tiene viva la stima nel tempo, accettando che cambierà man mano che il progetto rivela quello che non si poteva sapere all'inizio.
C'è una cornice mentale che le tiene insieme, ed è la più scomoda da accettare nelle culture organizzative che premiano la decisione netta. Una stima non è una promessa, è un'ipotesi. È l'ipotesi migliore che siamo in grado di formulare con le informazioni disponibili in un dato momento, e va trattata come trattiamo qualsiasi ipotesi scientifica, con la disponibilità a rivederla quando arrivano dati nuovi. Chi gestisce progetti complessi sa che la differenza tra un manager affidabile e uno problematico non sta nella precisione delle stime iniziali, sta nella velocità con cui aggiorna quelle stime e nella trasparenza con cui le comunica al team e agli stakeholder.
Smettere di sottovalutare significa accettare che il tempo è un'ipotesi, non una promessa. Tornando alle famose due settimane dell'inizio, il problema non era il numero ma il modo in cui era stato prodotto. Una stima vista interna, senza ancore storiche, senza buffer protetto, senza meccanismi di revisione. Cambiare metodo non rende infallibili, rende prevedibili. E nelle organizzazioni che ci capita di osservare, prevedibile è una qualità che vale più di veloce.
Sviluppare un proprio metodo di pianificazione richiede esposizione regolare a chi ha studiato il problema da prospettive diverse, da Kahneman a Brooks fino agli autori contemporanei di project management. Il catalogo 4books nasce per questo, per trasformare la lettura di libri seri in una pratica costante senza dover ritagliare tre ore di lettura ogni sera. Ogni titolo è condensato nelle idee chiave e diventa uno strumento operativo da usare prima della prossima riunione in cui qualcuno chiederà, ancora una volta, in quanto tempo si farà.