Stime Top-Down nella pianificazione dei progetti

Il comitato si riunisce fra due settimane e deve decidere se il progetto si fa. Non esiste un’analisi, non esiste una WBS, e non esisteranno prima della riunione. Serve un numero, e le stime top-down sono l’unico modo di produrlo in tempo.

La stima top-down serve esattamente a quel momento, e va difesa da due accuse opposte: quella di chi la considera approssimativa — lo è, per costruzione — e quella di chi la usa come se fosse un impegno.

Che cosa sono le stime top-down: un numero intero, poi spaccato

Parti dall’alto. Metti un numero sul progetto intero, basandoti su quello che hai visto succedere in progetti simili, e poi lo ripartisci verso il basso: prima fra le fasi, poi dentro ogni fase fra le attività.

La conferma circolare della stima top-down: le fasi ricavate dal totale, risommate, restituiscono il totale di partenza
Sommare le fasi non verifica niente: sono state ricavate dal totale, quindi lo restituiscono sempre.

La ripartizione non è arbitraria: nelle organizzazioni che hanno una storia, le proporzioni fra le fasi sono sorprendentemente stabili. Se nei tuoi ultimi cinque progetti l’analisi è stata intorno al 15% e il collaudo intorno al 20%, quelle percentuali sono un dato, non un’impressione.

Perché all’inizio è l’unico metodo possibile

Non è che il top-down sia preferibile agli altri in quel momento: è che gli altri lì non si possono eseguire. Il bottom-up richiede un elenco di attività che non esiste ancora; la parametrica richiede un registro storico che, se ce l’hai, è ottimo — ma quasi nessuno ce l’ha.

La velocità non è un compromesso accettato di malavoglia, è il punto: stai comprando una decisione (vale la pena esplorare questa cosa?) al prezzo di un pomeriggio. Spendere tre settimane per una decisione che potrebbe essere «no» sarebbe il vero spreco.

Il momento in cui diventa disonesta

Uno solo, e non ha niente a che vedere con la tecnica: quando viene citata senza il suo intervallo.

Un numero top-down consegnato come «sei mesi» è un’invenzione, perché nel punto del progetto in cui lo hai prodotto quel numero vale fra un quarto e quattro volte tanto. Lo stesso numero consegnato come «fra quattro e dodici mesi, e per restringerlo serve decidere X» è una risposta professionale, e per di più è una risposta che mette il committente al lavoro.

La larghezza dell’intervallo non te la inventi: dipende da dove sei sul cono dell’incertezza.

Il difetto silenzioso: la conferma circolare

Questo è il problema vero del top-down, e fa danni proprio perché non si vede.

Hai detto dodici mesi. Ripartisci: tre all’analisi, cinque allo sviluppo, due al collaudo, due all’avvio. Sommi per controllare: dodici. Sembra una verifica, e non lo è: hai appena ritrovato il numero da cui eri partito. La somma delle parti di una torta fa sempre la torta.

Una stima top-down non si controlla con se stessa. Si controlla con un metodo diverso, e il confronto fra le due è il vero controllo: come si fa, dentro il Gantt, sta in Confronto stime Top-Down e Bottom-Up con Microsoft Project.

Come si fa una ripartizione che regge

  • Usa percentuali storiche, non a occhio. Guarda i consuntivi degli ultimi progetti e ricava le proporzioni fra le fasi. Se non ce le hai, cominciare a registrarle costa una colonna in un foglio.
  • Ferma la ripartizione al livello di fase. Scendere fino al singolo compito dà l’illusione di un dettaglio che non hai: sono numeri inventati con due decimali.
  • Scrivi da dove viene il numero globale. «Simile al progetto X del 2024, più l’integrazione in più»: fra sei mesi nessuno se lo ricorda, e senza quella riga la stima non è discutibile.
  • Dichiara che cosa hai escluso. Le stime top-down saltano sempre qualcosa — migrazione dei dati, formazione, collaudo di accettazione. Elencare le esclusioni è metà del lavoro.

E dentro Microsoft Project?

Project ha un posto preciso per la stima top-down, ed è la programmazione manuale delle attività di riepilogo: metti la fase in modalità manuale e ci scrivi la durata che hai stimato dall’alto, mentre le attività sotto restano automatiche.

Da quel momento la barra della fase si divide in due: sopra la tua stima, sotto la somma di quello che c’è davvero dentro. Quando la seconda sfora la prima, Project lo colora e te lo fa vedere. È il confronto fra i due metodi fatto senza fogli di calcolo, e vale la pena impararlo.

In sintesi

  • La stima top-down mette un numero sul progetto intero e poi lo ripartisce verso il basso.
  • All’inizio è l’unico metodo eseguibile: non c’è ancora niente da scomporre.
  • Diventa disonesta in un momento solo: quando viene citata senza il suo intervallo.
  • La conferma circolare è il suo difetto silenzioso: sommare le fasi restituisce sempre il numero di partenza.
  • Una stima si controlla solo con un metodo diverso da quello che l’ha prodotta.
  • Le percentuali fra le fasi si prendono dai consuntivi veri, e ci si ferma al livello di fase.
  • In Microsoft Project vive nella programmazione manuale delle attività di riepilogo.

Domande frequenti

Quando si usa la stima top-down e quando la bottom-up?

Top-down quando il progetto non è ancora scomponibile e serve una decisione: vale la pena farlo? Bottom-up quando il perimetro è stabile e serve un impegno su una data. Non sono alternative, sono due momenti diversi.

Quanto è imprecisa una stima top-down?

Dipende da quanto sai, non dal metodo. All’inizio di un progetto, prima dei requisiti, qualunque stima porta un fattore quattro in tutte e due le direzioni. Il top-down non è impreciso di suo: eredita l’imprecisione del momento in cui lo fai.

Perché sommare le fasi non serve come verifica?

Perché le fasi sono state ricavate dal totale: sommandole ritrovi il numero di partenza, sempre. È una conferma circolare. Una stima si controlla solo con un metodo diverso da quello che l’ha prodotta.

Si può consegnare una stima top-down al cliente?

Sì, purché con tre cose: l’intervallo, che cosa lo restringerebbe e quando verrà riemessa. Quello che non si può fare è consegnarla come numero secco e poi esserne tenuti responsabili come se fosse un impegno: quella non è una stima, è una trappola.

Questo articolo fa parte della guida Metodologie di Stime nei Progetti.

Lascia un commento