Libro - Gestione dell'ambito del progetto

CAPITOLO 5 5

Gestione dell'ambito del progetto La gestione dell’ambito di progetto comprende i processi necessari ad assicurare che il progetto includa tutto il lavoro richiesto, e soltanto il lavoro richiesto, ai fini del suo completamento con successo5. Il suo obiettivo primario è definire e controllare ciò che è incluso nel progetto e ciò che non lo è. La figura 5-1 mostra una visione d'insieme dei processi di gestione dell'ambito del progetto, mentre la figura 5-2 illustra un diagramma di flusso di tali processi e dei relativi input, output e dei processi correlati alle altre aree di conoscenza. 5.1 Pianificazione dell'ambito: creazione di un piano di gestione dell'ambito del

progetto che documenti come l'ambito del progetto sarà definito, verificato e controllato e come sarà creata e definita la struttura di scomposizione del lavoro.

5.2 Definizione dell'ambito: sviluppo di una descrizione dettagliata dell'ambito del progetto che servirà come base per le future decisioni del progetto.

5.3 Creare la WBS: suddivisione dei principali deliverable del progetto, e del lavoro incluso nel progetto, in componenti più piccole e quindi maggiormente gestibili.

5.4 Verifica dell'ambito: accettazione formale dei deliverable di progetto completati.

5.5 Controllo dell'ambito: controllo delle modifiche apportate all'ambito del progetto. I processi descritti interagiscono tra loro e con i processi appartenenti ad altre

aree di conoscenza. Ogni processo può richiedere l’impegno di una o più persone o gruppi, secondo i requisiti del singolo progetto. Ciascun processo viene eseguito almeno una volta per ogni progetto e in una o più fasi di progetto, se il progetto è suddiviso in fasi. Sebbene i processi siano qui presentati come componenti discrete con interfacce ben definite, nella pratica essi possono sovrapporsi o interagire in modi diversi da quelli descritti. Le interazioni tra processi sono trattate in dettaglio nel capitolo 3.

Guida al Project Management Body of Knowledge (Guida al PMBOK®) Terza edizione 2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA 103

Capitolo 5 − Gestione dell'ambito del progetto

Nel contesto del progetto, il termine ambito (scope) si può riferire a: • Specifiche di prodotto: caratteristiche e funzioni che contraddistinguono un

prodotto, un servizio o un risultato. • Ambito del progetto: lavoro che bisogna fare per consegnare un prodotto, un

servizio o un risultato con le caratteristiche e le funzioni specificate. Questo capitolo analizza i processi utilizzati per gestire l'ambito del progetto.

Tali processi di gestione dell'ambito del progetto, e gli strumenti e le tecniche ad essi relativi, variano per area applicativa, vengono generalmente definiti come componenti del ciclo di vita del progetto (paragrafo 2.1) e sono documentati nel piano di gestione dell'ambito del progetto. La descrizione dettagliata e approvata dell'ambito del progetto, la WBS e il dizionario WBS ad essa relativi sono la baseline dell'ambito relativa al progetto stesso.

Generalmente, un progetto ha per risultato un unico prodotto, che può tuttavia contenere componenti secondari, ognuno avente un proprio ambito distinto ma interdipendente. Ad esempio, un nuovo sistema telefonico includerà in genere quattro componenti secondari: hardware, software, formazione e messa in opera.

Lo stato di completezza di un ambito del progetto viene misurato a fronte del piano di Project Management (paragrafo 4.3), della descrizione dell'ambito del progetto, della WBS e del dizionario WBS ad essa relativi; lo stato di completezza delle specifiche di prodotto viene invece misurato a fronte dei requisiti di prodotto. È opportuno che la gestione dell'ambito del progetto sia adeguatamente integrata nei processi delle altre aree di conoscenza, affinché il lavoro del progetto abbia come risultato la consegna del prodotto stabilito dalle specifiche dell’ambito del prodotto.

Guida al Project Management Body of Knowledge (Guida al PMBOK®) Terza edizione 104 2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA

5

Figura 5-1. Visione d’insieme della gestione dell'ambito del progetto



Nota: non vengono mostrate tutte le interazioni dei processi e il flusso di dati tra processi.

Figura 5-2. Diagramma di flusso dei processi di gestione dell'ambito del progetto


