Cos'è il metodo del percorso critico?

Il metodo del percorso critico, conosciuto anche come Critical Path Method o CPM, è una tecnica utilizzata per analizzare la sequenza delle attività di un progetto e identificare quali di esse ne determinano la durata. Per farlo, dobbiamo conoscere le attività, le loro durate e, soprattutto, le relazioni logiche che esistono tra di esse.

Il PMI spiega molto bene questa costruzione nei suoi materiali sulla pianificazione. In Moving from the WBS to a Critical Path Schedule , per esempio, viene mostrata la sequenza logica che parte dai deliverable del progetto, passa attraverso l'identificazione delle attività, delle dipendenze e delle durate, fino ad arrivare alla costruzione del percorso critico.

Questo significa che una pianificazione non dovrebbe essere semplicemente una lista come questa:

• Attività A — dal 1° al 5 maggio;
• Attività B — dal 6 al 10 maggio;
• Attività C — dall'11 al 15 maggio.

Le date sono importanti, ma raccontano soltanto una parte della storia. Voglio anche sapere perché B viene dopo A, se B dipende realmente da A e cosa succede a C se B non termina nella data prevista.

In un altro materiale, Critical Path Method Calculations , il PMI entra più nel dettaglio della logica del CPM e mostra come le relazioni tra attività, durate, date di inizio e fine e valori di float vengano utilizzati per calcolare il percorso critico.

Qui emerge una delle prime conclusioni importanti: un'attività in ritardo non significa automaticamente che il progetto sia in ritardo. Allo stesso modo, un'attività completata nei tempi previsti non significa automaticamente che il progetto sia in buona salute. Tutto dipende dalla posizione che quell'attività occupa nella rete del progetto e dall'impatto che una sua variazione può provocare sulle attività successive.

Prima del percorso critico dobbiamo capire le dipendenze tra le attività

Per identificare un percorso critico sufficientemente affidabile, dobbiamo prima comprendere le dipendenze tra le attività. Una dipendenza esiste quando l'inizio o la conclusione di un'attività è collegato all'inizio o alla conclusione di un'altra.

È un concetto semplice, ma estremamente importante. Pensiamo, per esempio, a un team che deve completare lo sviluppo di un'API prima che un altro team possa iniziare un'integrazione. Fino a quando quell'API non sarà disponibile, la seconda attività potrebbe semplicemente non avere le condizioni necessarie per procedere.

La guida di Atlassian sulle dipendenze nei progetti affronta proprio questo tipo di relazione e mostra come le dipendenze possano influenzare la sequenza del lavoro, le risorse e la pianificazione. Anche Asana dispone di una guida completa sulle dipendenze nei progetti , che include dipendenze logiche, di risorse, preferenziali ed esterne.

Sebbene le classificazioni possano cambiare a seconda del contesto, esiste una struttura tecnica classica per rappresentare le relazioni di precedenza tra le attività. In questa struttura troviamo quattro tipi principali: Finish-to-Start, Finish-to-Finish, Start-to-Start e Start-to-Finish.

I quattro tipi di dipendenza tra le attività

La relazione più comune è la Finish-to-Start — Fine-Inizio. Un'attività deve terminare prima che quella successiva possa iniziare. È il caso, per esempio, di uno sviluppo che deve essere completato prima che possano iniziare determinati test.

In una relazione Finish-to-Finish — Fine-Fine, la conclusione di un'attività è collegata alla conclusione di un'altra. Nella relazione Start-to-Start — Inizio-Inizio, l'inizio di una determinata attività dipende dall'inizio di un'altra. La quarta possibilità, Start-to-Finish — Inizio-Fine, è meno comune e si verifica quando un'attività non può terminare fino a quando un'altra non è iniziata.

La stessa documentazione di Asana sulle dipendenze tra le attività utilizza queste relazioni per spiegare come le task possano bloccare o dipendere l'una dall'altra.

Per me, però, è più importante comprendere il principio che sta dietro a queste relazioni piuttosto che memorizzarne semplicemente i nomi: un'attività può modificare il momento in cui un'altra attività riesce a iniziare o terminare. Quando molte di queste relazioni vengono concatenate, un problema apparentemente piccolo può propagarsi attraverso una parte significativa del progetto.

Come identificare il percorso critico di un progetto?

