Ciclo di vita

Aspetti generali

Un ciclo di vita di progetto, programma o portfolio illustra le varie fasi che formulano un’idea iniziale, raccolgono i requisiti degli stakeholder, sviluppano un complesso di obiettivi e poi li realizzano.

Gli scopi della gestione del ciclo di vita sono:

• Identificare le fasi del ciclo di vita adeguate al contesto del lavoro;
• Strutturare le attività di governance in conformità alle fasi del ciclo di vita.

I progetti ed i programmi sono i meccanismi principali per la realizzazione degli obiettivi, mentre i portfolio sono maggiormente focalizzati sul coordinamento e la direzione della consegna di molteplici progetti e/o programmi. Di conseguenza i cicli di vita del progetto e del programma hanno molte analogie e seguono lo stesso approccio di base.

Il ciclo di vita più semplice è quello di un progetto che riguarda solo lo sviluppo di un prodotto:

 

 

Tutto inizia con qualcuno che ha un’idea che vale la pena di essere studiata. Questo innesca la gestione dei requisiti di alto livello e la valutazione della fattibilità dell’idea per creare un business case. Alla fine della fase c’è un gate (potremmo definirla via d’uscita), in corrispondenza del quale viene presa una decisione se procedere o meno con una definizione più dettagliata (e perciò più costosa) del lavoro.

Se l’idea è sufficientemente buona, il lavoro continuerà fino alla definizione di dettaglio che produce una piena giustificazione del lavoro. Ancora una volta questa fase terminerà in un gate in corrispondenza del quale viene presa una decisione se procedere o meno con la fase di consegna.

Una volta che è stato realizzato, il prodotto è di solito sottoposto ad un processo di accettazione prima di essere formalmente consegnato al suo nuovo proprietario. Il ciclo di vita si conclude con la chiusura del progetto.

Tutti i prodotti sono destinati a realizzare benefici e questo aspetto può essere rappresentato come una fase aggiuntiva:

 

 

Questo ciclo di vita di base può essere adattato a contesti molto diversi, ad esempio a circostanze in cui il lavoro è:

• eseguito da un appaltatore per conto di un cliente;
• un progetto che è parte di un programma;
• l’ambito può essere definito anticipatamente o l’ambito evolve man mano che il lavoro progredisce.

Il ciclo di vita è altresì grandemente influenzato dalla complessità dell’ambito del lavoro, ad esempio nei casi in cui il lavoro:

• include l’ottenimento di risultati e benefici;
• è molto esteso ed ha bisogno di essere frazionato.

Questi contesti più complessi richiedono cicli di vita più sofisticati e vengono di solito chiamati programmi.

La struttura per fasi dei cicli di vita facilita la creazione di meccanismi di governance, come:

• Ciascuna fase del ciclo di vita descritta in questa pagina ha una voce corrispondente nelle sezioni metodo, competenza e capability maturity di PraxisProcessi definiti – la gestione di ciascuna fase può essere descritta come un processo costituito da una serie di attività pertinenti.

• Fasi e tranche – la fase di consegna può essere suddivisa in pacchetti di lavoro, chiamati tipicamente “fasi” nei progetti e “tranche” nei programmi.

• Gate review – queste verifiche sono condotte alla fine di una fase o tranche. Lo sponsor prenderà in esame la prestazione alla data attuale e pianificherà la fase successiva prima di decidere se il business case rimane fattibile, utile e realizzabile.

• Post-review (verifiche ex post) – imparare dall’esperienza è un fattore chiave della maturity. Le verifiche post-progetto e post-programma documentano le lezioni apprese da utilizzare in futuro.

• Verifiche dei benefici – misurano la realizzazione dei benefici rispetto al business case

I due approcci principali alle fasi del ciclo di vita sono quello seriale e quello parallelo. La differenza fondamentale risiede nel fatto se i requisiti e le soluzioni possono essere definiti in anticipo o se possono evolvere lungo tutto il ciclo di vita.

Due sono i fattori che influiscono sull’utilizzo di un ciclo di vita seriale o parallelo.

In primo luogo, laddove i deliverable possono, o devono, essere specificati sostanzialmente prima che inizi la consegna del lavoro, il ciclo di vita sarà prevalentemente seriale. Laddove una specifica evolve man mano che il lavoro progredisce il ciclo di vita sarà parallelo.

