Sei nell'area del PMBOK ® Guide con spiegazioni TenStep.

Per tornare al sito principale clicca su  Homepage

   con PMBOK ® Guide 4th Edition


Licenze di utilizzo
Condizioni Generali

Mappa di TenStep PB

(da rivedere)

  SCHEMA DEL  PMBOK 

  1 - Introduzione   

  2 -  Ciclo di Vita     

  3 - Processi di PM 

 AREE DI CONOSCENZA

 4 - Integrazione     

 5 - Ambito    

 6 - Tempi              

 7 - Costi                

  8 - Qualità           

  9 - Risorse Umane

 10 - Comunicazione 

 11 - Rischi             

 12- Acquisti          

     Appendici      

PMP-Prep Online

per certificarsi PMP o CAPM in meno di 100 giorni!

TenStep Italia

Via Orazio Console 140

00128 Roma

telefono 39-06-5088134

mobile 39-348-3974474

info@tenstep.it

5.3.02.1TS Approccio alla WBS –

Work Breakdown Structure 

Le seguenti tecniche aiutano a definire il contenuto del progetto attraverso lo sviluppo di una work breakdown structure.

Tratto dal Processo di Project Management TenStep.

 

2.0.P1   Panoramica Sviluppo Schedulazione

La schedulazione ed il budget vengono creati  insieme all'appropriata deliverable Capitolato di Progetto  previsto nel passo  1.0.

La schedulazione è uno strumento vitale per assicurare che il gruppo di progetto sappia cosa deve fare. Molti incontrano difficoltà nel creare una schedulazione, perché il progetto non è stato ben definito. E' veramente difficile  sviluppato una schedulazione  decente se il project manager non è proprio sicuro di ciò che il progetto deve produrre.

Il budget rappresenta la quantità di denaro disponibile, che si può spendere sul progetto. In funzione dalla tua organizzazione e da come viene tenuta la contabilità, il budget potrebbe comprendere soltanto i costi esterni del progetto (fornitori, hardware, software, etc.). Alcune organizzazioni, però, inseriscono nel budget  anche i costi del lavoro interno. Queste organizzazioni, di solito, dispongono di qualche tipo di processo di imputazione dei costi interni al cliente o al reparto cliente.

 (Il Processo TenStep non comprende la giustificazione finanziaria del progetto. La giustificazione finanziaria potrebbe comprendere semplicemente la determinazione dei costi/benefici oppure più sofisticati Ritorni degli Investimenti (ROI),  l'Internal Rate of Return (IRR), etc. Il  processo di giustificazione finanziaria di un progetto viene trattato nel processo di gestione del portafoglio progetti (PortfolioStep). Nel processo TenStep, si assume che l'analisi finanziaria di alto livello e la giustificazione finanziaria del progetto siano state già effettuate e che il progetto sia stato già approvato.)

Nel passo precedente è stato definito il progetto per garantire che vi sia  un accordo con lo Sponsor di progetto sul lavoro che dovrà essere svolto . In questo passo il  project manager determina come il lavoro sarà svolto. Potrebbero essere utilizzati approcci diversi  in base alla dimensione del progetto. Per piccoli progetti, il piano di lavoro  può essere sviluppato senza molte formalità. E' possibile utilizzare un pacchetto software come   MS Project, un foglio elettronico, o anche un semplice pezzo di carta.

Ci sono numerose tecniche per sviluppare la schedulazione. Forse la migliore alternativa è utilizzare, come punto di partenza, un piano di lavoro di un precedente  progetto simile. Comunque, per la unicità della natura dei progetti ciò può creare ancora delle difficoltà.

Una seconda buona alternativa è utilizzare la template preesistente di un piano di lavoro di un progetto con caratteristiche simili. Per esempio, se  è la prima volta che viene installato nella tua azienda  un particolare pacchetto software, potresti trovare una template generica per la sua implementazione.

