---
title: "Work breakdown structure (WBS): come costruirla e trasformarla in un cronoprogramma"
description: "Come costruire una WBS attorno ai deliverable, quando le fasi al livello 2 hanno senso e come 14 pacchetti di lavoro diventano un piano di 27 giorni."
url: https://planitude.app/it/blog/work-breakdown-structure-guide
language: it
---

# Work breakdown structure (WBS): come costruirla e trasformarla in un cronoprogramma

Come costruire una WBS attorno ai deliverable, quando le fasi al livello 2 sono giustificate e come una WBS di 14 pacchetti diventa un piano di 27 giorni con responsabili e margine.

di Team Planitude · Pubblicato il 20 ottobre 2026

Quando un piano dimentica i redirect delle vecchie pagine di documentazione, o la formazione a cui nessuno ha pensato, le date sono sbagliate prima ancora che parta la prima attività. La **work breakdown structure** (WBS) è il punto in cui si scopre quel lavoro mancante. Divide il progetto in ciò che deve consegnare, prima che qualcuno parli di date.

Questa guida presenta i due test che mantengono completa una WBS, la profondità giusta e il motivo per cui la maggior parte dei team piccoli dovrebbe tenere le fasi fuori dal livello 2. Poi segue il lancio di un centro assistenza, da una WBS di 14 pacchetti a un piano di 27 giorni, compresi i legami tra i deliverable.

> **In breve**
>
> - Il lavoro che non è nella WBS non fa parte del progetto.
> - Due test mantengono completo l’albero. I figli di un elemento coprono **tutto** il suo ambito e nessun pezzo di lavoro compare in due posti.
> - Per un team da tre a dieci persone, metti i deliverable al livello 2 e mostra le fasi come milestone. Un contratto pagato fase per fase è l’eccezione.
> - Ogni pacchetto di lavoro diventa almeno un’attività prima di inserire dipendenze e durate. Nell’esempio, 14 pacchetti diventano 16 righe di piano e un piano di 27 giorni il cui percorso critico attraversa quattro rami su cinque.

## Che cos’è una work breakdown structure

Una work breakdown structure è una gerarchia che divide un progetto nei deliverable che deve produrre, e ogni deliverable in parti di lavoro più piccole che si possono stimare e assegnare. Il manuale WBS della NASA la definisce «un albero genealogico orientato al prodotto che identifica hardware, software, servizi e tutti gli altri deliverable necessari a raggiungere l’obiettivo finale del progetto»[^1].

Il livello 1 è il progetto e il livello 2 contiene i deliverable principali. Ogni livello successivo divide un elemento in parti, fino ai **pacchetti di lavoro**, ciascuno «l’unità di lavoro necessaria a completare un compito specifico»[^1]. Nei grandi programmi costi e tempi si controllano un livello più in alto, nel control account, che può contenere più pacchetti di lavoro[^1]. Con tre-dieci persone i due coincidono e il pacchetto di lavoro è il punto in cui si indica un responsabile.

L’albero non ha date né sequenza. Quelle arrivano nel piano, costruito a partire dai pacchetti di lavoro in fondo a ogni ramo.

## Due test che mantengono completa una WBS

Il primo test nasce da una frase del manuale NASA: «L’ambito di lavoro non contenuto nella WBS del progetto non dovrebbe essere considerato parte del progetto»[^1]. Applicato a ogni elemento, diventa una domanda pratica. Se tutti i figli sono finiti, è finito anche il padre? Una risposta che comincia con «sì, tranne» ha trovato un elemento mancante. Anche il lavoro abilitante fa parte dell’ambito, e la checklist di sviluppo della NASA cita esplicitamente la gestione del progetto[^1].

Il secondo test intercetta i duplicati. Costi e tempi devono aggregarsi dagli elementi più bassi «senza assegnare un singolo elemento di lavoro a due o più elementi WBS»[^1]. Nei piani su foglio di calcolo il segnale tipico è una riga incollata sotto due titoli, come «Guida utente» sotto Sviluppo e di nuovo sotto Formazione, con due stime e due percentuali di completamento.