5.1 Pianificazione dell'ambito La definizione e la gestione dell'ambito del progetto influiscono sulla sua riuscita complessiva. Ciascun progetto richiede un attento equilibrio tra strumenti, origini dei dati, metodologie, processi e procedure, nonché tra altri fattori che garantiscono che l'impegno dedicato alle attività di ambito sia adeguato alle dimensioni, alla complessità e all'importanza del progetto. Ad esempio, un progetto critico potrebbe richiedere attività di ambito formali, accurate e intensive, mentre un progetto di routine potrebbe avere requisiti assai inferiori in termini di documentazione e verifica. Il gruppo di Project Management si occupa di documentare le decisioni sulla gestione dell'ambito nel contesto del piano di gestione dell'ambito del progetto; quest'ultimo è uno strumento di pianificazione che descrive in che modo il gruppo dovrà definire l'ambito del progetto, elaborarne una dettagliata descrizione, definire ed elaborare la struttura di scomposizione del lavoro, verificare e controllare l'ambito del progetto. L'elaborazione del piano di gestione dell'ambito del progetto e il relativo esame dettagliato cominciano con l'analisi delle informazioni contenute nel Project Charter (paragrafo 4.1), la descrizione preliminare dell'ambito del progetto (paragrafo 4.2), la più recente versione approvata del piano di Project Management (paragrafo 4.3), i dati storici contenuti negli asset dei processi organizzativi (paragrafo 4.1.1.4) ed eventuali altri fattori ambientali aziendali pertinenti (paragrafo 4.1.1.3).

5

Figura 5-3. Pianificazione dell'ambito: Input, Strumenti e tecniche e Output

5.1.1 Pianificazione dell'ambito: Input .1 Fattori ambientali aziendali

I fattori ambientali aziendali comprendono elementi quali la cultura dell’organizzazione, l'infrastruttura, gli strumenti, le risorse umane, le politiche relative al personale e le condizioni di mercato che potrebbero incidere sulle modalità di gestione dell'ambito del progetto.

.2 Asset dei processi organizzativi Gli asset dei processi organizzativi sono regole, procedure e direttive formali e informali che potrebbero incidere sulle modalità di gestione dell'ambito del progetto. Gli asset riportati di seguito rivestono un particolare interesse per la pianificazione dell'ambito del progetto.



• Regole organizzative che fanno capo alla pianificazione e alla gestione dell'ambito del progetto.

• Procedure organizzative relative alla pianificazione e alla gestione dell'ambito del progetto.

• Dati storici legati a progetti precedenti verosimilmente situati nella Knowledge base delle lesson learned.

.3 Project Charter Per la descrizione, consultare il paragrafo 4.1.

.4 Descrizione preliminare dell'ambito del progetto Per la descrizione, consultare il paragrafo 4.2.

.5 Piano di Project Management Per la descrizione, consultare il paragrafo 4.3.

5.1.2 Pianificazione dell'ambito: Strumenti e tecniche .1 Parere di esperti

Nell'elaborazione del piano di gestione dell'ambito del progetto si fa ricorso al parere di esperti relativo al modo in cui è stato gestito l'ambito in progetti equivalenti.

.2 Schemi di documento, Moduli, Standard Tra gli schemi di documento si contano quelli relativi alla struttura di scomposizione del lavoro (modelli di WBS), al piano di gestione dell'ambito e i moduli di controllo delle modifiche dell'ambito del progetto.

5.1.3 Pianificazione dell'ambito: Output .1 Piano di gestione dell'ambito del progetto

Il piano di gestione dell'ambito del progetto fornisce indicazioni sul modo in cui l'ambito del progetto verrà definito, documentato, verificato, gestito e controllato dal gruppo di Project Management. I componenti del piano di gestione dell'ambito del progetto includono: • Un processo che consenta di preparare una descrizione dettagliata dell'ambito

del progetto sulla base della descrizione preliminare. • Un processo che consenta la creazione della WBS a partire dalla descrizione

dettagliata dell'ambito del progetto e che stabilisca in che modo la WBS verrà aggiornata e approvata.

• Un processo che specifichi la modalità per ottenere la verifica e l'accettazione formale dei deliverable di progetto completati.

• Un processo che consenta di controllare in che modo verranno elaborate le richieste di modifica alla descrizione dettagliata dell'ambito del progetto. Tale processo è direttamente collegato al processo di controllo integrato delle modifiche (paragrafo 4.6).

Il piano di gestione dell'ambito del progetto è contenuto nel piano di Project Management, o ne è un componente secondario. Il piano di gestione dell'ambito del progetto può essere informale e sintetico oppure formale e molto dettagliato, in base alle necessità del progetto.


5.2 Definizione dell'ambito La preparazione di una descrizione dettagliata dell'ambito del progetto è critica per la riuscita del progetto stesso e si fonda sui deliverable principali, gli assunti e i vincoli documentati durante l'avvio del progetto nel corso della descrizione preliminare dell'ambito del progetto. Durante la pianificazione, si apprendono ulteriori informazioni sul progetto ed è quindi possibile definire e descrivere l'ambito del progetto con maggiore specificità. Le esigenze, le necessità e le aspettative degli stakeholder vengono analizzate e convertite in requisiti. Viene esaminata la completezza di assunti e vincoli che, se necessario, vengono integrati. Il gruppo di progetto ed altri stakeholder, che dispongono di informazioni approfondite sulla descrizione preliminare dell'ambito del progetto, sono in grado di eseguire e preparare le analisi.

