Gestione dell’ambito

Aspetti generali

La gestione dell’ambito identifica, definisce e controlla gli obiettivi, sotto forma di prodotti, risultati e benefici. Le sue finalità sono:

  • Identificare i desideri e i bisogni degli stakeholder;
  • Specificare i prodotti, i risultati e i benefici che soddisfano i requisiti concordati;
  • Mantenere fermo l’ambito durante tutto il ciclo di vita.

L’ambito rappresenta l’intero insieme di prodotti, risultati e benefici che devono essere realizzati. La complessità dell’ambito è il principale fattore distintivo fra un lavoro gestito come progetto, come programma o come portfolio.

Un elemento chiave del processo di identificazione è decidere se il raggiungimento degli obiettivi richiede cambiamenti alle attività operative ordinarie.

La gestione del cambiamento di basso livello si può tranquillamente realizzare tramite le tipiche strutture di governance del progetto. Un cambiamento più esteso e complesso rende invece consigliabili e più appropriate le strutture di governance del programma (o in alcuni casi del portfolio).

Il modo in cui viene gestito l’ambito dipende da tre fattori: la natura degli obiettivi (prodotti, risultati e benefici), la determinabilità degli obiettivi e la complessità del lavoro.

L’ambito di un progetto includerà generalmente solo prodotti, ma, in caso di bassa complessità, può arrivare a coprire anche i benefici. L’ambito di un programma comprenderà inevitabilmente la realizzazione dei benefici e la conseguente gestione del cambiamento. L’ambito di un portfolio standard è definito dai progetti e programmi che ne fanno parte, mentre l’ambito di un portfolio strutturato è delineato dagli obiettivi strategici che è chiamato a realizzare.

La gestione dell’ambito è costituita da cinque aree principali che lavorano all’unisono per identificare, definire e controllare l’ambito:

  • La gestione dei requisiti ‘cattura’ ed analizza i punti di vista degli stakeholder riguardo agli obiettivi del lavoro. I requisiti non prevedono soluzioni, vale a dire che descrivono i desideri e i bisogni degli stakeholder ma non stabiliscono quali sono i prodotti necessari per soddisfarli.

  • Lo sviluppo delle soluzioni prende in considerazione i requisiti e studia il modo per soddisfarli ottenendo il miglior ritorno dell’investimento.
  • La gestione dei benefici valuta i requisiti espressi in termini di benefici e li gestisce fino alla loro eventuale realizzazione. La gestione dei benefici dipende di solito dalla gestione del cambiamento per convertire i prodotti in risultati e far derivare da questi ultimi i benefici.
  • Il controllo dei cambiamenti è una procedura che individua e valuta i potenziali cambiamenti di ambito. Tale procedura assicura che siano implementati solo i cambiamenti effettivamente desiderabili, raggiungibili e fattibili.
  • La gestione della configurazione monitora e documenta lo sviluppo dei prodotti. Essa registra i cambiamenti approvati e l’archiviazione delle versioni sostituite. Le informazioni contenute in un sistema di gestione della configurazione saranno di aiuto nella valutazione delle richieste di cambiamento.

Il modo in cui queste aree si relazionano fra loro varia considerevolmente. Una procedura semplice di gestione dell’ambito potrebbe assumere la forma che segue (il passo ‘implementazione della soluzione’ comprende sia il controllo dei cambiamenti che la gestione della configurazione):

 

 

Questo schema descrive un approccio lineare che appare appropriato nei casi in cui una ridotta quantità di prodotti supporta un piccolo numero di benefici, vale a dire per un lavoro poco complesso che sarà probabilmente gestito come un progetto.

In un lavoro di maggiore estensione nel quale ci sono relazioni complesse fra molteplici prodotti e benefici, la gestione dell’ambito integra le procedure delle funzioni dalle quali è costituita.

 

 

La gestione dei requisiti fungerà sempre da innesco per lo sviluppo delle soluzioni, che progetta i prodotti tangibili. Se i requisiti sono stati definiti in termini di benefici allora sarà innescata la funzione di gestione dei benefici. I benefici dipendono dalla implementazione dei prodotti, per cui lo sviluppo delle soluzioni e la gestione dei benefici devono inizialmente lavorare in parallelo.

Una volta che i prodotti sono stati documentati in una specifica e i benefici sono stati definiti nel profilo dei benefici, il lavoro ha una baseline di quello che deve essere consegnato. Questo di solito avviene alla fine della fase di definizione del ciclo di vita, anche se qualche dettaglio può essere completato all’inizio delle fasi di progetto o tranche di programma in cui può essere suddivisa la consegna.

