Approcci di project management

Gli approcci utilizzati nell'ambito del project management consistono in diversi approcci metodologici adottabili per la gestione delle attività di un progetto, che includono gli approcci agili, interattivi, incrementali e basati sulla successione di fasi predefinite. Ciascuno di questi approcci presenta vantaggi e svantaggi che possono consigliarne l'adozione in certi contesti di progetto piuttosto che sconsigliarlo in altri. In progetti reali non è raro rilevare l'adozione di approcci misti che utilizzano parti dell'uno o dell'altro a seconda del contesto o della fase del progetto.

Molti di essi fanno riferimento al PMBOK sviluppato dal Project Management Institute. Tra i più importanti (vedere ad esempio recensione di Max Wideman) possono essere considerati RUP, PRINCE2 ^[1], TenStep, SDLC.

Indipendentemente dall'approccio utilizzato, una particolare attenzione va dedicata alla definizione chiara degli scopi/obiettivi del progetto e delle loro implicazioni; anche la definizione chiara dei ruoli e delle responsabilità di tutti gli attori coinvolti, inclusi i committenti, riveste una importanza decisiva per il successo del progetto.

Nel caso di progetti molto complessi (ad esempio nel caso di un insieme di progetti correlati) e comunque in caso di impatti rilevanti dei progetti sulle organizzazioni coinvolte e sui loro processi, il progetto deve essere considerato all'interno di un approccio più globale, agendo sul piano del Change management che si occupa principalmente di gestire l'impatto umano e organizzativo di una trasformazione all'interno di un contesto aziendale e/o sociale.

Approccio classico

L'approccio classico è di fatto rappresentato dalla ortodossia del PMBOK sviluppato dal Project Management Institute , all'interno della quale sono definiti 44 processi, raggruppati in 5 componenti e 9 aree di conoscenza. I processi del PMBOK, se applicati in modo appropriato ai progetti, consentono di pianificare, eseguire e monitorare tutti gli aspetti che direttamente o indirettamente possono influire sull'esito del progetto.

Le 5 componenti (4 fasi più il controllo) che rappresentano lo sviluppo di un progetto sono:

fase di allestimento e avviamento del progetto;
fase di pianificazione e progettazione;
fase di esecuzione o produzione;
sistema di monitoraggio e controllo;
fase di completamento e rilascio dei risultati.

Questa sequenza di fasi non va interpretata in modo deterministico: non tutti i progetti arrivano alla fine, qualche progetto probabilmente non ha la fase di pianificazione e monitoraggio, mentre diversi progetti iterano ciclicamente attraverso le fasi 2,3 e 4.

Molti contesti industriali utilizzano variazioni a queste fasi. Per esempio nel settore della progettazione civile i progetti tipicamente avanzano attraverso fasi come la pre-pianificazione, la progettazione concettuale, la progettazione schematica, lo sviluppo della progettazione, il disegno degli elementi costruttivi, l'amministrazione del progetto. Nel settore dei progetti informatici l'approccio classico spesso è conosciuto come modello a cascata (waterfall model) per via della linearità con cui viene esplosa la sequenza dei task nel processo di pianificazione. Il modello a cascata funziona meglio su progetti compatti e ben definiti mentre su progetti più complessi dove esistono larghe aree di scopo non ben definite o sconosciute, è meno indicato. Il Cono di incertezza descrive come la pianificazione fatta nella fase iniziale di un progetto sia affetta da un elevato grado di incertezza. Questo diventa particolarmente vero nei progetti software che hanno l'obiettivo di sviluppare nuovi prodotti. Il modello a cascata viene ritenuto poco affidabile nei progetti nei quali i requisiti non sono chiari e ben definiti e nei casi dove sono suscettibili di variazioni significative.

Mentre i nomi delle fasi possono differire da un campo di applicazione all'altro, le fasi effettive seguono tipicamente i passi tipici della prassi di problem solving (definizione del problema, valutazione delle alternative e delle opzioni, scelta del percorso ottimale, realizzazione e verifica).

Approccio Rational Unified Process

Il Rational Unified Process (RUP) è un framework per lo sviluppo iterativo di prodotti software creato da Rational Software Corporation (una divisione di IBM a partire dal 2003). Nelle prassi di sviluppo del software molte organizzazioni hanno adattato il RUP integrandolo con gli approcci di project management, anche se RUP non richiede esplicitamente o raccomanda questa prassi.

Nello schema del RUP, il ciclo di vita di un processo software viene suddiviso in cicli di sviluppo, a loro volta scomposti in fasi secondo lo schema seguente:

fase iniziale (Inception) – identifica lo scopo iniziale del progetto, la probabile architettura del sistema e ottiene il mandato e il finanziamento dal committente;
fase di elaborazione (Elaboration) – disegna e verifica l'architettura del sistema;
fase di costruzione (Construction) – produce il software con scadenze regolari su basi incrementali dando priorità più alta ai rilasci più attesi dai committenti;
fase di transizione (Transition) – testa e installa il sistema nell'ambiente di produzione.

Nel RUP ogni fase ha un certo insieme di obiettivi e si conclude con la realizzazione di un deliverable (prodotto) di qualche genere. Le fasi sono ulteriormente scomposte in iterazioni, che sono associate a periodi temporali e hanno deadline precise.

La versione aperta del RUP è la OpenUP.

Approccio Critical Chain Project Management!Critical Chain

L'approccio del Critical Chain (catena/percorso critico) sviluppato da Eliyahu M. Goldratt si focalizza sulla disponibilità delle risorse oltre che sulle dipendenze logiche tra attività di progetto.

