TenStep - Tecniche di Creazione della WBS

Non c'è necessariamente un ordine sequenziale tra la Definizione del Lavoro (passo 1) e lo Sviluppo della Schedulazione e del Budget (passo 2). Cioè, non puoi prima definire completamente il progetto, e poi Sviluppare la Schedulazione ed il Budget per secondo. Alcune sezioni del Capitolato di Progetto, come la stima dell’impegno e della durata, ad esempio, non possono essere completate senza iniziare a disegnare il Piano di Schedulazione. Allo stesso tempo, tu non puoi completare la Schedulazione senza concordare prima il Capitolato di Progetto. Per esempio, non si può sviluppare schedulazione e budget senza raggiungere un accordo di alto livello sulle deliverable e sul contenuto. Definire il progetto comporta anche descrivere l'intero approccio, che è utile conoscere prima di completare la schedulazione.

In una certa misura, la definizione del lavoro e lo sviluppo della schedulazione e del budget devono essere portati avanti simultaneamente. Le due principali deliverable, il Capitolato di Progetto e la Schedulazione di Progetto dovrebbero essere sviluppate in parallelo. Scoprirai che man mano che raccogli informazioni su contenuto e lavoro, tu puoi inserire più dettagli nella schedulazione. Quando deliverable, contenuto, assunzioni ed approccio sono completi, dovresti disporre di informazioni sufficienti per completare la schedulazione. A quel punto, puoi utilizzare la schedulazione di alto livello per stimare il budget necessario, l'impegno e la durata che a loro volta vengono utilizzati per completare il Capitolato di Progetto.

1.2.P2 Dividere i Grandi Progetti in Parti più Piccole

I giorni dei mega progetti sono finiti. I progetti molto grandi sono semplicemente troppo difficili da gestire ed eseguire con successo. I progetti molto grandi presentano numerosi problemi.

Quanto più è distante la fine del progetto, tanto meno chiaro e il lavoro. I grandi progetti di solito sono sempre anche lunghi e difficili da pianificare con accuratezza.

Poiché il lavoro futuro è meno chiaro, è più difficile fare stime accurate per impegno, durata e costo.

Business e condizioni tecniche cambiano nel tempo, le assunzioni fatte in fase di pianificazione sono molto incerte nel futuro. Le certezze di business e le tecniche di oggi possono cambiare anche sostanzialmente nel tempo.

Si rischia di perdere la fiducia di una organizzazione, se c'è un lungo ritardo prima di dare tangibili risultati. E' molto difficile mantenere l'entusiasmo di una organizzazione e la fiducia su periodi lunghi.

E' molto difficile predire le esigenze di risorse e la disponibilità per periodi molto distanti nel futuro. Di nuovo, ciò comporta difficoltà nello stimare accuratamente come andare avanti nel futuro.

Impegni molto grandi sono anche molto difficili e complessi da gestire come un singolo progetto. La migliore tecnica è dividere il lavoro in porzioni più maneggevoli, ognuna da considerare un singolo progetto, con il proprio Capitolato di Progetto ed la propria Schedulazione.

Per esempio, un lungo impegno di sviluppo IT può essere diviso in tanti progetti sequenziali, basati sul ciclo di vita. Viene messo su un progetto per il lavoro di analisi. Alla fine di questo progetto viene definito un secondo progetto in base a ciò che si conosce a quel momento, per realizzare il lavoro di disegno. Poi viene avviato un progetto di realizzazione e test, ed, in fine, un progetto per l'implementazione. Altre grandi iniziative potrebbero essere divise in progetti più piccoli che potrebbero procedere in parallelo. Alcune grandi iniziative possono essere una combinazione di piccoli progetti, alcuni dei quali devono essere realizzati in sequenza, ma altri possono essere eseguiti anche in parallelo. Ogni gruppo di lavoro lavorerà per completare il suo piccolo progetto, ma tutto il lavoro verrebbe coordinato in modo che l' impegno complessivo possa avere successo.

