Work Breakdown Structure (WBS): esempi e come crearla

Che cos'è una work breakdown structure (WBS)?

A work breakdown structure (WBS) è una scomposizione gerarchica e orientata ai deliverable dell'intero ambito di un progetto in parti via via più piccole. Il livello superiore è l'intero progetto; ogni livello sottostante suddivide il proprio elemento padre in componenti, fino ai work package che possono essere stimati, assegnati e monitorati. Una WBS mostra *cosa* sarà consegnato, non quando né come.

La Guida PMBOK del PMI definisce la WBS come una scomposizione gerarchica dell'intero ambito del lavoro che il team di progetto deve svolgere per raggiungere gli obiettivi del progetto e creare i deliverable richiesti. Nel framework del PMI, la dichiarazione dell'ambitoapprovata, la WBS e il dizionario WBS formano insieme la baseline dell'ambito, che è il punto di riferimento per misurare e controllare l'ambito.

La tecnica affonda le radici nei grandi programmi della difesa e spaziali statunitensi, e il Dipartimento della Difesa USA mantiene ancora uno standard WBS (MIL-STD-881). Il PMI pubblica anche un apposito *Practice Standard for Work Breakdown Structures*. Non serve però un progetto delle dimensioni della difesa per trarne vantaggio: una semplice WBS a tre livelli su una lavagna è spesso sufficiente per un piccolo team.

Una WBS viene di solito disegnata come diagramma ad albero (simile a un organigramma) oppure scritta come schema numerato e rientrato o come tabella. Entrambe le forme mostrano la stessa cosa: l'intero progetto scomposto in parti che sommano esattamente al tutto.

Perché una WBS è importante

Una WBS richiede poche ore per essere costruita e si ripaga per tutta la durata del progetto. Ti aiuta a:

• Vedere l'ambito completo. Scomporre il lavoro fa emergere deliverable che altrimenti verrebbero dimenticati, come formazione, migrazione dei dati o documentazione.
• Stimare con maggiore precisione. Work package piccoli e ben definiti sono molto più facili da stimare di un intero progetto. Consulta la nostra guida alle stima dei costi.
• Assegnare responsabilità chiare. Ogni work package ha un unico responsabile, il che rende visibile l'accountability. Una matrice RACI può associare i ruoli agli elementi della WBS.
• Costruire cronoprogramma e budget. Attività, durate e costi vengono pianificati per work package e risalgono lungo la WBS.
• Controllare l'ambito. Il lavoro che non trova posto nella WBS è un segnale di scope creep.
• Identificare i rischi. Passare in rassegna ogni elemento è un modo strutturato per chiedersi "cosa potrebbe andare storto qui?"
• Comunicare. Un diagramma WBS di una pagina offre a sponsor e team un quadro condiviso di ciò che il progetto comprende.

La WBS è una parte centrale del piano di project management: cronoprogramma, baseline dei costi e piano delle risorse sono tutti organizzati attorno a essa.

Regole chiave per una buona WBS

La regola del 100%

Il regola del 100% è il principio più importante. La WBS include il 100% del lavoro definito dall'ambito del progetto, compreso il lavoro di project management, e nulla al di fuori di esso. Si applica a ogni livello: i figli di qualsiasi elemento devono sommare esattamente al 100% del lavoro di quell'elemento, né più né meno. Se un elemento figlio contiene lavoro che non fa parte del padre, è fuori ambito; se i figli non coprono tutto il padre, manca qualcosa.

Deliverable, non attività

Denomina gli elementi della WBS con sostantivi che descrivono risultati ("Integrazione dei pagamenti", "Guida utente", "Sede") anziché con verbi che descrivono azioni ("Integrare i pagamenti", "Scrivere la guida", "Prenotare la sede"). Gli elementi orientati ai deliverable rendono più facile verificare la completezza e definire i criteri di accettazione. Le attività necessarie per produrre ciascun work package vengono elencate in seguito, nel cronoprogramma.

Elementi mutuamente esclusivi

Nessuna parte di lavoro dovrebbe comparire in due punti. Le sovrapposizioni portano a stime conteggiate due volte, responsabilità confuse e discussioni su chi fa cosa.

Scomponi al livello giusto

Smetti di scomporre quando un work package è abbastanza piccolo da essere stimato in modo affidabile, assegnato a un unico responsabile e monitorato, ma non così piccolo che gestirlo richieda più impegno che svolgerlo. Le regole empiriche più comuni (non standard formali) includono:

• La regola 8/80: un work package dovrebbe richiedere all'incirca tra 8 e 80 ore di impegno.
• La regola del periodo di reporting: un work package non dovrebbe estendersi oltre uno o due periodi di reporting, così l'avanzamento è visibile.
• La regola del "se ha senso": scomponi ulteriormente solo se migliora la stima, l'assegnazione o il controllo.

La maggior parte dei progetti richiede tre o quattro livelli. I grandi programmi possono richiederne di più, e i progetti piccoli possono averne bisogno solo di due.

Un responsabile per work package

Ogni work package dovrebbe avere un unico responsabile, anche se più persone vi contribuiscono. Una responsabilità condivisa di solito significa nessuna responsabilità.

Livelli e componenti della WBS

I livelli della WBS sono numerati dall'alto. Le etichette esatte variano tra le organizzazioni, ma una struttura tipica è la seguente:

Attività e task si collocano sotto i work package, ma appartengono al cronoprogramma di progetto anziché alla WBS stessa. La nostra guida a attività e task di progetto spiega la differenza.

Altri componenti che incontrerai:

• Codici WBS: uno schema di numerazione (1, 1.1, 1.1.1) che assegna a ogni elemento un identificativo univoco e mostra dove si colloca nella gerarchia. I codici collegano la WBS a cronoprogramma, budget e timesheet.
• Work package: il livello più basso della WBS, dove si stimano impegno, costi e durata e si assegna il lavoro. Consulta la nostra guida ai work package.
• Control account: punti di gestione sopra i work package in cui si confrontano ambito, budget e costo effettivo, spesso usati con l' earned value management.
• Planning package: segnaposto per lavoro che si sa essere nell'ambito ma non ancora abbastanza dettagliato da essere suddiviso in work package.
• Dizionario WBS: il documento di accompagnamento che descrive ciascun elemento nel dettaglio (trattato più avanti).

È nei work package che il piano diventa lavoro reale.

Tipi di work breakdown structure

La scelta principale riguarda come organizzare il livello 2. I due approcci più comuni sono quello basato sui deliverable e quello basato sulle fasi.

Molti team usano un approccio ibrido: fasi al livello 2 e deliverable al livello 3. Qualunque sia la scelta, applicala in modo coerente a ogni livello. Altre opzioni di organizzazione includono la localizzazione (siti o edifici), il sottosistema (ingegneria) o l'unità organizzativa, anche se organizzare per reparto tende a far perdere il focus sui deliverable.

Puoi presentare la stessa WBS in diversi formati:

• Diagramma ad albero: ideale per comunicare i primi tre livelli a sponsor e team.
• Schema: un elenco numerato e rientrato; rapido da creare e modificare.
• Tabella o foglio di calcolo: una riga per elemento con codice, responsabile, impegno e costo; ideale per il dettaglio e le aggregazioni.
• In uno strumento di schedulazione: la WBS diventa la struttura delle attività di riepilogo di un diagramma di Gantt.

Esempi di work breakdown structure

Questi esempi mostrano gli stessi principi applicati a diversi tipi di progetto. Usali come punto di partenza e adatta gli elementi al tuo ambito.

Esempio 1: portale clienti (basato sui deliverable)

Questo rispecchia l'esempio del nostro modello WBSgratuito, in cui impegno e costo inseriti per ogni elemento si sommano nel totale del progetto.

Esempio 2: lo stesso progetto, basato sulle fasi

La versione basata sulle fasi è più comoda per le revisioni stage-gate, ma nota che i deliverable principali sono nascosti dentro "Esecuzione". Servirebbe un ulteriore livello per renderli visibili.

Esempio 3: trasferimento di un ufficio

Nota il deliverable facilmente dimenticato al punto 1.6. Lasciare la vecchia sede è lavoro reale con costi reali, e una WBS lo rende visibile per tempo.

Esempio 4: conferenza

Come creare una work breakdown structure

Segui questi passaggi per costruire una WBS per qualsiasi progetto. Per un progetto piccolo puoi farlo in un unico workshop; i progetti più grandi possono richiedere più sessioni.