5

Figura 5-4. Definizione dell'ambito: Input, Strumenti e tecniche e Output

5.2.1 Definizione dell'ambito Input .1 Asset dei processi organizzativi

Per la descrizione, consultare il paragrafo 4.1.1.4.

.2 Project Charter Se in una Performing Organization non viene utilizzato alcun Project Charter, è comunque necessario acquisire o elaborare informazioni analoghe e utilizzarle per sviluppare la descrizione dettagliata dell'ambito del progetto.

.3 Descrizione preliminare dell'ambito del progetto Se in una Performing Organization non viene utilizzata alcuna descrizione preliminare dell'ambito del progetto, è comunque necessario acquisire o elaborare informazioni analoghe, comprese le specifiche del prodotto, e utilizzarle per sviluppare la descrizione dettagliata dell'ambito del progetto.

.4 Piano di gestione dell'ambito del progetto Per la descrizione, consultare il paragrafo 5.1.3.1.

.5 Richieste di modifica approvate Le richieste di modifica approvate (paragrafo 4.4) possono comportare modifiche all’ambito del progetto, alla qualità del progetto, ai costi stimati o alla schedulazione di progetto. Le modifiche vengono generalmente identificate e approvate mentre il lavoro del progetto è in corso.



5.2.2 Definizione dell'ambito Strumenti e tecniche .1 Analisi dei prodotti

Ciascuna area applicativa dispone di uno o più metodi largamente accettati per tradurre gli obiettivi di progetto in deliverable e requisiti concreti. L'analisi dei prodotti prevede l'uso di tecniche quali scomposizione dei prodotti, analisi di sistema, ingegneria di sistema, ingegneria del valore, analisi del valore e analisi funzionale.

.2 Identificazione delle alternative La tecnica di identificazione delle alternative si utilizza per generare approcci diversi all'esecuzione del lavoro di progetto. A tale scopo possono essere utilizzate varie tecniche di general management, tra cui le più comuni sono il brainstorming e il pensiero laterale.

.3 Parere di esperti A ciascuna area applicativa possiede esperti che possono essere impiegati per sviluppare parti della descrizione dettagliata dell'ambito del progetto.

.4 Analisi degli stakeholder L'analisi degli stakeholder consente di identificare l'influenza e gli interessi dei vari stakeholder e ne documenta esigenze, necessità e aspettative. L'analisi prosegue quindi selezionando, assegnando una priorità e quantificando tali esigenze, necessità e aspettative al fine della creazione dei requisiti. Le aspettative non quantificabili, quali la soddisfazione del cliente, hanno carattere soggettivo e la probabilità di un loro soddisfacimento è ad alto rischio. È possibile che gli interessi degli stakeholder subiscano l'influsso positivo o negativo dell'esecuzione o del completamento del progetto e che siano a loro volta in grado di esercitare la propria influenza sul progetto e i relativi deliverable.

5.2.3 Definizione dell'ambito Output .1 Descrizione dell'ambito del progetto

La descrizione dell'ambito del progetto illustra dettagliatamente i deliverable di progetto e il lavoro necessario per crearli. La descrizione provvede anche a creare una comune comprensione dell'ambito tra i diversi stakeholder e descrive i principali obiettivi del progetto stesso. Consente inoltre al gruppo di progetto di eseguire una pianificazione più dettagliata, guida il lavoro del gruppo di progetto durante l'esecuzione e fornisce la baseline per valutare se le richieste di modifiche o di lavoro ulteriore siano contenute all'interno o all'esterno dei confini del progetto.

Il grado e il livello di dettaglio in base ai quali la descrizione dell'ambito del progetto definisce quale sia il lavoro da eseguire e quale il lavoro da escludere, può determinare l'efficacia del controllo esercitato dal gruppo di Project Management sull'ambito complessivo del progetto. A sua volta, la gestione dell'ambito del progetto può determinare l'efficacia della pianificazione, della gestione, del controllo e dell'esecuzione del progetto da parte del gruppo di Project Management. La descrizione dettagliata dell'ambito del progetto comprende le voci descritte di seguito, sia direttamente che mediante riferimento ad altri documenti:


• Obiettivi del progetto: Gli obiettivi del progetto comprendono i criteri misurabili del successo del progetto. I progetti possono avere una vasta gamma di obiettivi commerciali, di costo, di schedulazione, tecnici e di qualità. Gli obiettivi del progetto possono comprendere anche obiettivi di costo, di schedulazione e di qualità. Ciascun obiettivo di progetto dispone di attributi quali il costo, di unità di misura quali il dollaro USA e di un valore assoluto o relativo come “minore di 1,5 milioni di dollari”.