1.2.P3 Mettere su un Programma per Coordinare un Insieme di Progetti Correlati

Se dividi un grande impegno in un numero di progetti correlati, c’è ancora bisogno di mantenere il coordinamento e la gestione complessiva. Questo è lo scopo di un programma. Un programma è la struttura ombrello stabilita per gestire una serie di progetti correlati. Ogni progetto ha un project manager dedicato o parttime. Il programma viene governato da un program manager. Il programma non produce nessuna deliverable di per sé, che, invece, vengono prodotte dai vari progetti. Lo scopo del programma è:

Fornire direzione, guida e leadership complessiva per i progetti.

Essere sicuri che i progetti correlati comunicano effettivamente fra loro.

Fornire un punto centrale di contatto e di attenzione per il cliente ed i gruppi di progetto.

Determinare come i singoli progetti dovrebbero essere definiti per garantire che tutto il lavoro venga ultimato con successo.

1.2.P4 Il Cliente Può non Essere in grado di Completare il Capitolato di Progetto

A volte, il project manager pone aspettative troppo alte su previsioni e visione dei clienti. In molti casi, il project manager farà delle richieste al cliente per definire il progetto, e il cliente non avrà tutte le informazioni necessarie. Ciò accade tutte le volte, e non significa che il cliente non sa cosa sta facendo. In molti casi, specialmente per grandi progetti, il cliente ha una visione di ciò che sarà il risultato finale, ma non può articolare questa visione in deliverable concrete. Può anche non conoscere tutte le risposte su contenuto, rischi, organizzazione del progetto, etc.

Sulla base delle informazioni incomplete che si hanno, il project manager può pensare di aver bisogno di ipotizzare dei dettagli. Questa non è una buona soluzione. Invece, se ti trovi in questa situazione, ci sono tre modi per procedere:

Specifica in anticipo tutto ciò che si conosce, come pure tutto ciò che non si conosce. Se ti viene chiesto di produrre delle stime di impegno, costi e durata, bisognerà fornire un range di valori da un minimo ad un massimo sulla base delle incertezze.

Dividi il lavoro in una serie di piccoli progetti (come descritto sopra). Anche se i risultati finali non possono essere definiti chiaramente, ci sarà parte del lavoro ben definito, che a sua volta condurrà alle informazioni necessarie per la soluzione finale. Tu devi soltanto definire un progetto che copra quanto ragionevolmente si riesce a vedere oggi. Poi, definirai e pianificherai i progetti susseguenti man mano che saranno note le altre informazioni. Per esempio, potresti creare un progetto per la raccolta dei requisiti di business, e poi utilizzare i risultati per definire un secondo progetto per sviluppare la deliverable finale.

Se non ti è concesso di dividere il progetto in porzioni più piccole, tu dovresti almeno conoscere abbastanza informazioni per poter pianificare il lavoro dei primi 90 giorni. Con questo terzo approccio, tu pianifichi il lavoro a breve termine in maggior dettaglio, e lasci più indefinito l'impegno a lungo termine. Man mano che acquisisci altre informazioni, puoi pianificare il rimanente lavoro con un maggiore livello di dettaglio.

2.0.P2 Relazione tra Definire e Pianificare il Progetto

Bisogna notare che la definizione del lavoro fa parte del primo passo del Processo TenStep e la pianificazione del lavoro fa parte del secondo passo. Tuttavia, ciò non implica che questi due passi debbano essere necessariamente sequenziali. Potresti accorgerti di non poter completare il Capitolato di Progetto senza iniziare a disegnare l'intera Schedulazione del lavoro. In molti casi, queste due deliverable devono essere lavorate in parallelo. Man mano che si raccolgono informazioni su contenuto e deliverable, si può ipotizzare la tempificazione e produrre le stime di impegno e durata. Appena si ottengono più informazioni di "definizioni", si inseriscono maggiori dettagli nella Schedulazione. Quando deliverable, contenuto, assunzioni, e approccio sono completi, dovrebbero esserci abbastanza informazioni sulla Schedulazione per poter stimare budget, impegno e durata necessari - che a loro volta verranno utilizzati per completare il Capitolato di Progetto.

