Work Breakdown Structure (WBS) di una commessa: come si costruisce

Work Breakdown Structure, WBS, è un termine che arriva dal project management e che in molte aziende viene subito associato a diagrammi, Gantt e metodologie. In un’azienda che lavora a commessa vale la pena guardarla da un angolo più stretto e più utile: più che uno strumento per pianificare i task, è lo scheletro su cui si appoggia il controllo del margine. Se la scomposizione del lavoro non ha un budget agganciato a ogni ramo, hai un piano, non uno strumento di controllo.

Cos’è, in breve

La WBS scompone una commessa in una gerarchia: il progetto nel suo insieme, le fasi principali (per esempio analisi, sviluppo, collaudo, avviamento), e dentro ogni fase i singoli task. È lo stesso principio con cui si scompone un buon budget di commessa: invece di una cifra unica, una struttura che si può verificare pezzo per pezzo.

Perché in un’azienda a commessa conta più il margine del piano

La differenza tra usare la WBS solo per pianificare e usarla per controllare sta in una domanda: ogni ramo ha un budget che si può confrontare a consuntivo? Un piano che dice “prima l’analisi, poi lo sviluppo, poi il collaudo” organizza il lavoro, ma da solo non dice niente sul margine. Lo stesso piano, con un budget di ore assegnato a ciascuna fase, permette di vedere se l’analisi sta consumando più ore di quelle previste mentre è ancora in corso, non quando il conto finale è già chiuso.

È la differenza tra una WBS che serve al project manager per sapere cosa fare dopo, e una WBS che serve anche al controllo di gestione per sapere dove si sta perdendo margine, dentro la stessa commessa.

Molte aziende hanno già una WBS di fatto, solo che vive nella testa del responsabile di commessa invece che nel gestionale: ogni volta che deve ricostruirla per capire dove sta andando un progetto, sta rifacendo a mano un lavoro che dovrebbe essere già scritto da qualche parte.

Come si costruisce

Costruire una WBS utile per il controllo, non solo per la pianificazione, segue pochi criteri:

• Scomponi per attività che si possono consuntivare separatamente. Se due task condividono lo stesso budget e nessuno li distingue mai nel consuntivo, tenerli separati nella WBS non serve a niente: uniscili.
• Fermati al livello in cui il dettaglio è ancora verificabile. Una WBS troppo fine, con decine di micro-task, diventa un esercizio di compilazione che nessuno aggiorna davvero. La domanda guida è: questo livello in più mi dà un budget che ha senso confrontare a consuntivo, o solo più righe da riempire?
• Assegna un budget a ogni ramo, non solo al totale. È il passaggio che trasforma la WBS da elenco di attività a strumento di controllo: senza budget per ramo, uno scostamento si vede solo sommato a fine commessa, quando la fase che lo ha causato è già chiusa.
• Rivedila quando cambia il perimetro, non alla fine. Una WBS scritta all’inizio e mai più toccata smette di rappresentare il lavoro reale già dopo le prime settimane.

Un esempio aiuta a fissare il livello giusto. Una commessa di system integration si scompone spesso su tre livelli: la commessa nel suo insieme, le fasi, per esempio analisi, configurazione, migrazione dati, formazione, avviamento, e dentro ogni fase i task settimanali del team. Il budget utile al controllo vive al livello della fase, non del singolo task: sapere che la fase di migrazione dati ha 120 ore a disposizione è un dato su cui decidere se intervenire; sapere che un singolo task ne ha 4 è quasi sempre più dettaglio di quanto serva al controllo, anche se resta comodo per organizzare il lavoro quotidiano del team.

Ogni ramo, il suo budget e il suo consuntivo

Ogni ramo della WBS, non solo la commessa nel suo insieme, può avere il proprio budget e il proprio consuntivo. Vuol dire che se la fase di sviluppo sta sforando ma l’analisi era chiusa in anticipo, lo vedi separatamente, invece di vedere un budget complessivo che sembra ancora in linea solo perché una fase compensa l’altra.

È lo stesso principio dietro gli scostamenti di schedule per fase che un project manager segue settimana per settimana: la WBS è la struttura che rende possibile guardare ogni fase separatamente, invece di aspettare che tutto si sommi in un unico numero a fine commessa.

L’errore più comune: la WBS come documento morto

Il rischio più frequente, anche in aziende organizzate, è trattare la WBS come un documento prodotto in fase di offerta e mai più aperto: serve a vincere la commessa, poi finisce in un cassetto mentre il lavoro reale prende un’altra forma. Una WBS che non si aggiorna quando cambia il perimetro smette di dire la verità su dove sta andando il budget, e con lei smette di funzionare anche il controllo del margine che dovrebbe rendere possibile.

Con Talete, dentro Business Central

In Business Central, con Talete la struttura Commessa → Task → Righe segue esattamente questa logica: ogni task può avere il proprio budget, il proprio tipo di fatturazione (a corpo, a consuntivo, a pacchetto ore) e il proprio consuntivo, aggiornati mentre il lavoro procede. È la struttura con cui la commessa viene pianificata e gestita nello stesso sistema, non una WBS scritta a parte e poi dimenticata.

Il punto

Una WBS che serve al controllo, non solo alla pianificazione, ha una caratteristica sola: ogni ramo ha un budget verificabile, non solo un’etichetta. È quello che permette di vedere dove nasce uno scostamento mentre la commessa è ancora aperta, invece di scoprirlo sommato a fine lavoro.

Per il passaggio successivo, come si costruisce il budget che accompagna ogni ramo della struttura, vedi budget di commessa: si pianifica prima, non si scopre a consuntivo. Per come questa struttura si inserisce nel lavoro quotidiano di chi segue il progetto, guarda responsabile di commessa: chi è, cosa fa e cosa deve vedere, oppure prova la demo.