• Descrizione delle specifiche di prodotto: Descrive le caratteristiche del prodotto, del servizio o del risultato per la cui realizzazione è stato creato il progetto. Poiché le caratteristiche del prodotto vengono elaborate progressivamente, esse presenteranno generalmente meno dettagli nella fase iniziale rispetto alle fasi successive. Anche se le caratteristiche subiscono una variazione sia formale che sostanziale, la descrizione dell'ambito deve sempre contenere informazioni sufficientemente dettagliate da consentire in seguito la pianificazione dell'ambito del progetto.

5

• Requisiti del progetto: Descrive le condizioni o le qualità che i deliverable del progetto devono soddisfare o possedere per garantire la conformità a un contratto, a uno standard, a specifiche di prodotto o ad altra documentazione il cui rispetto è formalmente imposto. Le analisi di tutte le esigenze degli stakeholder, le loro necessità e le loro aspettative vengono tradotte in requisiti cui viene assegnata una priorità.

• Limiti di progetto: Identificano in genere ciò che è incluso nel progetto. Dichiara esplicitamente ciò che è escluso dal progetto, nel caso in cui uno stakeholder possa basarsi sull'assunto che un determinato prodotto, servizio o risultato possa essere un componente del progetto.

• Deliverable di progetto: I deliverable (paragrafo 4.4.3.1) comprendono tanto gli output che contengono il prodotto o servizio del progetto, quanto i risultati collaterali, quali le relazioni e la documentazione del Project Management. A seconda della descrizione dell'ambito del progetto, i deliverable possono essere descritti a livello sommario o in modo particolarmente dettagliato.

• Criteri di accettazione del prodotto: Definisce il processo e i criteri di accettazione dei prodotti completati.

• Vincoli del progetto: Elenca e descrive i vincoli di progetto specifici associati all'ambito del progetto che limitano le opzioni a disposizione del gruppo di lavoro. Sono compresi, ad esempio, un budget predefinito o una data imposta (milestone di schedulazione) richiesti formalmente dal cliente o dalla Performing Organization. Nel caso in cui il progetto sia eseguito in dipendenza di un contratto, i termini del contratto si tradurranno, in genere, in vincoli. I vincoli elencati nella descrizione dettagliata dell'ambito del progetto sono solitamente più numerosi e dettagliati di quelli elencati nel Project Charter.

• Assunti del progetto: Elenca e descrive gli specifici assunti del progetto relativi all'ambito e l'impatto potenziale di tali assunti se dovessero dimostrarsi falsi. I gruppi di progetto spesso li identificano, li documentano e li convalidano nel corso del processo di pianificazione. Gli assunti elencati nella descrizione dettagliata dell'ambito del progetto sono in genere più numerosi e dettagliati di quelli elencati nel Project Charter.



• Organizzazione iniziale del progetto: Identifica i membri del gruppo di progetto e gli stakeholder. È inoltre documentata l'organizzazione del progetto.

• Rischi iniziali definiti: Identifica i rischi noti. • Milestone di schedulazione: Il cliente o la Performing Organization possono di

identificare milestone e mettere delle date imposte in tali milestone di schedulazione. Ci si può riferire a queste date come vincoli di schedulazione.

• Limite di finanziamento: Descrive qualsiasi limitazione a cui è soggetto il finanziamento del progetto, sia nel valore complessivo che riguardo ad un lasso di tempo specificato.

• Stima dei costi: La stima dei costi del progetto confluisce nel costo totale previsto del progetto e viene generalmente preceduta da una specifica che fornisce indicazioni di accuratezza, ad esempio concettuale o definitivo.

• Requisiti di gestione della configurazione del progetto: Descrive il livello della gestione della configurazione e del controllo delle modifiche da implementare sul progetto.

• Specifiche del progetto: Identifica i documenti delle specifiche a cui il progetto si deve attenere.

• Requisiti di approvazione: Identifica i requisiti di approvazione che è possibile applicare ad elementi quali obiettivi del progetto, deliverable, documenti e lavoro.

.2 Richieste di modifica Durante il processo di definizione dell'ambito possono venire elaborate richieste di modifica al piano di Project Management e ai relativi piani ausiliari. Le modifiche vengono elaborate per l'analisi e la disposizione dal processo di controllo integrato delle modifiche.

.3 Piano di gestione dell'ambito del progetto (aggiornamenti) Potrebbe essere necessario aggiornare il componente del piano di Project Management relativo al piano di gestione dell'ambito del progetto affinché comprenda le richieste di modifica approvate, come risultano dal processo di definizione dell'ambito.

.5.3 Creare la WBS La WBS è una scomposizione gerarchica, orientata ai deliverable, del lavoro che deve essere eseguito dal gruppo di progetto per realizzare gli obiettivi del progetto stesso e creare i deliverable richiesti. La WBS organizza e definisce l'ambito complessivo del progetto. Essa ne suddivide il lavoro in porzioni più piccole e più facili da gestire, dove ogni livello successivo della WBS comporta una definizione più dettagliata del lavoro di progetto. È possibile effettuare la schedulazione, la stima dei costi, il monitoraggio e il controllo del lavoro pianificato, contenuto nei componenti della WBS che si trovano ai livelli più bassi della gerarchia, chiamati anche Work Package.