In secondo luogo, anche se il lavoro può essere interamente descritto nei particolari in anticipo, si può ridurre la durata totale di un progetto o di un programma se il lavoro di descrizione e di consegna viaggiano in parallelo. Questa modalità viene spesso chiamata “fast tracking” (“avanzamento rapido”).

I cicli di vita paralleli facilitano i metodi di consegna agile e le metodologie concurrent engineering.

I cicli di vita dello sviluppo funzionano insieme al ciclo di vita del progetto, programma o portfolio. I primi si concentrano sullo specifico contesto tecnico del lavoro e sul come verrà realizzato, a differenza di come verrà gestito l’intero progetto, programma o portfolio. Fra i cicli di vita dello sviluppo comunemente citati si annoverano quello a cascata e quello a “V”.

 

Progetto

L’ambito del ciclo di vita di un progetto può assumere varie forme in base al contesto. Alcuni progetti faranno parte di un programma e riguarderanno solo la consegna di prodotti (il tradizionale ciclo di vita del progetto). Da alcuni progetti ci si aspetterà l’incorporazione della gestione del cambiamento e la realizzazione dei benefici (il ciclo di vita esteso del progetto). Qualche applicazione (per esempio la Whole Life Costing) può considerare l’intero ciclo di vita del prodotto, ma questo aspetto fuoriesce dall’ambito di Praxis.

Nel caso in cui un appaltatore sta lavorando per un cliente, il “progetto” dell’appaltatore può consistere semplicemente nelle fasi di sviluppo, trasferimento e chiusura del progetto del cliente, che include altresì l’identificazione, la definizione e la realizzazione dei benefici.

Qui sotto viene mostrato un tipico ciclo di vita in serie del progetto:

 

 

• Identificazione – è la fase in cui si sviluppa l’idea iniziale e si elabora un project brief. Viene nominato uno sponsor e, se possibile, un Project Manager. Deve essere effettuata un’analisi sufficientemente approfondita da permettere agli stakeholder senior, guidati dallo sponsor di progetto, di prendere due decisioni:

  • È probabile che il progetto sia auspicabile, realizzabile e fattibile?

  • Vale la pena di investire nella fase di definizione?

• Definizione – In questa fase si valutano più nel dettaglio i requisiti e si descrive nel dettaglio la soluzione prescelta. Si sviluppano i piani di gestione, i piani di consegna e il business case, che devono essere approvati dallo sponsor prima di procedere con la fase successiva.

• Consegna – Questa fase può essere ulteriormente suddivisa in due fasi. Alla fine di ciascuna deve essere verificata la sussistenza della giustificazione continua del progetto.

• Trasferimento e chiusura – I prodotti del progetto sono trasferiti ed accettati dallo sponsor, cliente o utenti come richiesto.

• Realizzazione dei benefici – Ove appropriato, un progetto può includere una fase di realizzazione dei benefici. Questo si verifica tipicamente quando esiste una relazione non complessa, di “uno a uno” fra un prodotto e il relativo beneficio.

Il ciclo di vita intero del prodotto include anche:

• L’esercizio – supporto e assistenza continui;

• La fine fisica – chiusura al termine della vita utile del prodotto.

 

In un ciclo di vita parallelo del progetto, la maggior parte delle fasi si sovrappongono e ci possono essere molteplici consegne di deliverable intermedi prima della chiusura del progetto.

 

 

La caratteristica significativa di un ciclo di vita parallelo è rappresentata dal feedback fra una fase e l’altra. La consegna del lavoro definito all’inizio influenza il successivo segmento di definizione. Allo stesso modo, l’esperienza di consegna, la realizzazione dei benefici e l’esercizio possono tutti influenzare le fasi precedenti creando una serie di iterazioni.

Il ciclo di vita parallelo può essere rappresentato, piuttosto che in termini cronologici, come una iterazione che si ripete con la frequenza necessaria a consegnare il prodotto, dopo di che il progetto viene chiuso.

 

 

L’idea del lavoro iterativo o parallelo è condotta alla sua conclusione logica nei metodi agili comunemente usati nello sviluppo dei sistemi IT.

 

Programma

Qui sotto viene mostrato un tipico ciclo di vita del programma:

 

 

• Identificazione – In questa fase vengono predisposti la vision e il business case preliminare. Viene nominato uno sponsor per sovrintendere alla fase e per determinare un meccanismo per le approvazioni. Vengono abbozzati i benefici attesi e si prepara un programme brief. Deve essere effettuata un’analisi sufficientemente approfondita da permettere agli stakeholder principali, guidati dallo sponsor di programma, di prendere due decisioni:

  • È probabile che il programma sia fattibile?

  • Vale la pena di investire nella fase di definizione?

