La verità sulle stime di progetto
C’è una domanda ricorrente che si presenta puntualmente in tutte le aule durante i corsi di Project Management e mentre lavoro con i team marketing: la famigerata domanda sulle stime di progetto. Questa domanda si presenta in vari modi: come possiamo fare stime migliori? Come facciamo a stimare? Perché le stime di progetto sono sbagliate? e varianti.
La questione stime di progetto è bellissima perché spesso parte da presupposti sbagliati e da una concezione errata di questo termine. Per migliorare le nostre stime dobbiamo partire dalle basi: che cosa è una stima?
Stima = Scommessa
Partiamo subito con una definizione semplice e immediata:
Una stima è una scommessa fatta in un certo momento sulla base delle informazioni disponibili
Il fatto che una stima sia una scommessa ci consente subito di eliminare una domanda: chiedere ad una persona perché hai sbagliato le stime ? è come chiedere perché hai sbagliato una scommessa? Riformulata in questo modo manifesta tutta la sua inconsistenza.
Scommesse e incertezza
Immagina di compilare la schedina del weekend: Carrarese–Pro Patria. Studi le statistiche, controlli gli infortuni, analizzi i precedenti. Sei convinto di avere fatto il pronostico perfetto. Poi arriva la domenica e al 93’ succede l’imprevisto che ribalta tutto.
Questo breve esempio sportivo sintetizza quello che c’è da sapere sul tema scommesse e rischi (e le stime rientrano in questa famiglia) ovvero che in una stima ci sono due dimensioni in gioco che vanno ad influenzare l’incertezza:
- Incertezza epistemica: quanta conoscenza abbiamo di quel fenomeno ( o progetto o dominio). Più conoscenza abbiamo più questa incertezza tenderà a zero.
- Aleatorietà del fenomeno: anche se sappiamo tanto, il futuro rimane incerto. Aver studiato le statistiche etc. non ci assicura la correttezza della scommessa.
Di conseguenza possiamo fare una considerazione: più conosciamo il progetto che andremo a fare più è probabile che la nostra stima sarà “corretta”anche se non potremo mai avere la stima esatta. Questo è ben raccontato da un semplice grafico (che potete trovare all’interno di Agile Estimating and Planning di Mike Cohn – nota il link è affiliato Amazon)

Nonostante tutto l’impegno del mondo, raggiungere il 100% di Accuracy è impossibile secondo l’autore (e su questo grafico ci sarebbe anche molto altro da dire). Tutto questo poi non avviene nel vuoto, ma all’interno di contesti che vanno ad influenzare il nostro mondo.
Stime e contesto
Dal mio punto di vista è fondamentale, per parlare di queste scommesse, fare una breve distinzione tra i contesti dinamici e contesti statici: come esempi possiamo prendere come elementi rappresentativi da un lato il mondo “digital” e dall’altro il mondo “construction” 1.
Semplificando questi due contesti, da un lato abbiamo un mondo le cui evoluzioni sono costanti ed è difficile sapere cosa succederà nei prossimi 12 mesi mentre dall’altro abbiamo storicità, sono noti gli elementi e il terreno cambia con minor rapidità rispetto all’ecosistema digitale. Di conseguenza ha perfettamente senso che in contesti diversi le qualità delle stime siano eterogenee:
Le stime diventano problematiche quando trattiamo contesti dinamici e statici allo stesso modo
Guardiamo questo grafico sempre dal libro di Cohn: è uno schema del 1981 realizzato da Barry Boehm chiamato “Cone of uncertainty”

