Per me, il vero valore del project management sta nel riconoscere che qualcosa si sta allontanando dalle aspettative mentre c'è ancora tempo per prendere una decisione. Uno studio accademico intitolato Dynamic Prediction of Delays in Software Projects using Delay Patterns and Bayesian Modeling, disponibile anche in una versione open access su arXiv, parte esattamente da questa idea.

Lo studio mostra come modelli aggiornati continuamente possano prevedere i ritardi già nelle prime fasi del progetto. Invece di affidarsi soltanto alla stima elaborata all'inizio, il rischio viene ricalcolato man mano che diventano disponibili nuovi dati sull'esecuzione e sulle prestazioni del team. Questo approccio mi sembra molto più vicino alla realtà, perché nessun progetto rimane esattamente uguale dopo il suo avvio.

1. La scadenza prevista inizia ad allontanarsi dalla baseline di progetto

La baseline di progetto è il riferimento che mostra come il progetto avrebbe dovuto evolvere. Comprende date, milestone, durate e deliverable approvati durante la pianificazione. Quando la previsione attuale inizia ad allontanarsi da quel riferimento, abbiamo uno dei primi segnali che l'esecuzione non sta più seguendo il piano originale.

Questo scostamento può manifestarsi in modi diversi. La data finale prevista può essere spostata continuamente in avanti, le milestone possono iniziare a essere completate più tardi del previsto oppure il team può consegnare meno lavoro di quanto atteso in un determinato periodo. Nella gestione dell'earned value, lo Schedule Variance mostra una situazione sfavorevole quando il valore del lavoro eseguito è inferiore a quello pianificato, mentre uno Schedule Performance Index, o SPI, inferiore a 1 indica che il progetto sta avanzando a un ritmo più lento del previsto. La guida del Department of Energy degli Stati Uniti sull'Earned Value Management spiega questi indicatori in modo più approfondito.

Non considero un singolo risultato sfavorevole sufficiente per dichiarare che un progetto è in ritardo. Ciò che mi preoccupa è la tendenza. Se lo SPI rimane sotto 1, lo Schedule Variance continua a essere sfavorevole e la previsione di completamento viene rivista più volte, il progetto sta producendo prove del fatto che il piano originale non rappresenta più la realtà dell'esecuzione.

Nel Saint Jude, il Modulo Progetto confronta continuamente ciò che era stato pianificato con ciò che è stato effettivamente consegnato. Questo confronto aiuta a identificare quali attività stanno contribuendo allo scostamento, quali deliverable sono in ritardo e quando la differenza tra piano ed esecuzione inizia a minacciare la scadenza finale.

2. Il margine del percorso critico inizia a ridursi

Non tutte le attività in ritardo hanno lo stesso impatto. Un'attività può subire qualche giorno di ritardo e avere ancora abbastanza margine per consentire al progetto di terminare nei tempi previsti. Un'altra attività, apparentemente piccola, può invece trovarsi sul percorso critico e determinare direttamente il momento in cui un deliverable potrà essere completato.

Per questo non mi piace analizzare il cronoprogramma semplicemente contando quante attività sono in ritardo. Dieci attività in ritardo possono avere un impatto limitato se dispongono ancora di margine. Una sola attività critica, invece, può bloccare altri team, consumare tutto il margine disponibile e modificare la data finale del progetto.

La Schedule Assessment Guide del Government Accountability Office spiega l'importanza di strutturare correttamente dipendenze, durate e attività che controllano il completamento del progetto. Ho approfondito questo tema anche nell'articolo Metodo del percorso critico: come prevedere i ritardi.

Per me, il punto più importante è capire che il percorso critico, chiamato anche cammino critico, non è una fotografia scattata all'inizio del progetto. Un'attività che prima aveva margine può iniziare a consumarlo. Una dipendenza può diventare più rischiosa. Una variazione nella durata può fare in modo che un altro percorso diventi quello che controlla la consegna. Il cronoprogramma deve seguire la realtà, perché la realtà continua a cambiare.