Non voglio trasformare questo articolo in una lezione sul calcolo della pianificazione, perché non è questo il nostro obiettivo. Ma dobbiamo capire almeno a livello concettuale come arriviamo a identificare il percorso critico.

Prima dobbiamo conoscere le attività necessarie per produrre i deliverable del progetto. Successivamente identifichiamo le dipendenze tra queste attività e stimiamo le loro durate. Con queste informazioni possiamo costruire una rete logica, individuare i diversi percorsi che portano dall'inizio alla fine del progetto e calcolare quanto tempo richiede ciascuna sequenza.

In modo molto semplificato, immaginiamo di avere tre possibili percorsi:

• A → B → C → consegna = 20 giorni;
• D → E → consegna = 12 giorni;
• F → G → H → consegna = 16 giorni.

Se nessun altro elemento interferisce con la pianificazione, la sequenza A → B → C merita particolare attenzione perché è quella che determina la durata della consegna. Il PMI spiega che le attività del percorso critico hanno poco o nessun margine per subire ritardi senza influenzare la conclusione del progetto. In Moving from the WBS to a Critical Path Schedule , questa relazione tra dipendenze, durata, margine e percorso critico viene affrontata in modo particolarmente chiaro.

Questo non significa che possiamo semplicemente ignorare tutte le altre attività. Un'attività che oggi dispone di margine può iniziare a consumarlo e diventare successivamente critica. Inoltre, i progetti reali coinvolgono risorse condivise, fornitori, modifiche allo scope, decisioni tecniche, approvazioni, team diversi e decine di altre variabili capaci di modificare ciò che avevamo pianificato.

È proprio per questo motivo che non mi piace considerare la pianificazione come una fotografia. Il piano è un modello che deve essere continuamente monitorato durante l'esecuzione, perché la realtà del progetto continua a cambiare.

Una dipendenza non è necessariamente un rischio

Qui esiste una distinzione che considero molto importante: dipendenza e rischio non sono la stessa cosa.

Immaginiamo ancora una volta che un team debba completare un'API prima che un altro team possa iniziare un'integrazione. La dipendenza esiste. Ma se l'API sta procedendo normalmente, dispone di una stima affidabile, il team ha capacità sufficiente e abbiamo ancora margine prima dell'inizio dell'integrazione, probabilmente quella dipendenza non rappresenta una minaccia significativa in quel momento.

Ora immaginiamo una situazione diversa. L'API dovrebbe essere quasi completata, ma la sua stima è già stata modificata due volte. Esistono subtask che non sono ancora state stimate, la persona responsabile è coinvolta contemporaneamente in altre consegne, lo sprint sta completando meno lavoro rispetto a quanto pianificato e l'integrazione che dipende dall'API non dispone praticamente di alcun margine.

La dipendenza è esattamente la stessa. Il rischio associato a quella dipendenza è completamente diverso.

È proprio qui che la discussione sulle dipendenze comincia ad avvicinarsi alla gestione dei rischi. Un materiale del PMI che considero particolarmente interessante è Project Interdependency Management . Il lavoro presenta un approccio per identificare, validare, analizzare, monitorare e comunicare le interdipendenze esterne tra progetti, trattandole all'interno del più ampio universo dei rischi.

L'aspetto che considero più interessante di questo approccio è che una dipendenza non viene semplicemente identificata all'inizio del progetto per poi essere dimenticata. Deve continuare a essere monitorata, perché anche ciò da cui dipendiamo cambia nel corso del tempo.

Il problema non è soltanto la dipendenza. È l'effetto a catena.

Forse una delle cose più pericolose nella gestione dei progetti è analizzare ogni attività individualmente. Immaginiamo che A permetta l'inizio di B. B permetta l'inizio di C e D. C debba terminare prima che E possa iniziare, mentre D deve terminare prima dell'inizio di F. Alla fine, E e F sono entrambe necessarie per una consegna importante al cliente.

Se A subisce un ritardo, l'informazione “A è in ritardo di due giorni” non è sufficiente per farmi comprendere realmente il problema. Voglio sapere fino a dove quei due giorni possono propagarsi. Voglio capire quanto margine esiste nelle attività successive, quali attività verranno influenzate, quali team dipendono dalla consegna e se quel ritardo può arrivare fino alla data finale del progetto.

Questo è uno dei motivi per cui considero pericoloso valutare la salute di un progetto semplicemente contando quante attività sono in ritardo. Dieci task in ritardo potrebbero avere un impatto minimo sulla consegna. Una sola attività critica in ritardo potrebbe compromettere l'intero progetto.

