Work Breakdown Structure: Caratteristiche e come costruire la WBS di un progetto

Work Breakdown Structure: Caratteristiche e come costruire la WBS di un progetto

WBS (Work Breakdown Structure)

La definizione delle attività costituisce uno dei momenti cardine della pianificazione. Dopo aver definito quelli che sono gli obiettivi di progetto rispetto a tempi, costi e risorse bisogna quindi procedere all’identificazione e la documentazione delle attività che dovranno essere eseguite per portare a termine con successo il progetto.

Per i progetti più complessi il modo migliore di procedere è quello di creare una struttura ordinata di scomposizione del progetto tale che nessuna sua parte o elemento venga tralasciato: la WBS (Work Breakdown Structure). Si tratta di un diagramma ad albero orientato al prodotto e costituito da tutti quegli elementi risultanti come output del lavoro svolto nella fasi di sviluppo e realizzazione del progetto. La WBS organizza in pratica tutto il lavoro che deve essere svolto. Il diagramma viene costruito partendo dall’obiettivo principale (il progetto globale) e scomponendolo al livello immediatamente inferiore in tutti quei deliverable (prodotti) o sottoprogetti principali che lo compongono. Essi saranno a loro volta scomposti e si procede in questo modo fino a quando si è soddisfatti del grado di dettaglio delle voci finali risultanti. Possiamo notare come ad ogni scomposizione si vada di fatto a ridurre l’ampiezza, la complessità ed il costo della parte interessata.

Work Breakdown Structure: Caratteristiche e come costruire la WBS di un progetto

Le voci che si trovano ai livelli più bassi della WBS prendono il nome di Work Package e rappresentano quei gruppi di compiti/attività inferiori (e per questo più semplici) sufficientemente significativi, ossia identificabili e quantificabili in modo chiaro. Di questi pacchetti di lavoro sarà effettuata una stima dei tempi, delle risorse, dei costi e sarà individuato un responsabile a cui attribuirli. È importante sottolineare che tali stime vengono eseguite solo al livello dei Work Package (WP); i valori dei livelli superiori saranno assegnati semplicemente sommando i valori dei livelli inferiori fino ad ottenere il tempo del progetto (il livello più alto). È un metodo di calcolo del tempo molto approssimativo, che non tiene conto delle sequenze temporali delle attività e che andrà di conseguenza aggiornato più avanti. Non è inoltre detto che il responsabile assegnato all’attività la debba eseguire personalmente, esso deve solo preoccuparsi che venga svolta. Deliverables diversi possono essere caratterizzati da livelli di scomposizione diversi. Per ottenere infatti un Work Package a volte basta scomporre un deliverable soltanto al livello successivo, mentre in altri casi sono necessari ulteriori livelli di scomposizione. È necessario trovare un equilibrio tra un livello scarso e un livello eccessivo di dettaglio poiché non è sempre detto che una scomposizione porti benefici nella gestione. Per essere completa una WBS dovrebbe contenere tutti i deliverables e tutte le attività (definizione, progettazione, realizzazione, assemblaggio e consegna) che devono essere svolte per tali deliverables. Le logiche secondo le quali il progetto viene scomposto sono molteplici a seconda di come vengono assegnate le responsabilità e del tipo di progetto. Un esempio di logica di scomposizione molto utilizzata è la logica dei processi di lavoro. Con questa logica il progetto viene scomposto in base ai processi che dovranno essere attuati per la realizzazione dei deliverables. Si procede quindi a collocare i macroprocessi nei livelli principali mentre nei livelli inferiori si troveranno i gruppi di attività che li caratterizzano.

Una logica di scomposizione utilizzata spesso nei progetti interni è quella per fase. In questo caso nei livelli più alti si trovano le fasi mentre nei livelli inferiori i gruppi di attività da svolgere nelle singole fasi e, qualora presenti, i deliverables. Altre logiche utilizzate sono poi quelle per obiettivi, che si basa su obiettivi da raggiungere e sulle attività da svolgere per ottenere tali obiettivi, o per localizzazione dove la suddivisione gerarchica è legata allo spazio fisico o luogo dove l’output del progetto verrà realizzato. È ovviamente impossibile definire tutte le logiche applicabili cosi come è molto difficile stabilire a priori quale criterio convenga applicare. Generalmente si procede perciò considerando una certa gamma di scomposizioni per poi giungere a quella desiderata in base a due fattori: il ruolo che la WBS avrà nella pianificazione e il sistema di controllo previsto. Per ottenere una WBS completa ed efficace è quindi molto importante che tutto il team di progetto partecipi alla sua costruzione e ne condivida le logiche utilizzate.

Ogni elemento della WBS deve essere munito di una descrizione chiara e concisa, priva di ambiguità. Deve inoltre essere presente un codice (numerico o alfanumerico) identificativo ed univoco che possa essere utilizzato come riferimento nell’applicazione delle tecniche reticolari, nella pianificazione ecc. E’ necessario infine identificare se l’attività in analisi è un’attività milestone. Essa rappresenta un momento chiave del progetto che può riguardare ad esempio l’inizio o la fine del progetto, la consegna al cliente, momenti di riunione, punti intermedi di controllo del progetto e cosi via. In ogni progetto sono presenti più attività milestone, vengono rappresentate graficamente in maniera diversa rispetto alle altre attività e con una durata nulla o breve.

Riassumendo, per ogni Work Package dovranno essere indicati i seguenti elementi:

  • Codice e descrizione del lavoro da svolgere;
  • Responsabile;
  • Tempi presunti, costi ed eventualmente risorse;
  • Input richiesti ad altri WP;
  • Altre voci come i risultati da ottenere (deliverables, milestone), condizioni contrattuali ecc.

Senza tutta questa serie di informazioni diventerebbe molto complesso gestire e controllare ogni aspetto del progetto. Risulta quindi evidente come la WBS rappresenti un po’ il punto di partenza per l’impostazione del progetto e del suo controllo e sia uno strumento indispensabile per la pianificazione dei tempi, dei costi e delle risorse.

Pubblicato da Vito Lavecchia

Lavecchia Vito Ingegnere Informatico (Politecnico di Bari) Email: [email protected] Sito Web: https://vitolavecchia.altervista.org

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *