Work breakdown structure

Esempio di WBS applicata a un sistema aeronautico.

Con l'espressione inglese work breakdown structure (WBS), detta anche struttura di scomposizione del lavoro (traduzione letterale) o struttura analitica di progetto, si indica la scomposizione gerarchica del lavoro necessario a realizzare un progetto, articolata per deliverable e organizzata in livelli via via più dettagliati fino ai singoli pacchetti di lavoro (work package).

La WBS è uno strumento fondamentale della pratica del project management e supporta il project manager nella definizione dell'ambito, nella pianificazione, nel controllo dei costi, dei tempi e della qualità e nell'organizzazione delle attività di cui è responsabile. Molto spesso i progetti sono composti da centinaia o migliaia di attività: per facilitarne l'organizzazione esistono WBS-tipo che raccolgono le attività generiche ricorrenti in un determinato ambito applicativo, il cui insieme può essere confrontato con una checklist.

Storia

Il concetto alla base della WBS emerge nel contesto dei grandi programmi statunitensi di difesa e delle infrastrutture aerospaziali a cavallo fra gli anni cinquanta e sessanta del XX secolo. La tecnica PERT fu introdotta dalla Marina degli Stati Uniti nel 1957 per supportare lo sviluppo del programma missilistico Polaris e organizzava le attività secondo categorie orientate al prodotto, sebbene il termine work breakdown structure non fosse ancora in uso.

Nel giugno 1962 il Dipartimento della difesa statunitense e la NASA, in collaborazione con l'industria aerospaziale, pubblicarono la guida DoD and NASA Guide, PERT/Cost System Design, che descriveva il sistema PERT/Cost e introduceva formalmente l'uso di una struttura di scomposizione del lavoro. L'approccio fu poi codificato dal Dipartimento della difesa con la prima edizione dello standard militare MIL-STD-881, Work Breakdown Structures for Defense Materiel Items, pubblicata il 1º novembre 1968 e successivamente revisionata fino alle edizioni MIL-STD-881A (1975), MIL-STD-881B (1993), MIL-STD-881C (2011), MIL-STD-881D (2018) e MIL-STD-881E (2020).

Dagli anni ottanta la WBS si è progressivamente diffusa oltre l'ambito militare, adottata come strumento generale di project management dalle imprese e dalle amministrazioni pubbliche. Il Project Management Institute (PMI) ha inserito la WBS fra i concetti fondamentali della prima edizione del Guide to the Project Management Body of Knowledge (PMBOK Guide) e nel 2001 ne ha dedicato una pubblicazione autonoma, Practice Standard for Work Breakdown Structures, successivamente aggiornata nel 2006 (2ª edizione) e nel 2019 (3ª edizione). La norma internazionale ISO 21500 e la successiva ISO 21502:2020 includono la WBS fra le tecniche raccomandate per la definizione dell'ambito di progetto.

Struttura

La work breakdown structure è un albero gerarchico orientato al prodotto (o deliverable) che scompone il progetto nel materiale, nel software, nei servizi, nei dati e nelle attrezzature che lo compongono. L'albero viene strutturato sulla base dell'ingegneria di sistema sviluppata nella fase iniziale del progetto e definisce il prodotto o i prodotti da sviluppare o da produrre, mettendo in relazione fra loro e con il prodotto finale gli elementi di lavoro necessari alla sua realizzazione. La WBS può articolarsi in un numero qualsiasi di livelli; lo standard MIL-STD-881C impone come minimo obbligatorio i primi tre livelli per la rendicontazione dei programmi di acquisizione.

Ogni nodo della gerarchia è denominato Work Breakdown Element (WBE); al livello terminale della scomposizione si trovano i work package (pacchetti di lavoro), unità elementari a cui vengono associati responsabilità, durate, costi e criteri di accettazione. A supporto della WBS viene spesso redatto un WBS dictionary, in cui ogni elemento è descritto con milestone, prodotti attesi, attività, limiti e, ove utile, date, risorse, costi e requisiti di qualità.

Principi alla base della WBS

Regola del 100%

Uno dei principi fondamentali della WBS è la cosiddetta regola del 100%, formalizzata dal Practice Standard for Work Breakdown Structures del Project Management Institute. La regola stabilisce che la WBS deve rappresentare il 100% del lavoro definito dall'ambito del progetto e nulla più, e si applica ricorsivamente a ogni livello della gerarchia.