La WBS rappresenta il lavoro specificato nella descrizione dell'ambito del progetto, approvata. I componenti costitutivi della WBS sono d’aiuto agli stakeholder nel visualizzare i deliverable (paragrafo 4.4.3.1) del progetto.


5 Figura 5-5. Creare la WBS: Input, Strumenti e tecniche e Output

5.3.1 Creare la WBS: Input

.1 Asset dei processi organizzativi Per la descrizione, consultare il paragrafo 4.1.1.4.

.2 Descrizione dell'ambito del progetto Per la descrizione, consultare il paragrafo 5.2.3.1.


.4 Richieste di modifica approvate Per la descrizione, consultare il paragrafo 4.4.1.4.

5.3.2 Creare la WBS: Strumenti e tecniche .1 Modelli della struttura di scomposizione del lavoro

Sebbene ciascun progetto sia unico, è possibile utilizzare la WBS di un progetto precedente come modello per progetto un nuovo, in quanto alcuni progetti possono essere affini a progetti precedenti. Ad esempio, molti progetti all’interno di un’organizzazione sono caratterizzati da cicli di vita identici o simili e di conseguenza i deliverable richiesti per ciascuna fase risultano identici o simili. Molte aree applicative o Performing Organization hanno adottato dei modelli di WBS standard.

Il Project Management Institute Practice Standard for Work Breakdown Structures fornisce una guida alla generazione, allo sviluppo e all'applicazione delle strutture di scomposizione del lavoro. Nel manuale sono contenuti numerosi esempi, specifici per settore, dei modelli delle WBS che possono essere personalizzati per progetti specifici creati in una determinata area applicativa. Nella figura 5-6 viene illustrata una parte di un esempio di WBS, con alcune diramazioni della WBS scomposta fino al livello dei Work Package.



Figura 5-6. Esempio di struttura di scomposizione del lavoro con alcune diramazioni scomposte fino ai Work Package

.2 Scomposizione La scomposizione è una suddivisione dei deliverable del progetto in componenti più piccoli e più facili da gestire fino a che lavoro e deliverable vengono definiti a livello di Work Package. Il livello dei Work Package rappresenta il gradino più basso della gerarchia creata dalla WBS ed è il punto che consente una stima più affidabile dei costi e della schedulazione previsti dal lavoro. Il livello di dettaglio dei Work Package varia in base alle dimensioni e alla complessità del progetto.

Non sempre è possibile effettuare la scomposizione di un deliverable o un sottoprogetto che dovrebbero essere eseguiti in un periodo troppo lontano nel tempo. Il gruppo di Project Management aspetta in genere fino a che i deliverable o il sottoprogetto siano più chiari per sviluppare i dettagli della WBS. Tale tecnica viene a volte denominata “pianificazione a finestra mobile”.

Deliverable diversi possono essere caratterizzati da livelli di scomposizione diversi. Per ottenere un impegno di lavoro che sia gestibile (come un Work Package), il lavoro relativo ad alcuni deliverable deve essere scomposto soltanto al livello successivo, mentre in altri casi sono necessari ulteriori livelli di scomposizione. Con l'incremento della scomposizione del lavoro in livelli di dettaglio inferiori, si incrementa la capacità di pianificare, gestire e controllare il lavoro. Tuttavia, una scomposizione eccessiva può portare a un impegno di gestione improduttivo, a un uso inefficiente delle risorse e a un calo dell'efficienza nell'esecuzione del lavoro. Il gruppo di progetto deve trovare un punto di equilibrio tra un livello scarso e un livello eccessivo di dettaglio nella pianificazione della WBS.


La scomposizione del lavoro complessivo di progetto comporta in genere le attività riportate di seguito: • Identificazione dei deliverable e del relativo lavoro. • Strutturazione e organizzazione della WBS. • Scomposizione dei livelli superiori della WBS in componenti dettagliati a livelli

inferiori. • Sviluppo e assegnazione di codici di identificazione ai componenti della WBS. • Verifica che i livelli di scomposizione del lavoro siano necessari e sufficienti.

5 L'identificazione dei principali deliverable del progetto e del lavoro necessario per produrre tali deliverable richiede l'analisi della descrizione dettagliata dell'ambito del progetto. Tale analisi necessita inoltre l’utilizzo del parere di esperti che consenta di identificare tutto il lavoro incluso nei deliverable di Project Management e nei deliverable richiesti da contratto.

La strutturazione e l'organizzazione dei deliverable e del lavoro di progetto ad essi associato in una WBS, che sia conforme ai requisiti di controllo e di gestione imposti dal gruppo di Project Management, è una tecnica analitica che può essere eseguita utilizzando un modello di WBS. La struttura che ne risulta può assumere diverse forme come: • Utilizzo dei deliverable e dei sottoprogetti principali come primo livello di

