Baseline di progetto e scostamenti: guida pratica

Un cronoprogramma cambia ogni settimana: attività che finiscono prima o dopo, dipendenze che spingono in avanti le date, informazioni nuove. Senza un riferimento fisso il Gantt mostra solo dove si trova il progetto oggi, non quanto si è allontanato da ciò che era stato concordato. La baseline è quel riferimento: una fotografia del piano approvato con cui si confronta ogni versione successiva.

Questa guida spiega cosa contiene una baseline, quando salvarla, come leggere gli scostamenti che produce e, soprattutto, quando una nuova baseline è legittima e quando serve solo a nascondere un ritardo.

Cos’è la baseline di progetto#

La baseline è una copia congelata del cronoprogramma nel momento in cui è stato approvato. È uno dei termini standard del project management, presente nel lessico dei termini di project management del PMI^[1]. In pratica, per ogni attività registra:

• l’inizio previsto e la fine prevista;
• la durata prevista in giorni lavorativi;
• per le attività riepilogative, gli stessi valori calcolati sulle attività sottostanti.

Molti strumenti possono salvare anche il lavoro e il costo previsti, e metodi come l’earned value management si basano su una baseline dei costi. È un altro argomento: questa guida riguarda la baseline dei tempi, quella che serve a ogni progetto.

Piano corrente e baseline convivono. Il piano corrente si muove a ogni aggiornamento dell’avanzamento; la baseline resta dov’era, e la distanza tra i due è la deriva del progetto.

Quando salvare la baseline#

Il momento giusto è dopo l’approvazione del piano e prima dell’avvio dei lavori. Salvarla prima significa congelare una bozza che cambierà ancora per motivi che non sono ritardi; salvarla dopo significa che i primi scostamenti sono già assorbiti nel riferimento.

Prima di salvarla, conviene verificare che:

• ogni attività abbia una durata realistica (la guida su come stimare la durata delle attività aiuta);
• le dipendenze siano complete, così che le date siano calcolate e non digitate a mano;
• il percorso critico abbia senso e la data di fine sia quella su cui ci si impegna;
• le milestone coincidano con le date concordate con il cliente o con la direzione;
• chi deve approvare il piano lo abbia effettivamente approvato.

Se ce ne si dimentica, uno strumento che salva la baseline in automatico al primo aggiornamento dell’avanzamento è una buona rete di sicurezza: fotografa il piano com’era nel momento in cui è partito il monitoraggio.

Scostamento di inizio, fine e durata#

Tre scostamenti descrivono come si è mossa ogni attività. Tutti si esprimono in giorni lavorativi, quindi un fine settimana tra due date non conta come ritardo.

Un valore positivo significa più tardi o più lungo; uno negativo, più presto o più breve. I tre scostamenti rispondono a domande diverse. Un’attività può partire con due giorni di ritardo perché la precedente è slittata, mantenendo esattamente la durata stimata: il problema è a monte. Un’altra può partire puntuale e finire tardi perché il lavoro era sottostimato: il problema è nell’attività stessa. Per le scadenze conta alla fine lo scostamento di fine, ma gli altri due dicono dove intervenire.

Leggere gli scostamenti: un esempio calcolato#

Prendiamo la prima fase di un progetto. La baseline è stata approvata con tre attività in sequenza: Requisiti (5 giorni), Progettazione (5 giorni) e Sviluppo (10 giorni), da lunedì 2 a venerdì 27 novembre, 20 giorni lavorativi in tutto.

Tre settimane dopo il piano corrente è questo. I Requisiti hanno richiesto due giorni in più; la Progettazione è partita con due giorni di ritardo ma ha mantenuto la sua durata; sullo Sviluppo è stato aggiunto un secondo sviluppatore e la stima è scesa da 10 a 9 giorni.

Come leggerla:

1. Si parte dalla riepilogativa. La Fase 1 finisce con 1 giorno lavorativo di ritardo (venerdì 27 diventa lunedì 30). È il numero da comunicare.
2. Si scende per trovare la causa. Il ritardo nasce nei Requisiti (durata +2) e passa alla Progettazione come scostamento di inizio di +2, senza alcuna colpa della Progettazione.
3. Si cercano le compensazioni. Lo Sviluppo recupera un giorno (durata −1), ed è per questo che la fase è in ritardo di 1 giorno e non di 2. La riepilogativa sembra quasi in salute, ma nasconde uno sforamento di 2 giorni e un recupero costato una persona in più.
4. Si controlla il percorso critico. Se dopo la Fase 1 vengono attività critiche, il +1 sposta la fine del progetto; se c’è margine sufficiente, viene assorbito. La guida al percorso critico spiega come capirlo.

Una buona abitudine settimanale è filtrare le attività con scostamento di fine maggiore di zero, ordinarle per entità e partire da quelle sul percorso critico.

Quando rifare la baseline, e quando no#

Una baseline è utile solo se resta stabile. Sostituirla ogni volta che il piano si muove azzera tutti gli scostamenti e rende invisibile la deriva. Salvare una nuova baseline è legittimo quando cambia l’impegno stesso:

• una modifica approvata del perimetro aggiunge o toglie lavoro;
• la scadenza è stata spostata formalmente, per esempio dopo aver concordato un piano di recupero (vedi come recuperare un progetto in ritardo);
• il progetto è stato sospeso e riparte con una nuova data di inizio;
• il piano originale conteneva un errore sostanziale, riconosciuto da chi lo aveva approvato.

Non è legittimo rifarla perché le attività sono in ritardo, perché il report non è presentabile prima di un comitato di indirizzo, o per abitudine ogni settimana. In quei casi lo scostamento è esattamente l’informazione di cui gli stakeholder hanno bisogno.

Lavorare con più baseline#

Conservare più baseline mantiene la storia degli impegni: il piano originale, quello dopo la prima modifica approvata, quello dopo la nuova scadenza. Ogni nuova baseline dovrebbe avere un motivo e una data, meglio se annotati nelle note del progetto.

Il confronto corrente si fa di norma con l’ultima baseline, perché è l’impegno in vigore. Le precedenti rispondono a un’altra domanda: quanto si è mosso il progetto dall’inizio, attraverso tutte le modifiche approvate. Insieme permettono di distinguere i ritardi dalle decisioni.

Gli errori più comuni#

• Non salvare mai la baseline. Senza, nessuno sa dire di quanto il progetto sia in ritardo, solo dove si trova oggi.
• Salvarla troppo presto. Una baseline presa su una bozza registra le modifiche al piano come se fossero ritardi.
• Rifarla ogni settimana. Lo scostamento è sempre zero e i ritardi spariscono dai report, non dal progetto.
• Guardare solo la riepilogativa. Gli scostamenti sottostanti che si compensano possono nascondere sforamenti e recuperi da tenere d’occhio.
• Contare i giorni di calendario. Uno slittamento da venerdì a lunedì vale un giorno lavorativo, non tre.
• Digitare le date a mano. Le date fisse non si muovono con le attività precedenti, e gli scostamenti smettono di riflettere la catena reale dei ritardi.

Come farlo in Planitude#

In Planitude la baseline si salva automaticamente al primo aggiornamento dell’avanzamento, quindi il monitoraggio non parte mai senza un riferimento. Se ne può salvare una in qualsiasi momento con Salva baseline, oppure chiederlo all’assistente AI. Tutte le baseline vengono conservate e il confronto avviene con l’ultima.

La baseline compare come barra grigia sotto ogni attività del diagramma di Gantt, e lo slittamento è indicato in giorni lavorativi (per esempio +3g), riepilogative comprese. Le funzioni di monitoraggio segnalano le attività scadute, quelle indietro sul piano e quelle spostate dall’ultima visita, e i collegamenti diventano rossi quando un ritardo supera il margine e si propaga alle attività successive.

Sull’insieme dei progetti, la vista portfolio mostra lo scostamento dalla baseline e uno stato automatico per ciascun progetto: in linea, a rischio o in ritardo. Chi arriva da Microsoft Project può importare il piano e continuare a lavorarci.

Domande frequenti#