In questo articolo vedremo nel dettaglio la differenza tra la WBS – Work Breakdown Structure, tipica dei progetti che applicano la metodologia classica ed il backlog, impiegato invece nei progetti agili o ibridi. Entrambi assolvono la medesima funzione: descrivere l’ambito di un progetto.

Partiamo quindi dal chiarire cosa si intende per ambito del progetto.

La gestione dell’ambito di progetto è una delle 10 aree di conoscenza individuate dal PMBOK® ed include i processi necessari a garantire che il progetto comprenda tutto il lavoro necessario, ed esclusivamente il lavoro necessario; l’obiettivo è completare con successo il progetto.

Gestire l’ambito significa quindi definire e controllare ciò che è incluso nel progetto.

La finalità dei processi di gestione dell’ambito è limitare fenomeni quali:

• gold plating: tendenza a fare di più di quanto concordato inizialmente (ed in fase di stipulazione del contratto) con la committenza
• scope creep: tendenza a far slittare l’ambito a fronte di continue richieste di modifiche dovute ad una non chiara definizione dei deliverable e/o dei loro requisiti

L’ambito di un progetto condotto secondo i principi della metodologia tradizionale, o meglio, predittiva, è noto fin dall’inizio ed è quindi possibile scomporlo fin da subito, grazie al ricorso alla metodologia WBS, anche definita come scomposizione strutturata del progetto.

Abbiamo parlato della differenza tra l’approccio predittivo e agile nell’articolo:

“Waterfall vs agile: qual è l’approccio migliore?”

La WBS è uno strumento utilizzato per la scomposizione analitica di un progetto in parti elementari.

Lo scopo è quello di organizzare il lavoro in elementi più facilmente gestibili e rendere meno complessa la comprensione del progetto, in modo da comunicare a tutti i soggetti coinvolti (stakeholder) le fasi e le attività da svolgere per il raggiungimento di un obiettivo.

Alla WBS viene sempre affiancato un WBS Dictionary contenente i dettagli delle attività descritte nella WBS.

Nell’immagine un esempio di WBS (Fonte: PMBOK® Guide 6th edition).

In sostanza la WBS è una rappresentazione grafica strutturata in maniera gerarchica. L’obiettivo viene posizionato nella parte superiore dello schema e da questo si diramano le dipendenze e le sotto-dipendenze. Man mano che si scende di livello, l’ambito viene frammentato in attività sempre più piccole, fino ad arrivare agli elementi finali chiamati work package. È quindi un documento utile per concordare e formalizzare ciò che è dentro l’ambito del progetto e ciò che invece ne resterà fuori.

La WBS è anche un valido strumento di coinvolgimento del team e degli stakeholder, perché consente di ottenerne il buy-in, cioè il consenso sulle attività di progetto e funge da strumento per la condivisione delle informazioni. Il processo di creazione della WBS consente al team di sfruttare al massimo le proprie competenze con benefici in termini di riduzione del rischio. Infine, mostrare una WBS gerarchica di un progetto completo, consente di relazionare facilmente tra loro i vari deliverable del progetto stesso.

Una WBS ben definita aumenta quindi la probabilità che il progetto raggiunga i suoi obiettivi dato che vi sono meno possibilità che il lavoro fondamentale venga omesso e rende più agevole quantificare tempi, costi, risorse coinvolte e rischi.

E nei progetti agili?

Nel caso di progetti agili o ibridi, accade spesso che l’ambito non sia del tutto noto all’inizio del progetto, ma che si delinei in corso d’opera. In questo caso, lo strumento utilizzato è il backlog.

Il backlog, spesso chiamato anche product backlog, è in buona sostanza una lista di tutte le attività funzionali e non funzionali identificate per il progetto. In altre parole, il backlog è l’elenco di tutto il lavoro che deve essere fatto ed i vari elementi che lo compongono saranno rimossi dall’elenco quando completati.

Gli elementi del backlog sono valutati dal team in termini di rischio, le priorità rispecchiano le esigenze del business. Le priorità nel backlog seguono una logica di tipo top-down: i primi elementi della lista sono quelli ai quali il product owner attribuisce il valore più alto e, di conseguenza, sono quelli con maggiore priorità di esecuzione per il team. Nella parte bassa del backlog, invece, sono presenti gli elementi di basso valore e quindi di bassa priorità per il team.

Il product backlog è uno strumento in continua evoluzione poiché costantemente aggiornato: le priorità sono man mano ridefinite durante l’esecuzione delle attività di progetto.

4 principali differenze tra la WBS e il product backlog

1. Lo scopo. Tutto ciò che è incluso nella WBS deve essere portato a termine per completare il progetto. Al contrario, il backlog può contenere elementi (a bassa priorità) che non verranno mai consegnati
2. Le priorità. La WBS non stabilisce priorità, pertanto, il lavoro è ottimizzato secondo la logica di risoluzione o costruzione del deliverable (ottimizzazione del processo di produzione). Il Backlog è invece ottimizzato in base al valore che le attività in esso contenute producono per il business.
3. La struttura. La WBS, come abbiamo già specificato, segue una struttura gerarchica. Tale logica non si ritrova all’interno del backlog, che può, tra l’altro, contenere elementi di diversa natura come user story, epiche, correzioni, miglioramenti, casi d’uso, requisiti.
4. Il concetto di “valore”. É possibile includere all’interno della WBS, più specificamente all’interno del WBS dictionary, il costo di un certo elemento. Non vi è alcun divieto nell’includere i riferimenti ai costi anche all’interno del backlog, ma l’organizzazione degli elementi in esso contenuti, deve sempre e comunque rispettare un ordinamento per valore prodotto; si tenga quindi ben presente la differenza tra costo e valore.

Vuoi sapere come costruire una WBS? Abbiamo racchiuso i nostri consigli in questo articolo.

Per restare sempre aggiornato sulla pubblicazione dei nostri articoli sui temi del project management, iscriviti alla nostra newsletter e ricevi il nostro regalo di benvenuto!