Anche il PMI, in Scheduling High-Tech Projects , affronta uno dei limiti di una lettura puramente deterministica del percorso critico: quando esiste incertezza nelle stime, percorsi diversi possono acquisire criticità. In altre parole, ciò che oggi sembra essere la sequenza principale del progetto non dovrebbe essere analizzato senza considerare anche i rischi presenti nelle attività.

Il rischio dovrebbe essere individuato prima del ritardo

È qui che, secondo me, la discussione diventa ancora più interessante. Il PMI ha pubblicato un materiale chiamato Risk-Based Scheduling and Analysis , che propone di analizzare i rischi a livello delle singole attività, adattare la pianificazione considerando queste incertezze e successivamente verificare come il rischio possa modificare lo stesso percorso critico.

Il principio continua a essere estremamente attuale: non dovremmo aspettare che un ritardo si verifichi prima di iniziare ad analizzare il rischio associato a quella determinata attività.

Eppure, molto spesso facciamo esattamente il contrario. Prima una task va in ritardo. Poi qualcuno scopre che un'altra attività non è riuscita a iniziare. Successivamente compare una deviazione nella pianificazione, lo stato del progetto passa da verde a giallo, qualcuno registra un rischio e soltanto allora iniziamo a discutere un piano di mitigazione.

Il problema di questa sequenza è abbastanza evidente: quando un'attività che dipendeva da quella precedente non è già più riuscita a iniziare, forse non stiamo più parlando soltanto di un rischio. Il problema ha già iniziato a manifestarsi.

Come possiamo scoprire in anticipo che un'attività potrebbe subire un ritardo?

È qui che credo sia necessario allontanarsi un po' da una visione puramente statica della pianificazione e iniziare a osservare il comportamento reale del progetto. Se un'attività critica dovrebbe terminare tra due settimane, non voglio aspettare due settimane per scoprire se avremo un problema. Voglio cercare dei segnali durante l'esecuzione.

Posso iniziare verificando se l'attività è ferma da troppo tempo, se lo sforzo già utilizzato è molto vicino o superiore alla stima, se la stima è stata modificata durante l'esecuzione oppure se esistono attività importanti che non sono ancora state stimate. Posso anche osservare se il volume del lavoro in corso sta crescendo troppo, se esistono blocchi, se una singola persona sta concentrando troppe attività o se la velocità del team sta diminuendo.

Nei team Agile esistono altri segnali interessanti. Ciò che viene realmente completato nello sprint potrebbe essere sempre più distante da ciò che era stato pianificato. Attività simili potrebbero richiedere sistematicamente più tempo rispetto alle stime. Bug e regressioni potrebbero aumentare, generando rilavorazioni. Determinate tipologie di attività potrebbero iniziare a consumare molto più effort rispetto a quanto accadeva in passato.

Nessuno di questi indicatori, analizzato singolarmente, dimostra che l'attività andrà necessariamente in ritardo. Ma molti segnali che si verificano contemporaneamente possono iniziare a raccontare una storia.

È lo stesso principio che utilizzo quando parlo di produttività. Come ho spiegato nell'articolo Indicatori di produttività: KPI e metriche per misurare e migliorare le performance del team , osservare un singolo KPI raramente è sufficiente per comprendere il comportamento di un team. Dobbiamo analizzare il contesto e la combinazione dei dati.

Alcune dipendenze dovrebbero essere individuate prima ancora che la task inizi

Esiste poi un altro problema: molte dipendenze vengono individuate troppo tardi perché l'attività è già iniziata senza che qualcuno abbia verificato se fosse realmente pronta per essere eseguita.

Immaginiamo di scoprire durante lo sviluppo che abbiamo bisogno di un'API che ancora non esiste, di un'approvazione che nessuno ha mai richiesto, di una definizione del cliente che non abbiamo mai ottenuto o dell'intervento di un altro team che non sapeva nemmeno che dipendevamo da lui. Tecnicamente abbiamo individuato una dipendenza. Nella pratica, però, l'abbiamo individuata troppo tardi.

Per questo motivo, quando lavoro con una Definition of Ready, una delle domande che considero importanti è proprio se le principali dipendenze della task siano già state identificate. È uno dei temi che approfondisco nell'articolo Definition of Done e Definition of Ready: cosa sono, differenze ed esempi .

