Progetto in ritardo: come recuperare con fast-tracking, crashing e le altre leve

Prima o poi arriva a ogni project manager: il fornitore consegna tardi, un’attività chiave dura più del previsto, la data di fine non regge più. La reazione istintiva è chiedere a tutti di correre. Di rado funziona, e soprattutto elude la domanda vera: quale ritardo conta, di quanto, e qual è il modo più economico per recuperare quei giorni?

Questa guida propone un metodo ripetibile. Prima si misura il ritardo e lo si colloca rispetto al percorso critico; poi si confrontano le quattro leve che un project manager ha davvero a disposizione, e si comunica un piano invece di una giustificazione.

Misurare il ritardo prima di tutto#

“Siamo in ritardo” non è una diagnosi. Prima di scegliere il rimedio servono tre risposte, prese dal cronoprogramma e non dalle impressioni:

1. Di quanto? Lo slittamento in giorni lavorativi tra la fine prevista oggi e quella del piano approvato. Senza una baseline salvata non si può rispondere con precisione: è uno dei motivi per tenerne una (vedi la guida su baseline e scostamenti).
2. Dove? Quale attività ha generato il ritardo, e se è già conclusa, in corso o ancora da iniziare. Un ritardo già avvenuto si può solo assorbire a valle.
3. Sta ancora crescendo? Un’attività slittata una volta per un’approvazione mancante è diversa da un’attività il cui lavoro residuo aumenta settimana dopo settimana.

Il primo passo è aggiornare l’avanzamento. Un piano di recupero costruito su percentuali vecchie recupera giorni mai persi, oppure ignora giorni già bruciati.

Il ritardo è sul percorso critico?#

La data di fine dipende dal percorso critico, la catena di attività collegate senza margine. Un ritardo su un’attività critica sposta la fine giorno per giorno. Un ritardo su un’attività non critica non sposta nulla finché non consuma il suo margine totale; da lì l’attività diventa critica e ogni giorno in più spinge in avanti la fine. La guida al percorso critico spiega come si calcola il margine.

Ne deriva uno smistamento semplice:

Due conseguenze sfuggono spesso. La prima: si recupera tempo solo sulle attività ancora davanti a noi, perché comprimere un’attività finita è impossibile. La seconda: dopo ogni modifica il percorso critico può spostarsi, e un ramo che aveva cinque giorni di margine può diventare il nuovo percorso critico una volta compresso il vecchio.

Le leve di recupero#

Termini come fast tracking e crashing fanno parte del vocabolario standard della pianificazione, raccolto nel lessico dei termini di project management del PMI^[1]. In pratica le leve sono quattro.

Fast-tracking: sovrapporre il lavoro

Fare fast-tracking significa avviare un’attività prima che la precedente sia finita, anche se il piano le prevedeva in sequenza. In termini di pianificazione, un legame fine-inizio diventa un legame inizio-inizio con un ritardo, oppure il ritardo del legame esistente diventa negativo (un anticipo). Il collaudo parte sui primi moduli completati invece di aspettare l’intero sviluppo; le finiture iniziano sui piani già pronti.

Non richiede lavoro in più, ma non è gratis: il lavoro sovrapposto poggia su informazioni che possono ancora cambiare, e il prezzo tipico è la rilavorazione. Conviene sovrapporre solo dove il risultato dell’attività precedente è già abbastanza stabile, e con sovrapposizioni brevi. La guida a dipendenze e ritardi mostra come modellarle correttamente.

Crashing: più risorse sulle attività critiche

Il crashing accorcia le attività critiche aggiungendo persone, straordinari o mezzi. La regola è economica: si confrontano le opzioni per lavoro aggiuntivo per giorno recuperato, si parte dalla più conveniente e si passa alla successiva solo se servono ancora giorni.

Non tutte le attività si possono comprimere. Fred Brooks, in The Mythical Man-Month (1975), ha formulato quella che è diventata nota come legge di Brooks: aggiungere persone a un progetto software in ritardo lo fa ritardare ancora di più. Chi arriva deve imparare il contesto, e ogni persona in più aumenta il coordinamento. Il crashing funziona sul lavoro che si divide in modo netto (sessioni di formazione parallele, script di test indipendenti, aree di cantiere separate) e male su quello che una persona o un piccolo gruppo affiatato deve ragionare dall’inizio alla fine.

Ridurre il perimetro

Consegnare meno in tempo vale spesso più che consegnare tutto in ritardo. Si sposta una funzione, un report o un deliverable secondario a una fase successiva, con l’accordo esplicito di chi è responsabile dei requisiti. È una decisione di business, non un artificio di pianificazione: va messa per iscritto.

Spostare la scadenza

A volte la risposta onesta è una nuova data. Se le altre leve costano più del ritardo, o introducono rischi inaccettabili, si propone una nuova data di fine, la si fa approvare e si salva una nuova baseline. Quello che non si deve fare è lasciarla scivolare in silenzio.

