Come raccogliere i consuntivi dal team e aggiornare il piano

Mandare il piano al team è la metà facile del lavoro. La metà difficile è farsi restituire i consuntivi: il giorno in cui un’attività è partita davvero, quello in cui è finita davvero, e quanto lavoro manca ancora. Quei numeri esistono solo nella testa delle persone, e invecchiano nel giro di pochi giorni.

Questo articolo parla di come raccogliere i consuntivi dal team senza farlo diventare un lavoro a sé. È il viaggio di ritorno del piano: l’andata, cioè mandare a ciascuno le sue attività senza Project Server, è un altro articolo. E che cosa farne una volta arrivati, nell’ordine giusto, è un altro lavoro ancora, spiegato in come aggiornare un piano di Microsoft Project.

I tre numeri da chiedere, e quello da non chiedere più

Quasi ogni riunione di avanzamento si apre con la stessa domanda: a che punto sei? Sembra la domanda giusta ed è quella sbagliata, per un motivo che vale la pena capire più che ricordare.

Una percentuale è un giudizio sul passato. Comprime quello che è stato fatto in un numero che nessuno può verificare, ed è ottimista per costruzione: l’ultimo dieci per cento di quasi ogni attività contiene più del dieci per cento del lavoro. E soprattutto non dice niente del futuro, che è l’unica cosa per cui esiste un piano.

Al suo posto servono tre numeri:

• Inizio effettivo. Il giorno in cui l’attività è partita davvero. La ancora alla realtà e impedisce al piano di spostarla a suo piacimento.
• Fine effettiva. Il giorno in cui è finita davvero, per le attività concluse. Chiude la questione.
• Lavoro rimanente. Quante ore servono ancora. È il numero che conta, perché è l’unico che cambia la data di fine.

«Sono all’ottanta per cento» e «mi mancano due giorni» sembrano la stessa frase. Solo una delle due può rivelarsi sbagliata in un modo che vedrai la settimana prossima.

C’è anche un vantaggio pratico. Chiedere il lavoro rimanente sposta la conversazione dal difendere il passato allo stimare il futuro, e sul futuro le persone sono molto più sincere. Nessuno ama ammettere di essere in ritardo; quasi tutti ti dicono che un’attività ha bisogno di altri tre giorni, se la domanda è semplicemente di quanti giorni ha bisogno.

Una distinzione da tenere a mente, se le percentuali le usi comunque per il reporting: in Microsoft Project la % completamento misura la durata trascorsa, la % lavoro completato le ore svolte. Rispondono a domande diverse, e raramente coincidono.

Il ciclo, in cinque passi

Qualunque strada tu scelga, la forma è la stessa, e si ripete in una data che non si sposta.

Il quarto passo merita l’accento. Qualcuno darà per finita un’attività che non lo è, e qualcuno si dimenticherà un’intera settimana e non manderà niente. Sono cose normali. Quello che non è normale, e che fa danni veri, è lasciare che quei numeri finiscano nel piano senza un’occhiata: una volta scritti, sono identici a quelli giusti.

Quattro modi di raccogliere, e quanto costa ciascuno

Sono le strade che si usano davvero. Nessuna è sbagliata: semplicemente si rompono a dimensioni diverse.

Strada	Funziona quando	Dove si rompe
Chiedere in riunione	poche persone, tutte nella stanza	le risposte vengono a memoria e arrotondate; non resta scritto niente finché non lo scrivi tu
Un foglio condiviso	un team stabile che si ricorda di aprirlo	due persone salvano insieme, o qualcuno riordina le righe e i nomi delle attività non corrispondono più al piano
Un giro di email	qualunque dimensione, nessuna preparazione	ognuno risponde a modo suo: ore, percentuali, frasi. Trasformarle in un aggiornamento è un pomeriggio di lettura
Un ciclo fisso con una forma sola	la cadenza si ripete e il team è sparso	va impostato una volta, e qualcuno deve essere il responsabile dell’approvazione

Guarda che cosa hanno in comune le prime tre. Raccolgono le informazioni, e tutte lasciano la traduzione a chi pianifica: leggere quattordici risposte, capire che cosa intendeva ciascuno, e riportarlo nel piano. È lì che se ne vanno le ore, ed è la parte che cresce male.

Le quattro regole che decidono se una strada funziona

• La data non si sposta mai. Stesso giorno, stessa ora, ogni periodo. Un ciclo che slitta una volta di due giorni, nel giro di un mese slitta di una settimana, e la serie smette di essere confrontabile. Scegliere il periodo conta meno che non spostarlo mai.
• Secondi a persona, non minuti. Due date e un numero, in qualcosa che hanno già aperto sullo schermo. Se serve entrare in un sistema, aprire uno strumento o ricordarsi una password, verrà fatto in ritardo, e poi non verrà fatto più.
• Una forma sola per tutti. Le stesse colonne, nello stesso ordine, a ogni periodo. È quello che rende le risposte unibili senza leggerle una per una.
• Si approva prima di scrivere. Guardi che cosa è tornato, chiedi su quello che non torna, poi scrivi. Cinque minuti qui risparmiano la riunione in cui qualcuno dice che il piano è sbagliato, e ha ragione.

