Come scegliere il migliore periodo di aggiornamento di un progetto

«Ogni quanto ci aggiorniamo?». È una delle prime domande che un committente fa, di solito nella stessa riunione in cui approva il piano, e di solito la risposta arriva d’istinto: «ogni settimana», oppure «alla fine di ogni mese, con il SAL». Non è una scelta da poco. Quel numero decide quante volte, da qui alla fine del progetto, avrai un piano aggiornato in mano, e quindi quante occasioni avrai per accorgerti in tempo che qualcosa non torna.

Ma decide anche quanto tempo passerai a raccogliere dati invece di gestire il lavoro. Il periodo di aggiornamento è un compromesso tra queste due cose, e come tutti i compromessi si sceglie meglio con una regola davanti che a naso.

Due ritmi, non uno: reporting e raccolta

La prima confusione da togliere di mezzo è tra due frequenze che spesso vengono chiamate con lo stesso nome. La prima è il periodo di reporting: ogni quanto il committente, la direzione o lo sponsor ricevono lo stato del progetto, con i numeri e le decisioni da prendere. La seconda è la frequenza di raccolta: ogni quanto tu, che il progetto lo gestisci, raccogli dalle risorse e dai fornitori le informazioni su cosa è stato fatto davvero.

Il periodo di aggiornamento del piano coincide con il primo. Non ha senso presentare uno stato del progetto calcolato su un piano fermo a tre settimane prima, e non ha senso nemmeno aggiornare il piano il doppio delle volte in cui lo si legge: l’aggiornamento serve a produrre una fotografia confrontabile con la precedente, e la fotografia la si guarda insieme al committente.

La raccolta invece può, e spesso deve, essere più fitta. Se il reporting è mensile e tu senti le risorse una volta al mese, il giorno prima della riunione, il ritardo lo scopri quando è già di quattro settimane. Se le senti ogni settimana, o ogni giorno in una fase delicata, i segnali deboli arrivano prima e alla riunione ci vai già sapendo cosa dire. Nell’articolo sul ritardo che non va taciuto ho descritto proprio questo: la tendenza si vede prima dell’evidenza, ma solo se qualcuno guarda.

Quanto costa un aggiornamento

Aggiornare un piano non è cliccare un pulsante. Per ogni periodo si fanno, nell’ordine, cinque cose:

1. raccogliere dalle risorse le date effettive di inizio e fine, il lavoro svolto e quello rimanente, i costi maturati;
2. inserire i dati nel piano;
3. spostare la data di stato al nuovo periodo;
4. confrontare il risultato con la previsione;
5. preparare la presentazione per chi decide.

Tra il tempo del project manager e quello, spesso dimenticato, delle persone che devono fermarsi a rispondere, un aggiornamento serio di un piano medio porta via da mezza giornata a una giornata intera.

Moltiplica per la frequenza e il conto è presto fatto. Un aggiornamento settimanale su un progetto di due anni sono un centinaio di aggiornamenti: cento mezze giornate di raccolta e analisi, e cento volte in cui il team viene interrotto per dire a che punto è. È il caso classico in cui si passa più tempo a misurare il progetto che a gestirlo, e in cui le risorse, dopo un po’, rispondono a caso pur di farla finita. A quel punto i dati sono anche inaffidabili.

L’estremo opposto costa di più, ma in un altro modo. Un progetto di un anno aggiornato ogni tre mesi ha quattro fotografie in tutto: quando la seconda mostra un ritardo, un quarto del progetto è già passato e le opzioni per recuperare sono la metà di quelle che avevi. Il costo di un aggiornamento si vede subito; il costo di un aggiornamento mancato si vede alla fine.

La regola di partenza: la durata del progetto

La tabella che segue è quella del 2010, e non ho trovato motivo di cambiarla. Per ogni durata indica la frequenza minima e la massima che un committente ragionevole chiede, o che ha senso proporgli. Il periodo di aggiornamento va scelto dentro quella forbice.

Durata del progetto	Frequenza minima di reporting	Frequenza massima di reporting
1 mese	quando serve, anche ogni giorno	ogni giorno lavorativo
3 mesi	ogni settimana	due volte a settimana
1 anno	ogni mese	ogni due settimane
2 anni	ogni due mesi	ogni mese
5 anni	ogni sei mesi	ogni due mesi

C’è una logica dietro, e vale la pena vederla perché aiuta con le durate che nella tabella non ci sono. Se conti quanti aggiornamenti produce ciascuna riga, il numero è quasi sempre lo stesso:

• 3 mesi, ogni settimana: 13 aggiornamenti;
• 1 anno, ogni mese: 12;
• 2 anni, ogni due mesi: 12;
• 5 anni, ogni sei mesi: 10.

Sul lato «massimo» della tabella si arriva a 24, 26, 30. Un progetto, qualunque sia la sua durata, ha bisogno di una decina di punti di controllo come minimo e di una trentina come massimo. Sotto i dieci non vedi la tendenza, sopra i trenta il controllo costa più di quello che protegge.

Questo dà anche la regola pratica per un progetto di otto mesi, o di tre anni, che nella tabella non compaiono: dividi la durata per dodici o quindici e hai il periodo di aggiornamento di base. Otto mesi diviso dodici fa circa tre settimane; tre anni diviso dodici fa un trimestre. Poi si aggiusta con i fattori che seguono.

I fattori che spostano la scelta dentro la forbice

La durata dice dove sta la forbice. Dentro la forbice, quattro cose decidono se stare vicino al minimo o al massimo.

• Il rischio. Un progetto con molte incognite tecniche, fornitori mai visti o un perimetro ancora in movimento si aggiorna più spesso di uno che ripete cose già fatte dieci volte. L’aggiornamento è l’unico momento in cui un’incognita diventa un numero.
• La fase. Il periodo non è per forza lo stesso per tutta la vita del progetto. Le fasi di avvio, di integrazione e di collaudo meritano un ritmo più fitto; una lunga fase di produzione a regime può reggere il ritmo più rado. Va detto nel piano di comunicazione, così nessuno lo legge come un cambio di rotta.
• Il contratto. Molti committenti chiedono un SAL mensile o un rapporto trimestrale per contratto. Quello è il periodo di reporting, e il periodo di aggiornamento va allineato: aggiornare a ritmo diverso da quello con cui si riporta produce fotografie che nessuno guarda, oppure report basati su dati vecchi.
• La stabilità del team. Risorse dedicate, sempre le stesse, forniscono dati in cinque minuti; risorse condivise tra più progetti, esterne, o distribuite su più sedi hanno un costo di raccolta molto più alto, e la frequenza deve tenerne conto, oppure va organizzata una raccolta che non passi per il project manager.

Un quinto fattore, meno nobile ma reale, è il calendario che c’è già. Se l’azienda ha un comitato di direzione il primo lunedì del mese, il periodo mensile con data di stato l’ultimo venerdì del mese precedente si impone da solo. Combattere contro i ritmi esistenti per difendere una frequenza teorica è una battaglia che si perde sempre.

Fissare il ritmo in Microsoft Project: la data di stato

Deciso il periodo, in Microsoft Project il ritmo si materializza in una cosa sola: la data di stato. Si imposta da Progetto → Informazioni sul progetto → Data di stato, e va portata avanti di un periodo a ogni aggiornamento, sempre allo stesso giorno della settimana o del mese. È la data alla quale il piano dichiara «fino a qui so cosa è successo»: le percentuali di completamento, il lavoro effettivo, gli indicatori di Earned Value vengono tutti calcolati rispetto a lei, non rispetto a oggi. Ho scritto un articolo apposta sull’impatto della data di stato, perché è il campo più trascurato e più importante di tutto il file.

