5.5.02TS Tecniche di Controllo dell'Ambito

Tutti possono riconoscere ed apprezzare che per grandi modifiche al progetto  deve essere invocato un processo di  richiesta di modifica. Tuttavia, per piccole richieste, potresti incontrare  resistenza per la gestione formale delle modifiche al contenuto. Il cliente può considerarlo una perdita di tempo non necessaria per decisioni così piccole.

Potrebbe essere corretto. Ci sono tre tecniche alternative da utilizzare per le piccole modifiche. Nota che nessuna di queste opzioni implica che non stai gestendo e tracciando le modifiche al contenuto. Queste sono soltanto tecniche aggiuntive che puoi utilizzare. Se non è praticabile nessuna di queste tecniche, il  project manager dovrebbe utilizzare la normale gestione delle modifiche al contenuto su tutte le modifiche.

5.2.P2 Raggruppare le piccole richieste

Non è sempre pratico chiedere allo  Sponsor di approvare ogni  piccola richiesta di modifica al contenuto del progetto. Il team di progetto, di solito, non ha contatti quotidiani con lo Sponsor, ed è difficile ottenere l'attenzione dello  Sponsor per queste piccole richieste. E' meglio raccogliere le piccole richiese in un unico pacchetto. Questo significa tenere traccia delle piccole richieste  di modifica al contenuto, del loro valore di business e del loro impatto sul progetto. Poi, quando diventano un certo numero, le sottoponi insieme all’approvazione dello Sponsor.  All'incontro  insieme al cliente  discutete tutte le proposte e raccogliete l'opinione dello Sponsor sulla loro fattibilità. Anche se queste sono piccole modifiche, esse devono passare ancora per  la gestione delle modifiche al contenuto. Altrimenti sei suscettibile di esporre il contenuto. Il beneficio di avere l'approvazione delle modifiche  al contenuto da parte dello Sponsor è che lo Sponsor approvando il lavoro aggiuntivo, può approvare anche l'aumento di budget ed il tempo per realizzarle.

5.2.P3 Discrezionalità  del Project Manager

Da un punto di vista pratico, può avere  senso per project manager e referente del cliente approvare a loro discrezione piccole richieste di modifica del contenuto entro certe soglie di ore di impegno. Questa delega non dovrebbe essere assunta in autonomia, ma dovrebbe essere data esplicitamente dallo sponsor. Ciò fa presupporre  che il progetto sia in piano  e che le modifiche non facciano andare il progetto oltre il costo, l'impegno e la durata. Al contrario, se il progetto corre qualche rischio di non rispettare costo, impegno e durata concordata, allora il  project manager non deve approvare nessuna modifica al contenuto di sua iniziativa - neanche per un'ora! Se il progetto è a rischio, tutte le richieste di modifica al contenuto dovrebbero arrivare allo Sponsor per l'approvazione, sia individualmente che in gruppo. Se lo Sponsor approva le modifiche, il progetto dovrà ricevere anche  il corrispondente contributo al budget ed alla schedulazione.

5.2.P4 Budget di Riserva  per le Modifiche al Contenuto

In certe organizzazioni è comune accantonare delle risorse finanziarie per situazioni contingenti come la gestione di piccole modifiche impreviste. Di solito, non è richiesta nessuna giustificazione. La tua organizzazione può riconoscere che un certo livello di modifiche al contenuto è inevitabile  e che puoi essere autorizzato a destinare una percentuale del budget totale a questo tipo di modifiche. Per esempio, puoi avere un 5% di budget per modifiche impreviste al contenuto. Se il tuo budget totale era  di  Euro 500.000, il tuo budget per modifiche impreviste al contenuto potrebbe essere  di Euro 25.000. Comunque, in questi casi, l'implicazione è che il budget per imprevisti è tutto ciò che si può destinare alle richieste di  piccole modifiche al contenuto. Il cliente deve gestire il budget  per garantirsi che tutte le piccole modifiche possano essere realizzate. Se il cliente impiega il suo budget prima delle piccole modifiche al contenuto, successivamente non disporrà  di fondi per eventuali piccole modifiche. Ciò mette il cliente in una posizione di razionare le richieste di modifiche per assicurarsi che vengano approvate solo quelle più importanti. Questo budget viene utilizzato per richieste di modifiche entro un certo importo o impegno in ore. Le richieste più grandi possono sempre essere soddisfatte, attraverso la normale gestione delle modifiche ed essere valutate dallo Sponsor.