scomposizione, come illustrato nella figura 5-6. • Utilizzo dei sottoprogetti illustrati nella figura 5-6, dove i sottoprogetti possono

essere sviluppati da organizzazioni esterne al gruppo di progetto. Ad esempio, in alcune aree applicative è possibile definire e suddividere la WBS di progetto in più parti, come una WBS di progetto riepilogativa con più sottoprogetti al suo interno, che possono essere dati in subappalto. Il fornitore sviluppa quindi una WBS di supporto al contratto come elemento costitutivo del lavoro pattuito.

• Utilizzo delle fasi del ciclo di vita del progetto come primo livello di scomposizione, con i deliverable del progetto inseriti al secondo livello, come mostrato nella figura 5-7.

• Utilizzo di approcci diversi all'interno di ciascuna diramazione della WBS, come mostrato nella figura 5-8, dove il collaudo e la valutazione sono una fase, l'aeromobile è un prodotto e la formazioni un servizio di supporto.

La scomposizione dei componenti della WBS di livello superiore richiede la suddivisione del lavoro per ciascun deliverable o sottoprogetto nei suoi componenti fondamentali, dove i componenti della WBS rappresentano dei prodotti, servizi o risultati verificabili. Ogni componente deve essere definito chiaramente ed esaustivamente e quindi assegnato a un'unità specifica interna alla Performing Organization che accetti la responsabilità legata al completamento dei componenti della WBS. I componenti vengono definiti in base alla modalità effettiva di esecuzione e controllo del lavoro previsto dal progetto. Ad esempio, il componente report di stato del Project Management può prevedere dei report di stato settimanali, mentre il prodotto da generare può comprendere numerosi componenti fisici unici più l'assemblaggio finale.



Nell'ambito della verifica della correttezza della scomposizione è necessario determinare se i componenti della WBS appartenenti ai livelli inferiori siano effettivamente quelli necessari e sufficienti al completamento dei corrispondenti deliverable appartenenti a livelli superiori.

Figura 5-7. Esempio di struttura di scomposizione del lavoro organizzata per fasi

Figura 5-8. Esempio di scomposizione del lavoro per articoli di materiale per la Difesa


5.3.3 Creare la WBS: Output .1 Descrizione dell'ambito del progetto (aggiornamenti)

Se dal processo Creare la WBS vengono originate richieste di modifica approvate, allora la descrizione dell'ambito del progetto viene aggiornata in modo da includerle.

.2 Struttura di scomposizione del lavoro La WBS corrente è il documento principale generato dal processo Creare la WBS. A ciascun componente della WBS, compresi i Work Package e i punti di controllo appartenenti a una WBS, viene in genere assegnato un identificativo univoco da un codice di classificazione. Questi identificativi forniscono una struttura per la somma gerarchica delle informazioni su costi, schedulazione e risorse.

5 La WBS non va confusa con altre forme di strutture di scomposizione utilizzate

per presentare informazioni del progetto. Di seguito vengono illustrate le altre strutture utilizzate in alcune aree applicative o in altre aree di conoscenza: • Struttura di scomposizione dell'organizzazione (OBS): fornisce una

rappresentazione gerarchica dell'organizzazione del progetto disposta in modo da correlare i Work Package alle unità della Performing Organization.

• Distinta base (BOM): rappresenta un elenco organizzato in ordine gerarchico dei componenti finiti, dei componenti semilavorati e dei componenti fisici necessari alla creazione del prodotto.

• Struttura di scomposizione dei rischi (RBS): fornisce una rappresentazione gerarchica dei rischi del progetto ordinata per categoria di rischio.

• Struttura di scomposizione delle risorse (RBS): fornisce una rappresentazione gerarchica delle risorse ordinate per tipo da utilizzare nel corso del progetto.

.3 Dizionario della WBS Il documento generato dal processo Creare la WBS che supporta la WBS viene chiamato “dizionario della WBS” ed è il documento di accompagnamento della WBS stessa. Nel dizionario della WBS è possibile descrivere in modo dettagliato il contenuto dei componenti inclusi in una WBS, compresi i Work Package e i punti di controllo. Per ciascun componente della WBS, il dizionario della WBS riporta un identificativo dei codici di classificazione, un capitolato, dati sull'organizzazione responsabile e un elenco delle milestone di schedulazione. Altre informazioni relative a un componente della WBS comprendono i dati di contatto, i requisiti della qualità e i riferimenti tecnici che servono per facilitare le prestazioni del lavoro. Altre informazioni relative al controllo possono invece essere costituite dalla voce di spesa. Per il Work Package possono invece essere aggiunte informazioni come un elenco delle attività schedulate ad esso associate, le risorse necessarie e una stima dei costi. Ogni componente della WBS dispone di un rimando, ove opportuno, ad altri componenti della WBS inclusi nel dizionario della WBS stessa.

