Milestone di progetto: come definirle e in cosa differiscono dalle scadenze

Una milestone inserita con una data e senza collegamento al lavoro che la precede resta su quella data qualunque cosa succeda al lavoro. È uno schema frequente nei piani importati da fogli di calcolo e da cronoprogrammi più vecchi, e ha due parenti stretti: una data esterna inserita come milestone e una milestone bloccata con un vincolo “deve finire il”.

Questa guida spiega cosa sono le milestone di progetto, in cosa differiscono dalle scadenze e dai vincoli di data e quali sono le due verifiche che ogni milestone deve superare. Poi segue uno stand in fiera dal brief all’allestimento, dove la stessa data viene modellata in tre modi e solo uno di questi sposta la data e segnala la scadenza mancata quando il lavoro slitta.

Cosa sono le milestone di progetto#

Una milestone di progetto è un punto del cronoprogramma con durata zero che segna un evento significativo, come un’approvazione o un passaggio di consegne. Una milestone non occupa tempo né richiede impegno: registra il momento in cui il lavoro che la precede è finito e quello che la segue può partire. Senza milestone, uno slittamento di tre giorni nella revisione del progetto resta invisibile fino al giorno in cui lo stand deve essere montato, e a quel punto nessuno può più recuperarlo.

Il glossario del PMI definisce la milestone come un punto o evento significativo di un progetto^[1]. In un diagramma di Gantt si disegna come un rombo su una singola data. Nel reticolo si comporta come qualsiasi attività: ha predecessori e successori, ha un margine e può trovarsi sul percorso critico.

Date a una milestone il nome di uno stato raggiunto e a un’attività il nome di un’azione. “Rivedere il progetto” è lavoro che dura due giorni; “Progetto approvato” è il momento in cui quel lavoro finisce. Milestone tipiche sono “Contratto firmato”, “Dati migrati e riconciliati”, “Collaudo superato” e “Go-live”.

Milestone, scadenze e vincoli di data#

Una milestone è un evento del piano, una scadenza è una data che un evento non dovrebbe mancare e un vincolo di data è un’istruzione che obbliga il motore di pianificazione a collocare un’attività su una data o attorno a essa. Gli strumenti di pianificazione trattano le tre cose in modo diverso, e i piani importati le confondono di continuo.

Una milestone senza predecessori si comporta come una data scritta su un planning appeso al muro. Un vincolo “deve finire il” tiene la milestone sulla sua data anche quando il lavoro a monte finisce dopo; gli strumenti che rispettano i vincoli mostrano lo scarto come margine negativo sulla catena che la precede, facile da non notare in un piano lungo. La guida al metodo del percorso critico spiega come si calcola il margine e perché può scendere sotto zero.

Il nostro consiglio: mettete ogni data esterna come scadenza su una milestone collegata, così la milestone mostra dove arriverà davvero il lavoro e la scadenza mostra quanto si è lontani dall’impegno preso. Usate un vincolo solo quando la data esterna limita il momento in cui si può lavorare, come il giorno in cui la sede apre per l’allestimento. Se altro lavoro va pianificato proprio da quella data, come le visite della stampa fissate per il giorno dopo l’apertura, date alle visite della stampa un vincolo “iniziare non prima del” e lasciate la milestone libera di spostarsi. Una milestone bloccata con “deve finire il” finisce per definizione alla scadenza, quindi la scadenza non viene mai segnalata come mancata, anche se sono impostate entrambe sulla stessa milestone.

Due verifiche che ogni milestone deve superare#

Una buona milestone ha un predecessore e un evento verificabile nel giorno stesso.

Ha un predecessore. Una milestone senza collegamenti in ingresso non ha motivo di spostarsi, quindi non segnala mai un ritardo. Collegatela all’ultima attività, o alle ultime attività, che devono finire perché l’evento si verifichi. L’inizio del progetto può restare isolato, e così una milestone che registra un input esterno al team, come i dati ricevuti dal cliente o un permesso rilasciato: datele un “iniziare non prima del” sulla data prevista e trattate quella data come un’ipotesi da verificare. Contano anche i successori: a parte la milestone finale, ognuna dovrebbe averne almeno uno, perché una milestone da cui non dipende nulla registra solo una data. La checklist sulle dipendenze chiede lo stesso a ogni attività.