Il periodo di aggiornamento è, in pratica, la distanza tra due date di stato consecutive. Se è fissa, le fotografie sono confrontabili e la tendenza si legge: la variazione di fine di un’attività critica che era di due giorni alla data di stato precedente e di cinque a questa dice che il ritardo cresce. Se le date di stato cadono a caso, una dopo dieci giorni e la successiva dopo quaranta, i confronti perdono senso e ogni aggiornamento ricomincia da capo.

Tre accorgimenti, tutti piccoli, fanno la differenza tra un ritmo dichiarato e un ritmo rispettato:

• rendi visibile la data di stato nel Gantt, con la linea verticale che si attiva da Formato → Linee della griglia → Data di stato: chi apre il file vede a colpo d’occhio a quando è aggiornato;
• inserisci gli avanzamenti con date effettive vere, non con la sola percentuale: sono le date effettive di inizio e fine a rendere il piano una registrazione di quello che è successo, e non solo una stima aggiornata;
• tieni una previsione salvata e non risalvarla a ogni periodo: senza il confronto con la previsione l’aggiornamento dice dove sei, ma non di quanto ti sei spostato.

Il ciclo completo, dalla raccolta alla lettura dei risultati, è descritto tappa per tappa nella guida su come aggiornare un piano in Microsoft Project: questo articolo risponde solo alla domanda «ogni quanto», quella risponde al «come».

Quando cambiare periodo, e quando no

Il periodo si concorda all’inizio, ma non è una condanna. Si stringe quando il progetto entra in una fase critica, quando un ritardo sul percorso critico si conferma per due aggiornamenti di fila, o quando un fornitore chiave comincia a mancare le date: in tutti questi casi il valore di ogni fotografia in più è alto e il costo si giustifica. Un progetto di un anno che passa da mensile a quindicinale negli ultimi tre mesi non sta ammettendo un fallimento, sta facendo il suo mestiere. Il recupero di un ritardo, in particolare, richiede quasi sempre un periodo più corto finché il ritardo non rientra.

Si allenta raramente, e solo con una ragione dichiarabile: una fase lunga e stabile, un team che fornisce dati affidabili senza sollecitazioni, un committente che chiede meno. Non si allenta mai perché il progetto va male e aggiornare è diventato sgradevole. È l’errore più umano e il più costoso: la fotografia in meno è esattamente quella che avrebbe mostrato il problema mentre era ancora recuperabile.

In entrambi i casi il cambio si comunica al committente prima di applicarlo, con la ragione. Un committente che riceve il report ogni due settimane invece che ogni mese, senza spiegazioni, non pensa «che bravo»: pensa «cosa mi nasconde».

Gli errori che vedo più spesso

• Aggiornare «quando serve». Cioè quando qualcuno chiede il piano. Il piano viene aggiornato di corsa il giorno della riunione, con dati raccolti al telefono la mattina stessa, e la data di stato è «oggi». Nessuna fotografia è confrontabile con la precedente.
• Data di stato lasciata vuota. Project usa allora la data corrente, che cambia ogni giorno: aprire il file il lunedì e il giovedì dà due stati di avanzamento diversi senza che nessuno abbia inserito nulla.
• Raccolta e reporting con lo stesso ritmo. Se senti le risorse una volta al mese, ogni problema ha avuto un mese per crescere prima che tu lo sapessi. La raccolta va tenuta più fitta del reporting.
• Ritmi diversi tra piano e report. Il piano aggiornato ogni settimana e il SAL mensile costruito a mano su un foglio a parte: dopo tre mesi i due non dicono più le stesse cose.
• Confondere aggiornamento e ripianificazione. L’aggiornamento registra cosa è successo fino alla data di stato; la ripianificazione decide cosa cambiare da lì in poi. Si fanno nello stesso giorno, ma la seconda non è obbligatoria e la prima sì.