Nel Saint Jude, il Modulo di Pianificazione aiuta a seguire le relazioni tra attività, milestone e possibili conseguenze di un ritardo. In questo modo il project manager può concentrare l'attenzione sul lavoro che può realmente modificare la data finale, invece di trattare ogni attività come se avesse la stessa importanza.

3. Il lavoro in corso (WIP) cresce oltre la capacità del team

C'è una situazione che vedo spesso nei progetti: la board è piena di attività in corso, ma pochissime vengono completate. A prima vista può sembrare produttività. Molte persone sono impegnate e diverse attività sono state avviate. Nella pratica, però, un eccesso di lavoro in corso può indicare che il team è sovraccarico e fatica a portare a termine ciò che ha iniziato.

Il WIP, o Work in Progress, rappresenta la quantità di lavoro aperto o in esecuzione. Quando cresce oltre la capacità reale del team, aumentano i cambi di contesto, le interruzioni e i tempi di attesa tra una fase e l'altra. Le persone iniziano molte attività, ma impiegano più tempo per completare ciascuna di esse. La guida della Kanban University presenta la limitazione del lavoro in corso come una pratica importante per migliorare il flusso.

Ciò che mi interessa non è semplicemente sapere quante attività sono aperte. Voglio capire quante stanno avanzando davvero, quante dipendono dalle stesse persone, quali sono bloccate e se il volume di lavoro cresce più rapidamente della capacità del team di completarlo. Quando inizia a formarsi una coda di attività, il ritardo può non essere ancora visibile nel cronoprogramma, ma si sta già formando nel flusso di lavoro.

Nel Saint Jude, il Modulo Prestazioni e Capacità del Team confronta il lavoro in corso con la capacità effettiva osservata. Questa analisi aiuta a identificare sovraccarichi, concentrazione delle attività su determinate persone e situazioni in cui il team sembra occupato, ma non riesce a trasformare lo sforzo in deliverable completati. Per approfondire il tema, puoi consultare anche il nostro articolo sugli indicatori di produttività per misurare e migliorare le performance del team.

4. Il lead time e il tempo di ciclo diventano più lunghi e meno prevedibili

Il lead time mostra quanto tempo impiega una richiesta dal momento in cui entra nel flusso fino al suo completamento. Il tempo di ciclo, chiamato anche cycle time, misura il periodo che va dall'inizio effettivo del lavoro alla sua conclusione. Mi piacciono questi indicatori perché mostrano come si comportano realmente le consegne, e non soltanto ciò che era stato stimato durante la pianificazione.

Quando lead time e cycle time iniziano ad aumentare, il team impiega più tempo per completare attività simili. Quando diventano anche meno prevedibili, il problema è ancora maggiore: anche se la media sembra accettabile, alcune attività iniziano a richiedere molto più tempo delle altre. La Kanban University presenta il lead time come un indicatore importante della prevedibilità.

Un team può continuare a consegnare e, allo stesso tempo, perdere prevedibilità. Gli sprint terminano, ma le attività richiedono sempre più tempo. Le stime devono essere riviste frequentemente e le date future iniziano a dipendere da una capacità che non si comporta più come prima. Per me, questo è un segnale che compare prima che il ritardo diventi ufficialmente visibile.

Nel Modulo Progetto di Saint Jude, verifichiamo la produttività a ogni sprint e osserviamo come le performance di consegna evolvono nel tempo. Questa analisi aiuta a capire quando il flusso sta rallentando, quando il team consegna meno di quanto pianificato e quando le previsioni future non dovrebbero più utilizzare le stesse ipotesi dell'inizio del progetto.

5. I cambiamenti dei requisiti e dell'ambito continuano dopo l'avvio del progetto

I cambiamenti di ambito fanno parte della realtà di molti progetti. Un nuovo requisito può emergere perché il cliente ha imparato qualcosa durante l'esecuzione, perché è stato scoperto un vincolo tecnico o perché è cambiata una priorità strategica. Il problema non è necessariamente il cambiamento in sé, ma la mancanza di visibilità sul suo impatto.

