L'indecisione è un costo: come trasformare i nodi decisionali in azioni

La scena è questa: fine riunione operativa, il responsabile tecnico riassume i punti aperti, ognuno annuisce, e qualcuno dice “ci aggiorriamo a breve”. Nessuna decisione, nessun mandato, nessuna scadenza. Trenta minuti dopo, due lavorazioni continuano a interferire tra loro e l’interferenza è ancora lì — non risolta, solo rinviata.

Nei grandi cantieri infrastrutturali questo schema si ripete con una frequenza sorprendente. Non perché manchi la competenza tecnica in sala, ma perché manca qualcosa di più sottile: un sistema che definisca chi decide, con quali informazioni e entro quando.

Il problema non è la complessità della scelta. È l’assenza di chi si espone.

Perché l’indecisione non appare nei report

Il registro dei rischi ha una colonna per probabilità, una per impatto, una per l’owner del rischio. Non ha una colonna per “decisione rinviata da tre settimane”. Eppure quella voce, in un cantiere complesso, vale quanto un rischio ad alta probabilità e impatto significativo.

Un variation order bloccato in attesa di approvazione interna ha un costo giornaliero. Uno scavo fermo per un dubbio interpretativo sul contratto — “è nella nostra scope o in quella del committente?” — accumula costi che nessun recovery plan riesce a recuperare interamente. Lo SPI scende, il CPI si deteriora, e quando il dato arriva al tavolo è già storia passata.

Il punto è che l’indecisione non è neutrale. Non è uno stato di attesa in cui il progetto si congela e aspetta. Il progetto continua a muoversi — i subappaltatori emettono ore, i macchinari occupano fronte cantiere, le lavorazioni adiacenti avanzano o si bloccano a cascata. L’assenza di una decisione produce effetti reali, solo che nessuno li attribuisce a quella causa specifica nel reporting.

Il PMBOK lo chiama governance: in cantiere si chiama chiarezza

Il PMBOK definisce la governance di progetto come il sistema che stabilisce chi prende le decisioni, con quali criteri e secondo quale struttura di escalation. Non è burocrazia: è il motore che impedisce ai nodi di diventare colli di bottiglia permanenti.

In un grande progetto infrastrutturale, i livelli decisionali sono tipicamente tre: la decisione operativa (chi la risolve nel team di cantiere), la decisione tecnica-contrattuale (che coinvolge il project manager e spesso il contratto), la decisione commerciale o di programma (che sale al senior management o al cliente). Il problema sorge quando non è chiaro a quale livello appartiene una questione — e allora la questione galleggia, senza casa.

Primo: definire la matrice delle decisioni prima che servano. Non durante l’emergenza, ma in fase di setup del progetto. Chi approva una variazione sotto una certa soglia economica? Chi ha mandato per accettare un’interpretazione contrattuale? Chi firma un’istruzione tecnica che ha impatto sul programma? Queste risposte devono esistere in un documento, non nella memoria di qualcuno.

Secondo: separare le riunioni informative da quelle decisionali. Le prime servono per condividere dati; le seconde per chiudere un punto aperto con un’azione e un responsabile. Tenerle distinte — per agenda, per partecipanti, per output atteso — cambia il tono della stanza. Una riunione decisionale che finisce senza decisione è una riunione fallita, e bisogna che chi la conduce lo riconosca esplicitamente.

Terzo: definire un tempo limite per ogni nodo aperto. Non “ci aggiorriamo presto”, ma “entro giovedì prossimo, in assenza di indicazioni diverse, si procede con l’opzione A”. Il countdown trasforma l’attesa passiva in pressione produttiva.

Il ruolo del Project Control nei momenti di stallo

Chi fa Project Control in un cantiere complesso sa che il suo lavoro non finisce con il forecast. La parte più difficile — e spesso quella più trascurata nelle descrizioni del ruolo — è portare le informazioni giuste al momento giusto, nella forma giusta, a chi deve decidere.