Se non disponi di un esempio di piano di lavoro precedente o di una template da utilizzare come punto di partenza, puoi ricorrere alla  tecnica della  WBS (Work Breakdown Structure).   La WBS è una tecnica per osservare il progetto ad un livello più alto, e successivamente spezzettare il lavoro in parti sempre più piccole, fino ad avere un quadro completo di tutto il lavoro da svolgere. A questo esercizio può partecipare l'intero team di progetto. Per la maggior parte dei casi, la tecnica della Work Breakdown Structure  può essere utilizzata come punto di partenza per creare una schedulazione da zero. Se tu (o altri) non hai abbastanza informazioni per creare una WBS per il progetto (o almeno per i primi tre mesi del progetto), probabilmente non sei ancora in condizione di avviare il progetto. In quel caso, potresti soltanto definire un progetto per la parte di analisi. Quando la parte di analisi sarà pronta, tu avrai informazioni sufficienti per definire il resto del progetto.

2.1.2P1 Panoramica Soglie di Stima

Quando crei un piano di lavoro generalmente, la prima volta non conosci abbastanza per entrare nel dettaglio. Invece, identifichi grosse porzioni di lavoro, e poi le suddividi in porzioni più piccole. Queste porzioni più piccole, a loro volta, vengono suddivise ancora in attività discrete ancora più piccole. Questa è la cosiddetta tecnica di creazione della Work Breakdown Structure (WBS).

La domanda da porsi è quanto deve esser piccola l’attività al livello più basso, da non suddividerla ulteriormente. La risposta rappresenta  la tua “soglia minima di stima”. Il lavoro potrebbe essere suddiviso anche in attività più piccole, ma, normalmente, nessun lavoro dovrebbe essere lasciato ad un livello più alto della soglia minima.

Puoi utilizzare il seguente criterio come guida. Per un progetto tipico (diciamo 5000 o più ore di impegno), qualsiasi lavoro più grande di 80 ore di impegno dovrebbe essere suddiviso in parti più piccole. Progetti di media grandezza (diciamo 1000 ore di impegno) dovrebbero avere attività non più grandi di 40 ore. Se il progetto è piccolo (diciamo 200 ore), dovresti suddividere il lavoro in attività non più grandi di 20 ore. Ricorda che questa soglia è un limite superiore.  Puoi ulteriormente suddividere il lavoro, se lo preferisci.

Assegnando del lavoro che è più piccolo della tua soglia rende il lavoro più maneggevole. Per esempio, se il tuo progetto è di 250 ore e tu hai attività più grandi di 80 ore l’una, non hai abbastanza tempo per recuperare se una attività finisce in ritardo. Però, se l’attività più grande è grande solo 20 ore, puoi scoprire molto più velocemente se il lavoro non è in linea con la schedulazione.

Naturalmente, è possibile che attività che devono essere eseguite più in la nel tempo possono non essere divisibili al di sotto della soglia, perché ci potrebbero essere troppi elementi sconosciuti. In questo caso, un approccio potrebbe essere suddividere il lavoro in tanti progetti più piccoli. Il secondo progetto può essere definito più accuratamente sulla base dei risultati del primo progetto.

Se non hai la possibilità di suddividere il lavoro in più progetti, il lavoro futuro può essere lasciato ad un livello più alto della soglia minima di stima. Però, se lasci il lavoro futuro ad un livello più alto, è ancora critico suddividere il lavoro in parti più piccole fino a due tre mesi prima dell’avvio del lavoro stesso.

In più, per gestire il lavoro in modo più efficace, un altro motivo per suddividere le attività in parti più piccole è assicurarsi di comprendere cosa significa quel lavoro.  Quando assegni un’attività del piano di lavoro ad un membro del team, egli può non comprendere che cosa è quel lavoro e chiedere una spiegazione. Se anche tu non sai  cosa vuol dire quel lavoro, ci può essere qualche problema. Così, tu devi assicurarti che il lavoro sia stato suddiviso in un livello basso abbastanza da poter comprendere le attività. Per esempio,  se una attività stimata 80 ore non è stata mai affrontata prima, può essere necessario suddividerla ulteriormente in attività più piccole per garantirsi che il membro del team al quale viene assegnato al lavoro sappia esattamente cosa ci si aspetta da lui.

Questi due fattori – la capacità di gestire il lavoro efficacemente e la capacità di comprendere il lavoro necessario -  dovrebbero ispirare la tua decisione su quanto devono essere piccole le attività.