Un dizionario WBS colma i vuoti che i nomi brevi degli elementi lasciano aperti, e la NASA ne prepara uno in parte per «eliminare duplicazioni e sovrapposizioni nelle assegnazioni di lavoro»[^1]. In un progetto piccolo bastano tre o quattro righe per pacchetto di lavoro. Una voce tipica dell’esempio che segue:

*1.1.5 Articoli pubblicati. Ambito: 23 articoli approvati caricati e collegati tra loro. Escluso: traduzioni e video. Responsabile: redattore tecnico. Finito quando: ogni articolo ha un URL pubblico ed è restituito dalla ricerca del centro assistenza.*

Quest’ultima riga conta più avanti, perché lega il ramo dei contenuti a quello della piattaforma.

## Deliverable, fasi o reparti al livello 2

Il livello 2 si può costruire attorno a ciò che il progetto produce (Contenuti, Piattaforma, Integrazione, Lancio), attorno al tempo (Progettazione, Sviluppo, Test, Rilascio) o attorno a chi svolge il lavoro. Solo il primo mostra che cosa esiste alla fine del progetto. Le fasi ripetono ciò che il diagramma di Gantt già mostra lungo le barre, e i reparti perdono il lavoro che cade tra due di loro.

La NASA elenca Progettazione, Ingegneria e Fase A tra gli elementi che «non sono prodotti e in genere non dovrebbero essere usati» come suddivisioni della WBS, essendo la Fase A «un arco di tempo»[^1]. I suoi controesempi basati su fasi e funzioni portano la stessa didascalia, «Questo approccio non è raccomandato»[^1]. La stessa sezione indica la spinta che porta agli alberi per reparto. Le persone chiedono «Dove sono io in questa WBS?» e vogliono elementi che rispecchino la propria area di responsabilità, un errore che il manuale invita a evitare[^1]. La responsabilità va in una matrice separata che incrocia la WBS con l’organigramma[^1], e in un progetto da tre persone quella matrice è una colonna Responsabile.

## Perché i team piccoli mettono le fasi al livello 2, e quando hanno ragione

I team piccoli finiscono spesso con Progettazione, Sviluppo, Test e Rilascio al livello 2, soprattutto quando albero e piano si costruiscono nella stessa griglia nello stesso pomeriggio e le righe di riepilogo diventano contenitori di tempo. Il conto arriva settimane dopo. I redirect delle vecchie pagine non appartengono né a Progettazione né a Sviluppo, quindi in un albero per fasi nessuno li stima.

**Il nostro consiglio:** per un team da tre a dieci persone, metti i deliverable al livello 2 e mostra le fasi come milestone nel piano. Il diagramma di Gantt mostra già il tempo, quindi un livello di fasi lo ripete. Un livello di deliverable risponde a colpo d’occhio a «il centro assistenza è completo?» e permette di leggere lo stato settimanale deliverable per deliverable.

L’eccezione è un contratto approvato e pagato fase per fase, come una discovery a prezzo fisso seguita da uno sviluppo finanziato a parte. Collaudo e fatturazione richiedono un totale per fase, e l’approvazione del cliente sblocca la fase successiva. Con le fasi al livello 2 quel totale è una riga di riepilogo invece di una somma manuale.

## Quanti livelli, e come numerarli

