• Il livello di incertezza, e quindi anche il rischio di non riuscire a raggiungere gli obiettivi, sono maggiori all’inizio del progetto. In genere la certezza di raggiungere il completamento si intensifica progressivamente con l’avanzamento del progetto

• L’abilità degli stakeholder di influenzare le caratteristiche e il costo finali del prodotto del progetto è massima all’inizio e diminuisce progressivamente via via che il progetto avanza. La figura 2-2 illustra questo fenomeno. Un maggior contributo a ciò lo da il fatto che di solito il costo delle modifiche e della correzione degli errori aumenta con l’avanzamento del progetto.

Figura 2-2. Influenza dei stakeholder nel corso del tempo

Sebbene molti cicli di vita dei progetti siano caratterizzati da nomi di fasi simili con deliverable analoghi, pochi sono completamente identici. Alcuni sono composti da quattro o cinque fasi, mentre altri ne possono contenere nove o più. Le singole aree applicative sono invece caratterizzate da variazioni anche significative. Il ciclo di vita dello sviluppo di un software di una struttura organizzativa può essere composto da una sola fase di progettazione, mentre un altro può essere composto da fasi separate per l’architettura e per il disegno di dettaglio. Inoltre i sottoprogetti posso avere cicli di vita di progetto differenti Ad esempio, uno studio di architetti, scelto per il progetto di un nuovo complesso di uffici, è dapprima impegnato nella fase di definizione del progetto del committente mentre sta facendo la progettazione; è poi impegnato nella fase di implementazione, mentre sta facendo da supporto alla fase di messa in opera. Il piano di progettazione dello studio di architetti, tuttavia, sarà fatto da un suo insieme di fasi, dallo sviluppo concettuale alla definizione fino alla messa in opera e alla chiusura. Gli architetti potrebbero addirittura considerare la progettazione dell’edificio e la consulenza per la sua costruzione come progetti separati, ciascuno con un proprio set di fasi.

Il completamento e l’approvazione di uno o più deliverable caratterizzano una fase di progetto. Un deliverable è un prodotto del lavoro misurabile e verificabile, come le specifiche di prodotto, il rapporto finale di uno studio di fattibilità, un documento di progettazione dettagliato o un prototipo funzionante. Alcuni deliverable possono corrispondere al processo di Project Management, mentre altri costituiscono i prodotti finali o i componenti dei prodotti finali per i quali era nato il progetto. I deliverable, e di conseguenza anche le fasi, sono un elemento costitutivo di un processo, in genere sequenziale, ideato per garantire un adeguato controllo del progetto e per raggiungere il prodotto o il servizio desiderati, ovvero l’obiettivo del progetto.

In qualsiasi specifico progetto, per ragioni di dimensioni, complessità, livello di rischio e vincoli di flusso di cassa, le fasi possono essere ulteriormente suddivise in sottofasi. Ogni sottofase, per l’esecuzione del monitoraggio e del controllo, è associata a uno o più deliverable specifici. La maggior parte di questi sono collegati ai deliverable della fase principale, e le fasi normalmente da questi prendono il nome: requisiti, progettazione, costruzione, collaudo, avviamento, volume di affari e molti atri ancora, in base alle esigenze.

Una fase di progetto termina in genere con una revisione del lavoro svolto e dei deliverable ottenuti per determinarne il livello di accettazione e verificare se è necessario ulteriore lavoro oppure se la fase può considerarsi conclusa. Spesso viene condotta un’analisi da parte della direzione per decidere se avviare le attività della fase successiva senza chiudere quella ancora in corso, ad esempio quando il project manager sceglie come linea di condotta il fast tracking. Un altro esempio di questo fenomeno è dato da un’azienda del settore informatico che sceglie di adottare un ciclo di vita iterativo per il quale più fasi del progetto vengono svolte contemporaneamente. È possibile raccogliere, analizzare, progettare e realizzare i requisiti di un modulo e, mentre si esegue l’analisi del modulo, è possibile avviare in parallelo la raccolta dei requisiti di un altro modulo.

Analogamente, è possibile chiudere una fase senza decidere di iniziarne una nuova. Una situazione simile si verifica quando il progetto è completato o quando si ritiene che proseguire il progetto sia troppo rischioso.

Il completamento formale della fase non include anche l’autorizzazione all’avvio della fase successiva. Per un controllo efficace, ogni fase viene formalmente iniziata al fine di produrre un output, dipendente dalla fase stessa, che specifichi cosa è permesso e previsto nell’ambito della fase in questione, come illustrato nella figura 2-3. È quindi possibile eseguire un’analisi di fine fase con l’esplicito intento di ottenere l’autorizzazione a chiudere la fase in corso e ad avviare quella successiva. A volte vengono concesse entrambe le autorizzazioni con una sola analisi. Le revisioni di fine fase sono spesso denominate uscite dalla fase, punti di uscita o punti di rottura.

Figura 2-3. Tipica sequenza delle fasi in un ciclo di vita del progetto

Molti progetti sono collegati al lavoro normalmente svolto all’interno della Performing Organization. Alcune strutture organizzative approvano formalmente i progetti solo dopo il completamento di uno studio di fattibilità, di un piano preliminare o di altra forma di analisi equivalente. In questi casi, la pianificazione e l’analisi preliminare costituiscono progetti separati. Ad esempio, è possibile che si ricorra a fasi aggiuntive per lo sviluppo e il collaudo di un prototipo prima di iniziare un progetto che riguarda lo sviluppo del prodotto finale. Alcuni tipi di progetti, soprattutto i progetti per lo sviluppo di servizi interni o di nuovi prodotti, possono essere avviati anche informalmente, per un lasso di tempo limitato, in modo da garantire l’approvazione formale delle fasi o delle attività aggiuntive.

I fattori abilitanti che generano gli stimoli per lo sviluppo di un progetto vengono generalmente denominate problemi, opportunità o requisiti aziendali. L’effetto di queste pressioni è quello di spingere la direzione ad assegnare una priorità a questa richiesta, nel rispetto delle esigenze e delle richieste di risorse di altri potenziali progetti.