Piano di progetto e cronoprogramma: cosa contiene ciascuno e chi lo legge

Chiedete "il piano" a quattro persone di un progetto: due potrebbero aprire un diagramma di Gantt e le altre due inoltrarvi un documento con ambito e budget. Il diagramma mostra quando si svolge il lavoro. Il documento dice qual è il lavoro e chi può modificarlo. I problemi arrivano con la prima richiesta di modifica, quando esiste solo uno dei due.

Questa guida mette a confronto il piano di progetto e il cronoprogramma. Una tabella mostra cosa contiene ciascuno e chi lo legge. Poi un convegno clienti di una giornata segue una singola richiesta di modifica, contata in giorni dal cronoprogramma e decisa secondo le regole del piano.

Piano di progetto e cronoprogramma: cosa sono#

Il piano di progetto è il documento concordato che definisce l’ambito di un progetto e le regole per gestirlo, compreso chi può modificarli. Il suo corrispettivo, il cronoprogramma, modella quel piano e assegna a ogni attività date e dipendenze^[1]. Senza un piano scritto, una modifica che aggiunge 4 giorni di lavoro e consuma l’ultimo giorno libero prima di una data fissata per contratto può essere approvata senza che nessuno sia indicato come responsabile di accettarla. Se a mancare è il cronoprogramma, la stessa modifica sembra gratuita, perché nessuno conta i giorni che consuma.

L’ordine tra i due viene dal Government Accountability Office (GAO) statunitense. La sua Schedule Assessment Guide (GAO-16-89G) afferma che la strategia complessiva di esecuzione è documentata nel piano di progetto, che definisce tra l’altro l’ambito e la work breakdown structure, e che la schedulazione è un processo distinto che segue la pianificazione^[1]. Nelle parole del GAO, il cronoprogramma è "essenzialmente un modello del piano di progetto"^[1].

La NASA tratta il piano come un accordo. Secondo la NPR 7120.5F il piano di progetto è concordato tra project manager, programme manager, Center Director e Mission Directorate Associate Administrator, e il suo modello contiene una sintesi dell’integrated master schedule in una sezione Schedule Baseline^[2].

Chi ha bisogno di un piano e di un cronoprogramma, e quando#

Il nostro consiglio: scrivete un piano da tre persone o quattro settimane di lavoro in su, una volta concordati obiettivo e ambito e prima che il cronoprogramma sia definitivo, perché è l’ambito a decidere quali attività esistono. Con due persone l’ambito vive in una sola conversazione. La terza persona è la prima che non l’ha sentita, e quattro settimane bastano perché arrivi una richiesta di modifica a lavori in corso.

Non serve per due persone che lavorano due settimane su un ambito fissato da contratto. Il contratto svolge già la funzione del piano.

Il project manager scrive il piano con lo sponsor e costruisce il cronoprogramma con chi svolge il lavoro. I lettori sono diversi:

• Lo sponsor approva il piano prima dell’avvio e torna alle esclusioni e alla regola sulle modifiche ogni volta che arriva una richiesta.
• Un team da 3 a 8 persone legge il cronoprogramma ogni settimana; oltre le 8, ogni responsabile di sottogruppo legge il proprio ramo.
• I fornitori ricevono la loro parte e nient’altro. Al catering dell’esempio serve una sola data, il giorno 22, quando arriva il numero dei partecipanti.

La nostra regola empirica sulla lunghezza: mezza pagina di piano basta per tre persone su un mese, e da una a tre pagine coprono fino a circa 8 persone e 6 mesi. Oltre le 8 persone il team tende a dividersi in sottogruppi, e ogni responsabile ha bisogno di una porzione scritta dell’ambito. Oltre i 6 mesi il solo registro delle modifiche supera un paragrafo.

Una volta concordato il piano, costruite il cronoprogramma a partire dalla work breakdown structure (WBS), come mostra la guida alla WBS e a come trasformarla in un cronoprogramma. Il cronoprogramma cambia a ogni aggiornamento dell’avanzamento, mentre il piano si rivede solo quando cambiano l’ambito o il team.

Cosa va nel piano, cosa va nel cronoprogramma e chi legge ciascuno#

