Non nascondere al Cliente che il tuo progetto sta accumulando ritardo

Il progetto accumula ritardo. Lo vedi tu, prima di tutti: le attività sul percorso critico chiudono qualche giorno dopo il previsto, una dietro l’altra, e il traguardo di fine fase si sposta a ogni aggiornamento. E ogni volta pensi la stessa cosa: «è recuperabile». Mancano ancora sette mesi, si può stringere, non è il caso di allarmare il cliente.

Poi i sette mesi diventano due, il ritardo non si è riassorbito e tocca dirlo a ridosso della consegna. A quel punto non stai più comunicando un ritardo: stai confessando di averlo saputo per mesi. Il problema tecnico è diventato un problema di fiducia, ed è il secondo che non si recupera.

Perché si tace, e perché lo fanno soprattutto i giovani

Nessuno nasconde un ritardo per malafede. Lo si nasconde per speranza: la speranza, quasi sempre sincera, che il tempo rimasto basti a recuperare. E per una paura comprensibile: il ritardo sembra un giudizio su chi lo comunica, e nessuno vuole essere quello che porta la cattiva notizia.

È l’atteggiamento tipico dei project manager alle prime esperienze. Quelli con qualche anno di più ci sono passati, hanno visto come finisce, e hanno imparato la lezione al contrario: la notizia cattiva data presto è una notizia normale; la stessa notizia data tardi è una crisi. Nei miei corsi lo ripeto da anni, ed è il consiglio su cui ricevo più conferme a distanza di tempo.

Cosa succede dall’altra parte del tavolo

Il committente, che sia un cliente esterno o una direzione interna, non è la fine della catena. Ha promesso a qualcuno, il suo cliente, il suo consiglio di amministrazione, un altro progetto che dipende dal tuo, che quello che stai realizzando sarà pronto a una certa data. Sulla tua data ha costruito impegni suoi.

Se lo scopre a ridosso della consegna, non ha più il tempo di proteggere quegli impegni: viene messo in difficoltà davanti ai suoi interlocutori, e reagisce di conseguenza. È in quel momento che il committente diventa un avversario, e che agisce con durezza verso chi ha condotto il progetto. Non perché il ritardo sia grave, ma perché gli è stato tolto il tempo di gestirlo. Del resto è comprensibile: al suo posto faremmo lo stesso.

Il committente non ti perdona il ritardo che gli hai comunicato. Non ti perdona il tempo che gli hai tolto per gestirlo.

Il ritardo si vede prima di quanto credi

Il ritardo che «scoppia» a fine progetto non è nato lì. Era visibile da mesi nei numeri del piano, per chi li guardava. Il segnale è preciso: le attività sul percorso critico, o vicine ad esso, richiedono più tempo del previsto, e lo fanno con regolarità. Un’attività che slitta è un incidente; tre aggiornamenti di seguito in cui le attività critiche chiudono in ritardo sono una tendenza, e la tendenza è ciò che va segnalato.

Per vederlo servono tre cose, e nessuna è facoltativa. Una schedulazione vera, con legami e durate, non un elenco di date scritte a mano. Una previsione salvata all’inizio, perché senza il termine di confronto ogni aggiornamento è una ripianificazione e il ritardo sparisce dai numeri: è il tema dell’articolo sulla previsione, questa sconosciuta. E un aggiornamento periodico a scadenza fissa, con data di stato e dati effettivi: il ciclo è descritto nella guida su come aggiornare un piano in Microsoft Project.

Con queste tre cose al loro posto, l’analisi delle variazioni è un gesto da un minuto: la tabella Variazione ordinata per variazione di fine, il Gantt verifica con le barre grigie della previsione sotto quelle correnti, il margine totale delle attività critiche che si consuma. Chi vuole un numero solo ha gli indici dell’Earned Value, e per i tempi l’Earned Schedule, che misura il ritardo in settimane invece che in euro. Ma il dato che decide è la direzione del ritardo: un ritardo che si allarga a ogni aggiornamento è un’emergenza anche se è piccolo; uno che si riassorbe da solo è un problema che si risolve senza spendere. Se non vuoi rifare questi conti a mano a ogni aggiornamento, GanttDerivata, un mio programma, legge il piano e mostra dimensione e direzione del ritardo sulle prossime tre settimane.

Quando dirlo: alla tendenza confermata, non al ritardo certo

La domanda che tutti si fanno è «quanto ritardo è abbastanza per parlarne?». È la domanda sbagliata, perché fissa una soglia sulla dimensione. La soglia giusta è sulla tendenza: si comunica quando due aggiornamenti consecutivi mostrano il percorso critico che slitta nella stessa direzione, e il margine sui traguardi contrattuali si sta consumando.

Un esempio con i numeri. Progetto di dodici mesi; a ogni aggiornamento mensile il percorso critico perde una settimana.

• Al terzo mese: tre settimane di ritardo, quattro opzioni. Aggiungere risorse alle attività critiche; sovrapporre attività che erano in sequenza; ridurre il perimetro di una consegna intermedia; spostare un traguardo interno senza toccare quello finale.
• Al sesto mese: sei settimane, due opzioni. Ridurre il perimetro, oppure rinegoziare la data.
• Al nono mese: nove settimane, una sola opzione. La nuova data, comunicata da una posizione di debolezza.

Il ritardo è lo stesso fenomeno in tutti e tre i casi. Cambia solo quanto tempo hai lasciato al committente per decidere.

Dirlo al terzo mese può sembrare prematuro, e qualche volta il ritardo si riassorbe davvero. Ma comunicare una tendenza con le opzioni per correggerla non è allarmismo: è la differenza tra un project manager che controlla il progetto e uno che lo subisce. Il committente lo capisce, e la volta successiva si fida di più, non di meno.

