Approcci di project management

Gli approcci 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.

L'approccio classico è di fatto rappresentato dalla ortodossia del PMBOK sviluppato dal Project Management Institute, nella quinta edizione della quale sono definiti 47 processi, raggruppati in 5 gruppi di processi e 10 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.

I 5 gruppi di processi di un progetto sono:

1. allestimento e avviamento del progetto (gruppo di processi di avvio);
2. pianificazione e progettazione (gruppo di processi di pianificazione);
3. esecuzione o produzione (gruppo di processi di esecuzione);
4. monitoraggio e controllo;
5. completamento e diffusione dei risultati (gruppo di processi di chiusura).

Questa sequenza non va interpretata in modo deterministico: i singoli gruppi di processi e i singoli processi sono spesso ripetuti prima del completamento del progetto e possono avere interazioni nell'ambito di un gruppo di processi e tra gruppi di processi. La natura di tali interazioni varia da progetto a progetto e può essere eseguita o meno in un particolare ordine.

Il PMBOK evidenzia come i gruppi di processi di un progetto non siano le fasi di ciclo di vita del progetto: laddove un progetto fosse diviso in più fasi, i gruppi di processi sono normalmente ripetuti per ciascuna fase, inoltre a seconda del contesto specifico le fasi di ciclo di vita di un progetto possono essere le più diverse tra loro.

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).

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 alle release più attese 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 scadenze precise.

La versione aperta del RUP è la OpenUP.

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 distribuzione 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à.

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.

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.

Praxis^[2] è un approccio di Project Management gratuito e open source, che evolve grazie al contributo della comunità dei Project Manager. Il Praxis Framework™^[3] contiene e integra quattro diverse tipologie di guide best practice; un knowledge body, un metodo, il censimento delle competenze necessarie e un Capability Model. È il primo framework a integrare in una sola guida progetti, programmi e portfolio.

Praxis Framework è sostenuto da un’attiva community internazionale che ha contribuito con numerose risorse, tra cui un glossario, le traduzioni, i template, i case study e un blog.

Si può liberamente utilizzare Praxis purché si rispettino i termini della Licenza rilasciata dall’associazione Creative Commons. Tutti possono, infatti, adottare ed adattare Praxis ai propri scopi riconoscendone la fonte; si ha solo l’obbligo di rendere il proprio lavoro disponibile ad altri senza far pagare alcun diritto d’autore. Il contributo di ciascuno di noi dovrebbe potere essere incorporato in questo sito web per apportare benefici anche agli altri.

Praxis riunisce in un singolo framework integrato, con una singola struttura e terminologia, non solo un body of knowledge (BoK) ma anche un competence framework ed un capability maturity model. Non c’è più alcun bisogno, quindi, di effettuare una mappatura ed una traduzione delle differenti guide.

Praxis non è prescrittivo nell’imporre come le sue componenti debbano essere applicate nell’ambito della gestione di un progetto, programma o portfolio. Il framework è stato, infatti, creato per fornire moduli che possano essere concretamente personalizzati e assemblati per adattarsi ai diversi contesti.

• Change management
• Critical chain
• Deliverable
• Diagramma di Gantt
• Earned Value Management
• Gestione della conoscenza aziendale
• Governance
• Ingegneria gestionale
• Metodologia agile
• Progetto
• PERT/CPM
• Processo di Project Management TenStep
• Project management
• Qualità (economia)
• Rational Unified Process
• Six Sigma
• Sistemi di project management
• Stato avanzamento lavori
• The Mythical Man-Month
• Time material
• Total cost management
• Work breakdown structure