2.1.6.P7 Suddividi i Grandi Progetti in Fasi e Stadi

Per descrivere il modo in cui grandi progetti possono essere divisi e suddivisi, si utilizzano termini differenti. Una coppia di termini comuni sono Fasi e Stadi. Possono non essere riconosciuti universalmente, ma in generale essi significano quanto segue:

Stadio: E' il termine più facile. E' usato di solito per indicare una porzione di lavoro di un progetto. Per esempio, potresti riferirti alla la raccolta dei requisiti di business, e tutto il lavoro correlato, come lo Stadio di Analisi . Similmente, se il progetto richiede la costruzione di un prototipo, potresti chiamarlo Stadio del Prototipo.

Fase: Le fasi possono avere due significati.

Primo, in molti casi, la parola "fase" significa esattamente quanto descritto per Stadio. Per esempio, un progetto può avere una Fase dei Requisiti, o una Fase del Prototipo. In questo contesto, la fase si riferisce ad una suddivisione di alto livello. Se viene utilizzato anche il termine 'Stadio', esso si riferisce ad una ulteriore divisione della fase. Per esempio, nella Fase di Analisi ci può essere uno Stadio dei Requisiti di Business e uno Stadio di Definizione della Strategia.

Il secondo uso del termine "fase" si riferisce ad una serie di progetti indipendenti, ma correlati. Per esempio, il progetto originale di rilascio di funzioni base potrebbe chiamarsi Fase I. Un successivo progetto per funzionalità aggiuntive potrebbe chiamarsi Fase II. Il passaggio in produzione dell'insieme delle funzionalità potrebbe chiamarsi Fase III. In tutti questi casi, il termine "fase" viene utilizzato per indicare un progetto separato, ma correlato ad un altro progetto simile, e con un altro che viene dopo.

2.2.P1 Utilizza Precedenti Schedulazioni e Modulistica Predefinita

Per creare una schedulazione da zero, è sempre possibile utilizzare una tecnica di Work Breakdown Structure (WBS). Però, la WBS non è sempre il modo più efficiente per sviluppare la schedulazione. Il miglior modo di sviluppare una schedulazione è riutilizzarne una creata precedentemente. Per esempio, se è stato realizzato un progetto simile nel passato, parti utilizzando quella schedulazione come base, e modificala dove serve. Ciò ti farà risparmiare la fatica di scoprire come deve essere rappresentato il lavoro. E' un beneficio specialmente se il precedente project manager ha mantenuto aggiornata la sua schedulazione, in modo da poterla utilizzare per lavori paragonabili.

Se non trovi la schedulazione di un precedente progetto simile, vedi se la tua azienda dispone di template di schedulazione pronte per progetti con certe caratteristiche. Per esempio, può esistere un modulo già pronto per implementare una soluzione con un pacchetto software, o una soluzione Internet, o una soluzione RAD. In questi casi, devi verificare se l'approccio che vuoi utilizzare coincide con uno delle template disponibili. Se è così, utilizza quella template come punto di partenza.

Comunque, bisogna fare attenzione. I moduli generici di una metodologia tendono ad essere enormi e complicati, perchè il fornitore vuole che siano applicabili a tutti i progetti con certe caratteristiche. Appurato che la template di schedulazione è adattabile, il project manager deve valutare le attività nei vari moduli e determinare quelli applicabili al progetto. Le attività applicabili rimarranno nella schedulazione, mentre le attività che non servono saranno rimosse.

5.3.01.1TS Esempi di Creazione la WBS

5.3.02.1TS Definizione Contenuto WBS

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