La definizione del lavoro richiesto per realizzare la specifica e i benefici viene inclusa all’interno della gestione della schedulazione. Questa definizione del lavoro sarà utilizzata per creare modelli del lavoro che rendano possibile la schedulazione dei tempi, la schedulazione delle risorse ed la programmazione del budget e controllo dei costi.

Una volta che il lavoro prende il via nella fase di consegna dei progetti e dei programmi, qualsiasi cambiamento alla baseline dell’ambito deve essere soggetto al controllo formale dei cambiamenti e registrato nella gestione della configurazione unitamente ai risultati del controllo di qualità.

Il processo di sviluppo dei prodotti riguarda la conduzione di quel lavoro che dipende interamente dal contenuto tecnico, sia che riguardi una costruzione edile, lo sviluppo di un software, lo sviluppo di un prodotto farmaceutico o qualunque altro settore. Il dettaglio di questo processo fuoriesce dalle competenze di project, programme e portfolio management, ad eccezione di quando si interfaccia con la gestione dell’ambito.

La gestione dei benefici prosegue oltre la produzione dei profili dei benefici, per occuparsi anche della gestione del cambiamento al fine di realizzare i benefici stessi. Questa funzione può essere descritta in maniera indipendente dal settore di appartenenza e si considera perciò parte del project, programme e portfolio management.

La misura in cui all’inizio del progetto, programma o portfolio si possono prevedere requisiti e soluzioni dettagliate influenzerà il modo idi gestire l’ambito.

L’evoluzione della terminologia dei progetti, programmi e portfolio ha determinato una confusione potenziale fra i termini ‘controllo dei cambiamenti’ e ‘gestione del cambiamento’.

Il controllo dei cambiamenti ha a che fare specificamente con il controllo di potenziali cambiamenti dell’ambito.

La gestione del cambiamento riguarda il lavoro da svolgere per cambiare le pratiche di lavoro delle attività ordinarie.

Quando l’obiettivo è ben compreso e si traduce in un prodotto tangibile (ad esempio nei progetti e programmi di edilizia ed ingegneria) si è soliti definire l’ambito il più accuratamente possibile nella fase di definizione. Il controllo dei cambiamenti valuta poi tutte le potenziali modifiche dell’ambito, riduce la lievitazione dei costi e mantiene la fattibilità del business case.

È utile altresì definire cosa è escluso dall’ambito per evitare fraintendimenti. La chiara definizione di ciò che è compreso e di ciò che è escluso dall’ambito riduce i rischi e serve a gestire le aspettative di tutti gli stakeholder chiave.

Quando l’obiettivo è meno tangibile o è soggetto a cambiamenti significativi, ad esempio nel caso di un cambiamento di business o per alcuni sistemi IT, è necessario adottare un approccio più flessibile rispetto all’ambito. Si può adottare un ciclo di vita parallelo e un approccio agile quando l’ambito è rifinito in maniera iterativa per tutta la durata della fase di consegna. Questo richiede grande attenzione al fine di evitare la lievitazione dei costi.

Un fattore importante della gestione dell’ambito del lavoro è la massimizzazione del valore dell’investimento. La disciplina della gestione del valore raccoglie una gamma importante di procedure e tecniche che operano in tutte le sei aree. Essa assicura l’ottimizzazione dell’investimento di un progetto, programma o portfolio in relazione al potenziale ritorno che ne può derivare.

 

Progetti, programmi e portfolio

Una volta che un prodotto è stato specificato, la definizione del lavoro stabilisce le singole attività che saranno necessarie per creare il prodotto stesso e tutte le sue componenti. Queste informazioni possono essere presentate sotto forma di struttura di scomposizione del prodotto (product breakdown structure - PBS) e/o di struttura di scomposizione del lavoro (work breakdown structure - WBS).

Lo sviluppo di una struttura di scomposizione è un esercizio di tipo iterativo. Inizialmente verrà eseguito durante il processo di definizione parallelamente alla pianificazione di dettaglio degli altri aspetti del progetto (cioè tempi e costi).  Questi tre elementi che costituiscono il triplo vincolo devono essere bilanciati, e questo può richiedere svariati aggiustamenti al dettaglio della PBS e della WBS.