Il piano contiene l’ambito e le regole ed è letto dallo sponsor; il cronoprogramma contiene le attività e le loro date ed è letto dal team ogni settimana.

Il GAO si aspetta che i cronoprogrammi siano sviluppati dal team di progetto, compresi i responsabili di specifiche aree di lavoro^[1]. Per questo la riga "Chi lo scrive" indica chi svolge il lavoro come coautore del cronoprogramma.

Leggete per prima la riga sulle richieste di modifica. Una richiesta ha bisogno di una risposta da entrambe le colonne prima che qualcuno possa dire sì, e nell’esempio che segue il cronoprogramma fornisce il numero di giorni mentre il piano indica chi decide. I ritardi si misurano rispetto alle date della baseline, e la guida pratica a baseline di progetto e scostamenti spiega come leggerli.

Un esempio pratico: un convegno clienti#

Una terza sessione parallela richiesta il giorno 8 aggiunge 4 giorni di lavoro a questo convegno e sposta la milestone "sala pronta" dal giorno 25 al giorno 26, sull’unico giorno libero prima dell’evento.

Un’azienda di software organizza un convegno di una giornata per 300 clienti. Il contratto con la location fissa la data: l’evento è il giorno 27. Il team di progetto è composto dal project manager più due persone, una coordinatrice eventi e un assistente marketing, e lo sponsor è il direttore commerciale. Il cronoprogramma ha due percorsi che si incontrano all’allestimento; tutte le dipendenze sono fine-inizio e le durate sono in giorni lavorativi.

Il percorso A richiede 5 + 15 + 2 = 22 giorni ed è il percorso critico. Il percorso B richiede 12 + 4 + 3 = 19. Quindi l’allestimento occupa i giorni da 23 a 25 e il giorno 26 resta libero.

Due termini vanno tenuti distinti. Il margine totale è il tempo di cui un’attività può slittare prima che la data di fine ne risenta^[1]; il percorso B ne ha 22 − 19 = 3 giorni. La riserva è il tempo libero tra la milestone "sala pronta" e la data fissa dell’evento: 1 giorno, il giorno 26.

Il piano occupa una pagina e fissa due regole. Qualsiasi modifica all’ambito richiede l’approvazione dello sponsor, qualunque effetto abbia sulle date. Una modifica di date o di metodo che lascia invariato l’ambito e resta entro il margine totale spetta al project manager, che la annota nel registro delle modifiche.

Il giorno 8, con "Prenotare i relatori" ancora in corso, lo sponsor chiede una terza sessione parallela: quattro relatori in più e una terza sala. La coordinatrice eventi, che finora ha prenotato tutti i relatori, stima 4 giorni di lavoro in più. Poco altro si muove. Il numero per il catering resta 300 perché partecipano le stesse persone, la tipografia conferma gli stessi 3 giorni per un programma più lungo e la squadra di allestimento conferma che una terza sala si allestisce comunque in 3 giorni. L’affitto della sala costa denaro ma non tempo, quindi il cronoprogramma non può mostrarlo.

Il percorso B diventa 16 + 4 + 3 = 23 giorni contro i 22 del percorso A. L’allestimento si sposta ai giorni da 24 a 26 e il percorso critico passa a B. Il margine totale assorbe 3 dei 4 giorni in più, e il quarto occupa il giorno 26, lasciando riserva zero.

La data dell’evento è salva, eppure la decisione spetta allo sponsor, perché il piano gli assegna ogni modifica all’ambito. Il project manager gli presenta tre opzioni:

1. Accettare la sessione e lavorare l’ultima settimana con riserva zero.
2. Dividere le nuove prenotazioni. L’assistente marketing prenota due dei quattro nuovi relatori nei giorni 9 e 10. La coordinatrice tiene gli altri due, entrambi dirigenti di aziende partner con cui ha già trattato, e li prenota nei giorni 13 e 14, dopo la fine delle prenotazioni originali il giorno 12. "Prenotare i relatori" finisce così il giorno 14 e il percorso B è di 14 + 4 + 3 = 21 giorni. Il giorno 26 resta libero, con 1 giorno di margine totale ancora su B.
3. Rifiutarla.