Uno dei passi nel processo di stima è aggiungere delle ore di contingenza (una riserva di ore)  per riflettere il livello di incertezza della stima stessa. (Per esempio, se le ore stimate erano 5.000, potresti aggiungere 500 ore per contingenza, per indicare un fattore di confidenza del 90%). Una volta approvata  il budget per contingenza, altri eserciteranno pressione sul  project manager per utilizzare quella contingenza per esigenze diverse. Il cliente può dire, "Perché dobbiamo invocare la Gestione delle Modifiche al Contenuto per questo miglioramento da 100 ore, se hai già 500 ore di  riserva nell'ambito della tua stima?"

Il  project manager deve resistere alla tentazione ed alle pressioni! Lo scopo della stima di contingenza è coprire l'incertezza nella stima. Ci saranno un sacco di opportunità per assorbire la contingenza quando le attività diventeranno più lunghe di quanto atteso.  Non utilizzare le ore di contingenza per assumere lavoro extra. Se le stime del progetto erano accurate, le ore di contingenza andranno restituite al cliente, alla fine del progetto (o la contingenza verrà considerata profitto se si tratta di un cliente esterno).

Pensi che per quanto tu possa gestire  diligentemente le richieste di modifiche al contenuto, il cliente possa essere libero di apportare modifiche nel corso del  progetto in qualsiasi modo?  Le  modifiche  verso fine progetto tendono a richiedere più tempo e impegno per essere realizzate. Però, tu potresti ritenere che i cliente lo possa fare, in quanto lo Sponsor vuole approvare aumenti di budget  e di tempo per effettuare tali modifiche.

Ciò, normalmente, è vero, ma soltanto fino ad un certo punto. In un progetto arriva un momento  in cui, semplicemente, non paga realizzare ulteriori modifiche o accettare altri requisiti. Quello è il momento di ottenere il permesso di congelare una richiesta di modifica. Non solo le nuove modifiche sono costose da implementare, esse costituiscono una distrazione per il team di progetto

In funzione della natura del progetto, le richieste congelate potrebbero essere implementate  dopo che il cliente abbia approvato il test ed il team è pronto per passare all’implementazione. A questo punto, il team è concentrato sull’implementazione della soluzione. il team potrebbe lavorare in orario straordinario. Il Project Manager potrebbe comportarsi da micromanager per garantire che tutti i dettagli vengano portati avanti in tempo. A questo punto del progetto, le richieste di modifiche al contenuto non solo sarebbero costose, ma sarebbero anche dannose. Il team potrebbe perdere la concentrazione e distrarsi mentalmente. Potresti accorgerti che con il passaggio in produzione successivo il team è distratto e commette più errori, perché è la seconda volta che esegue quel passaggio in produzione. 

