Change Management: gestione delle modifiche di progetto

La gestione delle modifiche rispetto al Piano di Project Management costituisce una delle attività prevalenti durante l’attuazione di un progetto.

In particolare deve essere regolata attraverso una specifica procedura descritta nell’articolo sul Monitoraggio e Controllo.

Il fatto che durante lo svolgimento di un progetto si presenti la necessità di introdurre modifiche è assolutamente fisiologico e non necessariamente indica la presenza di anomalie. Anzi in molti casi costituisce una fonte di opportunità a fronte di esigenze di ampliamento dell’ambito emerse da parte del cliente successivamente all’attività di pianificazione.

In altri casi può invece dipendere da un non corretto svolgimento delle fasi preliminari di avvio e pianificazione che produce come conseguenza inevitabile un progressivo “slittamento” o “scope creep” dell’ambito di progetto fino a determinare la distruzione del progetto stesso per eccesso di modifiche e di rifacimenti.

L’ambito di progetto

Per ambito o scope di progetto si intende una chiara e dettagliata definizione dei deliverables e dei confini del progetto che deve includere le informazioni necessarie al team di progetto per realizzare i prodotti del progetto nei tempi e costi previsti.

I processi necessari a definire l’ambito del progetto vengono svolti all’inizio dell’attività di pianificazione e la documentazione relativa viene prodotta e concordata con la collaborazione di tutti gli stakeholders.

Tuttavia, anche nei casi in cui l’ambito è stato definito può manifestarsi un successivo progressivo slittamento.

Questo fenomeno si produce a fronte dell’introduzione di nuove funzionalità rispetto a quanto precedentemente pianificato e senza fornire un’adeguata analisi degli impatti in termini di tempi, budget, risorse.

Le principali motivazioni di questo fenomeno possono essere:

• una analisi dei requisiti povera e svolta frettolosamente;
• una mancanza di coinvolgimento degli utenti finali fin dalle prime fasi di pianificazione in modo da “intercettare” le esigenze e le funzionalità effettivamente necessarie;
• una sottovalutazione della complessità del progetto a fronte di progetti nuovi o non ricorrenti in cui non ci sono molte informazioni su cui basarsi;
• la mancanza di una procedura per il configuration management ed il controllo integrato delle modifiche attraverso moduli di richiesta modifiche e work-flow di autorizzazione;
• gold plating, intendendo con questa espressione la tendenza ad andare oltre quanto inizialmente concordato con il cliente nell’intento di migliorare la customer satisfaction a spese del budget di progetto;
• un approccio metodologico di tipo Agile basato su quantificazioni troppo soggettive;
• project manager e sponsor deboli nell’interazione con gli stakeholders e troppo soggetti al loro condizionamento.

Sebbene lo scope creep non sia l’unico problema che può affliggere un progetto, sicuramente costituisce quello che ne determina il maggior allontanamento dagli obiettivi iniziali di business.

Molte statistiche indicano infatti che a causa di questo fatto:

• il 32% di tutti i progetti ha avuto successo, il che significa che i deliverables sono stati prodotti in tempo, entro il budget, con le funzionalità richieste;
• il 44% vengono contestati perchè in ritardo, oltre il budget, e/o con minori funzionalità rispetto a quanto richiesto;
• il 24% è fallito comprendendo sia i progetti che sono stati cancellati prima del completamento oppure che hanno prodotto deliverables che non sono poi stati utilizzati.

Definizione e gestione dell’ambito

Al fine di anticipare l’insorgere dello scope sreep è opportuno procedere ad una attenta definizione e gestione dell’ambito del progetto sulla base delle seguenti linee guida:

• assicurarsi di raggiungere una visione completa del lavoro da svolgere incontrando tutti gli stakeholders di progetto per condividere sia l’impostazione generale sia la configurazione di dettaglio dei deliverables;
• comprendere le priorità dei vari stakeholders e gli impatti sui tempi, costi e risorse di progetto;
• sviluppare ciascun deliverable in termini di specifiche tecniche e di task da svolgere;
• suddividere la schedulazione introducendo milestones per il controllo e la verifica dei deliverables in modo da “intercettare” tempestivamente possibili disallineamenti;
• presentare agli stakeholders che sono destinari di deliverables sia la WBS che il Gantt di progetto ed ottenere da loro una approvazione formale di quanto presentato raccogliendo le richieste di integrazione e modifica da apportare prima dell’approvazione;
• definire comunque una procedura di gestione delle modifiche da applicarsi durante lo svolgimento del progetto e addestrare i membri del team di progetto ed il personale del cliente al suo corretto utilizzo ed al rispetto delle regole in essa contenute;
• documentare la consegna dei deliverables verbalizzandone l’accettazione.

In tal senso sarebbe opportuno definire una procedura aziendale per la gestione delle modifiche da applicare su tutti i progetti e da concordare o integrare insieme con il cliente finale.

Il Processo di change management

Il processo si articola normalmente in tre fasi:
FASE I – Pianificazione del cambiamento. Viene definita la strategia per quanto riguarda le modifiche e viene comunicata alle persone del team di progetto affinché si preparino all’implementazione delle modifiche approvate.
FASE II – Implementazione delle modifiche. Le modifiche approvate vengono implementate dal team di progetto.
FASE III – Monitoraggio e controllo. Vengono svolte verifiche e controlli per evidenziare eventuali non-conformità ed errori di processo. Inoltre viene effettuato il reporting per informare gli stakeholders di progetto sui risultati ottenuti