(inglese)
«The 100% Rule... states that the WBS includes 100% of the work defined by the project scope and captures ALL deliverables – internal, external, interim – in terms of the work to be completed, including project management. The 100% rule is one of the most important principles guiding the development, decomposition and evaluation of the WBS. The rule applies at all levels within the hierarchy: the sum of the work at the "child" level must equal 100% of the work represented by the "parent" and the WBS should not include any work that falls outside the actual scope of the project, that is, it cannot include more than 100% of the work. It is important to remember that the 100% rule also applies to the activity level: the work represented by the activities in each work package must add up to 100% of the work necessary to complete the work package.»
(italiano)
«La regola del 100%... precisa che la WBS debba includere il 100% del lavoro definito dal progetto e includere TUTTO il necessario - interno, esterno e appaltato - alla realizzazione del progetto, inclusa la gestione del progetto stesso. La regola del 100% è una delle più importanti linee guida per lo sviluppo, la decomposizione e la valutazione della WBS. La regola si applica a tutti i livelli della gerarchia: la somma del lavoro dei livelli "figli" deve essere uguale al 100% del lavoro rappresentato dal loro "padre" e la WBS non dovrebbe includere alcun lavoro al di fuori dai limiti del progetto, ovvero non può includere più del 100% del lavoro. È importante ricordare che la regola del 100% si applica anche al livello di attività: il lavoro rappresentato dalle attività in ciascun pacchetto di lavoro deve dare, sommato, il 100% del lavoro necessario per completare il pacchetto.»

Programmazione dei risultati, non delle azioni

Se il progettista della WBS tenta di comprendervi ogni dettaglio relativo alle azioni, tende a includerne troppe o troppo poche: troppe eccederebbero il 100% dei limiti del nodo superiore, mentre troppo poche non raggiungerebbero tale percentuale. Il modo migliore di seguire la regola del 100% è definire gli elementi della WBS in termini di risultati (deliverable-oriented), evitando di prescrivere i metodi e lasciando così più spazio al contributo creativo dei membri del gruppo di progetto.

Per i progetti di sviluppo di nuovi prodotti la tecnica più comune per ottenere una WBS rivolta ai risultati è utilizzare una product breakdown structure (PBS); la WBS può inoltre risultare dal confronto fra PBS e ABS (activity breakdown structure). I progetti software feature driven adottano tecniche analoghe basate su una feature breakdown structure; nei progetti di servizi professionali è di uso comune organizzare la WBS attorno ai prodotti rilasciabili al cliente. Le WBS strutturate per fasi di progetto (per esempio fase di progetto preliminare e fase di progetto esecutivo) devono prevedere criteri chiari di delimitazione fra le fasi, tipicamente rappresentati da milestone come l'approvazione formale del progetto preliminare o esecutivo.

Elementi reciprocamente esclusivi

In aggiunta alla regola del 100%, è importante che non vi siano sovrapposizioni nella definizione dei limiti fra due elementi della WBS. Tale ambiguità potrebbe infatti portare a duplicazioni di lavoro, fraintendimenti circa responsabilità e autorità e confusione nell'imputazione dei costi. Quando i nomi degli elementi risultano ambigui è utile ricorrere a un WBS dictionary che chiarisca le distinzioni fra i componenti, descrivendone milestone, prodotti, attività, limiti e, se rilevanti, date, risorse, costi e criteri di qualità.

Livello di dettaglio (granularità) ed elaborazione progressiva

Un quesito fondamentale nella progettazione di una WBS è quando smettere di dividere il lavoro in elementi più piccoli. Se gli elementi terminali sono troppo ampi, può risultare impossibile monitorare in modo efficace le prestazioni progettuali; se al contrario sono troppo piccoli e quindi troppo numerosi, la tracciabilità diventa onerosa, soprattutto quando il lavoro è pianificato in un futuro distante.

Un compromesso soddisfacente è offerto dalla tecnica dell'elaborazione progressiva (progressive elaboration), che consente di dettagliare la WBS via via che il lavoro procede. Una sua declinazione, adottata soprattutto nei grandi progetti, è il rolling-wave planning (pianificazione ad aggiornamento costante), che prevede il ridettaglio della pianificazione a intervalli regolari; la tecnica è analoga agli approcci iterativi delle metodologie agili come Scrum. Nella pratica un limite effettivo della granularità della WBS può considerarsi raggiunto quando non è più possibile definire risultati di progetto pianificati e i soli dettagli rimanenti sono azioni; a meno che tali azioni non possano essere ridefinite in coerenza con la regola del 100%, la WBS non dovrebbe essere ulteriormente suddivisa.

Schema di codifica

È di uso comune numerare gli elementi della WBS in ordine sequenziale per metterne in evidenza la struttura gerarchica. Per esempio, 1.3.2 Ruota Posteriore identifica l'oggetto come elemento di livello 3, poiché sono presenti tre numeri separati da un punto decimale. Lo schema di codifica agevola inoltre l'identificazione degli elementi della WBS in ogni contesto scritto e nei sistemi informatici di gestione del progetto.