Il miglior approccio è congelare queste modifiche su un’apposita lista e trattarle come  richieste di miglioramento dopo che la soluzione è stata implementata e diventata stabile. (Ciò riguarda le richieste di modifiche e non gli errori. Gli utenti possono, nel loro test, scoprire errori da fissare prima  dell'implementazione).

Se raggiungi un accordo sulla data di congelamento delle modifiche, il team può concentrarsi sulla consegna della soluzione attuale. Naturalmente, come ogni processo, se c'è una richiesta di modifica che  deve essere implementata, puoi ancora concedere allo Sponsor di chiederla. Comunque, concordando la data di congelamento delle modifiche eliminerà il bisogno di modifiche aggiuntive su più progetti.

Un problema tipico sui progetti è che il team non capisce i ruoli dello Sponsor, del Cliente e degli Utenti finali nell’area della gestione delle modifiche. In generale, Lo Sponsor di progetto è la persona che finanzia il progetto. Se il Cliente  è rappresentato da una persona, quella persona dovrebbe essere lo Sponsor di Progetto. Egli è probabilmente in una posizione molto alta nell'organizzazione e non facile da incontrare ogni giorno. In molti casi, lo sponsor  incarica un'altra persona della sua organizzazione a prendere molte decisioni quotidiane.

Le persone con le quali il team di progetto tende a lavorare, molto spesso sono utenti finali. Gli utenti finali sono le persone che utilizzeranno la soluzione che il progetto sta sviluppando. Gli Utenti finali sono coloro che generalmente fanno richieste di modifiche alle  deliverable.  Non importa quanto sia importante una modifica per un utente finale - l'utente finale non può prendere decisioni su modifiche al contenuto e non può dare al team l'approvazione per una modifica. 

Nella corretta gestione delle modifiche al contenuto è lo Sponsor (o un suo incaricato) che deve dare l'approvazione. Gli utenti finali possono richiedere modifiche al contenuto, ma non possono approvarle.  L'Utente finale non può stanziare fondi  per le modifiche e non può sapere se l'impatto sul progetto è accettabile. Se la modifica è importante abbastanza per lo Sponsor, egli l'approverà, insieme alle modifiche al  budget ed alla durata del progetto. Se la modifica non è abbastanza importante, allora no sarà approvata. Comunque, sarà lo Sponsor a prendere la decisione, non il  project manager, il referente del cliente, il team di progetto o gli utenti finali.

Il  project manager ed il  team a volte pensano che essi prestano attenzione al cliente, accettando modifiche al contenuto anche quando  stanno ancora cercando di rilasciare il progetto secondo gli impegni originali. Ma, se il progetto viene consegnato in ritardo o fuori dal budget, di solito, non è sufficiente  tirar fuori il lavoro aggiuntivo  eseguito per prestare attenzione al cliente. Lo Sponsor di progetto ed il tuo manager non vogliono sentirne parlare. In molti casi,  il progetto non viene considerato di successo, perchè non consegna come promesso, secondo il budget e date stabilite all’inizio.

Lo Sponsor è il principale rappresentante del cliente. Permettendo allo Sponsor (o al suo incaricato) di decidere di cambiare il contenuto si dimostra maggiore attenzione al cliente. Se il team di progetto o il project manager permettono modifiche al contenuto di loro iniziativa, non mostrano attenzione al cliente, specialmente se il progetto è in ritardo o fuori budget.

Lo Sponsor del progetto non può prendere una decisione informata su una richiesta di modifica al contenuto senza comprendere il valore della modifica e l'impatto sul progetto. Tipicamente, il project manager fornisce informazioni sull'impatto in termini di impegno, costo e durata. Una comune mancanza nel determinare l'impatto, tuttavia, è che la stima non tiene conto del costo dei ritardati benefici del progetto.

In altre parole, il tuo progetto risulterà di solito  un vantaggio per l'azienda. Il beneficio parte immediatamente dopo (o subito dopo) l'implementazione della soluzione, Se una richiesta di modifica al contenuto comporta il ritardo del progetto, il costo della modifica dovrebbe includere non solo il costo reale della modifica stessa, ma anche il ritorno del beneficio.

Osserva il  seguente esempio.

Supponiamo  che un progetto  costi  Euro 100.000. Il beneficio di business è Euro 5.000 per mese in maggior fatturato (o diminuzione di costi). Nel corso del progetto il cliente chiede una modifica che costerà Euro 5.000 e allungherà i progetto di un altro mese. La modifica ha un ritorno di Euro 1.000 per mese.  Puoi andare dallo Sponsor con una richiesta di modifica che ha un costo di  Euro 5.000 ed un ritorno in cinque mesi di Euro 1.000 per mese. Però, ciò che manca è il costo di un mese di ritardo dell’implementazione. In questo caso, implementare la soluzione un mese dopo la data pianificata comporta per l'azienda un costo di Euro 5.000  in mancati ricavi , portando il costo della richiesta di modifica a Euro 10.000. Lo Sponsor può approvare o meno la modifica. Però, può valutare e comprendere la perdita causata dal ritardo del progetto dovuta all'impatto delle modifiche al contenuto.  

Una delle cose sistematiche circa l'applicazione della disciplina di far approvare le richieste di modifiche allo Sponsor  è che, a meno che  la modifica non sia molto importanti, lo Sponsor di solito dirà  'NO'. Di solito, lo Sponsor occupa una posizione alta nell'organizzazione. Non vuole sentir parlare di  richieste per piccole modifiche. Vuole che il progetto rispetti i costi originali, l'impegno e la durata. Anche se  per il  project manager dire  'NO' può essere duro, lo Sponsor di solito non ha alcun problema a farlo.

Molti processi di gestione delle modifiche al contenuto funzionano bene a livello di  project manager, ma vengono compromessi dai membri del team. Se il  project manager è rigido nel rispettare  le regole delle modifiche al contenuto, il cliente può rivolgersi direttamente ai membri del team per alcune modifiche. Per esempio, quando viene consegnato per la verifica un report concordato, il cliente può richiederne un secondo per ottenere maggiore chiarezza. Il membro del team accetta di fare il lavoro (mostrando attenzione al cliente).  Il risultato è che l'attività prende troppo tempo, o risorse, che potrebbero occuparsi di altro lavoro  di priorità più alta, invece di essere assorbite da un'area fuori dal contenuto del progetto.

La  morale  è che tutti devono  ritenersi responsabili del processo di gestione delle modifiche. I membri del team devono  comprendere il processo, e perchè è così importante. La comunità del cliente deve capire il processo e la sua importanza. Non bisogna considerare queste procedure solo di interesse per  project manager e Sponsor. Accertati che le procedure sono note all'intero team di progetto.

Quando i clienti chiedono le modifiche direttamente al team di progetto. Riferiscilo al referente del cliente oppure allo   Sponsor. Quando membri del team accettano lavoro fuori dal contenuto del progetto, contestalo immediatamente. La prima volta  può essere considerato un problema di formazione, la volta successiva potrebbe essere un problema di prestazione.

A volte, in progetti molto grandi, lo Sponsor non se la sente di  prendere decisioni  da solo sulle Richieste di Modifiche al Contenuto. Questo si può verificare, specialmente, quando la modifica impatterà altri reparti. Può darsi anche  che più reparti stiano partecipando, o contribuendo, al finanziamento del  progetto, e desiderino  dire la loro sulle richieste di modifiche. In questi casi, può essere necessario un gruppo che gestisca l’approvazione delle modifiche al contenuto.

Un nome comune di questo gruppo è "Comitato di Controllo delle Modifiche" (Change Control Board). Se esiste un Comitato, può essere più scomodo lavorarci insieme. Però, in generale, il processo di gestione delle modifiche non cambia molto. Per esempio, c'è ancora un documento che avvia la richiesta di modifica. Il  team ha bisogno di determinare l'impatto e il costo per il progetto. Il Comitato deve considerare l'impatto, il valore per il progetto, i tempi, etc., e infine determinare se approvare o respingere la richiesta.

Le procedure di modifica del contenuto devono essere in qualche modo più sofisticate per rendere conto al Comitato. Per esempio, bisogna chiarire chi fa parte del Comitato, ogni quanto si riunisce, come viene comunicato loro una emergenza, come arrivare alle decisioni (consenso, maggioranza, unanimità, etc.), come si paga il lavoro straordinario, etc.

E' possibile che lo  Sponsor non approvi delle Richieste di Modifiche al Contenuto durante il progetto, perché si possono realizzare in  un momento successivo. Queste  richieste dovranno essere raccolte in una lista di lavoro sospeso. Alla fine del progetto, e quando la soluzione è passata in produzione, ci può essere l'opportunità per i miglioramenti o una Fase II del progetto. Però, anche ad una data successiva, queste modifiche saranno implementate soltanto se verranno approvate e se verranno stanziati i fondi necessari.

5.5.01TS Processo di Controllo dell'Ambito

Gestione dei tempi di progetto