Apri un piano di progetto che non hai scritto tu e vai a cercare le milestone. Spesso troverai qualcosa come “Fase 2 completata”: una barra che si estende su due settimane di calendario, senza un responsabile, senza una definizione scritta di cosa significhi davvero “completata”.
Quella non è una milestone. È un'attività travestita, e non ti avviserà mai di niente.
Le milestone sono il sistema di allerta precoce più economico del project management. Nessuno strumento in più, nessuna riunione in più, forse venti minuti di configurazione. Ma funzionano solo se le costruisci in un modo preciso, e la maggior parte dei piani non lo fa. Ecco come si presenta la versione che funziona.
Una milestone è un momento, non un tratto di lavoro
La Guida al PMBOK definisce una milestone come un punto o un evento significativo in un progetto, programma o portfolio. La parola chiave è punto. Una milestone ha durata zero: non consuma tempo, né budget, né persone.
Quello zero non è un cavillo. È l'intero meccanismo.
Un'attività può essere completata al 60%. Una milestone no. O viene raggiunta in una data precisa o non viene raggiunta, ed è proprio questa natura binaria a renderla utilizzabile come punto di controllo. Nel momento in cui dai a una milestone una data di inizio e una di fine, offri al team lo spazio per dichiararla “quasi fatta”, ed è con il “quasi fatta” che quattro settimane di ritardo restano invisibili fino alla settimana prima del lancio.
Il test delle quattro domande
Prima di aggiungere una milestone a un piano, sottoponila a queste domande:
- È binaria? Se qualcuno può ragionevolmente rispondere “in parte”, hai davanti un'attività.
- Cambia qualcosa a valle? Una vera milestone sblocca lavoro, libera fondi o trasferisce responsabilità. Se il giorno dopo nulla si comporta diversamente, è decorazione.
- Interesserebbe a qualcuno al di fuori del team di consegna? Le milestone sono uno strumento di comunicazione tanto quanto di pianificazione. Un checkpoint che capisce solo il tuo team va nel tuo elenco di attività, non sulla linea delle milestone.
- Riesci a scriverne i criteri di accettazione in una frase? Se non ci riesci, nessuno sarà d'accordo sul fatto che sia stata raggiunta.
L'ultima domanda è quella che lavora di più. “Test” non è una milestone. “Test completati, zero difetti critici aperti” lo è. La seconda non può essere dichiarata vera finché ci sono tre bug critici aperti, ed è esattamente questo il punto: criteri di accettazione precisi sono la cura per la sindrome del 99%, in cui un checkpoint viene segnato come completato mentre dietro di lui continuano in silenzio due settimane di sistemazioni.
Poi assegna un responsabile. Non la persona che svolge il lavoro che porta alla milestone, ma l'unica persona che dichiara se è stata raggiunta o meno in base a quei criteri. Un checkpoint che appartiene “al team” è un checkpoint che nessuno deve difendere.
Quante milestone sono il numero giusto?
Ci sono due modi di sbagliare. Tre milestone su un programma di nove mesi sono inutili: il primo segnale onesto arriva al quarto mese. Quaranta milestone su un progetto di dodici settimane sono altrettanto inutili, perché quando tutto è un checkpoint, niente lo è.
Una regola pratica: distanziale in modo che nessun tratto del progetto superi le due-quattro settimane senza una milestone, e mantieni il totale abbastanza basso da stare in una sola slide di stato. Nella maggior parte dei progetti si arriva a un numero tra cinque e dodici.
Un set predefinito che funziona in quasi ogni ambito:
- Piano approvato e baseline impostata
- Ambito congelato
- Design o specifiche approvati
- Realizzazione completata / feature freeze
- Passaggio di consegne al committente, al cliente o al QA
- Go-live
Le milestone hanno bisogno di predecessori, non solo di date
È l'errore strutturale che disattiva in silenzio l'intero sistema: parcheggiare una milestone su una data senza dipendenze in ingresso.
Una milestone senza predecessori è un'affermazione. Sta al 14 novembre perché qualcuno ha digitato 14 novembre. Le attività le slittano intorno, il rombo non si muove e il tuo piano continua a pubblicare una data che ha smesso di essere vera tre settimane fa.
Una milestone con predecessori è un calcolo. Collega ogni attività che deve finire prima che il checkpoint possa essere dichiarato raggiunto (fine-inizio verso il rombo) e la milestone diventa la più tarda di quelle date di fine. Se un qualsiasi predecessore slitta, la milestone si sposta lo stesso giorno, sul diagramma, senza che nessuno debba accorgersene.
Due conseguenze di cui tenere conto nella pianificazione. Primo, una milestone con molti collegamenti in ingresso è un punto di convergenza, e i punti di convergenza concentrano il rischio: sei predecessori significano sei occasioni indipendenti di essere in ritardo, tutte sulla stessa data. Secondo, le milestone ereditano lo scorrimento come qualsiasi altro nodo del reticolo. Una milestone con scorrimento zero si trova sul percorso critico, il che significa che non è un checkpoint che puoi mancare senza che nessuno se ne accorga.
Monitorarle: l'analisi del trend delle milestone
Una volta che le milestone sono collegate come si deve al cronoprogramma, sblocchi il grafico più informativo e meno usato del project management.
L'analisi del trend delle milestone è semplice. A ogni ciclo di reporting, registra la data prevista a oggi per ciascuna milestone, e conserva lo storico invece di sovrascriverlo. Riporta la data del report sull'asse orizzontale e la data prevista della milestone su quello verticale.
Monitorare ogni settimana una milestone di go-live potrebbe produrre questo:
| Data di revisione | Go-live previsto |
|---|---|
| Settimana 1 | 14 nov |
| Settimana 2 | 14 nov |
| Settimana 3 | 19 nov |
| Settimana 4 | 26 nov |
| Settimana 5 | 3 dic |
Una linea piatta significa che la previsione è stabile. Una linea che sale significa che la milestone ti sta scappando, e il vero segnale è la pendenza. Dalla settimana 3 in poi questo progetto perde sette giorni a settimana: la data di go-live si allontana esattamente alla stessa velocità con cui avanza il calendario. Non è un progetto che si riprende nella seconda metà. È un progetto in cui piano e realtà si sono separati, e il grafico lo diceva tre settimane prima che la data venisse mancata ufficialmente.
Una disciplina fa funzionare tutto questo, ed è controintuitiva: registra lo slittamento invece di modificare la data originale per adeguarla alla realtà. Ogni volta che qualcuno trascina in silenzio una milestone nel punto in cui si trova adesso, un dato viene distrutto e il trend si appiattisce in una comoda bugia.
Come funziona in LoopGantt
In LoopGantt una milestone è un'attività con durata zero, e ogni vista la rappresenta in modo diverso, di proposito.
- Sul diagramma di Gantt appare come un rombo invece che come una barra, così i checkpoint del piano si leggono a colpo d'occhio, e l'evidenziazione del percorso critico mostra subito quali di questi non hanno più scorrimento.
- Nella vista Tabella le sue date di inizio e di fine coincidono e la colonna Giorni è vuota. Così controllare il piano di qualcun altro diventa rapido: tutto ciò che è etichettato come milestone ma mostra una durata non lo è.
- Nella vista Calendario il rombo sta nel suo unico giorno invece di estendersi su più celle, accanto alle attività che invece le occupano.
- Nell'albero WBS le milestone appaiono come nodi a rombo tra i nodi circolari delle attività, così puoi vedere se ogni fase termina davvero con un checkpoint.
È nella dashboard che le milestone dimostrano il loro valore. Contiene un pannello Milestone dedicato che le elenca una per una con data e stato, e una sezione Controlli della pianificazione che segnala quelle che, secondo il reticolo, sono in difficoltà: per esempio, Milestone a rischio: “Avvio del progetto” — aggiungi tempo cuscinetto prima di questa milestone o riduci l'ambito delle attività predecessore. Questi controlli vengono calcolati direttamente dal grafo delle dipendenze e dallo scorrimento, quindi compaiono all'istante e non consumano quota AI.
Per l'analisi del trend descritta sopra, le baseline memorizzano le date pianificate, così puoi confrontare le date pianificate con quelle attuali delle milestone invece di affidarti alla memoria o a vecchi screenshot. Diagrammi di Gantt, dipendenze, milestone e analisi del percorso critico sono tutti disponibili nel piano Free; baseline e monitoraggio degli scostamenti sono inclusi in Pro, e il piano Teams si paga per membro. Qui trovi i prezzi attuali.
Quattro errori da evitare
- Dare una durata a una milestone. Diventa possibile dichiararla parzialmente fatta, che è l'unica cosa che un checkpoint non deve mai essere.
- Lasciarla scollegata. Una milestone scollegata non può slittare, quindi non può avvisarti. Manterrà la sua data fino al giorno stesso in cui viene mancata.
- Non scrivere i criteri di accettazione. Senza di essi, “completato” viene negoziato nella riunione di stato da chi si mostra più sicuro.
- Modificare la data invece di registrare lo slittamento. Sembra buona igiene e invece distrugge l'unico insieme di dati che ti avrebbe mostrato il trend.
In sintesi
Una milestone utile ha cinque proprietà: durata zero, esito binario, un responsabile con nome e cognome, criteri di accettazione scritti e veri predecessori che la alimentano. Se le imposti bene, il tuo piano inizia a segnalare i problemi settimane prima che si materializzino. Se le sbagli, ti ritrovi con dei rombi decorativi.
Se il tuo piano attuale ha già delle milestone, fai un controllo questa settimana. Aprile una per una e verifica cosa c'è collegato in ingresso. Quelle senza niente a monte sono quelle che ti stanno mentendo.