Work breakdown structure: differenze tra le versioni

Versione delle 03:05, 30 mar 2008

Versione attuale delle 13:07, 23 nov 2023

(83 versioni intermedie di 47 utenti non mostrate)

Riga 1:

{{F|economia aziendale|gennaio 2012}}

Con l'espressione [[lingua inglese|inglese]] '''Work Breakdown Structure''' ('''WBS, Struttura Analitica di Progetto''') si intende l’elenco di tutte le attività di un [[progetto]]. Le WBS sono usate nella pratica del [[Project management]] e coadiuvano il [[project manager]] nell'[[organizzazione]] delle attività di cui è responsabile.

[[File:Work Breakdown Structure of Aircraft System.jpg|alt=|miniatura|Esempio di WBS]]

Con l'espressione [[lingua inglese|inglese]] '''Workwork Breakdownbreakdown Structurestructure''' ('''WBS'''), Strutturadetta Analiticaanche '''struttura di Progettoscomposizione del lavoro''' (traduzione letterale) o '''struttura analitica di progetto''', si intende l’elencol'elenco di tutte le attività di un [[progetto]]. Le WBS sono usate nella pratica del [[Projectproject management]] e coadiuvanoaiutano il [[project manager]] nell'[[organizzazione]] delle attività di cui è responsabile.

Molto spesso i progetti sono composti da migliaia di attività: per facilitare il lavoro di organizzazione delle varie attività esistono delle WBS-tipo che elencano tutte le possibili attività (generiche) per i progetti del rispettivo ambito. L'insieme delle attività può quindi essere confrontata con una ''check-listchecklist''.

==Struttura==

La Workwork Breakdownbreakdown Structurestructure è un [[Albero (informatica)|albero]] gerarchico orientato al [[prodotto (project management)|prodotto]] (o ''deliverable'') che viene suddiviso nel materiale, nel software, nei servizi, nei dati e nelle attrezzature che lo compongono. L'albero viene strutturato in base all'[[Ingegneria gestionale|ingegneria di sistema]] che è sviluppata nella fase iniziale dell'apertura del progetto. La WBS definisce il [[Prodotto (project management)|prodotto]], o i [[Prodotto (project management)|prodotti]], da sviluppare o da produrre. Essa mette in relazione con il prodotto finale e fra di loro gli elementi di lavoro che sono necessari alla sua realizzazione. La WBS può articolarsi in un numero qualsiasi di livelli.

==Principi alla base della WBS==

===Regola del 100%===

Uno dei più importanti principi alla base della WBS è noto come '''Regola del 100%'''. La ''Practice Standard for Work Breakdown Structures (Second Edition)'', edita dal [[Project Management Institute]] (PMI) definisce questa regola così:

:'' '''{{q|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 devonodeve dare, sommatesommato, il 100% del lavoro necessario per completare il pacchetto." (p. 8)}}

===Programmazione dei risultati, non delle azioni===

Se il progettista della WBS tenta di comprendervi ogni dettaglio relativo alle azioni, probabilmente includerà troppe azioni, o troppo poche. Troppe azioni eccederanno il 100% dei limiti del nodo superiore, mentre troppo poche non arriveranno a quella percentuale. Il modo migliore di seguire la regola del 100% è di definire gli elementi della WBS in termini di risultati. Questo assicura che la WBS non dia raccomandazioni eccessive riguardo ai metodi, dando più spazio al pensiero creativo dei partecipanti al progetto. Per i nuovi progetti di sviluppo, la tecnica più comune per assicurare una WBS rivolta ai risultati è di utilizzare una ''[[product breakdown structure]]''. Eventualmente la WBS può risultare dal confronto di PBS e ABS, dove ABS è un ''activity breakdown structure''. Progetti software ''[[Feature Driven Development|Featurefeature Drivendriven]]'' possono utilizzare una tecnica simile, che impiega una ''feature breakdown structure''. Quando un progetto fornisce servizi professionali, una tecnica di uso comune è di comprendere tutti i prodotti fornibilirilasciabili per creare una WBS orientatoorientata al [[prodotto (project management)|prodotto]]. Le WBS che suddividono il lavoro in fasi di progetto (per esempio, fase di progetto preliminare, fase di progetto esecutivo) devono assicurare che le fasi siano chiaramente separate da qualcosa che definisca anche i criteri di delimitazione delle fasi stesse (per esempio, l'approvazione del [[progetto preliminare]] o del [[progetto esecutivo]]) che comunemente vengono denominati [[Milestone (project management)|milestone]].

===Elementi reciprocamente esclusivi===

Line 21 ⟶ 23:

===Livello di dettaglio (granularità) ed elaborazione progressiva===

Un quesito fondamentale da porsi durante la progettazione di ogni WBS è quando smettere di dividere il lavoro in elementi più piccoli. Se gli elementi terminali sono troppo ampi, infatti, potrebbe risultare impossibile tenere traccia in modo efficiente delle prestazioni progettuali, mentre se al contrario gli elementi sono troppo piccoli e quindi troppo numerosi, diventerà difficile tenerne traccia, specialmente se il lavoro è pianificato in un futuro piuttosto distante. Un compromesso soddisfacente può essere trovato facendo ricorso alla tecnica dell'elaborazione progressiva, che permette ai dettagli della WBS di essere progressivamente ridefiniti prima che il lavoro inizi su ogni singolo elemento. Una forma di elaborazione progressiva, nei grossi progetti, è nota come '''rolling wave planning''' (pianificazione ad aggiornamento costante) che stabilisce una pianificazione su una base temporale regolare per l'elaborazione progressiva. Nella realtà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 queste azioni non possano essere ridefinite per conformarsi alla '''"regola del 100%'''", la WBS non dovrebbe essere ulteriormente suddivisa.

===Schema di codifica===

È di uso piuttosto comune numerare gli elementi della WBS in ordine sequenziale per metterne in risalto la struttura gerarchica. Per esempio, '''<code>1.3.2 Ruota Posteriore'''</code> identifica l'oggetto come elemento di livello 3, poiché ci sono tre numeri separati da un [[punto fermo|punto decimale]]. Inoltre, lo schema di codifica aiuta a riconoscere gli elementi del WBS in ogni contesto scritto.

==Esempio di costruzione di una WBS==

[[ImmagineFile:WBS_bicicletta_ITAWBS bicicletta ITA.png|thumb|500pxupright=2.3|'''Figura 1: Tecnica di costruzione di una WBS.''' Questa immagine di esempio è liberamente ispirata ''Practice Standard for Work Breakdown Structures (2nd Edition)''. Questa immagine illustra un metodo oggettivo di impiego 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 ad ognuno è frutto di un giudizio personale basato sullo sforzo richiesto: NON è 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 grandi elementi possono essere ulteriormente suddivisi usando la 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 ("installare la camera d'aria e illo pneumatico", per esempio) saranno assegnate agli elementi terminali invece che ai nodi superiori.

Incidentalmente, questo metodo quantitativo è collegato alla tecnica [[Metriche di progetto|Earned Value Management]].

È raccomandabile che il progetto sia iniziato con un software interattivo, per esempio un [[foglio elettronico]], in grado di sommare automaticamente i punteggi assegnati. Un'altra pratica raccomandata è discutere la stima dei punteggi con gli altri membri del project team, questa tecnica collaborativa aumenta la conoscenza della definizione dei limiti degli elementi e dei presupposti, e per una buona gestione del progetto il consenso circa il livello di granularità è necessario.

Line 40 ⟶ 42:

Una WBS non è una lista completa di lavori, bensì una classificazione degli scopi del progetto.

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

Una WBS non è un pianificazione del progetto e non è una lista in ordine cronologico. È sconsigliabile e considerato controproducente pianificare un progetto (per esempio usando un [[project management software]]) prima di progettare una WBS appropriata, sarebbe simile al voler pianificare le attività di un cantiere edile prima ancora di completare il progetto dell'edificio. Senza concentrarsi sui risultati del progetto, è molto difficile seguire la regola del 100% a ogni livello della gerarchia della WBS. Non è possibile recuperare una WBS con definizioni improprie senza rifarla dal principio, per cui vale sempre la pena di completarla prima di iniziare qualunque altra pianificazione.

# l'<nowiki/>'''allocazione''' delle risorse, consistente nel calcolo dei ''fabbisogni tempificati''<ref>Così in Nepi A., ''Introduzione al Project Management. Che cos'è, come si applica, tecniche e metodologie'', Guerini e Associati, terza edizione ampliata, 2006, p. 121. Sul concetto di ''Work Breakdown Structure'' cfr. ''ibidem'', p. 122-128.</ref> relativi alle ''assegnazioni;'' esso determina, per ciascuna assegnazione: a) l{{'}}''inizio'', b) la ''fine'', c) la ''produzione complessiva'' sulla base della ''produttività'' (normalmente espresse in ''ore/periodo'') accertata, d) il ''costo complessivo'' e il ''costo'' ''periodico;''

# la '''schedulazione''' delle attività (o, meglio, delle ''assegnazioni'') basata su quattro elementi, dei quali due sono ''necessari'' (il ''calendario'' e la ''durata'' di ciascuna attività/risorsa/assegnazione) e due sono ''eventuali'' (le relazioni di dipendenza<ref>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''</ref> e i vincoli temporali specifici<ref>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 temporali sono classificati 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''</ref>).

Una WBS non è un pianificazione del progetto e non è una lista in ordine cronologico. È sconsigliabile e considerato controproducente pianificare un progetto (per esempio usando un [[project management software]]) prima di progettare una WBS appropriata, sarebbe simile al voler pianificare le attività di un cantiere edile prima ancora di completare il progetto dell'edificio. Senza concentrarsi sui risultati del progetto, è molto difficile seguire la regola del 100% a ogni livello della gerarchia della WBS. Non è possibile recuperare una WBS con definizioni improprie senza rifarla dal principio, per cui vale sempre la pena di completarla prima di iniziare qualunque altra pianificazione.

Una WBS non è una gerarchia organizzativa. Talvolta, i principianti commettono l'errore di creare una WBS fedele alla struttura organizzativa, mentre è piuttosto comune che la responsabilità sia ''assegnata'' a elementi organizzativi, una WBS che ne rispecchi la struttura non è descrittiva del progetto e non è orientata ai risultati. Allo scopo, si veda anche: [[matrice di assegnazione responsabilità]].

La capacità della memoria a breve termine non dovrebbe influenzare la dimensione della struttura ad albero di una WBS. Alcune fonti di documentazione suggeriscono che ogni livello sia limitato a 5/9 elementi perché questo è il limite teorico della memoria umana. Tuttavia, è da ritenersi che questo consiglio sia un'applicazione errata delle teorie sui principi cognitivi (si veda: [http://en.wikipedia.org/wiki/The_Magical_Number_Seven%2C_Plus_or_Minus_Two[Il magico numero sette, più o meno due|The Magical Number Seven, Plus or Minus Two]]), poiché gli elementi di una WBS non sono dati interconnessi casualmente. La documentazione definitiva riguardo alle WBS non contengono questa raccomandazione. È molto più importante costruire un raggruppamento logico di risultati pianificati che preoccuparsi dei limiti della memoria umana a breve termine.

In questo senso può essere utile realizzare una [[mappa mentale]] prima della WBS: essendo uno strumento di creatività aiuta a sviscerare alcuni aspetti che potrebbero rimanere reconditi con un approccio esclusivamente logico-razionale.

Al di là della progressiva elaborazione dei dettagli, gli aggiornamenti della WBS richiede un controllo formale dei cambiamenti. Questo è un altro motivo per cui una WBS dovrebbe essere orientata ai risultati e non alle prescrizioni di metodi: i metodi possono cambiare rapidamente, e lo fanno, ma le modifiche nei risultati pianificati richiedono un maggiore grado di formalità. Se i risultati e le azioni si confondono a vicenda, il controllo dei cambiamenti può essere troppo rigido per le azioni e troppo informale per i risultati.

La realizzazione potrebbe essere affidata al singolo come al gruppo di lavoro; in ogni caso è importante tenere a mente il principio secondo cui "la mappa non è il territorio", per cui... la mappa mentale potrà descrivere in modo molto parziale l'articolazione del discorso e avrà invece soprattutto lo scopo di 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 richiede un controllo formale dei cambiamenti. Questo è un altro motivo per cui una WBS dovrebbe essere orientata aialla produzione di risultati (''[[Prodotto (project management)|deliverable]] oriented'') e non alle prescrizioni di metodi: i metodi possono cambiare rapidamente, e lo fanno, ma le modifiche nei risultati pianificati richiedono un maggiore grado di formalità. Se i risultati e le azioni si confondono a vicenda, il controllo dei cambiamenti può essere troppo rigido per le azioni e troppo informale per i risultati.

== Note ==

<references />

== Voci correlate ==

Line 54 ⟶ 65:

* [[PERT/CPM]]

* [[Diagramma di Gantt]]

* [[Prodotto (project management)]]

== Altri progetti ==

{{interprogetto}}

{{Portale|Ingegneriaingegneria}}

[[Categoria:Project management]]

[[Categoria:Ingegneria gestionale]]

[[bg:Съставна структура на работата]]

[[de:Projektstrukturplan]]

[[en:Work breakdown structure]]

[[es:Estructura analítica de un proyecto]]

[[fr:Work Breakdown Structure]]

[[gl:Work Breakdown Structure]]

[[ja:Work Breakdown Structure]]

[[nl:Work Breakdown Structure]]

[[pt:Estrutura analítica do projeto]]

[[sv:Work breakdown structure]]

[[zh:工作分解结构]]