2.1.6.P2  Crea Attività di Dettaglio e di Sintesi 

Se osservi un'attività della WBS e determini che bisogna suddividerla di un ulteriore livello, quell'attività diventa la sintesi delle attività ottenute con la nuova suddivisione. Una sintesi delle attività non ha  specificatamente alcun lavoro o ore di impegno associate. Essa rappresenta soltanto la visione logica delle attività sottostanti.

Per contro, le attività di dettaglio sono quelle che non vengono suddivise ulteriormente.

Le attività di sintesi vengono suddivise in attività di dettaglio. Perciò, una volta che sono state ultimate le attività di dettaglio sotto l’attività di sintesi, è terminata anche l’attività di sintesi. Se è necessario altro lavoro, allora significa che bisogna considerare altre attività di dettaglio sotto quell’attività di sintesi.

2.1.6.P3 Utilizza  l’Approccio  Post-it  per Creare la WBS in Modo Collaborativo

Non puoi immaginare quante persone utilizzano i post-it colorati ed una parete bianca per creare la prima bozza della Work Breakdown Structure. Questa tecnica è molto semplice e funzionale.

Per prima cosa, convochi le persone giuste in una stanza. Saranno membri del team di progetto e utenti che hanno esperienza nel creare la WBS.  Di solito, si parte scrivendo il nome delle deliverable principali su un post-it giallo - una deliverable per post-it. 

Poi, ti assicuri  che i partecipanti condividano di iniziare da una determinata deliverable. Se delle deliverable sono molto grandi, si possono utilizzare più foglietti per  descriverla ad un livello più basso o a livello di porzioni di lavoro da produrre. Questi foglietti post-it vengono inseriti sotto la deliverable di livello più alto.

La deliverable deve essere identificata ad un livello abbastanza basso da poter capire cosa deve produrre. In generale due livelli dovrebbero essere sufficienti. Un livello è tipico.

Successivamente, per ogni deliverable, si descrivono le attività da svolgere per realizzarla. Ogni attività va su un foglietto post-it separato. Di nuovo, questi vengono incollati sotto la specifica deliverable alla quale si riferiscono.  Se ha senso per l'ordine in cui le attività devono essere svolte, si possono mettere i foglietti in sequenza, ma, a questo livello la sequenza non è importante, invece, è importante identificare tutto il lavoro.

Si analizzano le attività necessarie per ogni deliverable e si  stima il lavoro necessario per ogni attività. Se l'impegno per un'attività è maggiore della soglia minima di stima bisogna identificare le attività di dettaglio che costituiscono il  livello più alto.  Ognuna di queste attività viene rappresentata da un nuovo post-it, sotto l'attività di livello più alto (che, per effetto della suddivisione, diventa un'attività di sintesi). 

Si continua con questo processo finché non è stato definito tutto il lavoro per realizzare tutte le deliverable, al meglio delle conoscenze alla data. I livelli di attività non saranno uguali per tutte le deliverable. Alcune deliverable possono soddisfare i criteri con uno o due livelli, altre possono richiederne tre o quattro, o più.

Il vantaggio di questo approccio è che il  team di lavoro può visivamente vedere la rappresentazione del lavoro, ed ognuno può  garantire che è stato identificato tutto il lavoro per completare il progetto.  I foglietti post-it colorati  danno la possibilità di cambiare facilmente posizione alle attività. Se aggiungi un'attività e poi decidi di rimuoverla, basta semplicemente staccare il foglietto dalla parete. Allo stesso modo, se una deliverable o gruppo di attività si trova al posto sbagliato, semplicemente si sposta il gruppo di  foglietti al posto giusto.

Quando tutto è fatto, puoi immettere le attività di sintesi e di dettaglio nello strumento software per la gestione della schedulazione delle attività.

2.1.6.P4 Identificare le Deliverable di Primo e Secondo Livello  e poi identificare le Attività 