Un esempio calcolato#

Un team sta introducendo un nuovo gestionale interno. La catena critica che resta è: Sviluppo, poi Collaudo (10 giorni, un tester), poi Formazione (5 giorni, un formatore), poi la milestone Avvio in produzione. Anche la Documentazione (6 giorni) parte dopo lo sviluppo e va chiusa entro l’avvio; procede in parallelo a collaudo e formazione e ha quindi 9 giorni di margine.

Un problema di integrazione ha allungato lo sviluppo di 6 giorni lavorativi. Lo sviluppo è critico, quindi l’avvio slitta di 6 giorni, oltre la data promessa alla direzione. I 9 giorni di margine della documentazione non c’entrano: il ritardo non è lì.

Le opzioni sulle attività critiche rimaste:

In ordine di costo per giorno recuperato viene prima la formazione (0,5 giorni-persona per giorno), poi il collaudo (circa 1,3 giorni-persona per giorno). Insieme recuperano 5 giorni con 5 giorni-persona in più. Il sesto giorno arriva da un giorno di sovrapposizione tra sviluppo e collaudo, accettabile perché l’ultimo giorno di sviluppo è dedicato alla documentazione del codice e non a nuove funzioni.

La verifica: dopo lo sviluppo, la catena critica richiede ora 7 + 3 − 1 = 9 giorni lavorativi invece di 15, quindi i 6 giorni sono recuperati. La documentazione richiede sempre 6 giorni e termina ampiamente entro i 9: resta non critica, con 3 giorni di margine invece di 9. Comprimendo ancora, sarebbe potuta diventare lei il nuovo percorso critico.

La riduzione del perimetro resta come piano B, se il collaudo dovesse far emergere più difetti del previsto.

Scegliere e comunicare il piano di recupero#

Un piano di recupero è una proposta rivolta a chi ha approvato il piano originale, e va presentato come tale:

• il ritardo in giorni lavorativi e la sua causa, in una frase;
• le opzioni valutate, con giorni recuperati, lavoro aggiuntivo e rischi;
• la combinazione consigliata e la data di fine che ne risulta;
• cosa serve dagli stakeholder: approvazione, budget per il lavoro in più, una decisione sul perimetro;
• la data del prossimo punto di controllo.

Prima di inviarlo, conviene verificare che:

• l’avanzamento sia aggiornato a oggi;
• il recupero agisca solo su attività non ancora concluse;
• il percorso critico sia stato ricalcolato dopo le modifiche, senza che un altro ramo sia diventato critico a vostra insaputa;
• le persone aggiunte siano davvero disponibili in quelle date e non già sovraccariche altrove;
• ogni sovrapposizione abbia un responsabile che vigila sulle rilavorazioni.

Gli errori più comuni#

• Recuperare sul ramo sbagliato. Comprimere attività con margine costa fatica e non sposta la data di fine.
• Comprimere tutto. Aggiungere persone ovunque fa crescere costi e coordinamento: si comprime solo il necessario, partendo dal più conveniente.
• Sovrapporre senza rete. Una sovrapposizione su input instabili trasforma un ritardo in rilavorazione, cioè in un ritardo più grande.
• Ignorare la legge di Brooks. Sul lavoro che non si può dividere, le persone nuove rallentano il gruppo per settimane.
• Rifare la baseline per far sparire il ritardo. Una nuova baseline è l’esito di una decisione approvata, non un modo per azzerare lo scostamento.
• Comunicare tardi. Gli stakeholder accettano molto meglio un ritardo accompagnato da un piano che una sorpresa sulla data di fine.

Come farlo in Planitude#

Le funzioni di monitoraggio di Planitude coprono la diagnosi. La baseline si salva automaticamente al primo aggiornamento dell’avanzamento e ogni barra mostra lo slittamento in giorni lavorativi. Le attività scadute, quelle indietro sul piano e quelle spostate dall’ultima visita sono segnalate, e i collegamenti diventano rossi dove un ritardo supera il margine e si propaga lungo la catena; al passaggio del mouse si vede di quanto si sposta ogni attività. Con percorso critico e margine totale visibili si capisce subito se il ritardo tocca la data di fine.

Per provare un recupero si modifica il piano e si lascia ricalcolare il motore: un legame FS diventa SS con ritardo, un’attività si accorcia dopo aver aggiunto una seconda persona, la vista Carico di lavoro segnala chi è sovraccarico. Cronologia delle versioni e annulla permettono di tornare indietro se un’opzione non funziona. L’analisi Monte Carlo indica quanto è probabile la nuova data di fine (P50, P80, P95), e la stima AI del rischio di ritardo evidenzia le attività aperte da tenere d’occhio.

Le modifiche si possono anche chiedere all’assistente AI: ogni proposta compare in anteprima e viene verificata prima di essere applicata. Quando il recupero è approvato, si salva una nuova baseline.

Domande frequenti#