L'approccio è derivato dall'applicazione della teoria dei vincoli al project management. L'obiettivo è quello di aumentare la produttività dei progetti (rappresentabile come la percentuale delle attività completate con la qualità richiesta entro le date di rilascio previste dalla pianificazione impostata) all'interno di una organizzazione. Applicando i primi tre passi della TDV le risorse vengono identificate come il vincolo primario di ogni progetto. Per fronteggiare il vincolo, viene data priorità a tutte le attività che si trovano sul percorso critico. In particolare i progetti vengono pianificati e gestiti in modo tale da assicurare una pronta partenza, con le risorse totalmente disponibili a tutte le attività che si vengono a trovare sul percorso critico.

Per alcuni progetti specifici, la pianificazione di progetto può essere fatta livellando opportunamente le risorse assegnate alle attività; in questo modo la catena di attività (task) più lunga viene identificata con il percorso critico ovvero critical chain (da cui il nome dell'approccio).

In ambienti con diversi progetti interconnessi, il livellamento delle risorse dovrebbe essere realizzato ragionando a livello globale. Tuttavia in molti contesti è facile identificare una risorsa che agisce come un jolly sui diversi progetti, creando forti rischi di destabilizzazione in relazione alla sua disponibilità.

Approccio Event chain

La metodologia Event chain (ECM o metodologia della Catena Critica) costituisce un ulteriore affinamento delle metodologie di project management basate sul Critical Path (CPM o Metodologia del Percorso Critico) e sul Critical Chain.

L'ECM è un approccio di modellazione e di analisi dei reticoli di pianificazione che considera e gestisce l'incertezza di alcune catene di eventi in grado di impattare sul piano del progetto. L'ECM è basata su questi principi fondamentali:

probabilità istantanea di rischio: un task nella maggior parte dei processi della vita reale non è un processo continuo e uniforme ma può essere impattato da eventi che possono accadere in qualche punto della sua vita;
catene di eventi (Event chain): gli eventi possono causare altri eventi, andando a creare catene di eventi che possono condizionare il corso del progetto. L'analisi quantitativa viene usata per determinare l'effetto cumulativo di queste catene di eventi nella pianificazione del progetto;
eventi critici o catene di eventi critiche: i singoli eventi o le single catene di eventi potenzialmente in grado di condizionare il progetto costituiscono gli eventi critici o le catene di eventi critiche. Esse possono essere individuate da un procedimento di analisi;
tracciamento degli eventi sul progetto: se un progetto è stato parzialmente completato e sono disponibili informazioni riguardanti la sua durata, i suoi costi e gli eventi accaduti nel suo svolgimento, è possibile calibrare previsioni circa i futuri potenziali eventi che potrebbero occorrere, aiutando così a valutare le future performance del progetto;
visualizzazione delle catene di eventi: gli eventi e le catene di eventi possono essere visualizzate usando diagrammi di catene di eventi o diagrammi di Gantt.

Approcci di project management basati sui processi (Agile e XPM)

Gli approcci di project management basati sui processi (process-based management) derivano da una generalizzazione del concetto di controllo di progetto.

Questi approcci, con maggiore diffusione nell'area informatica, sono stati indotti dall'uso del Capability Maturity Model Integration (CMMI) e dello standard ISO/IEC15504 (SPICE - Software Process Improvement and Capability Determination) che riscuotono una popolarità più vasta.

Uno di questi approcci più conosciuti è rappresentato dalla Metodologia Agile, basata sui principi di Management dell'interazione umana (human interaction management) che privilegiano la vista dei processi di collaborazione umana tra gli attori coinvolti nella gestione del progetto. Negli approcci Agile software development e Flexible product development il progetto viene visto come una serie di task relativamente snelli, disegnati ed eseguiti in modo fortemente orientato alla domanda, secondo una logica adattativa, piuttosto che come risultato di un processo completamente pianificato fin dall'inizio.

L'Extreme Project Management (indicato anche come XPM) anch'esso ispirato alla Metodologia agile rispetto al project management tradizionale si focalizza maggiormente sull'obiettivo, ne riduce l'ambito agli aspetti essenziali e si dimostra particolarmente versatile di fronte al cambiamento delle condizioni del contesto in cui il progetto si trova.

In alcune rivisitazioni critiche del project management è stato notato che i diversi approcci basati fondamentalmente su logiche PERT non sono particolarmente adatti agli ambienti multi-progetto delle grandi organizzazioni moderne. Oggi molte di queste sono orientate a progetti a scala molto larga, veloci, non ripetitivi, e va considerato anche che molte iniziative manageriali vengono portate avanti sotto forma di progetti.

L'XPM sostiene che, usando per i progetti (o addirittura per i task) modelli troppo complessi, specialmente quando si dilatano su alcune settimane, in molti casi si originano dei costi supplementari dannosi e si abbassano la flessibilità e la reattività del progetto. I fautori dell'XPM si sono ispirati ad approcci leggeri presenti nella Ingegneria del software come l'Extreme Programming e le tecniche Scrum. Se usato in combinazione con il process modeling ed i principi di gestione delle interazioni umane, l'XPM per molti versi può essere considerato come la generalizzazione dell'Extreme Programming all'ambito della gestione di progetto.

Note

^ The PRINCE2 Guide - A to Z, FAQ and 1000+ Exam Questions

Voci correlate

[1] The PRINCE2 Guide - A to Z, FAQ and 1000+ Exam Questions

[1]