L’opzione 2 ha un limite. Mantiene libero il giorno 26 solo finché l’assistente può iniziare entro il giorno 14: due giorni iniziati il giorno 14 finiscono il giorno 15, il percorso B diventa 15 + 4 + 3 = 22 giorni, pari al percorso A, e la riserva resta senza più margine totale su B.

Il nostro consiglio: mandate allo sponsor il costo di una richiesta in giorni e in denaro il giorno stesso in cui arriva, con le opzioni, in non più di cinque righe, anche quando la data regge. Una richiesta che consuma l’ultimo giorno libero fa sì che qualsiasi successivo slittamento di un giorno cada direttamente sull’evento.

Lo sponsor sceglie l’opzione 2.

Il giorno 10 uno dei due relatori dell’assistente rinuncia, e trovare un sostituto richiede fino al giorno 11. I nuovi relatori restano quattro, quindi l’ambito non cambia, e il lavoro dell’assistente finisce comunque prima di quello della coordinatrice, il giorno 14. Il project manager lo annota nel registro delle modifiche senza tornare dallo sponsor.

Nel cronoprogramma originale, un ritardo di stampa sarebbe stato lo stesso tipo di decisione. Una tipografia sovraccarica che sposta la stampa dai giorni 17–19 ai giorni 19–21 fa finire il percorso B il giorno 21, l’allestimento inizia comunque il giorno 23 e la riserva resta intatta, quindi il project manager lo annota da solo.

Perché un diagramma di Gantt non è un piano#

Un diagramma di Gantt non può essere il piano perché mostra solo il lavoro già schedulato: attività come barre su un calendario, con le dipendenze tra loro (la guida al diagramma di Gantt spiega come leggerlo). Quattro elementi del piano non vi trovano posto:

• Le esclusioni. Il lavoro fuori ambito non ha una barra, e una barra mancante sembra esattamente lavoro a cui nessuno ha ancora pensato.
• La regola di approvazione.
• Il motivo dietro una data. Il giorno 27 può comparire come scadenza del progetto, mentre il contratto con la location che lo rende immodificabile non compare da nessuna parte, quindi chi legge non distingue una data fissa da un obiettivo.
• I costi che non richiedono tempo, come l’affitto della terza sala.

Il GAO segnala la stessa lacuna dal lato del cronoprogramma: la sua buona pratica sulle baseline chiede un documento di base che descriva in dettaglio le regole e le ipotesi alla base del cronoprogramma e giustifichi vincoli e ritardi^[1].

Prendete un responsabile di produzione che entra nel progetto del convegno nella settimana 3 e riceve solo il diagramma di Gantt. Vede sette attività e una milestone "sala pronta" alla fine del giorno 25, con la data dell’evento segnata come scadenza del progetto il giorno 27, un giorno libero dopo. Un fornitore gli propone un photo booth che richiede mezza giornata di allestimento e, dato che nulla nel diagramma dice se le aggiunte rientrano nell’ambito, accetta, così l’allestimento si allunga fino al giorno 26. Nessuno avvisa lo sponsor. La regola che copriva il caso, "qualsiasi modifica all’ambito richiede l’approvazione dello sponsor", stava in un piano che nessuno gli aveva inviato.

Come scrivere il piano e costruirci sopra il cronoprogramma#

Sei passi portano un progetto da un obiettivo concordato a un cronoprogramma con baseline, e ciascuno ha un risultato da verificare prima del successivo.

1. Scrivete l’obiettivo e la data fissa in una frase. Per il convegno: "Un convegno di una giornata per 300 clienti il giorno 27, data fissata dal contratto con la location."
2. Elencate cosa è fuori ambito e indicate chi approva le modifiche. Lo sponsor approva entrambi per iscritto prima che si stimi qualsiasi attività; basta una risposta via email.
3. Scomponete l’ambito in deliverable. Risultato: una WBS i cui pacchetti di lavoro coprono l’intero ambito, ciascuno con un responsabile.
4. Trasformate ogni pacchetto di lavoro in attività con durate e dipendenze. Le stime le danno le persone che svolgono il lavoro, e la guida su come stimare la durata delle attività illustra i metodi. Ottenete una rete con un percorso critico e una data di fine.
5. Confrontate la fine con la data fissa. Nel convegno la riserva era di 1 giorno. Una riserva negativa vi rimanda al passo 2 per tagliare l’ambito o chiedere una data successiva, perché il GAO è esplicito: il lavoro va pianificato prima che le attività possano essere schedulate^[1].
6. Salvate la baseline e riportatene le milestone nel piano. Il GAO definisce la baseline il cronoprogramma obiettivo e la sottopone a un processo di controllo della configurazione^[1], che in un piccolo progetto significa che cambia solo attraverso la regola sulle modifiche del passo 2. Una riga del piano riporta poi le milestone e la riserva. Inviate il piano insieme al cronoprogramma a chiunque entri dopo il kick-off.