1. Parti dall'ambito approvato. Raccogli il project charter, la dichiarazione dell'ambito, i requisiti e l'eventuale contratto o statement of work. Non puoi scomporre un ambito che non è stato definito.
2. Definisci il livello 1. Scrivi in cima il deliverable finale o il nome del progetto.
3. Scegli come organizzare il livello 2. Decidi tra deliverable principali e fasi (vedi sopra), e includi un ramo di project management.
4. Scomponi ogni elemento. Suddividi ogni elemento di livello 2 nei suoi deliverablecomponenti. Chiediti "da cosa è composto?" anziché "cosa dobbiamo fare?"
5. Fermati ai work package. Continua finché ogni elemento di livello più basso può essere stimato, assegnato a un unico responsabile e monitorato entro un periodo di reporting.
6. Applica la regola del 100%. Per ogni elemento padre, verifica che i figli coprano tutto il suo lavoro e nient'altro. Cerca lacune e sovrapposizioni.
7. Numera gli elementi. Assegna a ogni elemento un codice WBS univoco, in modo che possa essere richiamato nel cronoprogramma, nel budget e nei report.
8. Scrivi il dizionario WBS. Descrivi ogni work package: ambito, deliverable, criteri di accettazione, responsabile, assunzioni e stime.
9. Rivedila con il team e gli stakeholder. Le persone che svolgono il lavoro individuano elementi mancanti e suddivisioni irrealistiche; gli stakeholder confermano che nulla è fuori ambito.
10. Fissa la baseline e mantienila. Una volta approvata, la WBS entra a far parte della baseline dell'ambito. Aggiornala solo tramite il controllo delle modifiche.

Il dizionario WBS

A Dizionario WBS è il documento di accompagnamento della WBS. La WBS mostra la struttura; il dizionario spiega ogni elemento affinché tutti capiscano esattamente cosa è incluso. È particolarmente utile per i work package, per i quali funge da mini-brief per il responsabile.

Una voce del dizionario include tipicamente:

• Codice WBS e nome dell'elemento.
• Descrizione del lavoro e di cosa è incluso ed escluso.
• Deliverable e criteri di accettazione.
• Responsabile (persona o organizzazione).
• Stime di impegno, costo e durata.
• Milestone e dipendenze principali.
• Assunzioni, vincoli e rischi noti.
• Risorse, requisiti di qualità e riferimenti.

Esempio di voce del dizionario

Per i work package più grandi puoi ampliare la voce in una descrizione completa del work package usando il nostro modello di work package.

Dalla WBS al cronoprogramma e al budget

La WBS non è un cronoprogramma, ma ne è l'input. Una volta concordata la WBS:

1. Elenca le attività necessarie per produrre ciascun work package.
2. Identificare dipendenze tra attività tra le attività.
3. Stima durate e impegno; la nostra guida alla stima dell'impegno spiega le tecniche principali.
4. Costruisci il cronoprogramma, individua il percorso critico e aggiungi le milestone.
5. Stima il costo per work package e aggregalo nel budget di progetto.

È utile avere chiaro quale documento risponde a quale domanda:

La schedulazione è il passo naturale successivo alla WBS.

Usare una WBS nei progetti Agile

La Scrum Guide non menziona la WBS, e i team Agile lavorano di solito a partire da un Product Backlog ordinato. L'idea di fondo, scomporre un risultato ampio in parti di valore più piccole, resta però pienamente parte di Agile.

Secondo la nostra esperienza, una gerarchia di backlog fatta di temi, epic, feature e user story svolge un ruolo simile a una WBS basata sui deliverable, con due differenze chiave: è ordinata per valore anziché strutturata per completezza, e si prevede che cambi man mano che il team impara.

Una WBS leggera e di alto livello può comunque aiutare i progetti Agile e ibridi:

• Per concordare ambito complessivo e budget con uno sponsor prima del primo Sprint.
• Per mostrare deliverable non software, come formazione, migrazione dei dati o approvvigionamenti, che potrebbero non comparire in un backlog.
• Per supportare la pianificazione a onda mobile: il lavoro a breve termine viene scomposto in dettaglio, mentre quello successivo resta sotto forma di planning package.
• Per integrare i team Agile in un programma più ampio che riferisce rispetto a una WBS.

Errori comuni nella WBS

Modello e strumenti per la WBS

Il nostro modello di WBS è disponibile in Google Sheets, Excel e PDF. Include colonne per codice WBS, livello, deliverable o work package, descrizione, responsabile, impegno (giorni), costo e stato, con impegno e costo che si sommano nel totale del progetto. Abbinalo al modello di stima dei costi di progetto per la stima dettagliata dei costi e al Modello di diagramma di Gantt per trasformare i work package in un cronoprogramma.

La maggior parte dei software di project management può contenere una WBS come attività annidate o attività di riepilogo con numerazione automatica, mantenendo sincronizzati WBS e cronoprogramma. Le nostre guide ai software per diagrammi di Gantt e i nostri classifiche dei software di project management confrontano le opzioni.

Modelli gratuiti per questo argomento

Sfoglia tutti i modelli

Domande frequenti