In questo esempio non si fa riferimento a uno specifico progetto ma si presentano delle attività generiche che possono essere presenti in tutti i progetti di realizzazione di un nuovo sistema informativo o di sostituzione di uno esistente. L’esempio è generalizzabile a ogni altro settore o tipologia di progetto adattando la terminologia e le attività con quelle del settore di interesse.
Figura 22: diagramma gerarchico di PBS a due livelli
Nell’esempio ci si limita a definire genericamente le attività con un minimo di descrizione di obiettivi generali senza entrare nel dettaglio degli altri elementi necessari per la definizione delle attività che saranno trattati in seguito nel corso. La scomposizione di un progetto in parti prende il nome di Project breakdown structure (PBS) ed è rappresentata generalmente attraverso tabelle descrittive e grafici gerarchici. Se la scomposizione delle attività giunge a livello di dettaglio tale da diventare dei compiti di lavoro (work package) allora la struttura prende il nome di Work breakdown Project (WBS)La struttura PBS si limita a definire la scomposizione del progetto in parti separate senza occuparsi di vincoli o propedeuticità, elementi questi riservati ad altri strumenti di project management. Ad ogni attività del PBS deve essere associato un codice univoco che consenta un’immediata individuazione e collocazione all’interno della struttura gerarchica definita. Il codice dell’attività viene poi solitamente utilizzato come parte iniziale dei codici associati a tutti gli altri elementi dell’attività come prodotti e compiti. Il ciclo di vita descritto nella tabella e nel grafico presenta un esempio di scomposizione delle fasi principali sino al secondo livello di dettaglio, nel seguito di questo libro questo stesso esempio verrà ripreso e dettagliato ulteriormente con altri sottolivelli per applicazioni specifiche.
Solitamente ogni livello, a meno di casi particolari, deve essere scomposto in un massimo di 5 elementi e deve essere sviluppato per un massimo di 4 livelli per non risultare complesso nella definizione e nella gestione. In caso di scomposizione di un elemento in più di 5 sotto-elementi si deve prendere in considerazione la possibilità di eventuale aggregazione di alcuni elementi in un livello superiore, così come la presenza di più di 4 livelli nella struttura gerarchica deve far pensare alla possibile scomposizione del progetto in sotto progetti indipendenti. L’esempio presentato non rispetta questi principi perché si sono voluti mettere in evidenza due elementi:
1. Il primo livello composto da 6 fasi/attività è una forzatura fatta per inserire l’attività di “Gestione progetto”. Questa non è una vera fase o prodotto di progetto ma è una attività trasversale che può essere gestita come sotto-attività di ogni faseprincipale, spesso però viene posta appositamente in evidenza per poterne meglio controllare gli obiettivi, i prodotti, l’organizzazione del lavoro, i costi e i tempi.
2. L’attività di dispiegamento ha sei sotto-attività inserite volutamente come attività separate per mettere in evidenza alcune attività/compiti come il collaudo finale del progetto, in genere alcune di queste attività o sono assenti oppure sono aggregate in delle macro attività.
Nella tabella seguente sono riportate le fasi presenti nel PBS del diagramma gerarchico con una breve descrizione degli obiettivi di ogni fase o attività, da notare oltre alla descrizione anche la codifica delle attività assegnata anch’essa secondo la struttura gerarchica.
Tabella 2: Scheda descrittiva del PBS
Partendo da questa suddivisione di base di un sistema informativo si può poi arrivare a livelli di dettaglio diversificati a seconda della complessità e delle dimensioni di ogni specifico progetto. Nel caso di progetti di sistemi informativi complessi, questo livello di dettaglio può risultare insufficiente e richiedere maggiore scomposizione delle attività inserite nell’esempio. Per un sistema informativo di piccole dimensioni lo stesso livello di scomposizione può risultare troppo analitico e richiedere l’accorpamento o l’eliminazione di alcune delle fasi attuali. Questo modello di ciclo di vita, anche se presenta riferimenti specifici ai sistemi informativi, può essere facilmente applicato ad altri settori adattando opportunamente terminologia e attività. Analizzando le varie metodologia di project management esistenti, è possibile individuare, a meno di qualche incongruenza, gli stessi principi e la stessa struttura PBS presentata in questo corso. Rimanendo entro i principi generali del project management, niente vieta in caso di necessità, di adattare una metodologia alle proprie specifiche esigenze. Molte aziende che operano per progetti definiscono ed applicano delle proprie metodologie, con strutture di PBS personalizzate e terminologia propria.