Prima conosciamo una dipendenza importante, più opzioni abbiamo a disposizione. Possiamo modificare la sequenza di esecuzione, parlare con un altro team, richiedere prima un'approvazione, preparare un'alternativa tecnica oppure decidere che quella task non dovrebbe ancora entrare nello sprint.

La mappatura delle dipendenze aiuta a rendere visibile ciò che normalmente rimane nascosto

Una pratica interessante per rendere queste relazioni più visibili è il dependency mapping. Atlassian dispone di un esercizio specifico chiamato Dependency Mapping , la cui proposta è individuare ciò che potrebbe ostacolare il successo di un'iniziativa, capire come il lavoro di un team possa influenzare altre parti dell'organizzazione e creare azioni prima che questi problemi si verifichino.

Il concetto è importante perché una dipendenza non esiste soltanto tra due ticket. Possiamo dipendere da un altro team, da una persona specifica, da un'approvazione, da un fornitore, da un'API, dall'infrastruttura, da una decisione architetturale, da una definizione del cliente, da un altro progetto oppure persino da una decisione executive.

Anche Asana, nella sua guida alle dipendenze di progetto , evidenzia come le dipendenze possano riguardare risorse e fattori esterni oltre alle relazioni puramente logiche. Questo è importante perché non tutti i rischi diventano visibili semplicemente disegnando una freccia tra due attività all'interno di una board.

Mappare queste relazioni migliora notevolmente la visibilità del progetto, ma lascia ancora una seconda domanda senza risposta: come possiamo capire quali di queste dipendenze stanno iniziando a diventare pericolose?

Una dipendenza può essere trattata come un rischio prima di diventare un problema

Questo approccio compare anche al di fuori del PMI. In How to Manage Dependencies and Assess Risks , Tempo propone di considerare determinate dipendenze come possibili rischi, permettendo al team di intervenire prima che si trasformino in problemi concreti.

Mi piace questa logica perché modifica il modo in cui affrontiamo la situazione. Invece di limitarci a registrare “il Team B dipende dalla consegna del Team A”, iniziamo a domandarci qual è la situazione del Team A, quando quella capacità deve essere disponibile, quali segnali stanno indicando una possibile difficoltà e quale sarà l'impatto sulla nostra consegna se ciò da cui dipendiamo non arriverà come previsto.

È un piccolo cambiamento nel modo di formulare la domanda, ma può avere un impatto enorme sulla capacità di gestione. Una dipendenza smette di essere semplicemente una linea che collega due attività e diventa qualcosa la cui salute deve essere continuamente monitorata.

La board conosce le task. Ma chi sta guardando il progetto?

Jira, Azure DevOps, Asana, Monday.com e ClickUp svolgono un ruolo estremamente importante. È all'interno di queste piattaforme che i team registrano attività, responsabili, stime, sprint, status, date, dipendenze e gran parte delle informazioni relative all'esecuzione del lavoro.

Il problema emerge quando il progetto cresce. Possiamo avere centinaia o migliaia di attività distribuite tra diversi team, progetti e tipologie di lavoro. In uno scenario del genere, individuare una task già in ritardo non è necessariamente difficile. La domanda difficile è un'altra:

“Cosa sta succedendo oggi che potrebbe far ritardare la mia consegna tra tre settimane?”

Per rispondere a questa domanda non voglio guardare soltanto la data finale di una task. Voglio capire come quell'attività sta evolvendo, come si sono comportate attività simili, se il team sta consegnando ciò che aveva pianificato, se esistono problemi nelle stime, se il lavoro è concentrato su poche persone, se stanno comparendo segnali di rilavorazione e se iniziano a emergere deviazioni significative di effort, produttività o costo.

In altre parole, la board continua a essere fondamentale per organizzare il lavoro. Ma esiste una differenza tra monitorare delle task e interpretare ciò che i dati di quelle task ci stanno dicendo sulla salute del progetto.

È qui che entra Saint Jude Project Intelligence

Questo è esattamente uno dei motivi per cui abbiamo creato il modulo rischi di Saint Jude Project Intelligence .

Saint Jude non è stato creato per sostituire Jira, Azure DevOps, Asana, Monday.com o ClickUp. Queste piattaforme continuano a essere il luogo in cui i team organizzano ed eseguono il lavoro. Saint Jude opera su un livello differente: utilizza i dati di questi progetti per aiutare project manager, PMO e leadership a interpretare ciò che sta succedendo e individuare segnali che potrebbero richiedere attenzione.