Errori comuni quando piano e cronoprogramma si confondono#

L’errore che correggeremmo per primo è il cronoprogramma fatto circolare come piano, perché il giorno in cui arriva una richiesta nessuno è in grado di mostrare cosa conteneva il brief. Cinque schemi da cercare:

• Il cronoprogramma fatto circolare come piano. Il giorno 8 nessuno può dimostrare se una terza sessione fosse mai nel brief, e la discussione si chiude a memoria.
• Ogni modifica fatta due volte, perché l’elenco delle attività è stato incollato nel documento di piano; dopo il primo aggiornamento dell’avanzamento una delle due copie è sbagliata.
• Un file .mpp importato di 140 attività la cui riga di riepilogo principale si chiama "Ambito": raggruppa attività, e nessuna esclusione è scritta da nessuna parte.
• Sezioni che nessuno apre. Eliminate qualsiasi sezione del piano che non sia stata consultata almeno una volta tra il kick-off e la chiusura.
• Nessun responsabile indicato per le modifiche, così ogni richiesta va a chi ha parlato per ultimo con il team.

Cosa non può fare ciascun documento#

Un piano non può verificare la propria scadenza; solo il cronoprogramma può farlo. Nel convegno, il percorso A richiede 22 giorni prima che l’allestimento possa iniziare, e un contratto che prometteva l’evento il giorno 20 sarebbe sembrato perfettamente sensato in un piano senza un cronoprogramma alle spalle.

Un cronoprogramma non vede il lavoro che nessuno ha messo nell’ambito. La stampa dei badge mai messa per iscritto non ha barra né margine totale. Il percorso critico viene calcolato come se i badge si stampassero da soli.

Pianificare per fasi mantiene l’ordine tra i due. Il GAO accetta una pianificazione svolta per fasi man mano che gli stakeholder conoscono più dettagli, un approccio noto come rolling wave planning, e afferma che in nessun caso la pianificazione deve essere contemporanea alla schedulazione^[1]. In un progetto pianificato a ondate, l’ambito di ogni ondata viene messo per iscritto prima che le sue attività ricevano date.

Il formato breve ha un limite. La nostra regola empirica: quando un contratto o un ente regolatore chiede un documento di piano separato, come un piano di sicurezza, il piano di progetto diventa un indice che rimanda a esso. La sezione 3 del modello di piano di progetto della NASA, sui piani di controllo del progetto, ha 29 sottosezioni, tra cui il Risk Management Plan (3.3) e il Configuration Management Plan (3.16)^[2].

Come farlo in Planitude#

Costruite il cronoprogramma nel diagramma di Gantt con dipendenze e milestone, e impostate la scadenza del progetto così che la fine prevista venga confrontata con essa. Per evitare la pagina bianca, partite da uno dei 13 modelli, che hanno già dipendenze e milestone impostate; tra questi ci sono un evento e un trasloco d’ufficio. Anche un vostro progetto può essere salvato come modello.

Verificate il risultato nella scheda Riepilogo. Confronta la fine prevista con la scadenza o con la baseline e mostra l’avanzamento pianificato rispetto a quello effettivo, con le milestone in scadenza nei prossimi 14 giorni in un elenco a parte. Planitude salva la baseline automaticamente al primo aggiornamento dell’avanzamento, così i ritardi si misurano rispetto alle date originali. Se il cronoprogramma esiste già in Microsoft Project, importate il file .mpp.

Planitude non ha un documento di piano. Tenete le esclusioni e la regola sulle modifiche in un documento condiviso e incollatene il link nelle note della milestone "sala pronta", dove lo troverà chiunque apra il cronoprogramma.

Domande frequenti#