Cost of Delay: come trasformare il ritardo di un progetto in un numero che guida le priorità

La risposta viene da Donald Reinertsen, l’autore che ha formulato il CD3: la durata misura per quanto tempo un progetto tiene occupata la capacità del team, e quindi per quanto tempo blocca l’avvio di tutti gli altri progetti in coda. Finché il progetto non è completato, l’organizzazione continua ad accumulare il Cost of Delay non solo di quel progetto, ma di tutti quelli che aspettano dietro di lui.  

Dividere per la durata, quindi, non calcola un costo totale: pesa ogni progetto in base a quanto a lungo tiene ferma la coda. Un progetto che dura poco libera in fretta la capacità del team per il progetto successivo; un progetto lungo la tiene bloccata più a lungo, anche a parità di valore settimanale. Moltiplicare, al contrario, darebbe solo l’esposizione economica totale se il progetto slittasse per la sua intera durata: un dato utile per stimare un rischio, ma inutile per decidere in che ordine lavorare.  

Reinertsen dimostra la differenza con un esempio numerico: confrontando tre iniziative eseguite nell’ordine di arrivo (FIFO) rispetto allo stesso set ordinato per CD3 decrescente, il costo totale del ritardo scende del 61% nel suo caso. La differenza nasce proprio dal fatto che il CD3, dividendo per la durata, dà priorità a chi libera prima la coda, non solo a chi vale di più.  

La logica è la stessa alla base del WSJF (Weighted Shortest Job First), il metodo di prioritizzazione adottato da SAFe: si preferisce sistematicamente il lavoro che restituisce più valore per unità di tempo investita, non il lavoro che genera più valore in assoluto. 

La parte più utile del Cost of Delay non è calcolarlo per un singolo progetto: emerge quando più iniziative competono per le stesse risorse. L'ordine in cui vengono eseguite cambia il costo complessivo del ritardo, perché il valore di ogni progetto resta bloccato finché il progetto stesso, e tutti quelli che lo precedono in coda, non sono completati.  

Le strategie di prioritizzazione più comuni sono quattro: partire dal progetto più breve, partire da quello di maggior valore, ordinare per punteggio CD3 decrescente, oppure lavorare su tutto in parallelo.  

Confrontando l'impatto economico di questi approcci su uno stesso portafoglio di progetti emerge un pattern ricorrente. Lavorare in parallelo su tutto è quasi sempre la scelta più costosa, perché nessun valore si realizza finché l'ultimo progetto non è finito. Ordinare per durata o per valore migliora la situazione, ma è la prioritizzazione basata sul CD3 a minimizzare in modo sistematico il costo totale del ritardo, perché bilancia insieme velocità di consegna e valore generato invece di ottimizzare una sola delle due variabili.  

Ecco perché framework come SAFe (Scaled Agile Framework) hanno adottato il CD3 come criterio di prioritizzazione di default nei portafogli agili: permette di superare la scelta tra «veloce» e «prezioso» e di trovare il compromesso che massimizza il valore recuperato nel tempo. 

Non tutti i ritardi si comportano allo stesso modo. È utile distinguere tre profili di Cost of Delay.  

Il CoD lineare cresce in modo costante nel tempo, senza accelerazioni improvvise. È il caso tipico di una funzionalità SaaS che genera un flusso di ricavi regolare: ogni settimana di ritardo costa più o meno quanto la precedente.  

Il CoD a scadenza fissa resta pari a zero fino a una data specifica, spesso legata a una SLA o a un vincolo contrattuale, dopo la quale il costo sale bruscamente. Un downtime che supera la soglia di SLA concordata con un cliente ne è l'esempio più immediato.  

Il CoD guidato dall'urgenza cresce rapidamente per poi stabilizzarsi su un plateau. È tipico delle situazioni competitive: se un concorrente lancia per primo una funzionalità equivalente, il costo del ritardo sale in modo marcato nel breve periodo e poi continua a crescere più lentamente, man mano che il divario si consolida.  

Riconoscere quale profilo si applica a un'iniziativa aiuta a capire non solo se darle priorità, ma quando il ritardo comincia davvero a pesare sui risultati. 

Il Cost of Delay vale soprattutto come lente decisionale: aiuta a scegliere le priorità sulla base di dati economici, invece che di sensazioni o pressioni del momento. Aiuta i team a rispondere a una domanda che raramente viene posta in modo esplicito: cosa succede, in euro, se questo progetto slitta di due settimane?  

Nella gestione dei progetti vale la stessa logica che sta ridisegnando il modo di valutare il software: il criterio che conta non è quanto lavoro si produce, ma quanto valore quel lavoro genera, e in quanto tempo. In un contesto in cui la maggior parte dei team di prodotto gestisce più iniziative in competizione per le stesse risorse, ragionare in termini di Cost of Delay, e non solo di valore o di sforzo, è spesso ciò che separa una roadmap che genera risultati da una che si limita a tenere tutti occupati.