Aspetti generali
Il controllo dei cambiamenti è il mezzo attraverso cui tutte le richieste di cambiamento alla baseline dell'ambito sono acquisite, valutate e quindi approvate o rifiutate. Gli obiettivi propri di questa funzione sono:
- acquisire dagli stakeholder le richieste volte alla realizzazione di cambiamenti dell'ambito;
- assicurare che siano approvate solo le richieste fattibili e realizzabili;
- integrare i cambiamenti all'interno dell'ambito già esistente.
Quando l'ambito è chiaramente definito all'inizio del ciclo di vita, per una buona riuscita è essenziale che i cambiamenti alle baseline approvata siano tenuti sotto controllo. Deve essere stabilita e mantenuta una procedura rigorosa di controllo dei cambiamenti su tutti i progetti, programmi e portfolio. Questa deve consentire agli stakeholder di sottoporre le loro proposte di cambiamento dell'ambito. Qui sotto viene mostrata una procedura tipica:
Il passo di pianificazione definirà in che modo il team di gestione lavorerà con gli stakeholder per gestire una materia che può essere una fonte significativa di conflitti. Tale attività può includere la fissazione di limiti sulla quantità di cambiamenti ammissibili e deve certamente integrarsi strettamente con la funzione di gestione degli stakeholder. Può anche definire a quali stakeholder è consentito di presentare richieste, magari fungendo da punto di contatto e filtro iniziale per il proprio gruppo di stakeholder.
Il passo di inizio assicurerà che siano mobilitate le risorse dotate delle competenze necessarie a trattare la complessità dell'ambito. Questo a volte richiede la designazione di un'entità chiamata autorità per il controllo dei cambiamenti al fine di assicurare non solo che le richieste di cambiamento siano valutate in maniera appropriata ma anche che la procedura si mostri aperta e giusta.
La pianificazione e l’inizio saranno spesso eseguiti come parte della complessiva gestione dell’ambito e saranno di solito combinati con i passi corrispondenti della procedura di gestione della configurazione.
Il primo passo specifico della procedura di controllo dei cambiamenti è il momento in cui uno stakeholder fa una richiesta di cambiamento. Lo stakeholder deve fornire le informazioni pertinenti riguardo alla natura del cambiamento. La richiesta è inserita in un registro dei cambiamenti che registra tutte le richieste e il loro stato (per esempio pendente, approvata, rifiutata o differita).
La richiesta di cambiamento è rivista per stabilire il suo impatto di alto livello sui prodotti, sui risultati e sui benefici. Se necessario, si possono chiedere ulteriori chiarimenti prima di decidere se vale la pena di eseguire una valutazione dettagliata. Il cambiamento proposto può essere rifiutato senza alcuna ulteriore valutazione, nel qual caso saranno registrate le ragioni del rifiuto e inviato il feedback agli stakeholder.
Se invece si giustifica l’esecuzione di una valutazione approfondita, vengono individuate e valutate tutte le opzioni relative al cambiamento. Una proposta di cambiamento per essere accettata dovrebbe essere vantaggiosa, praticabile ed attuabile economicamente.
Vantaggiosa significa che essa ha un impatto positivo sul business case, oppure presenta qualche altro vantaggio, come la riduzione del rischio. Praticabile significa che funzionerà nel contesto della specifica e rispetto a qualsiasi altro cambiamento. Attuabile economicamente significa che c’è disponibilità di fondi per pagare il cambiamento, magari tramite un budget per i cambiamenti o una riserva di gestione.
Viene inoltre valutato l’impatto dettagliato sui piani di consegna e predisposta una raccomandazione di approvazione, rifiuto, differimento o richiesta di maggiori informazioni. Sono fissate le soglie per stabilire se la decisione deve essere presa dal project, programme o portfolio manager, dallo sponsor o da altri membri del team di gestione.
La decisione viene poi comunicata al team di gestione e agli stakeholder, incluso se del caso il feedback. La registrazione delle lezioni apprese dall’attività di valutazione può accelerare le attività di valutazione future che hanno contenuti tecnici simili.
Se il cambiamento è approvato, vengono aggiornati i piani di consegna pertinenti e vengono apportati i cambiamenti ai prodotti esistenti o alle specifiche dei prodotti futuri.
C’è sempre la possibilità che dei cambiamenti urgenti siano imposti o fatti passare senza il processo dovuto. Questo tipo di cambiamenti dovrebbe essere sottoposto a posteriori alla procedura di controllo dei cambiamenti.
Qualsiasi cambiamento approvato deve essere riportato nel sistema di gestione della configurazione. In alcune circostanze può essere appropriato mettere un punto di blocco ai cambiamenti, a partire dal quale non saranno presi in considerazione ulteriori cambiamenti dell’ambito. Nel caso in cui questo blocco sia stato concordato con lo sponsor, lo stesso dovrebbe essere incluso come un punto di decisione chiave nel piano di gestione dell’ambito.
Progetti, programmi e portfolio
La maggior parte delle richieste di cambiamento si riferisce ai prodotti che compongono un prodotto complessivo di progetto. I cambiamenti approvati di solito hanno implicazioni di spesa ed in linea ideale nel budget di progetto saranno accantonati i fondi necessari a coprire tali costi. Alcuni progetti saranno soggetti a condizioni contrattuali che hanno un impatto significativo sul controllo dei cambiamenti. I metodi di pagamento scritti nel contratto potrebbero non consentire alcun cambiamento alla specifica concordata mentre altri metodi includeranno una programmazione dei pagamenti per i cambiamenti autorizzati già predeterminata.
Proprio come qualunque altro budget, un budget per i cambiamenti avrà limiti e tolleranze. Se si prevede che il lavoro superi queste tolleranze il project manager dovrà scalare la questione allo sponsor che potrebbe dover trovare finanziamenti aggiuntivi.
I progetti agile adottano un approccio molto differente e fanno del cambiamento una parte integrante dello sviluppo. Ciascuna iterazione inizia con una riunione di pianificazione che chiarisce e mette in ordine di priorità i prodotti presi in esame nell’iterazione. Alcune di queste funzionalità possono essere cambiamenti alle funzionalità esistenti ma vengono prese in considerazione contemporaneamente a tutte le altre.
Il controllo dei cambiamenti a livello di programma riguarda i cambiamenti relativi ai benefici, o perché una richiesta di cambiamento colpisce direttamente un profilo di beneficio, o a causa dell’effetto indiretto di un cambiamento di progetto sui benefici.
La procedura valuterà inizialmente l’impatto di una richiesta di cambiamento sui benefici e poi valuterà l’impatto sui progetti che fanno parte del programma. Un cambiamento significativo ad un progetto può richiedere una redistribuzione delle risorse o dei fondi e può avere un effetto a catena sugli altri progetti.
Alcune richieste di cambiamento nell’ambito di un singolo progetto possono avere effetti a catena su altri progetti. La complessità di queste interdipendenze è qualcosa di cui il team di gestione del programma deve avere consapevolezza.
Un portfolio strutturato dipende dalla strategia aziendale riguardo ai suoi obiettivi. Questa può cambiare per riflettere un cambiamento dell’ambiente commerciale e naturalmente il portfolio deve rispondere di conseguenza. La procedura di controllo dei cambiamenti in realtà non si applica alle ‘richieste di cambiamento’ che scaturiscono dalla strategia aziendale relativa alle decisioni sul se accettare o rifiutare le richieste di cambiamento stesse. Ciononostante, questi cambiamenti devono comunque essere valutati per le loro implicazioni sugli obiettivi dei progetti e programmi che fanno parte del portfolio.
Invece che nell’approvazione o nel rifiuto di una richiesta di cambiamento, la ‘versione portfolio’ della procedura può consistere nella riprioritizzazione, o anche nella cancellazione, di qualche progetto o programma e nella identificazione di nuovi.
Grazie a E-quality Italia e a Project Management Europa per la traduzione