Nei progetti tradizionali nei quali c’è una specifica del prodotto del progetto abbastanza completa, la struttura di scomposizione approvata viene immessa in baseline al termine del processo di definizione. I prodotti di una PBS diventeranno elementi della configurazione di un sistema di gestione della configurazione, per cui qualsiasi cambiamento proposto per l’ambito passerà attraverso una procedura di controllo formale dei cambiamenti.

Alcuni progetti utilizzano un approccio agile quando la baseline dell’ambito riguarda inizialmente solo i requisiti funzionali piuttosto che prodotti pienamente specificati. I prodotti che soddisfano queste funzioni saranno sviluppati in iterazioni note come time box.

La terminologia relativa all’ambito negli ultimi anni è diventata qualcosa di molto confuso. Praxis per fare un po’ di chiarezza adotta il seguente approccio:

  • Un obiettivo può essere un prodotto di progetto, un risultato o un beneficio.

  • La maggior parte dei prodotti di progetto sono formalmente trasferiti da una parte ad un’altra – nel qual caso possono essere chiamati deliverable.

  • Un prodotto di progetto più complesso può essere composto da molteplici prodotti, alcuni dei quali possono essere loro stessi dei deliverable.

  • Alcuni prodotti saranno anche inseriti in un sistema di gestione della configurazione e definiti come elementi della configurazione.

  • I prodotti, i gruppi di prodotti ed il lavoro che serve per produrli sono noti nel loro insieme come pacchetti di lavoro.

I requisiti di programma sono di solito descritti in termini di risultati e benefici cui sono associati i prodotti che devono essere consegnati dai progetti. L’ambito di un programma è perciò specificato per mezzo di un blueprint, dei profili dei benefici e di una lista dei progetti che fanno parte del programma stesso.

La relazione fra prodotti di progetto, risultati e benefici raramente è di uno a uno e ci saranno molteplici dipendenze fra i prodotti di progetto, i risultati e i benefici. Queste interdipendenze devono essere definite e documentate. Uno sviluppo delle soluzioni, una gestione dei benefici, un controllo dei cambiamenti e una gestione della configurazione del programma nel suo insieme realmente efficaci dipenderanno tutti dalla comprensione di queste interdipendenze.

L’ambito di un programma tende ad essere più fluido di quello di un progetto. È improbabile che all’inizio possano essere identificate le soluzioni per tutti i progetti del programma, inoltre l’ambiente di business può cambiare. Un team di gestione del programma dovrà gestire un ambito in evoluzione per tutto il ciclo di vita.

Un portfolio standard è una raccolta di progetti e programmi che hanno obiettivi non connessi fra loro. Lo scopo principale di un portfolio standard è di creare un’infrastruttura che implementi standard coerenti e faccia il miglior uso possibile delle risorse dell’organizzazione. Il suo ambito è flessibile e non è altro che la somma dei progetti e programmi che contiene.

Un portfolio strutturato è definito dagli obiettivi strategici della propria organizzazione sede che è chiamato a soddisfare. Il suo ambito è dato dalla somma dei progetti, programmi e attività di cambiamento necessari per realizzare quegli obiettivi strategici. 

La gestione dell’ambito di un portfolio strutturato inizia con l’identificazione dei progetti e programmi pertinenti. È probabile che inizialmente saranno inclusi i progetti e programmi già in essere e che durante la vita di un portfolio emergeranno molte idee per progetti e programmi che si batteranno per essere prese in considerazione. L’ambito è regolarmente rivisto e messo a punto attraverso la prioritizzazione ed il bilanciamento delle attività nel corso del processo di gestione del portfolio. È necessario stabilire dei criteri di idoneità che possono essere espressi in termini di livelli di ritorno dell’investimento richiesti o di livelli di rischio accettabili.

Il processo di governance del portfolio dovrebbe definire le regole per sottoporre a revisione le nuove proposte. Per mezzo di tali regole il portfolio manager aiuterà gli sponsor di progetto e di programma a delineare il potenziale ingresso delle iniziative nel portfolio. Nonostante lo sviluppo delle soluzioni e la gestione dei benefici siano delegati in larga misura ai progetti e ai programmi, il processo di coordinamento del portfolio ne assicurerà la massimizzazione del valore.

 

Grazie a E-quality Italia e a Project Management Europa per la traduzione

SHARE THIS PAGE

Please consider allowing cookies to be able to share this page on social media sites.

Change cookie settings
No history has been recorded.
Torna in cima