Lavoro e Denaro

4min

Come pianificare un progetto con margine di errore: stime, buffer, scope

Perché i piani saltano sempre nello stesso punto, e tre leve concrete per renderli più onesti

Il piano che salta sempre nello stesso punto

C’è un momento riconoscibile in qualsiasi progetto. Si parte con il file di pianificazione pulito, le stime allineate, il calendario che chiude. Tre settimane dopo, le stesse persone si ritrovano a tagliare scope di corsa, a mandare mail di scuse al cliente e a trasformare il fine settimana in zona produttiva. Quando si chiede dove sia andato storto il piano, la risposta più frequente è una versione di “abbiamo sottovalutato la complessità”. È vera, ma è incompleta. Ogni piano è una previsione, e ogni previsione contiene un margine di errore che il piano stesso si rifiuta di nominare.

I progetti non saltano per pigrizia o cattiva fede. Saltano per la combinazione di tre falle strutturali che si presentano quasi sempre nello stesso ordine. La prima è cognitiva: stimiamo male i tempi perché il cervello è cablato per farlo. La seconda è organizzativa: i buffer che mettiamo per “stare tranquilli” si dissolvono prima di essere usati. La terza è negoziale: trattiamo lo scope come una promessa intoccabile invece che come la variabile più flessibile del triangolo. Pianificare con margine vuol dire intervenire su tutte e tre, non rinforzare solo l’ultima quando la pressione è già esplosa. Le tre leve che seguono affrontano una falla per volta.



Stime calibrate, ovvero perché le previsioni mentono prima di essere scritte

Il primo errore non è nei numeri, è nel modo in cui il cervello arriva ai numeri. Daniel Kahneman, premio Nobel per l’economia, racconta nel suo Pensieri Lenti e Veloci un aneddoto che funziona meglio di qualsiasi spiegazione teorica. Insieme a un gruppo di colleghi accademici, stimò che un manuale scolastico richiedesse circa due anni di lavoro. Quando però chiese a uno dei membri del team, esperto di curricoli, quanto fossero durati progetti simili in passato, la risposta fu sette o otto anni, e quasi metà delle squadre non aveva nemmeno terminato. Il manuale di Kahneman ne richiese otto. La planning fallacy non è ottimismo, è una scorciatoia cognitiva che esclude le evidenze esterne.

Il meccanismo è quello che Kahneman chiama inside view: quando stimi un progetto, ti rappresenti mentalmente i passi che bisogna fare e li sommi. Più sei competente, più la simulazione è dettagliata, più il numero ti sembra solido. Il problema è che la simulazione non include gli imprevisti, perché gli imprevisti, per definizione, non li stai prevedendo. La correzione si chiama outside view e consiste nel fare una domanda diversa: dimentica per un attimo i dettagli del progetto e chiediti come sono andate le ultime dieci iniziative simili in questa stessa azienda. Quanto sono durate in media? Quante hanno chiuso in tempo? Sostituire la inside view con la outside view è il primo correttivo, e costa una sola domanda: quanto sono durati i progetti simili a questo?

In pratica, prima di stimare una landing page in cinque giorni, controlla quanto ne hanno richiesto in media le ultime dieci. Se la media è otto, parti da otto. Le obiezioni del tipo “questa volta è diverso” sono quasi sempre false, e Kahneman lo dimostra con decenni di dati. La stima migliore non è quella più dettagliata, è quella più ancorata al base rate.



Buffer espliciti, non gonfiati

Una volta che hai stime più oneste, c’è il secondo problema: cosa fare con il margine. Quasi tutti i team conoscono la tentazione di imbottire silenziosamente le singole stime per tutela personale. Cinque giorni diventano sette, una settimana diventa dieci giorni, e così via. Il padding viene aggiunto task per task, e nel piano finale non si vede. Sembra prudenza, ma è il modo più rapido per sprecare il margine. Un buffer nascosto dentro le stime non è un margine, è una bugia che il team racconta a se stesso per sopravvivere alla riunione di kick-off.

Due cose succedono. La prima è la legge di Parkinson: il lavoro si espande per occupare il tempo disponibile. Se un task è stato stimato sette giorni anche se ne richiede cinque, ne richiederà sette. La seconda è più subdola: quando il padding è distribuito sui singoli task, nessuno lo vede come riserva di sistema, e quando arriva l’imprevisto vero ognuno consuma il proprio margine senza che il progetto ne benefici. Si arriva alla fine con tutti i task “in tempo” individualmente e il progetto in ritardo collettivamente.

