Cinque modi in cui un cronoprogramma mal costruito ti toglie gli strumenti per difenderti

L’ho visto succedere più volte: un’impresa avanza una richiesta di proroga per un ritardo chiaramente imputabile al committente, ha le notifiche protocollate, ha i verbali di cantiere, ha persino le mail. Ma non ha un programma lavori che regge un’analisi del ritardo. La controparte lo smonta in tre domande, e la richiesta si arena.

Il cronoprogramma, in quei momenti, non è più un foglio di Gantt. Diventa la differenza tra un claim sostenibile e carta straccia.

Eppure nella maggior parte dei progetti che ho incontrato, il programma viene prodotto in fretta all’avvio, aggiornato per obbligo contrattuale e poi ignorato fino a quando — troppo tardi — qualcuno prova a usarlo per dimostrare qualcosa.

Il critical path come strumento di prova

Il problema più frequente — e il più pericoloso — è il critical path invisibile o non verificabile. Su un programma costruito con logiche di schedulazione approssimative, le dipendenze tra attività sono spesso impostate a occhio, senza che riflettano la sequenza costruttiva reale. Il risultato è un critical path che non sopravvive a un’analisi esterna.

Quando si apre una disputa su un ritardo, la prima cosa che farà la controparte — o il suo consulente — è smontare la logica del programma. Se le dipendenze non sono giustificabili tecnicamente, se ci sono lag arbitrari, se il float totale è manipolato per gonfiare artificialmente la criticità di certe attività, il programma non regge. E senza un critical path credibile, dimostrare che un evento esterno ha impattato la data di completamento diventa quasi impossibile.

La cura è nella costruzione, non nella revisione emergenziale. Il programma va schedulato con logiche FS, SS, FF motivate, con lag documentati e giustificati. Vale in qualsiasi regime contrattuale — NEC, FIDIC, o un contratto domestico che richiami gli standard di schedulazione AACE o PMI.

I lead time non modellati come attività

Su opere con componenti a lungo ciclo di approvvigionamento — carpenterie metalliche, apparecchiature elettromeccaniche, prefabbricati speciali — la data di ordine, la data prevista di consegna e la data di installazione devono essere modellate nel programma come attività collegate tra loro e con la sequenza esecutiva a valle.

Se non lo sono, succedono due cose. La prima: il programma non permette di anticipare l’impatto di un ritardo di fornitura sulla catena delle lavorazioni successive. La seconda, più grave dal punto di vista contrattuale: quando un componente arriva in ritardo per ragioni imputabili al committente — ad esempio per un’approvazione shop drawing ritardata — non si riesce a dimostrare formalmente che quel ritardo ha colpito una fornitura che stava su critical path e che ha trascinato la data di completamento.

In molti contratti FIDIC e NEC esiste un obbligo di notifica tempestiva degli eventi che possono generare un compensation event o una variation. Se il programma non modella la catena approvvigionamento-fornitura-installazione, quella notifica arriva in ritardo o non arriva affatto — e il diritto alla proroga si prescrive.

Le interfacce esterne trattate come date fisse

Un cantiere di grande infrastruttura non esiste in isolamento. Dipende da consegne di aree da parte del committente, da autorizzazioni di enti terzi, da lavorazioni di contractor paralleli che devono liberare fronte prima che tu possa avanzare. Queste dipendenze esterne hanno una natura condizionale: la loro data è un’aspettativa, non una certezza.

Il modo sbagliato di gestirle nel programma è inserirle come vincoli rigidi — una data fissa, un milestone di constraint, e via. Questo crea un’illusione di controllo che scompare al primo slittamento. Quando l’area non viene consegnata nei tempi previsti, il programma semplicemente non funziona, e non c’è nessuna rappresentazione del collegamento causale tra la mancata consegna e il ritardo che si propaga a valle.

Il modo corretto è modellare quelle dipendenze come attività esterne con le loro predecessors e successors, in modo che il software di schedulazione propaghi automaticamente l’impatto di qualsiasi ritardo sulla sequenza esecutiva. Così, quando succede qualcosa, il programma ti dice già quanto vale — in termini di giorni — l’impatto sulla data di completamento. E tu hai una base oggettiva per la notifica e per la quantificazione del claim.

La baseline non protetta

Questo è l’errore che mi fa più effetto, perché è anche il più evitabile. In molti progetti il programma viene aggiornato progressivamente — come è giusto fare — ma senza mantenere la baseline originale separata, protetta, confrontabile con lo stato di avanzamento corrente.

Senza quella baseline, non si può misurare il delta tra what was planned e what happened. Non si può fare Earned Schedule. Non si può costruire un’analisi del ritardo con metodo — né TIA (Time Impact Analysis), né Windows Analysis, né alcun altro approccio riconosciuto. E senza un’analisi del ritardo metodologicamente solida, un claim di proroga è difficilissimo da sostenere in sede di disputa.

La baseline va salvata al momento dell’accettazione del programma contrattuale, marcata come tale nel sistema di schedulazione, e non modificata mai. Gli aggiornamenti successivi vivono su versioni separate. Se il contratto prevede baseline revisions — come in molti contratti NEC — anche quelle vanno gestite con la stessa disciplina, documentando la ragione di ogni revisione.

Il programma come documento contrattuale

C’è un cambio di prospettiva che cambia tutto: smettere di leggere il cronoprogramma come uno strumento operativo e iniziare a trattarlo come un documento contrattuale — con la stessa cura con cui si scrive una notifica formale o si redige una variation order.

Questo significa che ogni revisione del programma va accompagnata da una nota esplicativa che documenta le ragioni delle modifiche alle logiche, l’impatto sui milestones contrattuali, e la posizione dell’impresa rispetto agli eventi che hanno generato le variazioni. Significa che il programma viene revisionato non solo dal planner, ma anche da chi gestisce i contratti, perché le scelte di schedulazione hanno conseguenze sul posizionamento contrattuale.

Nella mia esperienza su progetti AV/AC e opere sotterranee complesse, i team che gestiscono il programma con questa doppia lettura — operativa e contrattuale — hanno invariabilmente più strumenti quando si apre una disputa. Non perché siano più bravi a fare i claim, ma perché hanno documentato correttamente mentre il progetto andava avanti.

Su questo si connette direttamente il tema della costruzione di un claim: identificare, quantificare, documentare. Ma identificare è possibile solo se il programma ha registrato gli eventi con la giusta struttura. E se ti interessa capire perché il critical path a volte tradisce proprio nei momenti più critici, vale la pena leggere anche questo articolo dedicato.

Un programma lavori mal costruito non ritarda solo il progetto. Ti toglie gli strumenti per difenderti quando le cose vanno storte — e in grandi infrastrutture, prima o poi, qualcosa va sempre storto. La qualità del programma non si misura alla consegna: si misura quando apri il file per costruire un’analisi del ritardo e capisci se hai lavorato bene o no.

Nel tuo progetto, il cronoprogramma viene revisionato anche con un’ottica contrattuale, o rimane esclusivamente in mano al team di pianificazione operativa?