A volte la gente ha difficoltà ad iniziare un processo di creazione della WBS perchè non sa cosa affrontare per prima, ed è incerta su come suddividere il lavoro sottostante. Anche se ci sono molti modi di iniziare la WBS, in ultima analisi, tu devi porre attenzione alle deliverable. Se assumi che il livello più alto (livello 0) è il progetto, allora il livello successivo può descrivere le deliverable principali. 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à, ma esse devono essere sviluppate nel contesto per produrre le deliverable.

Ci sono diverse alternative per definire la  WBS a livello 1 (sotto il livello di progetto).

Si possono piazzare le principali deliverable direttamente a livello 1, e suddividerle in componenti più piccoli su livelli successivi, fin dove necessario.

Un'altra opzione per il livello 1 è  descrivere i reparti che saranno coinvolti, come Vendite, Marketing, IT, etc. Il livello successivo dovrebbe descrivere le deliverable che ogni reparto produrrà.

Una terza opzione è 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. Tuttavia, se scegli un altro modo di organizzare inizialmente la tua visione del progetto, devi passare immediatamente da questo alle deliverable, e poi passare alle attività necessarie per realizzarle.  Per ulteriori informazioni, vedi la sezione 2.1.6.1 Esempi di WBS.

2.1.6.P5 Tecniche per Suddividere le Attività di Sintesi

Quando il gruppo di lavoro crea la WBS, ci si chiede quanto dettagliate dovrebbero essere le singole attività. La risposta determina quando smettere di suddividere il lavoro in attività più piccole. Parte della risposta è utilizzare una soglia minima stimata, come descritto nella sezione 2.1.2

Altre cose da tener presente comprendono:

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 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 lo 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.

2.1.6.P6 Non fare la WBS con Troppi Livelli 

Se concepisci la WBS attraverso i foglietti post-it su una  parete, è importante non far diventare la WBS troppo lunga (o troppo profonda). In base all'approccio alla WBS, possono essere necessari da uno a tre livelli per definire le attività di ogni deliverable. La regola generale  del pollice è che il numero di  livelli di attività per deliverable non deve superare i cinque livelli, ed anche cinque potrebbero essere troppi. I progetti più piccoli possono non richiedere più di due o tre livelli di attività per ogni deliverable. Se hai un progetto molto grande, i livelli possono essere più estesi. Comunque, c'è un punto in cui il dettaglio sarà 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, vedi se una deliverable  grande può essere divisa in pezzi integrati  più piccoli. Il lavoro per le deliverable più piccole non dovrebbe richiedere così tanti livelli.

 2.1.6.P8 Crea un Dizionario WBS  per i Grandi Progetti 

Normalmente non sarebbe necessario un dizionario, ma se la WBS ha centinaia (o migliaia) di attività di dettaglio, ci potrebbero essere molti concetti da ricordare. Se la WBS è molto grande, può essere utile mettere tutte le informazioni importanti in un dizionario. Il dizionario aiuta a tenere traccia di tutte le attività di sintesi e di dettaglio, una breve descrizione, il numero identificativo di WBS ( 1.1, 1.1.1, 1.1.2, etc.) e la stima dell'impegno. Una volta immesse le informazioni di WBS in un tool, il tool può aiutare a tenere traccia delle modifiche al lavoro in modo che tu possa tracciare l'impatto delle modifiche sulla WBS e sulla schedulazione.  Con la WBS in un tool le informazioni sono più facilmente riusabili per progetti futuri.

2.1.6.P9 Utilizza le Attività di Sintesi per Schedulare le Milestone

La tua WBS contiene attività di dettaglio e di sintesi. Quando crei il diagramma reticolare nella schedulazione, tuttavia, dovresti includere soltanto le attività di dettaglio e non quelle di sintesi. Per chiarezza e leggibilità, spesso conviene inserire anche le attività di sintesi di livello  più alto nella schedulazione per rappresentare la sequenza logica delle attività di dettaglio. Potrebbe essere inserita nella schedulazione anche un’attività di sintesi che rappresenta la fine di una deliverable principale come milestone.

2.1.6.P10 Suddividi le Attività di Sintesi in Due o più Attività di Dettaglio