Nel modulo rischi, il manager può strutturare e monitorare i rischi del progetto e mantenere uno storico della loro evoluzione. Ma esiste una parte che considero ancora più interessante: l'intelligenza artificiale di Saint Jude può analizzare l'avanzamento reale del progetto per generare rischi e suggerire piani d'azione sulla base delle informazioni individuate.

Questo significa che segnali come uno sprint che consegna meno di quanto pianificato, attività senza stime, problemi nella qualità con cui le task sono state descritte, differenze significative tra effort e valore consegnato o altri pattern rilevati durante l'esecuzione possono smettere di essere informazioni disperse tra decine o centinaia di ticket e diventare parte di un'analisi del rischio.

Il manager mantiene comunque l'autonomia di creare manualmente i propri rischi e piani d'azione, perché non tutti i rischi esistono all'interno di una board. Esistono decisioni politiche, cambiamenti strategici, informazioni provenienti dal cliente, negoziazioni commerciali e fattori esterni che nessuna integrazione può individuare completamente da sola.

L'obiettivo non è togliere la decisione al manager. È offrirgli più informazioni e, soprattutto, più tempo per decidere.

La differenza tra identificare un rischio e spiegare un ritardo

Per me esiste una differenza enorme tra dire “il progetto è andato in ritardo perché l'attività X è terminata otto giorni dopo il previsto” e dire “l'attività X sta mostrando segnali che potrebbero compromettere la prossima consegna”.

La prima frase è utile. Spiega il passato e può aiutarci a evitare che lo stesso problema si ripeta. È esattamente il tipo di analisi di cui parlo anche nell'articolo Come trovare la causa radice dei problemi del tuo progetto .

Ma la seconda frase ha una caratteristica diversa: permette ancora di prendere una decisione prima che si verifichi la conseguenza. Potrei riuscire a cambiare una priorità, riallocare una persona, dividere lo scope, parlare con un altro team, rinegoziare una dipendenza oppure informare uno stakeholder prima che il problema diventi una sorpresa.

Project Intelligence non elimina i rischi. Aumenta il tempo che hai per reagire.

Non credo che esista una piattaforma, una metodologia o un manager capace di eliminare tutti i rischi di un progetto. I progetti contengono incertezza. Le persone cambiano, le stime possono essere sbagliate, i fornitori possono ritardare, le priorità vengono modificate, i clienti cambiano idea e le tecnologie possono fallire. Le dipendenze continueranno a esistere indipendentemente dallo strumento che utilizziamo.

La differenza sta nel momento in cui scopriamo che qualcosa sta iniziando ad andare nella direzione sbagliata.

Se scopro un problema nel momento in cui la consegna avrebbe dovuto avvenire, ho poche possibilità. Se lo individuo alcune settimane prima, forse posso cambiare una priorità, riallocare professionisti, ridurre o dividere lo scope, rinegoziare una dipendenza, modificare la sequenza del lavoro, coinvolgere un altro team oppure creare un piano di mitigazione.

Alla fine, la gestione dei rischi è anche gestione del tempo disponibile per prendere decisioni.

E forse questa è una delle principali differenze tra monitorare una pianificazione e comprendere realmente un progetto. Il metodo del percorso critico ci aiuta a identificare quali sequenze di attività determinano le nostre consegne. Le dipendenze mostrano come queste attività sono collegate. La gestione dei rischi cerca di capire cosa potrebbe impedire a ciò che abbiamo pianificato di accadere realmente.

Project Intelligence aggiunge un quarto livello a questa equazione: utilizzare i dati che il progetto produce già per cercare segnali che qualcosa stia iniziando a deviare da ciò che ci aspettavamo.

Perché l'obiettivo non dovrebbe essere soltanto scoprire perché una consegna è andata in ritardo. È ancora importante farlo, ma a quel punto stiamo già analizzando il passato.

L'obiettivo dovrebbe essere capire, quando abbiamo ancora tempo per fare qualcosa, cosa potrebbe far ritardare quella consegna.

E molto spesso la risposta inizia con una task apparentemente piccola che un'altra attività sta aspettando per poter iniziare.

E nel tuo progetto? Sai quali attività possono realmente compromettere la data finale oppure lo scopri soltanto quando sono già in ritardo?

A presto!

Erik Scaranello