WBS: lo strumento giusto usato nel modo sbagliato

La prima volta che ho visto una WBS di un grande progetto infrastrutturale stamparla su plotter, ho pensato che fosse un’opera d’arte. Decine di livelli, colori distinti per fase contrattuale, milestone evidenziate. Tutto perfettamente allineato con il contratto. Tutto perfettamente inutile per il caposquadra che il lunedì mattina doveva sapere da dove cominciare.

Quella struttura raccontava cosa doveva essere consegnato e quando. Non diceva nulla su come organizzare le squadre, su quali lavorazioni si condizionavano a vicenda, su quale fosse il ritmo produttivo sostenibile per zona. Era un documento di reporting vestito da strumento di pianificazione.

Il problema non era la WBS in sé. Era il criterio con cui era stata costruita.

Deliverable vs. flusso di lavoro: una distinzione che cambia tutto

La WBS orientata ai deliverable è la norma nei grandi appalti. Lo dice anche il PMBOK: la WBS scompone il progetto in pacchetti di lavoro (Work Packages) organizzati per risultati da produrre. È coerente con la logica contrattuale, è comprensibile al committente, è difendibile in sede di reporting. Per questo si continua a usarla esattamente così.

Il punto è che descrive il progetto come un insieme di output, non come un processo produttivo. E in cantiere, quello che conta è il processo.

Prendiamo un’opera lineare: gallerie, tratte ferroviarie, viadotti ripetuti. La scomposizione logica per il controllo contrattuale tende a seguire le sezioni del progetto o le categorie di lavorazione. La scomposizione utile per il cantiere, invece, segue il flusso: quali squadre avanzano in quale sequenza, in quale sottozona, con quale durata bilanciata rispetto alle squadre che le precedono e le seguono. Sono due strutture diverse. Una risponde alla domanda “cosa consegniamo?”, l’altra risponde a “come scorre la produzione?”.

La Lean Construction ha formalizzato questa distinzione da anni. Non come critica al project management tradizionale, ma come integrazione necessaria per chi deve governare la produzione in campo, non solo rendicontarla.

Gli errori che si ripetono

Nella mia esperienza su progetti AV/AC e opere complesse, ci sono tre errori che tornano quasi sempre quando si analizza una WBS mal costruita.

Primo: la scomposizione segue la contabilità, non la produzione. I Work Packages coincidono con le voci di computo o con le categorie di subappalto. È comodo per il cost control, ma produce pacchetti eterogenei dal punto di vista esecutivo: lavorazioni con logiche diverse, durate incompatibili, vincoli che non emergono finché non si è già in ritardo.

Secondo: i vincoli di flusso non sono strutturati, sono annotati. Le dipendenze tra pacchetti vengono gestite come note nel programma lavori, non come criteri di scomposizione. Risultato: ogni aggiornamento del piano richiede una rinegoziazione manuale delle sequenze, e il lookahead diventa un esercizio di recupero anziché di controllo anticipato.

Terzo: la WBS viene definita senza chi esegue in campo. Questo è forse il più grave. I project controller e i pianificatori costruiscono la struttura a partire dai documenti contrattuali, i capisquadra e i responsabili di produzione la ricevono a costruzione avviata. A quel punto adattarla è costoso, quindi si va avanti con quello che c’è. Il Last Planner System — che per funzionare ha bisogno di pacchetti di lavoro piccoli, chiari e sequenziati — si trova a operare su una base strutturale inadatta.

Come si costruisce una WBS orientata al flusso

Il principio è semplice: la WBS deve riflettere il modo in cui il lavoro scorre attraverso il cantiere, non il modo in cui il progetto è descritto nel contratto. Nella pratica, questo richiede alcune scelte precise durante la fase di preconstruction.

Partire dalla logica di avanzamento, non dal piano delle consegne. Prima di strutturare i Work Packages, occorre capire come si muovono le squadre: il cantiere avanza per zone? Per lotti ripetuti? Per fronti di avanzamento sovrapposti? La risposta a queste domande determina il criterio di scomposizione, non il contratto.

Bilanciare le durate dei Work Packages. Uno degli obiettivi della WBS orientata al flusso è ottenere pacchetti di durata comparabile all’interno di ogni treno di lavorazioni. Quando un pacchetto è tre volte più lungo degli altri, crea un collo di bottiglia che il piano non mostra ma il cantiere sente. Questo richiede un’analisi quantitativa in preconstruction: volumi, rendimenti attesi, risorse disponibili. Il QS e il production planner devono lavorare insieme in questa fase, non in sequenza. Sul contributo del QS in preconstruction ho già scritto in un articolo dedicato.

Rendere espliciti i vincoli di flusso nella struttura, non nelle note. I vincoli tra lavorazioni — spazi fisici condivisi, sequenze tecnologiche obbligate, dipendenze da terzi — devono emergere nella struttura della WBS, non essere aggiunti a posteriori nel cronoprogramma. Questo significa che la scomposizione deve includere anche i pacchetti di interfaccia: attività di preparazione, attività di attesa controllata, attività di verifica che abilitano il flusso successivo.

Coinvolgere chi esegue nella definizione della struttura. Non è una questione di partecipazione per principio. È una questione di accuratezza: chi lavora in campo conosce i vincoli reali, le sequenze che funzionano, i ritmi sostenibili. Una WBS costruita solo da ufficio incorpora ipotesi ottimistiche che poi il cantiere non riesce a rispettare.

Il rapporto con il Last Planner System

Il Last Planner System non sostituisce la WBS: la presuppone. Il sistema funziona a partire da Work Packages definiti, con scope chiaro e precondizioni verificabili. Se la WBS produce pacchetti ambigui o sovradimensionati, il lookahead a sei settimane e il weekly work plan diventano esercizi di interpretazione, non di pianificazione.

Ho visto cantieri dove il Last Planner System veniva accusato di non funzionare. Quasi sempre, il problema reale era a monte: una struttura di scomposizione che non permetteva di isolare il lavoro in unità gestibili. Il sistema di controllo era corretto; la base su cui operava, no. Lo stesso vale per il Critical Path: come ho già argomentato in un altro articolo, il CPM può mentire proprio quando la struttura sottostante non rispecchia la realtà produttiva.

Questo conferma che la WBS non è un documento da consegnare in fase di offerta e dimenticare. È l’infrastruttura logica del piano: se è sbagliata, tutto quello che ci si costruisce sopra — scheduling, earned value, controllo dei costi — lavora su basi fragili.

Non è troppo tardi, ma il momento giusto è prima

Una WBS mal costruita si può correggere. Ma il costo di farlo aumenta drasticamente dopo che il cantiere è partito: squadre già organizzate secondo una logica diversa, contratti di subappalto firmati su scope che riflettono la struttura precedente, sistemi di reporting tarati su quella struttura. Ogni modifica genera discontinuità nei dati storici e resistenza organizzativa.

Il momento in cui la WBS deve essere progettata con attenzione al flusso produttivo è la preconstruction: quando si analizza il progetto prima che diventi un problema operativo, quando i vincoli si identificano sulla carta invece che in cantiere, quando è ancora possibile scegliere il criterio di scomposizione invece di subirlo.

Lo strumento non è il problema. Il criterio con cui lo si costruisce, e il momento in cui lo si definisce, fanno tutta la differenza.

Nella tua esperienza, la WBS viene definita con il contributo di chi poi deve eseguire in campo, o rimane un esercizio da ufficio?