Avendo scelto di dividere le attività di sintesi in attività più piccole, non avrebbe senso avere una sola attività di dettaglio sotto una attività di sintesi. Se tu lo facessi, l’attività di dettaglio rappresenterebbe esattamente lo stesso lavoro  dell’attività di sintesi. Ciò non ti direbbe niente di nuovo.  Se capita una cosa del genere nella tua WBS, allora devi:

Suddividere le attività di sintesi in tante attività più piccole

Eliminare le attività di dettaglio e associa il lavoro all’attività di sintesi – che in questo caso diventa attività di dettaglio

2.1.6.P11 Le Attività di Dettaglio Devono Essere Orientate all’Azione

Le attività di dettaglio della tua WBS vengono trasferite nella schedulazione. Per questo motivo, è più facile se le attività di dettaglio della WBS sono Orientate all’Azione – proprio come devono essere le attività di una schedulazione. Per esempio, invece di scrivere “riunione”, dovresti scrivere la stessa cosa con “Schedulazione di una riunione settimanale”. Invece di avere un’attività di dettaglio della WBS “Piano dei Test”, dovresti avere “Creare un Piano di Test”. In questo modo, le attività di dettaglio possono essere trasferite nella schedulazione con pochi cambiamenti.

2.1.6.P12 Non Inserire Requisiti  in WBS

La WBS viene utilizzata per decomporre porzioni di lavoro più grandi in parti di lavoro più piccole. Se inserisci una deliverable nella tua WBS, puoi spezzettarla nelle attività necessarie per creare la deliverable. Non suddividere mai una deliverable nei  requisiti che la descrivono. I requisiti non appartengono alla WBS.

Le attività di dettaglio della WBS sono attività che devono essere trasferite nella schedulazione. Ecco come apparirebbe la schedulazione se contenesse cose come “bisogna avere interfacce semplici” oppure “bisogna essere in grado di lavorare 25 piedi sotto il livello dell’acqua”. Questi sono requisiti. I requisiti appartengono al Piano di Gestione dei Requisiti.  Essi non servono nella schedulazione o nella WBS.

2.1.6.P13 Lascia la WBS a Livello di  Work Package  per Grandi Progetti

I progetti molto grandi generalmente hanno anche  deliverable molto grandi. Un modo per sviluppare la WBS su questi progetti è definire le deliverable e poi suddividerle in componenti di lavoro. I componenti di lavoro sono semplicemente parti più piccole di grandi deliverable. Quando tutti i componenti di lavoro più piccoli sono stati ultimati ed integrati, è stata creata anche la deliverable più grande.

A volte non è pratico determinare le attività di sintesi e di dettaglio su progetti molto grandi perchè ce ne sono veramente poche. Sui progetti molto grandi, la WBS può essere suddivisa soltanto a livello di componenti di lavoro “work package”. Il livello dei  work package può essere molto grande – forse grande abbastanza da essere un sotto progetto, e forse grande abbastanza da avere una propria unità di costo.

Se sei in presenza di un grande progetto, puoi interrompere la WBS a livello di work package. Però, lo stesso il lavoro non può essere assegnato alle persone, a questo livello. Il work package dovrebbe essere assegnato ad un team. Il team leader dovrebbe suddividere il lavoro nelle attività necessarie  per sviluppare il componente (o per realizzare l’intero contenuto di lavoro work package).

In questo scenario, l’intera WBS viene lo stesso creata al livello di dettaglio delle attività. Però, viene realizzata in due fasi – la prima iterazione a livello alto di  work package, e poi, quando il  work package viene realmente assegnato ad un team di lavoro, vengono definite le attività di dettaglio.

5.3.02.1TS Tecniche di Creazione della WBS

 Verifica dell'ambito

English Spanish Portuguese  French  Spanish Croatian Spanish French German Hungarian Indian English Hebrew  Italian Japanese Spanish Spanish Polish Portuguese Romanian and Moldavian English   Swedish French  

Condizioni Generali            |        Mappa del sito principale              |              Informativa sulla Privacy          |         Contattaci        |   

TenStep Italia di Vito Madaio - Via Orazio Console 140 -  00128 Roma  -  tel. +39-348-3974474 - +39-06-5088134 - P. IVA 07627281004 - Copyright ©2004 - 2011