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, 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, 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:

allestimento e avviamento del progetto (gruppo di processi di avvio);

pianificazione e progettazione (gruppo di processi di pianificazione);

esecuzione o produzione (gruppo di processi di esecuzione);

monitoraggio e controllo;

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

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