La NASA lega il numero di livelli a «le dimensioni e la complessità dell’impegno complessivo, il grado di incertezza tecnica, le strutture organizzative coinvolte e il giudizio della direzione sulla necessità»[^1], e non tutti i rami devono fermarsi alla stessa profondità. Come regola pratica, tre livelli bastano per un team da tre a dieci persone su due o tre mesi, con i pacchetti di lavoro direttamente sotto i deliverable. Il limite è la riunione settimanale di stato: a uno o due minuti per pacchetto, 15-20 pacchetti riempiono mezz’ora. Scendi a un quarto livello su un ramo quando un pacchetto richiederebbe due responsabili, o quando la sua stima pessimistica è più del doppio di quella ottimistica. La stessa decisione un livello più in basso, dentro il piano, è trattata in [quando dividere un’attività in sottoattività](https://planitude.app/it/blog/when-to-split-task-into-subtasks).

I codici decimali indicano il livello di un elemento e l’elemento a cui appartiene. Il codice 1.2.3 sta al livello 3 sotto 1.2. Una volta condiviso il piano, i report di stato e i ticket citano quei codici, quindi un nuovo elemento va in fondo al suo ramo, come 1.3.3 dopo 1.3.2, anche se starebbe meglio in mezzo.

## Un esempio concreto: il lancio di un centro assistenza

Un’azienda software sostituisce un manuale PDF e un insieme di vecchie pagine di documentazione con un centro assistenza pubblico. Il team è composto da un redattore tecnico, uno sviluppatore front-end e il responsabile del supporto, che gestisce anche il progetto. La prima versione è solo in inglese.

La prima bozza della WBS aveva 10 pacchetti di lavoro. Leggendo ogni ramo con il primo test ne sono comparsi quattro in più. Nessuno aveva approvato le bozze, le vecchie pagine salvate nei preferiti si sarebbero rotte al go-live, il prodotto avrebbe continuato a puntare al PDF e il supporto avrebbe continuato a rispondere ai ticket con il vecchio manuale.

| Livello 2 | Pacchetti di lavoro (livello 3) |
| --- | --- |
| 1.1 Contenuti | 1.1.1 Inventario degli articoli, 1.1.2 Bozze degli articoli (23), 1.1.3 Screenshot, 1.1.4 Revisione e approvazione degli articoli, 1.1.5 Articoli pubblicati |
| 1.2 Piattaforma | 1.2.1 Configurazione del centro assistenza, 1.2.2 Tema e branding, 1.2.3 Ricerca e analytics, 1.2.4 Test di accettazione |
| 1.3 Integrazione nel prodotto | 1.3.1 Link alla guida nell’app, 1.3.2 Redirect dalla vecchia documentazione |
| 1.4 Lancio | 1.4.1 Formazione del team di supporto, 1.4.2 Annuncio del lancio |
| 1.5 Gestione del progetto | 1.5.1 Pianificazione e stato settimanale |

Il go-live non è nell’albero perché non ha un ambito proprio; segna solo il momento in cui il lavoro precedente è finito. Entra nel piano come milestone, come «Contenuti approvati».

Ogni pacchetto di lavoro diventa un’attività con un nome che inizia con un verbo, in linea con la regola della NASA per cui il livello più basso di ogni elemento «dovrebbe avere almeno un compito o un’attività»[^1]. Le durate sono in giorni lavorativi e ogni legame è fine-inizio (la guida a [dipendenze tra attività e anticipo/ritardo](https://planitude.app/it/blog/task-dependencies-fs-ss-ff-sf-lag) tratta gli altri tre tipi). Le due milestone stanno in fondo ai rispettivi rami, così uno strumento che numera ogni riga mantiene i codici dei pacchetti di lavoro della WBS.

| WBS | Attività | Responsabile | Durata | Predecessori | Giorni | Margine totale |
| --- | --- | --- | --- | --- | --- | --- |
| 1.1.1 | Costruire l’inventario degli articoli | Redattore | 2 | nessuno | 1–2 | 0 |
| 1.1.2 | Scrivere 23 articoli | Redattore | 11 | 1.1.1 | 3–13 | 0 |
| 1.1.3 | Fare gli screenshot | Redattore | 3 | 1.1.2 | 14–16 | 0 |
| 1.1.4 | Rivedere e approvare gli articoli | Resp. supporto | 3 | 1.1.3 | 17–19 | 0 |
| 1.1.5 | Pubblicare gli articoli | Redattore | 2 | Contenuti approvati, 1.2.3 | 20–21 | 0 |
| fine 1.1 | Contenuti approvati (milestone) |  | 0 | 1.1.4 | fine giorno 19 | 0 |
| 1.2.1 | Configurare il centro assistenza | Sviluppatore | 4 | nessuno | 1–4 | 10 |
| 1.2.2 | Applicare tema e branding | Sviluppatore | 3 | 1.2.1 | 5–7 | 10 |
| 1.2.3 | Configurare ricerca e analytics | Sviluppatore | 2 | 1.2.2 | 8–9 | 10 |
| 1.2.4 | Eseguire il test di accettazione | Resp. supporto | 2 | 1.3.1, 1.3.2 | 25–26 | 0 |
| 1.3.1 | Aggiungere i link alla guida nell’app | Sviluppatore | 3 | 1.1.5 | 22–24 | 0 |
| 1.3.2 | Impostare i redirect | Sviluppatore | 2 | 1.1.1, 1.2.3 | 10–11 | 13 |
| 1.4.1 | Formare il team di supporto | Resp. supporto | 2 | Contenuti approvati | 20–21 | 5 |
| 1.4.2 | Annunciare il lancio | Resp. supporto | 1 | Go-live | 27 | 0 |
| fine 1.4 | Go-live (milestone) |  | 0 | 1.2.4, 1.4.1 | fine giorno 26 | 0 |
| 1.5.1 | Pianificare e fare report settimanale | Resp. supporto | attività di supporto | copre tutto il progetto | 1–27 | n/d |

La pubblicazione aspetta la ricerca perché il dizionario dice che un articolo è finito solo quando la ricerca lo restituisce. Senza quel legame, ricerca e analytics mostrerebbero 13 giorni di margine e potrebbero slittare oltre la pubblicazione senza che nessuno se ne accorga.

La gestione del progetto (1.5.1) è un’attività di supporto (level of effort): va dal giorno 1 al giorno 27 a poche ore a settimana e non governa nulla, quindi resta fuori dalla lettura del percorso critico. I redirect usano gli slug concordati nell’inventario e aspettano la ricerca solo perché li fa lo stesso sviluppatore. I link nell’app aspettano gli URL pubblicati perché escono con un rilascio del prodotto, e un link sbagliato richiede un altro rilascio.

Il progetto dura **27 giorni lavorativi**. Il percorso critico passa da inventario, bozze, screenshot, revisione, pubblicazione, link nell’app, test di accettazione e annuncio, 2 + 11 + 3 + 3 + 2 + 3 + 2 + 1 = 27 giorni, e attraversa quattro rami su cinque. Un report di stato per deliverable mostrerebbe la Piattaforma quasi finita al giorno 9, con tre pacchetti su quattro conclusi, mentre il pacchetto che decide la data, il test di accettazione, non può iniziare prima del giorno 25. Configurazione, tema e ricerca hanno 10 giorni di margine, i redirect 13, la formazione 5.

Le bozze portano il rischio maggiore: ventitré articoli in 11 giorni sono poco più di due al giorno per un solo redattore, e ogni giorno di slittamento sposta il go-live. Meritano una stima a tre punti ([stimare la durata delle attività](https://planitude.app/it/blog/how-to-estimate-task-durations)); la [guida al percorso critico](https://planitude.app/it/blog/critical-path-method-guide) spiega i passaggi che stanno dietro ai valori di margine.

La verifica del carico di lavoro trova un buco: lo sviluppatore non ha nulla in programma dal giorno 12 al giorno 21. Basta concordare gli slug quando l’inventario è finito, togliere i link nell’app dalla pubblicazione (predecessori 1.1.1 e 1.3.2) e farli girare nei giorni 12-14. La pubblicazione si collega allora direttamente al test di accettazione, che parte al giorno 22. Il go-live si sposta a fine giorno 23 e l’annuncio al giorno 24. È il fast-tracking ([come recuperare un progetto in ritardo](https://planitude.app/it/blog/project-delay-recovery-fast-tracking-crashing)), e allarga la scommessa sugli slug dell’inventario ai link rilasciati nel prodotto, dove uno slug rinominato richiede un rilascio per essere corretto.

## Errori comuni

- **Riusare la WBS dell’ultimo progetto senza cambiarla.** La NASA mette in guardia dal portarsi dietro «eventuali errori o caratteristiche indesiderate della WBS precedente»[^1]. Parti da quella se aiuta, poi ripeti il primo test sull’ambito di questo progetto.
- **Elementi chiamati «Riunioni» o «Rifacimenti».** Nessuno dei due è qualcosa che il progetto produce, e il rifacimento è nell’elenco NASA dei termini che non sono prodotti[^1]. Il tempo delle riunioni va nella gestione del progetto, il rifacimento dentro il pacchetto che corregge.
- **Il go-live come pacchetto di lavoro.** Non ha un ambito da stimare.

## Quando una WBS completa non vale la pena

Sotto le 15 attività circa con un solo responsabile, come regola pratica, un elenco piatto di attività con una riga «finito quando» su ognuna fa il lavoro di un albero e di un dizionario. Applica comunque il primo test all’elenco.

Scomporre ogni ramo fino ai pacchetti di lavoro il primo giorno funziona male per il lavoro che è a mesi di distanza, perché inventa una precisione che il trimestre successivo smentirà. L’alternativa della NASA è il pacchetto di pianificazione, che «definisce il lavoro lontano a livello di sintesi»[^1] e si divide in pacchetti di lavoro man mano che il lavoro si avvicina. In un piano è una riga con una durata approssimativa e una nota con la data entro cui va scomposta.

## Come farlo in Planitude

Costruisci l’albero nel [diagramma di Gantt](https://planitude.app/it/features#planning), senza limiti di livelli. Tab trasforma una riga in sottoattività di quella sopra, Maiusc+Tab la riporta fuori. Planitude chiama fasi le righe di riepilogo; dai loro il nome dei deliverable e i pacchetti di lavoro diventano le loro sottoattività.

Per partire da un foglio di calcolo, [importa il file Excel o CSV](https://planitude.app/it/features#import). Planitude ricostruisce le righe di riepilogo da una colonna WBS, da una colonna di livello o dal rientro, legge i predecessori scritti come codici WBS e mostra prima un’anteprima. Un [modello](https://planitude.app/it/features#templates) o un piano proposto dall’[assistente AI](https://planitude.app/it/features#ai) sono gli altri punti di partenza.

La colonna WBS è di sola lettura. Le nuove righe, milestone comprese, prendono un codice dalla loro posizione. I codici di un file importato (.mpp compreso), di un modello o di un progetto duplicato vengono invece salvati e restano fermi quando le righe si spostano, quindi aggiungi le nuove righe in fondo al loro ramo. Per avere codici come 1.2.3, metti tutto sotto una riga di riepilogo con il nome del progetto. Non c’è un dizionario WBS; ambito e riga «finito quando» vanno nelle note dell’attività.

**Prova Planitude con il tuo piano** [Prova Planitude gratis](https://planitude.app/it/signup)

## Domande frequenti

### Chi dovrebbe costruire la WBS, il project manager o il team?

Entrambi, con ruoli diversi. Il manuale NASA dice che la WBS «dovrebbe essere sviluppata dal team di progetto e approvata dal project manager»[^1]. In pratica il project manager imposta il livello 2, e le persone che faranno il lavoro scrivono i propri pacchetti di lavoro e le righe del dizionario, che è il punto in cui di solito emerge il lavoro dimenticato.

### Una WBS è la stessa cosa di un elenco di attività?

No. La WBS elenca ciò che il progetto produce, con nomi al sostantivo, senza date né ordine. L’elenco delle attività è la vista del piano sullo stesso lavoro, con nomi al verbo, durate e legami. Nell’esempio, 14 pacchetti di lavoro sono diventati 14 attività più due milestone; in un progetto più grande un pacchetto spesso diventa più attività.

### La WBS serve nei progetti agili?

Sì, a livello di deliverable. Se il team del centro assistenza lavorasse a sprint di due settimane, Contenuti, Piattaforma, Integrazione e Lancio resterebbero com’è mentre il backlog sotto di essi cambierebbe a ogni sprint. Un rilascio entra nell’albero solo se è nominato per il suo contenuto, come «Centro assistenza, seconda lingua»; un «rilascio del terzo trimestre» basato sulla data è un arco di tempo e va nel piano.

## Fonti

Le pagine ufficiali citate nell’articolo, consultate a ottobre 2026.

[^1]: [NASA Work Breakdown Structure (WBS) Handbook (NASA/SP-3404, 2019)](https://ntrs.nasa.gov/citations/20200000300)

## Prova Planitude con il tuo piano

Crea un account gratuito, importa il tuo file .mpp o parti da un modello: in pochi minuti vedrai il Gantt con dipendenze, calendari e percorso critico.

[Prova Planitude gratis](https://planitude.app/it/signup)