Come dirlo: cinque righe, numeri e opzioni

La comunicazione che funziona ha una struttura fissa e sta in mezza pagina. Prima il fatto, con i numeri del piano: di quanto slitta il percorso critico, da quando, in che direzione. Poi la causa, senza cercare colpevoli: una stima ottimistica, una fornitura in ritardo, una risorsa condivisa con un altro progetto. Poi l’impatto se non cambia nulla: la nuova data di fine e, se ci sono, i costi a finire. Poi le opzioni, due o tre, ciascuna con il suo prezzo in tempo, denaro o perimetro. Infine la richiesta: quale decisione serve dal committente, ed entro quando, perché anche le opzioni hanno una scadenza.

Tre cose da non scrivere. «Contiamo di recuperare»: se avevi un piano per recuperare lo avresti già messo tra le opzioni, con il suo costo. «Il ritardo è dovuto a…» seguito da un nome: la causa serve a scegliere il rimedio, non a distribuire colpe, e il committente lo sa. E «vi terremo aggiornati»: l’aggiornamento ha già una scadenza concordata, e il ritardo si misura di nuovo alla prossima, con gli stessi numeri.

Il contratto lo chiede sempre più spesso

Una cosa è cambiata rispetto a qualche anno fa: sempre più committenti chiedono, e lo scrivono nel contratto, che il fornitore gestisca un programma lavori, lo aggiorni a scadenza fissa e lo consegni periodicamente. Non è burocrazia: è il modo in cui il committente si compra il tempo per reagire. Un programma aggiornato ogni mese rende impossibile tacere un ritardo, e questo protegge entrambe le parti, anche il fornitore, che a quel punto ha una data certa in cui il ritardo è stato dichiarato.

La frequenza si concorda all’inizio: settimanale per progetti brevi o critici, quindicinale o mensile per quelli lunghi. Come scegliere il periodo di aggiornamento è un articolo a parte; qui basta dire che il periodo va rispettato anche quando le notizie sono cattive, anzi soprattutto allora. Saltare un aggiornamento perché «non c’è niente di nuovo da dire» è il primo passo verso il ritardo taciuto.

Il caso opposto: quando non è il momento di allarmare

Non ogni slittamento è una notizia. Un’attività fuori dal percorso critico che chiude in ritardo dentro il suo margine non sposta niente, e comunicarla come ritardo abitua il committente a non ascoltare. Un’oscillazione di pochi giorni su un aggiornamento singolo, senza tendenza, è rumore. Il criterio resta quello detto sopra: percorso critico o vicino, tendenza confermata, margine sui traguardi che si consuma. Se manca anche uno solo dei tre, si annota e si aspetta il prossimo aggiornamento. Comunicare tutto equivale a non comunicare niente.

Domande frequenti

Quanto ritardo è «significativo»?

Non c’è una percentuale valida per tutti. È significativo un ritardo che consuma il margine dei traguardi contrattuali e che si ripete nella stessa direzione per due aggiornamenti consecutivi. Su un progetto di un anno possono essere due settimane; su un cantiere con penali giornaliere, due giorni. La soglia va decisa all’inizio con il committente e scritta nel piano di comunicazione, così quando arriva il momento non c’è da discutere se sia il caso di parlarne.

E se il committente reagisce male comunque?

Reagirà male, qualche volta: è una cattiva notizia. Ma reagisce al ritardo, non a te, e il giorno dopo ha delle opzioni tra cui scegliere e il tempo per farlo. La reazione a un ritardo scoperto a ridosso della consegna è di un’altra natura: colpisce la persona, non il problema, e dura oltre il progetto. Tra le due, la prima è quella che si sopporta.

Devo dirlo prima al mio responsabile o direttamente al cliente?

Prima al responsabile, sempre, e nello stesso giorno. Non per coprirsi, ma perché alcune opzioni, aggiungere risorse, rinegoziare il perimetro, le decide lui. Presentargli la comunicazione già strutturata nelle cinque righe rende la conversazione breve e la porta subito sulle opzioni. Poi al committente, con il responsabile informato o presente.

E se il ritardo è causato dal committente stesso?

Si comunica allo stesso modo e con più urgenza, perché la variazione va documentata mentre accade, non ricostruita a posteriori. Il piano aggiornato con la previsione salvata è la prova: mostra la data in cui un’approvazione o una fornitura del committente era prevista e quella in cui è arrivata, e l’effetto sul percorso critico. È esattamente il caso in cui si salva una previsione numerata prima di riprogrammare, come descritto nella guida sull’aggiornamento del piano.

Come documento la comunicazione?

Per iscritto, con la data, allegando il piano aggiornato o il suo estratto: la tabella Variazione o il Gantt verifica alla data di stato. Le cinque righe in un’email sono sufficienti. Conta che esista una traccia con una data, perché è quella traccia che, mesi dopo, distingue un ritardo dichiarato da un ritardo taciuto.

Come faccio a vedere la direzione del ritardo senza rifare i conti a ogni aggiornamento?

A mano si fa confrontando la tabella Variazione di due date di stato consecutive: se la variazione di fine delle attività critiche cresce, il ritardo si sta allargando. In alternativa GanttDerivata, un mio programma, legge il file .mpp senza bisogno di Microsoft Project e mostra di quanto slitta il percorso critico e se il ritardo cresce o rientra, concentrandosi sulle prossime tre settimane. Il metodo è lo stesso dell’articolo; cambia solo che i conti li fa lui.