La gestione strutturata dei progetti: fasi, ciclo di vita del progetto e processi di project management
Antonio Giannico
MScEng, Project Manager UNI 11648, PMP®, SMC™ Scrum Master, Accredited Senior Project Management Teacher (ISIPM), ISIPM-Prado® Assessor
Quando ci apprestiamo a gestire un progetto dovrebbe venire naturale interrogarci su quale sarà il suo ciclo di vita, quali saranno le sue fasi evolutive, quali i processi gestionali che dovranno caratterizzare le singole fasi, quali gli input e gli output che legheranno questi processi all’interno della singola fase o in grado di interconnettere tra loro due o più fasi. Ragionare in quest’ottica significa avere un approccio strutturato alla gestione del progetto. Si tratta di maturare e possedere un approccio sistemico che consenta al project manager di integrare il progetto in maniera efficace sia al suo interno che verso l’esterno.
La strutturazione del progetto in fasi
Quando ci apprestiamo a strutturare un progetto dovrebbe venire naturale interrogarci su quale sarà il suo ciclo di vita intendendo con ciclo di vita le fasi attraverso le quali esso dovrà evolvere per giungere, nel modo più efficace ed efficiente possibile, al raggiungimento degli obiettivi. Porsi consapevolmente il problema è un inizio tutt’altro che scontato, dare risposte corrette e appropriate è un’opportunità da cogliere oltre che una necessità.
La risposta più intuitiva e immediata all’interrogativo è certamente quella che ci porta, quasi sempre, a tentare di scomporre il progetto in fasi sequenziali (Figura 1). L’approccio in linea di massima è corretto. Si tratta tendenzialmente di un approccio waterfall e fully plan driven che tuttavia quasi mai può essere applicato in maniera pura, rigorosa ed efficace allo stesso tempo. A seconda del caso specifico infatti, le fasi del progetto possono, per loro natura, essere sequenziali nel senso classico del termine piuttosto che parzialmente sovrapposte (in questo caso perdono il significato classico del termine) e possono nello specifico anche presentarsi come iterative o incrementali. Le iterazioni dal punto di vista temporale sono comunque fasi di progetto sebbene non predittive (si pensi agli sprint della metodologia scrum). Gli aspetti che contribuiscono a definire le relazioni tra le fasi sono infatti molteplici e tali da portare il progetto ad essere più o meno predittivo (si pensi a progetti relativamente standardizzati) piuttosto che adattativo (si pensi a progetti di ricerca, progetti innovativi e altamente rischiosi).
Figura 1-Il cilco di vita del progetto è dato dall’insieme delle fasi che ne costituiscono il processo evolutivo e dalle relative relazioni di interconnessione
Un progetto fortemente predittivo presenta ambito, tempi e costi abbastanza definiti già in partenza e questo tende a suggerire fin dall’avvio un approccio waterfall cioè con fasi in cascata anche se non è raro che queste vengano talvolta, nell'evoluzione pratica, a sovrapporsi parzialmente rimanendo comunque fondamentalmente fully plan driven (Figura 2).
Figura 2-Schematizzazione di un tipico progetto con ciclo di vita predittivo (dalla definizione dei requisiti alla consegna dei deliverble finali)
Per contro, in un progetto altamente incerto, il ciclo di vita assume caratteristiche molto diverse. Spesso, le fasi di un progetto siffatto assumono natura iterativa poiché, per quanto si cerchi di definire l’ambito in partenza, esso resta in parte più o meno ampia non definito o determinato tanto che tempi e costi vengono meglio elaborati e pianificati in corso d’opera man mano che ad ogni iterazione gli obiettivi (per esempio le funzionalità dei prodotti o del servizio) vengono progressivamente compresi, affinati, talvolta aggiunti, e via via sottoposti a verifiche e correzioni sulla base della disponibilità di nuove e più accurate informazioni. In scenari di questo tipo, un approccio consapevolmente adattativo e non più fully plan driven ma change driven e agile diventa un esigenza oltre che il focus gestionale per il successo del progetto.
E’ anche logico immaginare che un progetto possa contenere fasi maggiormente predittive gestibili secondo un approccio tradizionale e fully plan driven e fasi maggiormente incerte e scarsamente definite che necessitano di essere invece gestite in maniera adattativa. Solitamente, le fasi maggiormente predittive sono legate a deliverable maggiormente standardizzati mentre quelle maggiormente adattative sono legate a deliverable meno standardizzati. In questi casi occorre come project manager avere una sufficiente sensibilità e abilità a gestire il progetto secondo approcci ibridi, spesso diversificati da fase a fase.
Il project manager supportato dal gruppo di project management ha il compito di decidere e impostare il ciclo di vita del progetto adeguatamente, in linea con le caratteristiche del progetto, dei suoi obiettivi e dell’ambiente in cui si sviluppa. Approfittiamo di questa affermazione per osservare come team di project management e team di progetto non sono in realtà due termini equivalenti. Infatti, molti componenti del team di progetto non fanno necessariamente parte del team di project management. Quanto le due cose siano all’atto pratico più o meno nettamente distinte dipende da caso a caso.
Compresa la necessità di strutturare il progetto in fasi e di relazionarle opportunamente, nasce una seconda necessità di cui il PM ed i team di project management hanno responsabilità diretta: quella di identificare e definire in maniera più o meno formale o informale i processi di project management per ciascuna fase del progetto. Di detti processi il PM ed il team di project management devono essere profondi conoscitori. Essi dovranno avere ben chiaro perché detti processi si rendono necessari, quali sono gli ingressi e le uscite tipiche che li caratterizzano e li legano all’interno della singola fase piuttosto che in relazioni inter-fase e quali sono gli strumenti e le tecniche di project management proprie di ciascun processo (Figura 3).
Sull’argomento, il PM ha normalmente ben chiaro un’altra fondamentale distinzione: quella tra ciclo di vita del progetto e ciclo di vita del prodotto. … e guai se non lo fosse. Il perché è presto detto. Mentre il ciclo di vita del progetto è definito dall’insieme delle fasi di progetto con le relative interazioni e interconnessioni, il ciclo di vita del prodotto è fatto da un insieme di fasi che descrivono l’intera parabola di vita del prodotto, dalla sua concezione al suo rilascio, dall’evoluzione verso la piena maturità fino al suo declino e ritiro. Questa parabola, occorre osservare, va ben oltre il progetto tanto che buona parte di essa può essere il risultato di uno o più progetti che si concentrano in momenti anche molto distanti temporalmente tra loro. Il cilco di vita del progetto o dei progetti e il ciclo di vita del prodotto sono quindi parabole imparentate, in alcuni punti volutamente interconnesse ma pur sempre distinte.
Uno sguardo ulteriore al concetto di fase
In generale, le tecniche utilizzate per gestire un progetto possono essere riproposte per gestire la singola fase del progetto. Il PM deve ricordare che le singole fasi sono interconnesse tra loro e questo comporta uno scambio di informazioni e di risultati tra fasi. Queste interconnessioni sono spesso critiche per la corretta gestione e integrazione del progetto.
Il concetto di integrazione tuttavia non si limita a questo aspetto, è qualcosa di ben più ampio e profondo come avremo modo di comprendere in successivi articoli. Così come un progetto nella sua globalità necessita di essere identificato, definito in termini di ambito (comprenderemo successivamente questo fondamentale concetto), pianificazione, esecuzione e controllo temporale, in termini di costi e qualità, la stessa cosa vale per la singola fase. I processi di project management che vedremo nel seguito possono essere applicati non semplicemente al progetto nel suo insieme ma alla singola fase del progetto.
In generale non vi è una regola precisa che definisce in maniera rigorosa quale sia la strutturazione in fasi più efficace per un dato progetto. La scomposizione del progetto in fasi resta comunque il primo approccio che consente di vedere il progetto non come un monolita ma piuttosto come un sistema. Si tratta del primo passo per un approccio strutturato, modulare e scalabile che introduce nel progetto gradi di flessibilità ed efficacia gestionale per niente scontati. E’ un aspetto che non riguarda unicamente la panificazione e l’esecuzione poiché si ripercuote in modo potenzialmente assai positivo sul controllo del progetto stesso. E’ infatti naturale vedere i punti di connessione tra una fase e l’altra come punti decisionali di tipo go/no go. Ciò poiché viene naturale vedere i deliverable di fase come pietre miliari, milestone che necessitano di essere verificate e validate prima di procedere oltre.
Non a caso, chi ha lavorato in un team di progetto avrà sentito dire più volte al PM frasi del tipo: “…A questo punto occorre fermarci e fare una verifica di fase, prima di rendere esecutiva la prossima.” oppure “Dobbiamo sottoporre a validazione i deliverable in modo che il cliente li consideri ufficialmente accettati”.
I concetti di verifica e validazione, spesso erroneamente considerati equivalenti, sono infatti generalmente legati al concetto di deliverable di fase. Vedremo in prossimi articoli che i due concetti, sebbene parzialmente sovrapponibili, non sono in realtà equivalenti.
Un progetto correttamente scomposto in fasi è, in ultima analisi, non solo meglio pianificabile, ma anche meglio eseguibile e meglio controllabile. Una tale strutturazione, insieme alle verifiche e validazioni di fase consente correzioni in corso d’opera con maggiore prontezza e maggiore efficacia a beneficio dell’intero progetto e del team stesso. Decidere tempestivamente se passare alla fase successiva, se ripetere la fase, se introdurre modifiche, se chiudere il progetto prematuramente, sono tutte azioni da gestire in maniera tempestiva se si vogliono prevenire rischi ed effetti deleteri su tempi, costi, qualità e in ultima analisi sulla sostenibilità finanziaria del progetto. La fine di fase può essere per il PM ed il team tutto un utile e strategico punto di controllo o se vogliamo di rottura del progetto.
I processi di project management
Occorre sottolineare che la strutturazione del progetto, di cui al momento stiamo solo dando alcune linee guida generali e basilari, necessita sempre di una personalizzazione specifica più o meno spiccata rispetto al progetto stesso e all’ambiente in cui esso si sviluppa. Detto ciò, occorre entrare all’interno delle fasi di progetto per comprenderne meglio la natura.
Le fasi in cui il progetto è scomposto vengono gestite attraverso specifici processi di project management. Un processo di project management presuppone un determinato insieme di attività attraverso le quali elaborare dati, informazioni e più in generale input al fine di trasformarli in output finali o intermedi e necessari ad altri processi. Questa elaborazione avviene attraverso l’applicazione di tecniche e metodi di project management oltre che di consolidate best practice (Figura 3).
Possiamo, da un punto di vista logico-funzionale, immaginare i processi di project management come delle black-box all’interno delle quali trova posto un “motore” fatto di specifici strumenti e tecniche che elaborano specifici ingressi del processo per produrre specifiche uscite.
Recommended by LinkedIn
Figura 3-I processi di project management sono fatti di tecniche, best practice e strumenti di project management che elaborando ingressi definiti fornendo uscite definite
Occorre a questo punto metterci nei panni del PM per comprendere che se egli inizialmente ha dovuto strutturare il progetto scomponendolo in fasi interconnesse, se successivamente a dovuto definire i processi utili al team di project management per gestire ciascuna fase, adesso è chiamato ad entrare in quelle ideali black box che rappresentano i processi e a “maneggiare sapientemente” quelle tecniche e quegli strumenti di projet management che fanno funzionare i processi. Il progetto nel suo complesso viene a configurarsi come un macchina complessa che una volta avviata necessita di andare a regime per trasformare gli input generali, fase dopo fase, processo dopo processo in maniera parzialmente sequenziale, parzialmente parallela, parzialmente iterativa e adattativa per evolvere in maniera definita fino a produrre i deliverable ultimi richiesti al progetto stesso. Per questo, i processi di project management sono interconnessi tra loro nella singola fase e tra fase e fase attraverso input ed output di fase. Non basta, essi devono essere quanto più possibilmente definiti, discreti e tempo-determinati.
Ci possono essere processi percorsi una sola volta come quello di avvio e di chiusura del progetto o della singola fase, altri percorsi ciclicamente. Molti dei processi di monitoraggio e controllo, per esempio, hanno carattere continuativo lungo l’intero ciclo di vita del progetto. Resta il fatto che essi debbano essere sincronizzati tra loro è che il sistema da essi formato ha un valore ben più grande della loro somma.
Uno dei compiti fondamentali del project manager supportato dal team di project management è quello di integrare i processi in maniera tale che essi possano costituire una macchina complessivamente sincronizzata, internamente e verso l’esterno, in grado di evolvere in maniera definita verso gli obiettivi. Questa visione sistemica vale rispetto all’intero progetto come rispetto alla singola fase di progetto e conferma la necessità di un approccio gestionale modulare e scalabile.
Conclusioni
Abbiamo compreso come il PM debba necessariamente avere un approccio strutturato alla gestione dei progetti. Per far ciò deve essere in grado di analizzare il progetto partendo dai suoi obiettivi, da un business case, da assunti realistici, dall’individuazione di vincoli, dall’analisi dell’ambiente di progetto e dei rischi al fine di strutturare il progetto stesso in fasi adeguate a definire e configurarne un cilco di vita anche esso adeguato ed efficace. Fatto ciò dovrà, in maniera più o meno formale, popolare le singole fasi del progetto con gli adeguati processi di project management in modo tale che attraverso la loro gestione e controllo possa gestire e controllare il progetto stesso.
Nel prossimo articolo esploreremo ulteriormente l’argomento, introdurremo il framework dei processi di project managemet promosso dal PMI attraverso l’ultima edizione del PMBOK e non mancheremo di sottolineare come l’approccio per processi sia trasversale alla gestione strutturata dei progetti a prescindere dallo specifico standard di riferimento o dalla specifica metodologia. Diremo anzi di più poiché l’approccio per processi è oggi tipico di qualunque disciplina di management strutturata. Comprendere l’approccio può avere per questo una valenza trasversale persino più ampia rispetto all’ambito al quale ci riferiamo. Come dire che cambiando area di management cambiano i processi ma non cambia la filosofia di approccio ai problemi e agli obiettivi!
Ricondividi l’articolo, lascia un commento o delle osservazioni. Grazie!
Articoli della collana
ACCESSO:
SE LA TUA APP MOBILE NON RISPONDE AL LINK ACCEDI DA BROWSER MOBILE