Il suo evento è verificabile. Qualcuno deve poter rispondere sì o no alla domanda “è successo?”, indicando qualcosa: un’email con l’approvazione, una bolla di consegna, un verbale di prova, una pagina che si carica. “Progetto completato all’80%” non supera la verifica. “Progetto approvato dal direttore commerciale” la supera.

Come regola pratica, fissate una milestone per ogni decisione o passaggio di consegne che cambia chi lavora dopo. In un progetto di tre mesi con cinque persone di solito significa da sei a dieci, tranne quando diversi fornitori esterni si passano il lavoro: ogni passaggio tra aziende merita allora una milestone propria, anche se il numero sale. Oltre 13 in un piano di tre mesi diventano un secondo elenco di attività; sotto 3, può passare un mese senza un controllo.

A chi servono le milestone, quando e quanto tempo richiedono#

Le milestone servono a chi deve agire su un passaggio di consegne o rispondere di una data: il project manager e chi aspetta una consegna. Si guadagnano il posto in qualsiasi piano più lungo di circa due settimane che contenga almeno una decisione o un passaggio di consegne. Non servono a una lista di cose da fare di una sola persona, né a un flusso continuo di ticket, dove nulla viene consegnato e una milestone registrerebbe solo una data.

Aggiungetele quando esiste la prima versione del piano, non alla fine, perché sono i collegamenti a decidere dove cade ciascuna. In un piano di 40 attività, collegare otto milestone è questione di minuti; verificarle una per una con i due test visti sopra richiede di più, ed è la parte che ha bisogno di qualcuno che sappia cosa significa “finito”.

Dove vanno le milestone nel cronoprogramma#

Mettete ogni milestone alla fine del lavoro che chiude, collegata con una dipendenza fine-inizio alle ultime attività di quel lavoro, e collegate le prime attività della fase successiva alla milestone invece che alle attività precedenti.

Far passare i collegamenti dalla milestone riduce il lavoro e rende visibile il punto di decisione. Se tre attività alimentano “Progetto approvato” e quattro la seguono, i collegamenti diretti tra loro sarebbero 12; passando dalla milestone sono 7, e una quinta attività dopo l’approvazione richiede un solo collegamento nuovo invece di tre.

Le milestone sono anche il modo in cui le fasi compaiono in un piano costruito attorno ai deliverable. La guida alla work breakdown structure (WBS) tiene le fasi fuori dalla WBS e le mostra come milestone nel cronoprogramma. Una volta salvata una baseline, le righe delle milestone sono le prime che lo sponsor legge: “Progetto approvato, 3 giorni dopo la baseline” dice più di una percentuale (vedi baseline di progetto e scostamenti).

Un esempio pratico: uno stand in fiera#

Un’azienda che produce sensori industriali espone a una fiera. Il team è composto dal responsabile marketing, da un designer freelance, dal team prodotto che prepara le unità demo e da un allestitore che lavora prima nella propria officina e poi nel padiglione. L’organizzatore fissa due date: il padiglione apre per l’allestimento al giorno 24 del piano, e ogni stand deve essere finito entro la fine del giorno 26, quando il padiglione chiude per le pulizie prima dell’apertura.

Le durate sono in giorni lavorativi e ogni collegamento è fine-inizio. Il margine è misurato rispetto alla fine del piano, il giorno 25.

Il percorso critico è brief, progettazione, revisione, costruzione, spedizione e montaggio: 3 + 6 + 2 + 10 + 2 + 2 = 25 giorni, un giorno entro il limite dell’organizzatore. Entrambe le milestone superano le due verifiche. L’approvazione è il via libera scritto del direttore commerciale sui disegni definitivi, di cui l’allestitore ha bisogno prima di tagliare qualsiasi cosa. “Stand pronto” significa che lo stand è montato, la grafica è applicata e le unità demo sono accese, con una foto inviata al responsabile marketing.

Il vincolo sul montaggio in questa versione non ha effetto, perché la spedizione finisce il giorno 23. Serve per l’altro caso: se l’officina finisse in anticipo, lo stand non potrebbe comunque entrare nel padiglione prima del giorno 24.

Ora la revisione sfora. Il direttore commerciale è in viaggio e l’approvazione arriva dopo 5 giorni invece di 2, alla fine del giorno 14. La costruzione passa ai giorni 15–24, la spedizione ai giorni 25–26 e il montaggio ai giorni 27–28. Il lavoro ora finisce il giorno 28, due giorni lavorativi dopo la chiusura del padiglione. Cosa mostra il piano dipende da come è stato inserito “Stand pronto”:

La seconda versione mostra lo slittamento solo a chi legge la colonna del margine o l’elenco dei conflitti; il rombo dice ancora giorno 26. La terza sposta la data e segnala la scadenza mancata il giorno 14, appena il responsabile marketing aggiorna la revisione a 5 giorni, dodici giorni lavorativi prima della chiusura del padiglione.

La grafica ha ancora 6 giorni di margine e le unità demo sono pronte da tempo, quindi il tempo va recuperato su spedizione e montaggio. L’allestitore può portare lo stand in fiera in un giorno con il proprio furgone e aggiungere due montatori per finire il montaggio in un giorno: spedizione il giorno 25, montaggio il giorno 26, “Stand pronto” alla fine del giorno 26. Lo stand rispetta la scadenza senza più alcun margine, al costo del furgone e di due giornate-montatore in più. Questo compromesso è il crashing, trattato in progetto in ritardo: come recuperare.

Errori frequenti#

• Milestone con una durata. “Milestone di test, 5 giorni” è un’attività. Se qualcosa richiede tempo, pianificatelo come lavoro e mettete la milestone alla sua fine.
• Una milestone dopo ogni attività. Seppellisce le poche che segnano una decisione sotto righe chiamate “Attività completata”.
• Riunioni come milestone. Un comitato guida il 14 è un appuntamento in calendario. La milestone è la decisione che dovrebbe prendere: “Budget della fase 2 approvato”.
• Trascinare il rombo sulla data che qualcuno vuole. In Planitude, spostare un’attività a mano imposta un vincolo “iniziare non prima del” sulla nuova data, e la milestone continua a seguire i suoi predecessori. Una data più vicina di quanto il lavoro consenta non ha effetto: il rombo torna alla data che il lavoro consente. Una data più lontana resta anche se il lavoro finisce prima, e il vincolo sopravvive al motivo per cui era stato impostato.

Quando le milestone non bastano#

Una milestone dà notizie solo alla sua fine. Nell’esempio, i 10 giorni di costruzione non dicono nulla fino al giorno 21 a chi guarda solo “Stand pronto”; le attività critiche lunghe hanno bisogno di aggiornamenti sull’avanzamento nel frattempo.

Una singola data di milestone nasconde anche quanto sia incerta. Il giorno 25 è ciò che dà il piano se ogni stima regge, e con sei attività in fila la probabilità che nessuna sfori è bassa: se ciascuna ha l’80% di probabilità di finire in tempo, tutte e sei ci riescono circa il 26% delle volte (0,8 alla sesta), un dato costruito a scopo illustrativo (la guida su come stimare la durata delle attività spiega perché). Per una data promessa fuori dal team, indicate una data con una probabilità, come la P80, e tenete lo scarto visibile come margine prima della scadenza.

Le milestone contrattuali che fanno scattare un pagamento richiedono più di una data. Se il 30% del prezzo è legato a “Collaudo superato”, il contratto deve dire cosa succede quando il collaudo è superato con riserva; il cronoprogramma traccia solo quando l’evento è previsto.

Come farlo in Planitude#

Chiedete all’assistente AI di aggiungere una milestone dopo un’attività, oppure importatela da un file .mpp o da un foglio di calcolo, dove una durata 0 diventa una milestone. Nel diagramma di Gantt è un rombo; collegatela come qualsiasi attività. Inserite la data esterna nel suo campo Scadenza: la scadenza non sposta la milestone, ma il suo indicatore diventa rosso quando la milestone la supera. Digitare una data o trascinare una barra imposta “iniziare non prima del”, quindi quando una milestone cade più avanti di dove la metterebbero i suoi collegamenti, controllate il vincolo nello stesso pannello.

Il Riepilogo elenca le milestone in scadenza nei prossimi 14 giorni. I promemoria delle scadenze inviano un’email agli assegnatari verso le 8:00 ora dell’Europa centrale sulle scadenze del giorno dopo e sulle attività in ritardo, e un link iCal privato porta attività, milestone e scadenze in Google Calendar, Outlook o Apple Calendar. La scheda Rischi fornisce le date P50, P80 e P95 di ogni milestone, con la probabilità di rispettarne la scadenza.

Non c’è un campo per l’approvazione: scrivete l’evento verificabile nelle note dell’attività.

Domande frequenti#