• Definizione – L’idea generale viene sviluppata in una descrizione dettagliata dello stato finale del programma, spesso denominata blueprint. I piani di gestione, i piani di consegna e il business case sono sviluppati di modo che lo sponsor e gli stakeholder chiave possano prendere una decisione informata riguardo all’andare avanti o meno con il programma.

• Consegna – Questa fase viene normalmente suddivisa in gruppi di progetti chiamati tranches, ciascuno dei quali produce per parte sua un cambiamento positivo. Una revisione alla fine di ciascuna tranche valuta la giustificazione continua del programma.

• Realizzazione dei benefici – Man mano che i nuovi prodotti vengono consegnati dai progetti, si deve mettere in atto una trasformazione del lavoro per garantire che i nuovi metodi di lavoro siano incorporati nelle attività operative ordinarie (business as usual). I benefici vengono misurati e confrontati con la baseline costituita dal business case. Questa fase è frazionata perché la gestione del cambiamento necessaria per la realizzazione dei benefici non è costante e subirà oscillazioni di livello.

• Chiusura – Chiusura degli ultimi progetti, chiusura dei budget e smobilitazione dei team di gestione e di consegna del programma.

La realizzazione dei benefici di solito continua dopo la chiusura del programma. Alcuni membri del team di programma (generalmente lo sponsor di programma e i manager del cambiamento di business) continueranno a svolgere il loro ruolo per assicurare che i benefici siano realizzati come richiesto nel business case.

I cicli di vita del programma sono per natura paralleli. Anche se la fase di definizione produrrà dettagli sufficienti ad autorizzare la fase di consegna, ciascuna tranche e ciascun progetto provocheranno ulteriori definizioni di dettaglio. Poiché ogni progetto consegna dei prodotti, la realizzazione dei benefici camminerà in parallelo alla fase di consegna del programma.

 

Portfolio

A differenza dei progetti e dei programmi, è molto meno probabile che i portfolio abbiano un inizio e una fine definiti. La gestione del portfolio è un ciclo più continuo di coordinamento di progetti e programmi. Esso può essere in ogni caso vincolato da un ciclo di pianificazione strategica, che verifica la strategia in un periodo definito. Se, per esempio, un’organizzazione ha un ciclo di pianificazione strategica triennale, il ciclo del portfolio avrà vincoli di tempo conformi.

 

 

L’obiettivo del portfolio è di coordinare progetti e programmi.

• Inizio – Questa è una fase unica che rappresenta il punto nel quale l’organizzazione sede (“ospitante”) decide di dare vita ad un portfolio. È il momento in cui si crea l’infrastruttura che consente al ciclo del portfolio di operare.

Il ciclo di vita del portfolio è per natura parallelo. A seconda dei momenti l’attenzione potrà essere incentrata sua una fase o su un’altra, ma saranno intrapresi contemporaneamente gli aspetti di tutte le fasi.

• Nel modello di processo di Praxis queste quattro fasi sono combinate all’ interno del processo di gestione del portfolioDefinizione – I progetti, i programmi ed il cambiamento alle attività operative ordinarie (business as usual) richiesti per soddisfare gli obiettivi di portfolio sono identificati e valutati attraverso un processo di selezione che massimizza l’efficacia e l’efficienza del portfolio.

• Categorizzazione – I progetti e i programmi possono essere organizzati in “sub-portfolio” o gruppi che condividono determinate caratteristiche, quali l’allineamento con particolari obiettivi strategici.

• Prioritizzazione – Le priorità possono essere assegnate sulla base di un obiettivo strategico, del ritorno sull’investimento o di qualsiasi altra metrica prescelta. Sul presupposto che nessuna organizzazione ha risorse sufficienti per fare tutto ciò che vuole, il processo di prioritizzazione costituisce la base della fase successiva.

• Bilanciamento – Il portfolio deve essere bilanciato in termini di rischio, utilizzo delle risorse, flusso di cassa e impatto sul business.

La gestione del portfolio incorpora la governance complessiva di progetti e programmi all’interno dell’organizzazione sede. Il team di gestione del portfolio può essere responsabile non solo del coordinamento di progetti e programmi per la realizzazione di obiettivi strategici, ma anche del miglioramento della maturity del project, programme e portfolio management.

 

 

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