All’inizio di un progetto le stime, secondo questo grafico, oscillano tra un +160% e un -60% (altre scuole di pensiero hanno valori diversi, ma il concetto rimane):
Chiediamo di stimare il lavoro quando la conoscenza è minima e l’incertezza è massima
Questa consapevolezza è il motivo per cui sono anche nati diversi approcci alla realizzazione di prodotti e progetti e non abbiamo un’unica scuola di pensiero.
Scommesse vs Promesse
La criticità quindi sulle stime nasce da questo fraintendimento: il trattare delle scommesse (crediamo ci vorrà x) come delle promesse (entro x sarà tutto finito). Questo approccio poi apre tutto il discorso sui progetti value driven (facciamo quello che serve) contrapposti a quelli plan driven (facciamo quello che abbiamo detto) che a sua volta apre al tema della fiducia e della cultura organizzativa. Ma lasciamo perdere il bianconiglio e stiamo sulle stime.
Se le stime non sono esatte a cosa servono? Smettiamo di farle? NO!
Le stime sono un processo particolarmente utile che possono aiutare il team ad acquisire rapidamente consapevolezza e il business ad avere delle conversazioni profonde sulle priorità e possiamo usare varie tecniche tra cui, ad esempio, :
- T-shirt sizing: S, M, L, XL per ragionare in grandezza relativa;
- Story points: misura della complessità relativa;
- Stima a tre punti (PERT): si considerano tre scenari (ottimistico, pessimistico e più probabile) per calcolare una media ponderata che tenga conto dell’incertezza;
- Montecarlo: si eseguono migliaia di simulazioni con valori casuali compresi nei range stimati (ottimistico, pessimistico, probabile) per calcolare distribuzioni di probabilità dei risultati.
Alla fine abbiamo tecniche di stime per Analogia (confronto tra elementi simili: T-Shirt e Story Points) e Parametriche (uso di variabili misurabili con calcoli matematici: PERT e Montecarlo). Quale uso? Dipende.
Come sempre prima di risolvere un problema, devo capire che problema voglio risolvere, che miglioramento apportare o quale sfida voglio affrontare: fatto questo poi posso scegliere come agire.
L’elemento rilevante sono le conversazioni intorno alle stime, non le stime di per sé
Come nelle User Story la cosa che ci interessa (e per questo è rilevante per il team e per il Business) sono le discussioni per capire cosa fare, le priorità, valutare la conoscenza del team e la sua maturità… insomma sono delle conversazioni importanti.
Pensiamo solamente alla domanda “quanto tempo è necessario per fare questa cosa?”: prima di rispondere è il caso di parlare di cosa vogliamo sapere (effort? Duration? Elapsed?) e da li considerare cosa potrebbe succedere e che cosa per noi è rilevante.
Stima: come ho imparato a non preoccuparmi e amare l’incertezza
Lavorare su progetti (e soprattutto su prodotti) significa abbracciare l’incertezza e convivere con questa situazione nella quale il controllo (inteso come capacità di prevedere con certezza quello che accadrà) è prossima allo zero: siamo in contesti VUCA.
Il tema delle stime è fondamentale per ogni persona: quanti post ci vogliono? quanto budget? quanti dev? sono tutte domande legate alle stime e di conseguenza è importante comprendere questo mondo e i vari approcci (altrimenti si rischia di vedere tutto come un chiodo)
Le stime non servono a inchiodare qualcuno a una data, ma a capire insieme cosa è possibile fare. Manager e team hanno entrambi una responsabilità: i primi nel chiedere le stime con l’atteggiamento giusto, i secondi nell’usarle come occasione per condividere rischi e limiti.
Se continuiamo a trattarle come promesse mancate, rimarremo intrappolati nel gioco dei “perché era sbagliata?”. Se invece le viviamo come strumenti di consapevolezza, diventano una palestra di dialogo, fiducia e decisioni migliori.
È un cambio di prospettiva semplice ma potente: le stime non sono un “problema” da risolvere, ma una conversazione da avere. Ed è in quella conversazione che si gioca la differenza tra un progetto che arranca e uno che cresce. Il problema non è la stima in sé, ma l’uso che ne facciamo. Se diventa un impegno (“entro questa data deve essere pronto”), stiamo forzando il gioco.
La stima è una bussola, non un contratto: serve per orientarsi, non per incatenarsi a un numero.
Eppure questo equivoco è frequentissimo: trasformiamo un’ipotesi in un vincolo, e quando la realtà non si allinea alla nostra illusione di certezza, scatta la caccia al colpevole. Invece di imparare, ci limitiamo a puntare il dito.
In letteratura agile questo è stato anche definito come il contract game (in LeSS), ovvero quella dinamica disfunzionale in cui manager e team si accordano su un piano che sanno entrambi essere irrealistico, trasformando una stima in un contratto da rispettare 2. Un gioco che porta solo sfiducia e conflitti, invece che apprendimento e collaborazione che sono fondamentali per avere delle stime utili e per generare valore..
Note:
- Si tratta di categorie che potrebbero essere approfondite e suddivise ulteriormente e i cui confini non sono così netti, ma le utilizzeremo a scopo esplicativo ↩
- qui un breve video che illustra il concetto del contract game ↩
Leave a Reply
Want to join the discussion?Feel free to contribute!