Quando i requisiti continuano a cambiare dopo l'inizio del lavoro, le attività possono perdere chiarezza, le stime smettono di rappresentare lo sforzo reale e il team inizia a lavorare su qualcosa di diverso da ciò che era stato pianificato. Un'attività può sembrare piccola, ma dover essere riaperta più volte perché il suo obiettivo o i criteri di accettazione non sono ancora chiari.

La documentazione della NASA sulla volatilità dei requisiti mostra come i cambiamenti frequenti possano influire sulla stabilità dello sviluppo. Nella mia esperienza, questo è anche uno dei segnali più difficili da riconoscere, perché il cronoprogramma può continuare a essere aggiornato mentre il progetto accumula lavoro che non faceva parte del piano originale.

Nel Modulo Progetto di Saint Jude, analizziamo se le attività sono sufficientemente chiare e se le loro stime sono allineate con attività simili già completate. Questo confronto aiuta a identificare attività generiche, stime fuori dal normale andamento e situazioni in cui i cambiamenti di ambito stanno aumentando lo sforzo necessario senza che il management lo veda con chiarezza.

6. Dipendenze, attività bloccate e tempi di attesa iniziano ad accumularsi

Non tutte le attività in ritardo sono in ritardo perché il team ha smesso di lavorare. Spesso stanno aspettando un'approvazione, un'informazione, un altro team, un fornitore, un ambiente tecnico o una decisione del cliente. Quando questo tempo di attesa non è visibile, può essere interpretato come una bassa produttività individuale, anche se il problema sta nel modo in cui il lavoro è collegato.

Una dipendenza, da sola, non è necessariamente un rischio. Se il team da cui dipendiamo sta avanzando normalmente, ha capacità sufficiente e c'è ancora margine nel cronoprogramma, la dipendenza può essere sotto controllo. Il rischio cambia quando la stima viene rivista, l'attività si blocca, la persona responsabile è sovraccarica o il deliverable successivo non ha più margine sufficiente per aspettare.

Il materiale del GAO sulle interdipendenze e sul percorso critico mostra come le relazioni tra attività possano influire sul cronoprogramma. Una breve attesa su un'attività può propagarsi a diverse altre, soprattutto quando esiste una sequenza di attività dipendenti o quando team diversi devono lavorare in un ordine specifico.

È anche questo il momento in cui il rischio di ritardo deve essere rivalutato continuamente. La stima iniziale può essere stata adeguata quando il progetto è iniziato, ma nuovi blocchi, variazioni delle prestazioni e tempi di attesa accumulati modificano la probabilità di completamento. Non ha senso guardare al rischio solo perché è stato registrato all'inizio. Dobbiamo osservare ciò che sta accadendo adesso.

Nel Modulo Rischi di Saint Jude, i rischi vengono valutati continuamente in modo proattivo dalla nostra Intelligenza Artificiale. Quando viene identificato un possibile problema, le possibili mitigazioni vengono assegnate automaticamente all'utente responsabile sulla piattaforma. L'obiettivo è permettere al team di affrontare il rischio mentre c'è ancora tempo per agire, prima che una dipendenza diventi un ritardo concreto.

7. Aumentano rilavorazioni, difetti e problemi di qualità

Un progetto può continuare a registrare attività completate e, allo stesso tempo, avvicinarsi a un ritardo. Questo accade quando una parte del lavoro deve essere rifatta. Un'attività viene chiusa, ma torna in sviluppo. Un deliverable viene inviato per la validazione, ma rientra con nuovi problemi. Una modifica provoca una regressione e costringe il team a correggere qualcosa che avrebbe già dovuto essere terminato.

La rilavorazione consuma capacità che non era stata inclusa nella stima originale. Il team continua a essere impegnato, ma una quota sempre maggiore dello sforzo viene destinata a correzioni, revisioni e attività riaperte. Con il tempo, le nuove attività iniziano ad accumularsi, il cycle time aumenta e il progetto produce meno valore di quanto il volume di lavoro eseguito potrebbe far pensare.