La soluzione è invertita. Stimare ogni task in modo realistico ma stretto, e aggiungere un buffer di progetto unico, visibile, dichiarato, collocato alla fine del piano. È la logica della Critical Chain: invece di sei task da sette giorni con padding nascosto, sei task da cinque netti più otto giorni di buffer trasparente. Il totale è uguale, ma la riserva è spendibile dove serve davvero. I buffer funzionano solo se sono visibili, dichiarati e collocati a livello di progetto, non di singolo task. È un cambio organizzativo prima che metodologico: smettere di trattare il padding come un segreto professionale e iniziare a trattarlo come un dato di pianificazione.



Slack come capacità organizzativa, non come spreco

Il buffer di progetto risolve il margine sul singolo piano. Ma c’è un livello sopra, ed è quello che Slack di Tom DeMarco mette al centro. La tesi del libro è netta e controintuitiva: un’organizzazione che opera al cento per cento di utilizzo non è performante, è fragile. Senza tempo non assegnato, qualsiasi imprevisto si propaga in cascata su tutto il sistema, perché non c’è spazio dove assorbirlo. La metafora che DeMarco usa è quella del traffico autostradale: una corsia piena al cento per cento non scorre, si congestiona; servono spazi vuoti per permettere alle auto di cambiare velocità.

Lo slack non è inefficienza, è la capacità di assorbire l’imprevisto senza che il sistema crolli. Tradotto in pratica per un team di progetto, vuol dire pianificare consapevolmente quote di tempo settimanale non assegnate a deliverable specifici, indicativamente tra il quindici e il venti per cento. Quel tempo serve per il debito tecnico, le richieste fuori scope che arrivano dal cliente, la revisione dei processi, l’apprendimento. La parte più difficile non è progettarlo, è difenderlo davanti a un management che misura la produttività in ore fatturate.

DeMarco offre un argomento utile per quella conversazione: la differenza tra efficienza ed efficacia. Un team al cento per cento è efficiente nel breve, ma incapace di reagire nel medio. Un team con margine ha capacità di risposta, ed è esattamente ciò che il management dice di volere quando parla di “agilità”. Lo slack non è la negazione dell’efficienza, è il prerequisito per essere agili davvero. Chi gestisce progetti complessi sa che la differenza tra una settimana che chiude e una che salta sta quasi sempre in quella riserva non assegnata.



Scope come variabile, non come costante

Resta il terzo lato del triangolo. Tempo, budget e scope sono tre variabili interdipendenti: se due sono fisse, la terza deve muoversi. Il problema dei progetti che saltano è che spesso si presentano con tutte e tre fissate, e quando la realtà bussa, l’unica leva disponibile è la qualità, che però non è una variabile dichiarata, è il modo in cui paghi gli altri tre vincoli. In un piano onesto, lo scope è la variabile che si muove per prima, non per ultima.

La leva più sottovalutata è la scope-cut rule definita in fase di pianificazione, non sotto pressione. Vuol dire stabilire all’inizio del progetto, quando le emozioni sono basse e le opzioni sono lucide, una regola del tipo “se sforiamo del venti per cento sul tempo, queste tre funzionalità escono dalla prima release”. Una regola di taglio decisa a freddo è migliore di una decisa a caldo, perché non dipende dal capriccio del momento o dalla persona più rumorosa nella riunione. La convenzione MoSCoW, che classifica i requisiti in must have, should have, could have e won’t have, è una versione semplice di questa logica: rende esplicito già nel brief cosa è negoziabile.

Pianificare con margine non significa lavorare meno, né accontentarsi di meno. Significa fare i conti con il fatto che ogni piano è una scommessa sul futuro, e che le scommesse oneste contengono un intervallo di confidenza, non un singolo numero. Le tre leve qui sopra, stime ancorate all’outside view, buffer di progetto visibili, slack come capacità stabile, lavorano insieme. Nessuna funziona da sola, e nessuna richiede una rivoluzione metodologica per essere applicata domani mattina. Pianificare con margine non significa lavorare meno, significa accettare in anticipo che la realtà avrà voce in capitolo.

Per chi vuole entrare nel dettaglio dei meccanismi cognitivi di Kahneman o nella tesi di DeMarco sull’efficacia che batte l’efficienza, le due sintesi su 4books permettono di assorbire le idee chiave dei due libri in un’oretta ciascuna, senza affrontare le cinquecento pagine originali. Iscrivendosi a 4books si sbloccano oltre 2.500 sintesi di non-fiction in italiano, ascoltabili anche in audio nei tempi morti tra una riunione e l’altra: i tempi morti che, una volta finito di leggere quest’articolo, sembreranno improvvisamente meno morti di prima.

Prova 4books Premium gratis

Iscriviti e ottieni 7 giorni di prova gratuita di 4books

  • +1800 libri premium
  • +25 corsi in formato podcast
  • +27 soft-skill in cui migliorare
  • Top news giornaliere in 5’
  • Liste curate