.4 Baseline dell'ambito La descrizione dettagliata e approvata dell'ambito del progetto (paragrafo 5.2.3.1), la WBS e il dizionario della WBS ad essa relativi costituiscono la baseline dell'ambito del progetto.



.5 Piano di gestione dell'ambito del progetto (aggiornamenti) Se dal processo Creare la WBS vengono originate richieste di modifica approvate, il piano di gestione dell'ambito del progetto potrebbe necessitare di un aggiornamento in modo da includere le modifiche approvate.

.6 Richieste di modifica Le richieste di modifica alla descrizione dell'ambito del progetto e ai suoi componenti possono essere generate dal processo Creare la WBS e quindi elaborate per l'analisi e l'approvazione mediante il processo di controllo integrato delle modifiche.

5.4 Verifica dell'ambito La verifica dell'ambito è il processo che consente di ottenere l'accettazione formale da parte degli stakeholder dell'ambito del progetto completo e dei deliverable associati. La verifica dell'ambito del progetto prevede l'analisi dei deliverable per controllare che ciascuno di essi sia stato completato in modo soddisfacente. Se il progetto viene concluso prima, il processo di verifica dell'ambito del progetto deve stabilire e documentare il livello e la dimensione del completamento. La verifica dell'ambito differisce dal controllo qualità per il fatto che la prima riguarda principalmente l'accettazione dei deliverable, mentre il secondo riguarda soprattutto la conformità ai requisiti di qualità specificati per i deliverable. Il controllo qualità viene in genere eseguito prima della verifica dell'ambito; i due processi possono essere tuttavia eseguiti in parallelo.

Figura 5-9. Verifica dell'ambito: Input, Strumenti e tecniche e Output

5.4.1 Verifica dell'ambito: Input

.1 Descrizione dell'ambito del progetto La descrizione dell'ambito del progetto comprende la descrizione delle specifiche di prodotto che illustra il prodotto del progetto da analizzare e i criteri di accettazione del prodotto adottati.

.2 Dizionario della WBS Il dizionario della WBS è un componente della definizione dettagliata dell'ambito del progetto che consente di verificare che i deliverable prodotti e accettati siano inclusi nell'ambito del progetto approvato.



.4 Deliverable I deliverable sono quelli che sono stati completati sia totalmente che parzialmente e rappresentano l'output del processo Dirigere e gestire l'esecuzione del progetto (paragrafo 4.4).

5.4.2 Verifica dell'ambito: Strumenti e tecniche 5 .1 Ispezione

L'ispezione prevede attività quali la misurazione, l'esame e la verifica che consentono di determinare se il lavoro e i deliverable rispondono ai requisiti e ai criteri di accettazione del prodotto. Le ispezioni sono anche denominate analisi, analisi del prodotto, revisioni e analisi passo-passo. In alcune aree applicative, questi termini hanno significati più limitati e specifici.

5.4.3 Verifica dell'ambito: Output .1 Deliverable accettati

Il processo di verifica dell'ambito documenta i deliverable completati che sono stati anche accettati. I deliverable completati ma non accettati vengono invece documentati unitamente ai motivi alla base della mancata accettazione. La verifica dell'ambito comprende la documentazione di supporto ricevuta dal cliente o dallo sponsor che conferma l'accettazione dei deliverable del progetto da parte degli stakeholder.

.2 Richieste di modifica Le richieste di modifica possono essere generate dal processo di verifica dell'ambito e vengono elaborate per la revisione e la disposizione attraverso il processo di controllo integrato delle modifiche.

.3 Azioni correttive consigliate Per la descrizione, consultare il paragrafo 4.5.3.1.

5.5 Controllo dell'ambito Il controllo dell'ambito del progetto si occupa di come influire sui fattori che creano le modifiche all'ambito del progetto e di come controllare l'impatto di tali modifiche. Il controllo dell'ambito garantisce che tutte le modifiche richieste e le azioni correttive consigliate siano elaborate attraverso il processo di controllo integrato delle modifiche del progetto. Il controllo dell'ambito del progetto, integrato con altri processi di controllo, consente inoltre di gestire le modifiche effettive nel momento stesso in cui queste si verificano. Ci si riferisce alle modifiche non controllate con l'espressione “cambiamento non controllato dell'ambito del progetto”. Le modifiche sono inevitabili e rendono quindi necessario un processo di controllo delle modifiche.



Figura 5-10. Controllo dell'ambito: Input, Strumenti e tecniche e Output

5.5.1 Controllo dell'ambito: Input

.1 Descrizione dell'ambito del progetto La descrizione dell'ambito del progetto, unitamente alla WBS e al dizionario della WBS ad essa associati (paragrafo 5.3), definisce la baseline dell'ambito del progetto e le specifiche di prodotto.