Esempio di costruzione di una WBS

Figura 1: Tecnica di costruzione di una WBS. Esempio liberamente ispirato al Practice Standard for Work Breakdown Structures (2ª ed., PMI, 2006), che illustra un metodo oggettivo di applicazione della regola del 100% durante la costruzione di una WBS.

La Figura 1 mostra una tecnica di costruzione di una WBS che dimostra quantitativamente la regola del 100%. All'inizio del processo di pianificazione, il project manager ha assegnato 100 punti all'intero progetto, che consiste nella progettazione e realizzazione di una bicicletta personalizzata. Al livello 2 della WBS i 100 punti totali sono suddivisi in sette elementi comprensivi. Il numero di punti allocato a ognuno è frutto di un giudizio basato sullo sforzo richiesto e non rappresenta una stima del tempo occorrente. I tre elementi di dimensioni maggiori del livello 2 sono suddivisi al livello 3, e così via: l'elemento terminale più grande del terzo livello rappresenta solamente il 17% del totale del progetto. Questi elementi possono essere ulteriormente suddivisi ricorrendo alla tecnica di elaborazione progressiva descritta sopra.

Talvolta lo schema di codifica WBS include un carattere di sottolineatura (_) al termine del nome per identificare gli elementi terminali. Si tratta di un sistema utile poiché le attività pianificate (per esempio «installare la camera d'aria e lo pneumatico») sono assegnate agli elementi terminali e non ai nodi superiori.

Questo metodo quantitativo è collegato alla tecnica dell'earned value management, descritta nella voce dedicata alle metriche di progetto.

È buona pratica avviare la costruzione della WBS con un software interattivo, per esempio un foglio elettronico, in grado di sommare automaticamente i punteggi assegnati. Un'ulteriore prassi raccomandata è discutere la stima dei punteggi con gli altri membri del gruppo di progetto: la tecnica collaborativa aumenta la conoscenza dei limiti degli elementi e dei presupposti, e per una buona gestione del progetto il consenso circa il livello di granularità è necessario.

Errori e malintesi comuni

Una WBS non è una lista completa di lavori, bensì una classificazione dell'ambito del progetto orientata ai risultati.

Una WBS non è una pianificazione del progetto né una lista in ordine cronologico. Perché una toolbox di pianificazione sia completa, al processo iterativo di composizione/scomposizione (il ciclo top-down → bottom-up e viceversa) di attività/produzioni (ABS, Activity Breakdown Structure; PBS, Product Breakdown Structure) e all'assegnazione delle responsabilità rispetto alla OBS (Organizational Breakdown Structure) devono seguire:

  1. l'allocazione delle risorse, consistente nel calcolo dei fabbisogni tempificati relativi alle assegnazioni; essa determina, per ciascuna assegnazione: a) l'inizio, b) la fine, c) la produzione complessiva sulla base della produttività (normalmente espressa in ore/periodo) accertata, d) il costo complessivo e il costo periodico;
  2. la schedulazione delle attività (o, meglio, delle assegnazioni) basata su quattro elementi, dei quali due necessari (il calendario e la durata di ciascuna attività/risorsa/assegnazione) e due eventuali (le relazioni di dipendenza e i vincoli temporali specifici).

È sconsigliabile e considerato controproducente pianificare un progetto (per esempio utilizzando un software di project management) prima di aver progettato una WBS appropriata: sarebbe come voler pianificare le attività di un cantiere edile prima di completare il progetto dell'edificio. Senza concentrarsi sui risultati del progetto è molto difficile rispettare la regola del 100% a ogni livello della gerarchia della WBS, e non è possibile recuperare una WBS con definizioni improprie senza rifarla dal principio: per questo vale sempre la pena di completarla prima di avviare qualunque altra attività di pianificazione.

Una WBS non è una gerarchia organizzativa. Talvolta i principianti creano una WBS fedele alla struttura organizzativa dell'ente esecutore, mentre è più corretto assegnare la responsabilità dei WBE a elementi organizzativi tramite strumenti dedicati come la matrice delle responsabilità (matrice RACI): una WBS che rispecchi la struttura organizzativa non è descrittiva del progetto e non è orientata ai risultati.

