Cambiamento

Tutti i progetti (ma proprio tutti!) avranno questioni da gestire, ..issues, i quali richiederanno richieste di modifica, per esempio nuovi requisiti. Questa Tematica tratta la seguente domanda: “Qual’è l’impatto della questione o issue di progetto?”

Pertanto, questa tematica descrive:

(1) come si andrà a valutare queste questioni/issues e richieste di cambiamento, (2) Come rispondere agli stessi e (3) Come gestirli. Tutte queste questioni e cambiamenti potrebbero avere un diretto impatto diretto sul piano di progetto originale.

Qualsiasi cambiamento proposto deve essere correttamente gestito. Tutti i progetti necessitano di una buona gestione delle issue (questioni) e cambiamenti o modifiche. Questo approccio di gestione partirà dell’identificazione dei cambiamenti, la loro valutazione o assessment ed, infine, il controllo.

L’issue e change control (il controllo delle questioni/issues e dei cambiamenti o modifiche) avviene durante l’intera vita del progetto. Ricordati, l’obiettivo NON è di prevenire modifiche al progetto ma di gestire questi cambiamenti, concordandoli prima del loro avvenimento.

E’ da notare che la tematica del Cambiamento copre anche il Configuration Management. Ciascun progetto richiede un sistema di Configurazione, che fa tracking dei prodotti, le loro versioni, le issue e modifiche al progetto. Il documento delChange Control Approach descrive come avverrà questa gestione e risponde a domande del tipo:

• Come verranno pianificati, identificati, controllati e verificati i prodotti di progetto?
• Come si gestiranno le issues e le modifiche?
• Quali strumenti utilizzeremo (e.g., SharePoint, Niku Clarity, Shared Drive)?
• Quali dati dobbiamo gestire per ciascun prodotto (e.g., Product Description, Configuration Item Records, etc.)?

La Fase di Inizio: Il documento del Change Control Approach va adattato al particolare contesto. Questo documento descrive il processo e l’approccio che si andrà ad utilizzare per gestire i cambiamenti e la configurazione durante il progetto stesso. In questo momento viene anche creato il Registro delle Questioni, meglio noto come l’Issue Register dove verranno aggiunte man mano tutte le questioni da prendere in carico.

I Configuration Item Record (o Schede di Configurazione) possono essere create per ciascuno dei prodotti nel Product Breakdown Structure oppure appena le Descrizioni di Prodotto sono state create.

Limiti di Fase: Gli Product Status Accounts sono report molto semplici usati per riportare lo status dei prodotti alla fine di ciascuna fase. Per intenderci: I Product Status Accounts possono consistere anche nel risultato di una query in un database oppure, nei casi meno complessi, al risultato di un filtro su un foglio Excel…

Controllo di una Fase: L’Issue Report viene utilizzato per “allertare” il Project Board nel caso incui una questione di progetto porti ad una previsione di fuori tolleranza. In tal caso, il Comitato di Progetto darà indicazioni al Project Manager su come procedere. L’Issue Register va continuamente aggiornato ogni volta che si presentino nuove issues o questioni ed ogni volta bisogna aggiornare informazioni circa le issues esistenti e già registrate precedentemente.

Configuration Item Records: Un archivio sull’avanzamento di status dei prodotti del progetto: per esempio. Product Description completato, da sviluppare in fase X, in via di sviluppo, quality tested, approvato…

Chiusura di un Progetto: Infine, i Product Status Accounts servono per riportare efficacemente lo status di tutti i prodotti alla fine del progetto. Questi report vengono consegnati alle persone che avranno il compito di gestire il prodotto dopo la chiusura del progetto stesso.

I Configuration Item Records vengono, infine, aggiornati per l’ultima volta e consegnati anch’essi alle persone che dovranno “mantenere” il prodotto dopo la chiusura del progetto.