.2 Struttura di scomposizione del lavoro Per la descrizione, consultare il paragrafo 5.3.3.2.

.3 Dizionario della WBS Per la descrizione, consultare il paragrafo 5.3.3.3.


.5 Report sulle prestazioni I report sulle prestazioni forniscono informazioni sulle prestazioni del lavoro di progetto, come sui deliverable provvisori che sono stati completati.

.6 Richieste di modifica approvate Una richiesta di modifica approvata (paragrafo 4.4.1.4), che impatta sull'ambito del progetto, è una qualsiasi modifica alla baseline dell'ambito, come definito nella descrizione approvata dello stesso, alla WBS e al dizionario della WBS approvati.

.7 Informazioni sullo stato di avanzamento del lavoro Per la descrizione, consultare il paragrafo 4.4.3.7.


5.5.2 Controllo dell'ambito: Strumenti e tecniche .1 Sistema di controllo delle modifiche

Il sistema di controllo delle modifiche dell'ambito del progetto, documentato nel piano di gestione dell'ambito, definisce le procedure da seguire per apportare delle modifiche all'ambito del progetto e alle specifiche di prodotto. Il sistema comprende la documentazione, i sistemi di rilevamento e i livelli di approvazione necessari per autorizzare le modifiche. Il sistema di controllo delle modifiche dell'ambito viene integrato con qualsiasi sistema informativo completo di Project Management (paragrafo 4.6.2.2) al fine di controllare l'ambito del progetto. Quando il progetto viene gestito in ottemperanza a un contratto, il sistema di controllo delle modifiche deve conformarsi alle disposizioni contrattuali.

5

.2 Analisi dello scostamento Le misurazioni delle prestazioni del progetto consentono di valutare la dimensione dello scostamento. Un aspetto importante nel controllo dell'ambito del progetto è la determinazione della causa dello scostamento rispetto alla baseline dell'ambito (paragrafo 5.3.3.4) e la decisione su quale azione correttiva sia necessaria.

.3 Ripianificazione Le richieste di modifica approvate che influiscono sull'ambito del progetto possono comportare delle modifiche anche alla WBS e al dizionario della WBS, alla descrizione dell'ambito e al piano di gestione dell'ambito. Le richieste di modifica approvate possono inoltre essere causa di aggiornamenti ai componenti del piano di Project Management.

.4 Sistema di gestione della configurazione Un sistema formale di gestione della configurazione (paragrafo 4.3.2.2) fornisce le procedure per lo stato dei deliverable e garantisce che le modifiche richieste all'ambito del progetto e alle specifiche di prodotto siano prese in considerazione e documentate in modo accurato prima di essere elaborate dal processo di controllo integrato delle modifiche.

5.5.3 Controllo dell'ambito: Output .1 Descrizione dell'ambito del progetto (aggiornamento)

Se le richieste di modifica approvate hanno impatto sull'ambito del progetto, la descrizione dell'ambito del progetto viene rivista e quindi ripubblicata in conformità alle modifiche approvate. La descrizione aggiornata dell'ambito del progetto diviene la nuova baseline dell'ambito del progetto per modifiche future.

.2 Struttura di scomposizione del lavoro (aggiornamenti) Se le richieste di modifica approvate hanno impatto sull'ambito del progetto, la WBS viene rivista e quindi ripubblicata in conformità alle modifiche approvate.

.3 Dizionario della WBS (aggiornamento) Se le richieste di modifica approvate hanno impatto sull'ambito del progetto, il dizionario della WBS viene rivisto e quindi ripubblicato in conformità alle modifiche approvate.



.4 Baseline dell'ambito (aggiornamento) Per la descrizione, consultare il paragrafo 5.3.3.4.

.5 Richieste di modifica I risultati del controllo dell'ambito del progetto possono generare delle richieste di modifica, che vengono elaborate per la revisione e la disposizione in conformità al processo di controllo integrato delle modifiche del progetto.

.6 Azione correttiva consigliata Un’azione correttiva raccomandata rappresenta un passo consigliato per allineare le prestazioni future previste per il progetto al piano di Project Management e alla descrizione dell'ambito del progetto.

.7 Asset dei processi organizzativi (aggiornamenti) Le cause degli scostamenti, la motivazione alla base dell'azione correttiva scelta e altri tipi di lesson learned, derivanti dal controllo delle modifiche dell'ambito del progetto, vengono documentati e aggiornati nel database dei dati storici degli asset dei processi organizzativi.

.8 Piano di Project Management (aggiornamenti) Se le richieste di modifica approvate influiscono sull'ambito del progetto, allora i corrispondenti documenti che le compongono, le baseline dei costi e le baseline di schedulazione del piano di Project Management vengono rivisti e ripubblicati in conformità alle modifiche approvate.


Libro - Gestione dell'ambito del progetto

Documents

Transcript of Libro - Gestione dell'ambito del progetto