La capacità della memoria a breve termine non dovrebbe influenzare la dimensione della struttura ad albero di una WBS. Alcune fonti suggeriscono di limitare ogni livello a 5-9 elementi in base al presunto limite teorico della memoria umana. Si ritiene tuttavia che questo consiglio derivi da un'applicazione impropria delle teorie sui principi cognitivi (si veda Il magico numero sette, più o meno due), poiché gli elementi di una WBS non sono dati interconnessi in modo casuale, e la documentazione definitiva sulla WBS non riporta tale raccomandazione. È molto più importante costruire un raggruppamento logico di risultati pianificati che preoccuparsi dei limiti della memoria umana a breve termine.

In questa prospettiva può essere utile realizzare una mappa mentale prima della WBS: essendo uno strumento di creatività, aiuta a portare in luce aspetti che potrebbero rimanere reconditi con un approccio esclusivamente logico-razionale. La realizzazione può essere affidata al singolo come al gruppo di lavoro; in ogni caso è importante tenere presente il principio secondo cui «la mappa non è il territorio», per cui la mappa mentale descriverà in modo parziale l'articolazione del discorso e servirà soprattutto a focalizzare l'attenzione sulla preparazione delle attività. Si noti che, benché la WBS abbia uno scopo più denotativo, anche per essa vale il principio del dualismo mappa-territorio.

Al di là della progressiva elaborazione dei dettagli, gli aggiornamenti della WBS richiedono un controllo formale dei cambiamenti (change control). Questa è un'ulteriore ragione per cui una WBS dovrebbe essere orientata alla produzione di risultati (deliverable-oriented) e non alle prescrizioni di metodi: i metodi possono cambiare rapidamente, mentre le modifiche nei risultati pianificati richiedono un maggiore grado di formalità. Se risultati e azioni si confondono, il controllo dei cambiamenti rischia di essere troppo rigido per le azioni e troppo informale per i risultati.

Note

Annotazioni
  1. ↑ Sono relazioni di dipendenza tipiche: FS = finish-to-start; SS = start-to-start; SF = start-to-finish; FF = finish-to-finish; SSL = start-to-start with lag; FSL = finish-to-start with lead.
  2. ↑ Sono vincoli temporali tipici: MSO = must-start-on; MFO = must-finish-on; SNET = start-no-earlier-than; FNET = finish-no-earlier-than; SNLT = start-no-later-than; FNLT = finish-no-later-than. Tali vincoli si classificano come rigidi (MSO, MFO) o semi-rigidi (SNET, FNET, SNLT, FNLT) in contrapposizione ai vincoli totalmente flessibili ASAP = as-soon-as-possible e ALAP = as-late-as-possible.
Fonti
  1. 1 2 3 4 5 Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK Guide), 6ª, Newtown Square (PA), Project Management Institute, 2017, ISBN 978-1-62825-184-5. La WBS è definita come «hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables».
  2. 1 2 WBS (Work Breakdown Structure): cos'è e come si utilizza, su BibLus, ACCA software. URL consultato il 20 settembre 2026.
  3. 1 2 3 4 5 La WBS - L'architettura del Tuo Progetto, su PMI Northern Italy Chapter, Project Management Institute. URL consultato il 20 settembre 2026.
  4. 1 2 3 (EN) Mosaic Project Services, The Origins and History of Work Breakdown Structures (PDF), su mosaicprojects.com.au, 9 dicembre 2020. URL consultato il 20 settembre 2026.
  5. 1 2 3 4 5 6 (EN) Department of Defense, Department of Defense Standard Practice — Work Breakdown Structures for Defense Materiel Items (MIL-STD-881C) (PDF), su secnav.navy.mil, 3 ottobre 2011. URL consultato il 20 settembre 2026.
  6. ↑ (EN) MIL-STD-881 – Work Breakdown Structures for Defense Materiel Items, su ASSIST-QuickSearch, Defense Logistics Agency. URL consultato il 20 settembre 2026.
  7. 1 2 3 4 5 6 7 8 9 10 11 12 13 (EN) Practice Standard for Work Breakdown Structures – Second Edition, su PMI Learning Library, Project Management Institute. URL consultato il 20 settembre 2026.
  8. 1 2 (EN) Practice Standard for Work Breakdown Structures – Third Edition, su Project Management Institute, 2019-07. URL consultato il 20 settembre 2026.
  9. ↑ (EN) ISO 21502:2020 – Project, programme and portfolio management — Guidance on project management, su iso.org, International Organization for Standardization, 2020-12. URL consultato il 20 settembre 2026.
  10. 1 2 Antonio Nepi, Introduzione al Project Management. Che cos'è, come si applica, tecniche e metodologie, 3ª ampliata, Milano, Guerini e Associati, 2006, pp. 121-128, ISBN 9788883357701.

Bibliografia

Voci correlate

Altri progetti

Collegamenti esterni

  Portale Ingegneria: accedi alle voci di Wikipedia che trattano di ingegneria