C’è una quinta regola, che non riguarda la meccanica: dire alle persone che cosa è successo ai loro numeri. Un team che non vede mai le conseguenze di quello che comunica smette di comunicarlo con cura. Mostrare il piano aggiornato, anche di sfuggita, trasforma il ciclo da tassa amministrativa in qualcosa di cui si vede il senso; un cruscotto operativo è un modo per renderlo automatico.

Che cosa tutto questo non risolve

• Una cultura in cui ammettere un ritardo non è sicuro. Se le cattive notizie vengono punite, riceverai numeri ottimisti per sempre, raccolti in modo molto efficiente. Nessun ciclo e nessuno strumento lo risolve: è un problema di gestione, e va risolto come tale.
• Un piano troppo grossolano per essere aggiornato. Se un’attività dura otto settimane, il «lavoro rimanente» è un’ipotesi per sette di quelle. La soluzione sta nel piano, non nella raccolta: attività abbastanza corte da rendere la risposta osservabile.
• Stime sbagliate fin dall’inizio. Raccogliere i consuntivi ti dice la verità prima. Non migliora la stima di partenza, e non sceglie al posto tuo l’azione correttiva.
• Il progetto molto piccolo. Quattro persone che si parlano ogni giorno non hanno bisogno di un ciclo. Hanno bisogno che chi pianifica ascolti il venerdì e lo scriva.

Se qualcosa va storto

• Dopo aver inserito l’avanzamento le date tornano indietro. Quasi sempre la data di stato non è impostata, o è stata impostata dopo aver inserito i consuntivi. Prima la data di stato, poi i consuntivi, e poi si controlla che il lavoro non finito sia stato spostato oltre quella data invece di restare nel passato.
• Dopo tre o quattro periodi le risposte smettono di arrivare. Prima di dare la colpa al team, guarda quanto costa a ciascuno. Se compilare richiede cinque minuti, i cinque minuti sono il motivo. Se richiede venti secondi e si ferma lo stesso, il motivo è che nessuno ha mai visto a che cosa servivano i suoi numeri.
• Due persone aggiornano la stessa attività. Un’attività con due responsabili non ha un responsabile. Dividila, oppure indica una sola persona che la aggiorna, e dillo.
• Qualcuno dà per finita un’attività che il periodo dopo ricompare. È il caso per cui esiste il quarto passo. Quando passa lo stesso, non correggere in silenzio: torna a chiedere, perché lo stesso equivoco si ripeterà.

Niente di questo metodo richiede uno strumento: su un progetto, un foglio con le stesse quattro colonne ogni settimana e cinque minuti di revisione coprono tutto. Se però è la traduzione a mangiarti la settimana, per questo ho costruito GanttTimesheet: manda a ciascuna risorsa le sue assegnazioni per email, importa quello che torna, te lo fa approvare riga per riga e lo scrive nel piano.

Domande frequenti

Ogni quanto conviene raccogliere i consuntivi?

Ogni settimana va bene per la maggior parte dei progetti, con attività di pochi giorni; ogni due settimane o ogni mese per lavori lunghi di ingegneria o di cantiere. La frequenza conta molto meno del tenerla fissa: una serie raccolta ogni lunedì è confrontabile da un periodo all’altro, una raccolta quando c’è tempo è una collezione di fotografie scollegate.

Perché non chiedere semplicemente la percentuale di completamento?

Perché una percentuale è un giudizio sul lavoro già fatto, ed è ottimista per costruzione. Il lavoro rimanente è una stima sul futuro, si può verificare con la realtà il periodo dopo, ed è il numero che sposta davvero la data di fine. Se la percentuale ti serve per il reporting, ricavala invece di chiederla.

Il team deve avere Microsoft Project?

No, e di solito è un errore darglielo. Chi deve scrivere due date e un numero ha bisogno di un formato che sa già aprire, non di uno strumento di pianificazione. Mandare le assegnazioni è l’altra metà di questo ciclo, ed è spiegata in come inviare a ciascuno le sue attività senza Project Server.

E se il team scrivesse direttamente nel piano?

Ti toglie la digitazione e insieme ti toglie la revisione, e non è un buon cambio. Gli errori che arrivano già registrati sono invisibili: sembrano identici ai dati giusti. Tieni il passo di approvazione, anche quando è rapido.

E se qualcuno semplicemente non risponde?

Lascia il buco visibile invece di riempirlo con un’ipotesi. Un’attività segnata come non aggiornata è un’informazione; un’attività spostata in avanti in silenzio con numeri inventati è un errore che si moltiplica a ogni periodo. Se la stessa persona manca per tre periodi di fila, è una conversazione da fare, non un problema di dati.

Gli stessi controlli in forma di scheda, da tenere accanto alla tastiera: la checklist per analizzare un piano, con il PDF di una pagina da stampare.