La regola 87/13: perché i progetti falliscono per ragioni che non trovi nel programma

Erano le 7:30. Il coordinamento settimanale era appena iniziato e già si capiva come sarebbe finito: tre subappaltatori che si rimpallano le responsabilità su una lavorazione in ritardo di undici giorni, un fornitore che non aveva consegnato nei tempi concordati la settimana prima, e il look-ahead della settimana successiva compilato con attività che nessuno aveva verificato fossero effettivamente eseguibili.

Il programma generale era aggiornato. Il registro dei rischi era completo. Le curve S erano lì, stampate e rilegate. Tutto corretto sulla carta — e tutto fermo sul terreno.

Quella mattina ho capito qualcosa che nei mesi successivi ho visto confermarsi più volte: il problema non era mai dove sembrava.

La regola 87/13: di cosa si tratta davvero

La regola 87/13 afferma che circa l’87% dei fallimenti di progetto ha una causa comportamentale, e solo il 13% una causa tecnica. Non è una formula motivazionale da citare nelle slide di apertura di un kick-off. È un’osservazione operativa che chiunque abbia lavorato su progetti complessi riconosce quasi subito, anche senza averle mai dato un nome.

Il 13% tecnico riguarda lacune metodologiche reali: un’analisi del critical path eseguita male, un sistema di earned value mal configurato, una WBS che aggrega troppo e nasconde le anomalie invece di mostrarle. Problemi risolvibili con formazione, strumenti, procedure.

L’87% comportamentale è più difficile da affrontare perché non sta nei sistemi. Sta nel modo in cui le persone comunicano, decidono, si impegnano — e nel modo in cui reagiscono sotto pressione. Un ritardo segnalato tre settimane dopo che è emerso. Un impegno preso in riunione e dimenticato il giorno dopo. Una variante riconosciuta a voce e mai formalizzata. Singolarmente, ciascuna di queste cose sembra un dettaglio. Sommate, sono la storia di ogni progetto che va fuori controllo.

Perché il Last Planner System lo mette a nudo

Il Last Planner System è lo strumento che rende questa dinamica visibile in modo sistematico. Non perché sia pensato per misurare i comportamenti — ma perché la sua struttura li espone inevitabilmente.

Il PPC, il Percent Plan Complete, è una metrica semplice: quante delle attività impegnate nella settimana precedente sono state effettivamente completate. Non stimate, non in corso — completate. Quando un team inizia a usarlo con rigore, le prime settimane sono spesso scomode. Il PPC si attesta intorno al 50-60%, a volte meno. Non perché le persone siano incompetenti, ma perché per la prima volta esiste una misura diretta tra ciò che si dichiara di poter fare e ciò che si fa.

La distanza tra quelle due cose non si chiude aggiornando il programma. Si chiude lavorando sui motivi per cui gli impegni non vengono rispettati — e quei motivi, quasi sempre, sono comportamentali: informazioni non condivise in tempo, vincoli non segnalati, decisioni rinviate, coordinamento mancato.

L’articolo Last Planner System: non risolve i problemi di flusso, li rende visibili approfondisce esattamente questo punto: il LPS non è una bacchetta magica, è uno specchio. Quello che mostra può essere scomodo.

Le abitudini operative che fanno la differenza

Se il problema è comportamentale, la soluzione non può essere solo procedurale. Ma questo non significa affidarsi al carattere o all’istinto. Significa costruire abitudini operative concrete, piccole pratiche quotidiane che riducono la distanza tra intenzione ed esecuzione.

Nella mia esperienza con contractor internazionali su grandi infrastrutture, le abitudini che hanno fatto la differenza più misurabile sono state sempre poche e semplici.

Prima: iniziare la giornata dai vincoli, non dalla posta. Prima di aprire la mail, dieci minuti a verificare quali vincoli aperti rischiano di bloccare le lavorazioni nei prossimi tre giorni. Non la prossima settimana — i prossimi tre giorni. Questo sposta l’attenzione dal reporting alla prevenzione.

Seconda: chiudere ogni riunione con impegni nominali. Non “valuteremo”, non “ci aggiorneremo”. Una persona, un’azione, una data. Scritta. Verificabile alla riunione successiva. La differenza tra una riunione che produce qualcosa e una che produce solo verbale sta quasi sempre qui.

Terza: segnalare il ritardo il giorno in cui emerge. Non quando è diventato impossibile da ignorare. Non quando qualcun altro lo ha già visto. Il giorno in cui emerge. In cantiere questo richiede una cultura esplicita: chi segnala prima non viene penalizzato, viene ascoltato.

Quarta: separare l’analisi dalla difesa. Quando un’attività non viene completata, la prima domanda non è “di chi è la colpa” ma “cosa ha impedito il completamento”. Questa distinzione non è semantica — determina se la riunione produce informazioni utili o solo conflitto.

Il gap che separa sapere e fare

C’è una distanza reale tra conoscere uno strumento e applicarlo con continuità sotto pressione. Su progetti AV/AC e su cantieri di grandi infrastrutture, ho visto professionisti con curriculum eccellenti andare in difficoltà non perché non sapessero cosa fare — ma perché sotto pressione tornavano ai comportamenti di default: evitare il conflitto rimandando una decisione scomoda, segnalare solo le buone notizie, aggiornare il programma invece di affrontare il problema che il programma stava segnalando.

Questo non è un giudizio morale. È una dinamica prevedibile. La pressione attiva risposte automatiche, e le risposte automatiche raramente sono quelle ottimali per un progetto complesso. La disciplina — nel senso tecnico del termine, non in quello punitivo — è la capacità di applicare il comportamento corretto anche quando la pressione spingerebbe altrove.

L’articolo L’indecisione è un costo: come trasformare i nodi decisionali in azioni affronta il costo concreto — economico e di programma — di uno dei comportamenti di default più frequenti nei progetti: rimandare le decisioni difficili.

Cosa significa in pratica applicare la regola 87/13

Riconoscere che la maggior parte dei problemi ha una causa comportamentale non significa ignorare la parte tecnica. Significa investire in entrambe le direzioni, senza illudersi che l’una compensi l’altra.

Un sistema di project control ben configurato serve a poco se chi dovrebbe alimentarlo con dati reali continua a inserire stime ottimistiche per evitare conversazioni difficili. Un look-ahead preciso non produce valore se gli impegni che genera vengono trattati come aspettative vaghe invece che come impegni verificabili. La competenza tecnica crea le condizioni. La disciplina operativa le trasforma in risultati.

Il punto non è diventare manager migliori in senso astratto. È identificare due o tre pratiche concrete — quelle che ciascuno già sa essere giuste — e applicarle con costanza, ogni giorno, anche quando nessuno sta guardando. Soprattutto quando nessuno sta guardando.

Qual è l’abitudine operativa che nella tua esperienza ha avuto l’impatto più misurabile sulla gestione quotidiana di un progetto?