Il Software Engineering Institute sottolinea l'importanza di utilizzare i dati del flusso di sviluppo per comprendere la qualità e l'efficienza delle consegne. Anche le ricerche sui fattori che influenzano la consegna nei tempi previsti, come lo studio pubblicato dall'IEEE, confermano che i problemi di qualità e la rilavorazione possono compromettere la prevedibilità.

Per me, il segnale principale non è un difetto isolato. Ciò che merita attenzione è quando attività simili iniziano a essere riaperte più spesso, quando aumenta il numero di correzioni o quando lo sforzo necessario per completare un deliverable cresce anche se l'ambito non è cambiato. A quel punto il team può generare molta attività, ma pochissimo progresso reale.

In Saint Jude, gli indicatori di performance possono essere analizzati insieme ai dati del progetto per identificare quando lo sforzo viene consumato da rilavorazioni, revisioni o attività che non avanzano verso una conclusione definitiva. Questa visione aiuta a capire non solo quanto è stato fatto, ma quanto lavoro si è realmente trasformato in un deliverable accettato.

Il problema è la combinazione dei segnali

Nessuno di questi segnali, preso singolarmente, dimostra che un progetto subirà un ritardo. Uno SPI inferiore a 1 può rappresentare una variazione temporanea. Un aumento del lead time può essere legato a un'attività eccezionalmente complessa. Un cambiamento di ambito può essere necessario per proteggere il risultato del progetto. Ciò che mi preoccupa è quando diversi segnali iniziano a comparire contemporaneamente.

Quando la scadenza prevista si allontana dalla baseline, il margine del percorso critico diminuisce, il WIP cresce, le consegne diventano più lente, i requisiti continuano a cambiare e i blocchi si accumulano, il progetto ci sta raccontando una storia. Il ritardo potrebbe non essersi ancora verificato ufficialmente, ma i dati stanno già mostrando che il modo attuale di lavorare potrebbe non essere sufficiente per rispettare il piano.

Per questo non credo in un project management basato soltanto su report statici o riunioni di stato. Un report mostra ciò che è successo. Una riunione può aiutare a discutere ciò che sta succedendo. Ma dobbiamo anche interpretare ciò che i dati indicano su quello che potrebbe accadere tra qualche settimana. La gestione dei rischi di progetto deve aggiornarsi con la realtà dell'esecuzione, non rimanere legata alla stima iniziale.

Come l'intelligenza artificiale per la gestione dei progetti aumenta il tempo a disposizione per reagire

Non credo che esista una piattaforma capace di eliminare ogni rischio da un progetto. Le persone cambiano, i fornitori sono in ritardo, le stime sono sbagliate, i clienti modificano le priorità e le decisioni importanti possono richiedere più tempo del previsto. L'incertezza farà sempre parte del lavoro di gestione.

La differenza sta nel momento in cui ci accorgiamo che qualcosa si sta allontanando dalla direzione pianificata. Se scopriamo il problema il giorno in cui il deliverable dovrebbe essere consegnato, le nostre opzioni sono limitate. Se individuiamo il rischio qualche settimana prima, potremmo ancora redistribuire la capacità, modificare una priorità, dividere l'ambito, negoziare una dipendenza o creare un piano di mitigazione.

Saint Jude non sostituisce strumenti come Jira, Azure DevOps, ClickUp, Monday.com o Asana. Queste piattaforme rimangono fondamentali per organizzare ed eseguire il lavoro. Saint Jude opera a un livello diverso: utilizza i dati già prodotti dai progetti per aiutare project manager, PMO e leadership a comprendere la salute dei progetti, identificare pattern e prendere decisioni con maggiore anticipo.

Alla fine, prevedere i ritardi non significa indovinare il futuro. Significa osservare il presente con sufficiente attenzione per riconoscere quando il comportamento del progetto inizia ad allontanarsi dalle aspettative. Significa capire che un'attività in ritardo può essere una semplice variazione oppure l'inizio di una reazione a catena.

E forse questa è la domanda più importante: nel tuo progetto aspetti che la data venga mancata prima di agire, oppure riesci già a identificare i segnali che indicano che potrebbe essere mancata?

A presto!

Erik Scaranello