Per poter procedere adeguatamente nell’uso del decision tree mostrato nel post precedente, è fondamentale analizzare i deliverable di progetto.

Ciò è possibile attraverso due strumenti di riferimento diventati nel tempo una sorta di “standard de facto”: la Work Breakdown Structure (WBS), con la definizione dell’annesso dictionary di riferimento, e lo Story Mapping.

La WBS è lo strumento principe dell’approccio predittivo (waterfall, serial) chem, partendo dalla Vision, permette di dettagliare lo scope di progetto (e/o prodotto) attraverso una sua specializzazione (scomposizione) ad albero che si conclude al livello di massimo dettaglio con i Work Package (WP). I WP sono, dunque, i diversi elementi che compongono il progetto (prodotto) e sono accompagnati da tutte le informazioni di dettaglio che ne permettono la realizzazione, a cui è possibile collegare specifici membri del team o anche un singolo specialista.

Un approccio costruttivo alla WBS è quello di considerarla per quello che è: non il piano, ma uno strumento di rappresentazione del piano. In tal mondo non si corre il rischio di considerarlo come la “stella polare” ma comune un ausilio alla governance del progetto.

Esempio di WBS

Quando ci si sposta verso un approccio più adattivo (agile), si tende a focalizzarsi maggiormente su funzionalità rilasciabili velocemente ai consumatori, rappresentando, atomicamente, un nuovo “pezzettino” di valore. In questo ambito le Storie (o User Story) sono un po' diventate lo standard de facto per stabilire un agreement con il team di progetto, in sostituzione dei Work Package visti in precedenza.

Per poter però individuare il quadro d’insieme, similarmente alla WBS, viene spesso utilizzato lo Story Mapping che consente di creare una “mappa”, facile da visualizzare, strutturata, condivisa e contestuale delle storie.

 Esempio di Story Mapping

Una volta identificato lo Scope e i deliverable di progetto, è possibile procedere a convalidare e formalizzarel’approccio complessivo per la gestione ed esecuzione del progetto, ovvero il Lifecycles Bouquet.

Tale modello è articolato nei termini già visti in chiave ModernPM Lifecycle Toolkit (MLT), mixandoli opportunamente tra loro:

• Lifecycles, scelti come indicato sopra. Si può avere un solo lifecycle per progetto, o un mix di essi (situazione ibrida) in relazione alle caratteristiche dei deliverable da produrre.
• Roles, ovvero i ruoli necessari in relazione ai lifecycle selezionati.
• Tools, la cassetta degli attrezzi specifica.
• Metrics, le metriche necessarie a misurare le performance operative e applicare le necessarie attività di miglioramento continuo.

Per maggiori approfondimenti poteste scaricare il “paper” del ModernPM direttamente dal portale agileconstellation.info.

Stay tuned 😊