Approccio alla WBS

Tratto dalla Newsletter di www.tenstep.it

Qualche regola: Approccio alla WBS

A volte la gente ha difficoltà ad iniziare il processo di creazione della WBS perchè non sa cosa affrontare per prima, ed è incerta su come suddividere il lavoro. Anche se ci sono molti modi di iniziare la WBS, in ultima analisi, bisogna concentrarsi sulle deliverable. Se assumi che il livello 0 è il progetto, allora il livello successivo può descrivere le deliverable principali che il progetto deve produrre. Quando sono state descritte tutte le deliverable, possono essere definite le attività necessarie per realizzarle. La schedulazione di progetto, in fondo, si compone di attività, che devono essere sviluppate nel contesto per produrre le deliverable.

Ci sono diverse alternative per definire una WBS.

Si possono piazzare le principali deliverable direttamente a livello 1, e suddividerle in componenti più piccoli su livelli successivi, fin dove necessario.
Si possono descrivere i reparti che saranno coinvolti, come Vendite, Marketing, IT, etc. Il livello successivo dovrebbe descrivere le deliverable che ogni reparto produrrà.
Si può guardare al livello 1 in termini di ciclo di vita di progetto, per esempio analisi, disegno, codifica, test. Se questo è il miglior modo logico di guardare al livello 1, allora il livello 2 dovrebbe descrivere le deliverable da produrre in ogni passo del ciclo di vita.
E’ da notare che il livello 1 può partire con le deliverable, o può descrivere un altro modo per raggruppare logicamente le componenti più grandi del progetto. Se scegli un altro modo di organizzare inizialmente la tua visione del progetto, poi devi passare immediatamente alle deliverable, e in fine alle attività necessarie per realizzarle.

Tecniche per Suddividere le Attività
Il gruppo di lavoro che crea la WBS si chiede quanto devono essere dettagliate dovrebbero essere le singole attività. La risposta determina quando smettere di suddividere il lavoro in attività più piccole.

L'attività dovrebbe contenere sub-attività correlate e continue. Per esempio, se hai un'attività chiamata 'Creare i casi prova e la strategia di formazione ', probabilmente l’attività dovrebbe essere suddivisa ulteriormente, poiché la strategia dei casi prova e quella della formazione non sono necessariamente correlate né continue.
L'attività dovrebbe essere completata dalla stessa persona, o dallo stesso gruppo di persone. Se hai un'attività che richiede persone diverse per differenti sub-attività, allora dovrebbe essere suddivisa nelle rispettive sotto-attività in modo che quella persona, o qeullo stesso gruppo di persone, possa realizzare l’intera attività. Poiché le attività di dettaglio, alla fine, vengono trasferite nella schedulazione, non puoi assegnare una attività schedulata a due differenti gruppi, o due persone distinte.
In generale, il lavoro dovrebbe essere suddiviso ad un livello controllabile da parte del project manager. Teoricamente, la schedulazione potrebbe essere suddivisa fino al punto in cui ogni attività non sia di una o due ore. Ovviamente, non serve suddividere il lavoro a questo livello. Il numero di persone assegnate non deve gestire il lavoro a questo livello. Similmente, non è il caso di schedulare attività con meno di un'ora di impegno.
Quanti Livelli definire ?

Se concepisci la WBS con foglietti post-it su una parete, è importante non far diventare la WBS troppo estesa. Per definire le attività di ogni deliverable, possono essere necessari da uno a tre livelli. E' bene non superare cinque livelli, i quali potrebbero essere ancora troppi. I progetti piccoli non richiedono più di due o tre livelli di attività per ogni deliverable. I progetti più grandi possono richiederne qualcuno in più. Comunque, ad un certo punto il dettaglio sarebbe troppo complesso da gestire. Se ti accorgi che stai definendo cinque o più livelli di attività per una deliverable, fermati e rifletti su cosa stai facendo. Forse stai definendo il lavoro ad un livello troppo basso. Secondo, puoi aver definito le tue deliverable troppo estesamente. In questo caso, verifica se una deliverable grande può essere divisa in pezzi più piccoli. Il lavoro per le deliverable più piccole non dovrebbe richiedere così tanti livelli.