IL LIBRO

UDA 13 - Scope management - 13.2 Registro delle questioni (issue log)

13.2 Registro delle questioni (issue log)

È indispensabile monitorare e gestire in modo adeguato tutte le richieste di cambiamento rispetto al piano iniziale che si hanno in un progetto.

Il modo classico per seguire tutte le questioni aperte del progetto è quello di istituire un apposito registro, magari elettronico, in cui riportare e monitorare non solo le richieste di cambiamento ma anche tutte le questioni aperte che, in qualche modo, occorre affrontare e risolvere per permettere al progetto di procedere secondo gli obiettivi. Sul registro, oltre alle problematiche, è indispensabile che siano riportate anche le possibili soluzioni proposte per poterle analizzare e poi eventualmente scegliere la migliore. Dover formulare delle soluzioni spinge ad analizzare le questioni con la conseguenza, in alcuni casi, cheun problema a prima vista complesso può essere scomposto in parti più piccole risolvibili singolarmente in modo più semplice. Sul registro dovrebbero essere riportate anche tutte le informazioni necessarie ad affrontare la questione, per esempio dovrebbe essere indicato dove trovare l’archivio di progetto relativo alla questione in esame. Il registro delle questioni deve essere consultato giornalmente come una agenda per poter tenere sotto controllo tutti i problemi aperti. Un registro elettronico dovrebbe gestire anche altre funzionalità utili come degli alert, dei livelli di priorità, uno scadenzario ed altro ancora. Sul registro, oltre alle informazioni di base sopra esposte devono essere riportate anche altre informazioni utili come:

• un numero progressivo identificativo,
• il tipo di questione,
• le date di: registrazione, segnalazione, scadenza e finale di chiusura della questione,
• il segnalatore,
• il responsabile a cui è stata assegnata,
• I soggetti coinvolti nella gestione,
• lo stato attuale,
• la soluzione finale adottata.

Alla fine del progetto il registro permetterà di verificare se sono rimaste delle questioni aperte e poi permetterà di ricostruire molti elementi significativi e fare valutazioni che possono essere utilizzate come esperienze per il futuro. Particolari casi di progetti di scope management possono essere rappresentati i casi di gestione dei rischi di progetto che verranno trattati nella prossima unità didattica del libro. I cambiamenti che riguardano i rischi di progetto sono trattati come scope management solo se richiedono modifiche a tempi, costi e deliverable di progetto. Nella scheda seguente viene riportato un esempio di registrazione relativa all’esempio riportato nel paragrafo precedente riguardante la variazione della normativa relativa ai contenuti della modulistica degli uffici tecnici comunali. Come si può notare analizzando il gantt di progetto la data di pubblicazione della nuova normativa è coincisa con il periodo di pubblicazione del bando di gara e in attesa delle offerte dei fornitori. Questa coincidenza non ha apportato particolari problemi tecnici a parte la richiesta di una integrazione dei contenuti del progetto esecutivo ma ha comportato un ritardo sui tempi di completamento dell’attività che aggiunto ad altri ritardi già accumulati risulterà un ritardo complessivo di un mese alla fine dell’attività A2 progettazione ed al conseguente avvio dell’attività A3 Realizzazione. Le conseguenze sarebbero state sicuramente maggiori se il decreto legislativo fosse stato pubblicato dopo l’inizio dell’attività “A3 Realizzazione” perché avrebbe richiesto modifiche al lavoro di analisi tecnica e sviluppo software già svolto con ritardo nei tempi ed aumento dei costi dovuti al nuovo effort richiesto.

Tabella 28: esempio di registrazione sul registro delle questioni (Issue Log)

• < Prec
• Succ >