Un decision-maker che dice “ho bisogno di più dati prima di decidere” a volte ha ragione. Spesso no. Spesso quello che manca non sono altri dati, ma la sintesi di quelli che già esistono. La risposta del Project Control in quel momento è produrre un’analisi che riduca l’incertezza percepita, non che la aumenti con ulteriori variabili.

In pratica: quando un variation order è bloccato perché nessuno vuole assumersi la responsabilità di approvarlo, il dato che sblocca la situazione non è un’altra revisione del costo. È la proiezione chiara di cosa succede al programma se la decisione slitta di altre due settimane. Un numero concreto — “stiamo accumulando X euro di costo stand-by al giorno, e il ritardo impatta direttamente sull’attività critica Y” — toglie all’incertezza l’alibi di restare tale.

Il costo controller come detective dei numeri non produce solo reporting: costruisce il contesto informativo che rende le decisioni possibili. Questo vale doppio nei momenti di stallo.

Decidere con dati incompleti: la competenza che non si insegna in aula

Aspettare la certezza assoluta per decidere non è prudenza. È paralisi mascherata da rigore.

Nei contratti FIDIC, la clausola che regola le Engineer’s Instructions (o le decisioni del Project Manager in base alla forma contrattuale) prevede tempi definiti di risposta. Non perché la risposta sarà sempre completa — ma perché il silenzio ha conseguenze contrattuali. Il contratto stesso riconosce che il tempo di indecisione non è gratuito: costruisce il presupposto per un claim.

Una decisione sbagliata ma tempestiva ha una caratteristica preziosa: è reversibile, o almeno gestibile. Si corregge, si adatta, si negozia. Il vuoto decisionale, invece, si accumula silenziosamente. Genera claim da parte dei subappaltatori (che hanno tutto il diritto di documentare i costi del proprio cantiere fermo), deteriora il rapporto con il committente, e produce ritardi di programma che nessun recovery plan riesce davvero a recuperare per intero — come ho già sviluppato nell’articolo sullo schedule recovery.

La competenza che distingue chi guida bene un progetto complesso non è avere sempre la risposta giusta. È saper decidere con le informazioni disponibili, esplicitando le assunzioni su cui si basa la scelta e creando le condizioni per correggerla se quelle assunzioni si rivelano errate.

Come tenere traccia delle decisioni aperte

Un registro dei rischi gestisce le incertezze future. Ma chi gestisce le decisioni aperte nel presente?

In molti cantieri, la risposta è: nessuno, formalmente. Le decisioni pendenti vivono nelle email, nelle note sparse delle riunioni, nella testa del project manager. Il risultato è che alcune vengono prese in ritardo, altre non vengono prese affatto, e quando arriva il claim del subappaltatore nessuno riesce a ricostruire esattamente perché quella lavorazione è rimasta ferma.

Uno strumento semplice che funziona è un decision log: una lista strutturata delle decisioni aperte, con la descrizione del nodo, il livello a cui è stata escalata, la data di apertura, la deadline fissata e il responsabile. Non serve un software dedicato — serve la disciplina di aggiornarlo ogni settimana e di portarlo come primo punto in ogni riunione operativa.

Il decision log fa una cosa fondamentale: rende visibile l’indecisione. E quello che è visibile può essere gestito; quello che resta nell’ombra si accumula fino a diventare un problema che nessuno riesce più a risolvere in silenzio.

Chi lavora in cantiere sa che la pressione non sparisce mai. La differenza tra un progetto che tiene la rotta e uno che si inceppa sta spesso nella capacità di trasformare i nodi in azioni — anche con dati imperfetti, anche in condizioni di incertezza, anche quando nessuno vorrebbe essere il primo a mettere la firma.

Come sono gestiti i nodi decisionali nel tuo progetto? Esiste un decision log, una matrice delle autorità, una deadline fissata — o si decide riunione per riunione, sperando che qualcuno si esponga?