Il caso opposto: quando la tabella non basta

La tabella ragiona su progetti con un piano di durata definita, gestiti a fotografie. Ci sono almeno tre contesti in cui il ritmo lo decide qualcos’altro.

• Progetto gestito a sprint. Il periodo di aggiornamento è lo sprint, di solito due settimane, qualunque sia la durata totale: la tabella direbbe «ogni mese» per un progetto di un anno, e sarebbe sbagliato, perché la cadenza è già decisa dal metodo.
• Cantiere con penali giornaliere. Nelle ultime settimane l’aggiornamento è quotidiano anche se il progetto dura due anni, perché ogni giorno ha un prezzo scritto nel contratto.
• Progetto di un mese con risorse esterne che non riportano ogni giorno. La frequenza massima della tabella è semplicemente irraggiungibile, e tanto vale dichiararlo subito invece di rincorrere dati che non arrivano.

La tabella resta il punto di partenza: serve ad avere una proposta ragionata da mettere sul tavolo. Poi vince sempre il contesto, purché la decisione sia presa e scritta, e non lasciata al caso.

Domande frequenti

Per un progetto di un anno: ogni settimana o ogni mese?

La tabella dice ogni mese come minimo e ogni due settimane come massimo. Ogni settimana è troppo per tutto l’anno: cinquanta aggiornamenti costano più del controllo che danno. La scelta più comune che funziona è mensile nelle fasi stabili e quindicinale nelle fasi critiche, dichiarata così nel piano di comunicazione fin dall’inizio.

Devo aggiornare il piano anche se non è cambiato niente?

Sì. L’aggiornamento non registra solo i cambiamenti, registra che alla data di stato le cose stavano così. Spostare la data di stato, confermare le date effettive e salvare è la prova che il controllo c’è stato; e un periodo in cui «non è cambiato niente» su attività che dovevano avanzare è, di per sé, un’informazione che vale.

Il committente vuole un aggiornamento ogni giorno su un progetto di due anni. Che faccio?

Gli chiedo cosa vuole sapere ogni giorno. Quasi sempre la risposta è «se ci sono problemi», e quella è una comunicazione per eccezione, non un aggiornamento del piano: si concorda un canale per gli imprevisti e si tiene il piano su un ritmo mensile. Se invece vuole davvero i numeri ogni giorno, gli mostro il costo con la tabella: cinquecento aggiornamenti, ciascuno con la sua raccolta. Di solito la richiesta si ridimensiona da sola.

Che giorno scegliere come data di stato?

Un giorno fisso, sempre lo stesso, e possibilmente la fine di un’unità naturale di lavoro: il venerdì per il periodo settimanale, l’ultimo giorno lavorativo del mese per quello mensile. La raccolta si fa il giorno prima, l’aggiornamento il giorno stesso o il primo giorno utile dopo, la presentazione entro pochi giorni. Se tra data di stato e report passano due settimane, il report è già vecchio quando viene letto.

Aggiornamento del piano e SAL sono la stessa cosa?

No, ma devono avere lo stesso ritmo. L’aggiornamento è l’operazione sul piano: si portano dentro i dati effettivi alla data di stato. Il SAL, o status report, è il documento che ne esce e che va al committente: cosa è stato fatto, cosa è in ritardo, cosa si decide. Un SAL costruito da un piano aggiornato alla stessa data è credibile; un SAL scritto a mano con un piano fermo a un mese prima è un’opinione.

La tabella è del 2010: vale ancora?

Sì, perché non dipende dal software ma dal rapporto tra durata del progetto e numero di fotografie utili. Quello che è cambiato è la facilità della raccolta: oggi le risorse possono riportare l’avanzamento da un foglio condiviso o da un’app invece che al telefono, e questo abbassa il costo di ogni aggiornamento. L’effetto è che ci si può permettere di stare più vicini alla frequenza massima della forbice, non che la forbice sia cambiata.