La crisi degli ultimi anni ha provocato una crescente attenzione verso le possibilitá finanziamento europeo che a sua volta ha fatto aumentare il numero di percorsi formativi orientati allo studio degli “strumenti” dell’europrogettazione.

All’interno di questi percorsi formativi rientra lo studio della metodologia di progettazione partecipata e delle fasi di vita del progetto, il Project Cycle Management (PCM), tradizionalmente definito il framework di project management dell’Unione Europea.

Il progetto europeo deve rispondere e sottostare a regole precise e deve essere in primo luogo capace di rispondere con efficacia alle “chiamate”, appunto “Calls”, che la Commissione Europea effettua nei diversi settori d’interesse comunitario, dall’Agricoltura alle Imprese, dalla Cultura all’Occupazione e cosi via.

In particolare il PCM pone una forte enfasi sulle fase di presentazione delle domande e di rendicontazione, ma non approfondisce particolarmente gli aspetti di attuazione del progetto approvato. Una volta approvato il progetto, chi pensa all’esecuzione? Sembra che agli autori del PCM non importi piú di tanto…

Su questo tema, il legislatore europeo si muove in un’ottica di beneficio a monte, concentrandosi piú sull’individuazione dei bisogni che sulla fase di esecuzione del progetto, fase in cui entra in gioco in modo fondamentale il project management, inteso come insieme di metodi e tecniche per ottimizzare l’ottenimento degli obiettivi stabiliti.

Dato questo scenario, sottolineare e valorizzare la capacità di delivery dei progetti finanziati, congiuntamente all’adozione di metodologie e strumenti appositi, potrebbe portare ad un’utilizzo piú controllato ed accorto dei fondi elargiti a beneficio di tutti i cittadini dell’Unione Europea.

Mi piacerebbe sapere cosa ne pensa chi, come me, é entrato in contatto con questa attivitá…

Nel precedente articolo ho presentato la problematica. In questo articolo vedremo come:

1. Definire una nuova LookUp Table

2. Definire alcuni campi enterprise per gestire i Change Request

Una LookUp Table ha lo scopo di definire una tabella di codifica da poter riutilizzare più volte nei progetti enterprise gestiti nella nostra organizzazione. Questo tipo di gestione permette di codificare una volta per tutte ed in modo controllato tutti I valori che può assumere un campo di un progetto.

Per definire una LookUp Table occorre richiamare la pagina Server Settings (occorre essere utente amministratore) e cliccare sul link Enterprise Custom Fields and LookUp Tables, come nella figura seguente

Subito dopo verrà visualizzata la finestra come in figura

Possiamo vedere elencate le Lookup Tables presenti al momento sul server.

Per creare una nuova LookUp Table occorre cliccare sul pulsante New Lookup Table e verrà visualizzata la seguente videata:

Nella finestra precedente inseriamo il nome della LookUp Table (Change Request Status), il tipo di dato (Testo), il tipo di Codice Maschera (tutti caratteri)  ed infine l’elenco dei valori codificati. Questa tabella indicherà lo stato attuale della richiesta di modifica da parte del cliente (In sospeso, approvato, negato,..).

Nella figura seguente vediamo un elenco di valori della Lookup Table.

Dopo avere definito la tabella di lookup (Change Request Status), creiamo alcuni campi enterprise che ci permetteranno una gestione più precisa delle richieste di modifica.

Nella tabella seguente vediamo quelli che ho creato:

Abbiamo definito in tutto sette campi. Non sono pochi effettivamente, ma permetteranno, come vedremo successivamente, una gestione puntuale e completa dei Change Request.

Nel prossimo articolo vedremo come modificare un template enterprise per inglobare i sette campi precedentemente definiti con una opportuna Vista Tabella per una facile gestione.

Alla prossima

Nel confrontarmi con i Project Managers dei miei clienti, non sempre ho riscontrato processi ben definiti di Change Management ed il tenere traccia in modo strutturato dei changes ricevuti e gestiti.

In sintesi ho riscontrato la seguente gestione:

1. Fogli di lavoro di Excel, direi il 70%

2. Documenti di Word il 10-15%

3. Applicazioni specifiche di Project Management meno del 5-10%

4. Strumenti come Sharepoint e simili intorno al 10%

Probabilmente voi che mi leggete potete avere avuto  un riscontro diverso, ma penso che le cifre non si discostino molto dalle mie.

Mancanza di gestione centralizzata e visione globale

Fatta salva la gestione centralizzata disponibile con applicazioni specifiche di Enterprise Project management o software sviluppato ad-hoc,, non ho mai visto in giro una gestione centralizzata in modo strutturato ed automatizzato. Solo alcuni PMO che ho conosciuto si fanno carico di aggiornare in fogli di Excel i Change Request trattati nei vari progetti aziendali. Da qui ad arrivare a fare statistiche su quanto e come incidano le Richieste di Modifica ce ne corre e di solito si rinuncia.

Può servire per una migliore e più proficua gestione avere una visione chiara ed aggiornata dell’andamento dei Change Request su tutti i progetti gestiti in azienda?

Secondo me si, sicuramente, e in questo articolo voglio dare un suggerimento su come farlo in modo strutturato e “pensato” sulla piattaforma Microsoft Project Server 2010 (ma può essere estesa alle versioni precedenti di Project e ad altri software concorrenti, ovviamente con le dovute differenze).

Aree di intervento per una visione centralizzata dei Change Request

In questo articolo vedremo alcune parti di Project Server e Project Professional 2010 in cui intervenire, e precisamente:

1. Definizione di una LookUp Table (tabella di codifica sul server)
2. Definizione di alcuni campi enterprise
3. Creazione di un modello di estrazione dati nel modulo di Business Intelligence (per analisi con Tabelle Pivot di Excel)
4. Aggiunta dei Campi Enterprise nei Modelli Globali (Templates) dei progetti
5. Definizione del Processo di Gestione dei Change Request che i Project Managers devono seguire nella pianificazione ed esecuzione dei loro progetti

Dall’elenco precedente si evince che non è come bere un bicchiere d’acqua (soprattutto l’ultimo punto), ma un componente del PMO che ha la responsabilità della gestione della piattaforma Project Server 2010 dovrebbe avere ricevuto la formazione necessaria per implementare le attività che ho delineato (il punto 3 richiede un’expertise maggiore).

In ogni caso cercherò di essere il più chiaro possibile anche con l’aiuto di videate catturate dallo schermo del computer.

Nella seconda parte di questo articolo vedremo come implementare i primi due punti dell’elenco, a presto.

Il caso pratico

A causa della particolare struttura dell’organizzazione del progetto, la gestione dei rischi e delle issue è stata svolta con l’ausilio di un Risk&Issue database appositamente sviluppato e personalizzato da Projectize Srl. Il database è stato sviluppato in MS Office Access, sfruttando le potenzialità del software per creare non soltanto le tabelle e le query, ma anche l’interfaccia grafica, le maschere ed i report per l’inserimento e la visualizzazione dei dati (Fig. 2).

Figura 2 - Una scheda esemplificativa estratta dal Risk&Issue database (fonte: documentazione del progetto)

Un risk (letteralmente traducibile come “rischio”) è un evento incerto che se si verifica, può avere un impatto positivo o negativo sul progetto: tenere traccia dei rischi di progetto e delle azioni necessarie a mitigarli è fondamentale per ridurre al minimo le emergenze e poter quindi lavorare.

Un esempio di un risk estratto dal database è:

“Danneggiamento dei gruppi macchina durante il trasbordo”.

Segnalatore: Mr. xxx.

Responsabile: Mr. xxx.

Azioni necessarie: Assicurarsi che il fornitore abbia la dovuta copertura assicurativa.

Una issue (letteralmente traducibile come “istanza”) è un problema oppure una richiesta di informazioni o una variazione in corso d’opera. In breve qualsiasi informazione che il progetto deve tenere presente per la sua corretta gestione.

Esempio di una issue estratta dal database è:

“Chiedere a Azienda xxx disegni Autocad macchine da inserire in Layout stabilimento”.

Segnalatore: Mr. xxx.

Responsabile: Mr. xxx.

Azioni necessarie: la risorsa responsabile, Mr. xxx, richiede i disegni a Azienda xxx con consegna entro il xx/xx/xxxx.

L’implementazione, fin dalla fase iniziale, di una metodologia di project management ha permesso di integrare la gestione del rischio in tutte le attività di programmazione del progetto. Ciò ha portato il più alto valore aggiunto all’iniziativa, perchè ha fornito, mediante il suddetto database, un sistema integrato per l’identificazione dei rischi e la loro contestuale assegnazione al responsabile, identificando anche le azioni correttive da intraprendere.

Seguendo questa impostazione, ad ogni riunione di progetto si è potuto assegnare nuove azioni, verificarne l’esecuzione ed effettuare le necessarie comunicazioni agli stakeholder in modo del tutto automatizzato (Fig. 3).

Figura 3 - Funzionamento del Risk&Issue database (fonte: elaborazione propria)

I rischi e le issue venivano comunicati personalmente o via e-mail ai membri del program management office dai membri del Team di Progetto e dai Responsabili dei Pacchetti di Lavoro. Il project manager provvedeva così ad inserirle nel database di controllo per valutarli e gestirli insieme ai rispettivi Responsabili dei Pacchetti di Lavoro.

L’interfaccia grafica del software era molto intuitiva e permetteva di specificare il pacchetto di lavoro interessato dal rischio, fornendo anche una descrizione del potenziale problema. Tra gli aspetti di maggiori interesse vi era un codice di priorità, che veniva calcolato in base alla probabilità di accadimento ed all’impatto sul progetto. Per ogni rischio era possibile inserire le azioni individuate come possibile soluzione e, cosa più importante, la persona a cui l’azione era stata assegnata.

Infine, è stata creata una integrazione con MS Office Outlook per la segnalazione e l’invio automatico delle attività sul computer della persona interessata. Nella figura sottostante (Fig. 4) si può vedere un’attività di Outlook creata automaticamente dal sistema: contiene tutte le informazioni necessarie all’individuazione del rischio, oltre, ovviamente, all’azione da svolgere da parte della persona interessata.

Figura 4 - L’integrazione con MS Outlook (fonte: documentazione di progetto)

Le date di inizio e di scadenza venivano determinate automaticamente, ed era anche possibile impostare il promemoria secondo la criticità del rischio cui l’azione era collegata.

Quando un risolutore completava l’attività, era sufficiente che segnasse la stessa come terminata in MS Outlook: il software era infatti in grado di recuperare automaticamente queste informazioni da tutti i computer client e di aggiornare il database tenendo traccia delle azioni già svolte.

Conclusioni

Abbiamo visto che la gestione del rischio è una componente fondamentale per la corretta gestione di ogni progetto. La sua applicazione può variare notevolmente a seconda del contesto e della complessità operativa ma è un elemento che non può mai essere trascurato perchè ogni rischio non gestito puó trasformarsi in un’insidia per il raggiungimento degli obiettivi prefissati.

Date queste premesse, questo articolo vuole essere uno stimolo per ricordare a chiunque si trovi a che fare con la gestione di un progetto di adottare consapevolmente un processo di Risk Management adatto al proprio contesto.

Free Templates

Sul Sito internet di Projectize Srl sono a disposizione di tutti gli utenti registrati due semplici template, una Risk and Issue Management Form ed un Risk and Issue Management Log studiati per chi desidera iniziare ad applicare da subito una corretta gestione dei rischi di progetto.

Per scaricarli, è sufficiente registrarsi gratuitamente al sito attraverso il link Registrami

In ambito progettuale, per Risk Management si intende l’applicazione sistemica di principi, approcci e processi volti ad identificare e valutare i rischi di progetto in modo da pianificare ed implementare per tempo adeguate azioni correttive.

Una buona comprensione dei rischi (cause, probabilità, impatto, tempi di manifestazione e le possibilità di risposta) attuata attraverso il mantenimento di una procedura efficiente (cost effective) ed integrata con i processi e le policy aziendali è un supporto indispensabile al processo decisionale. La gestione dei rischi in ambito progettuale nasce infatti dalla necessità di identificare, valutare e controllare l’incertezza al fine di salvaguardare il raggiungimento degli obiettivi di ogni iniziativa.

Cosa avviene nella realtà?

Benchè la gestione dei rischi venga riconosciuta come un aspetto cruciale per ogni progetto (anche quelli di minor importanza) dalla maggior parte delle imprese, la sua applicazione viene spesso trascurata perchè ritenuta un processo troppo complicato o costoso da implementare (assimilandolo erroneamente al Risk Management proprio del settore finanziario!).

Vedremo ora come, attraverso piccoli accorgimenti, si può arrivare ad un processo semplice, diretto e di facile implementazione.

La gestione sistemica dei rischi in 5 fasi

Il Risk Management non è un’attività lineare ma un processo continuo, da portare avanti lungo tutta la vita del progetto, che possiamo sintetizzare in cinque fasi:

1. Identify. Identificazione periodica dei rischi e del loro contesto.
2. Assess. Quantificazione del rischio, basata sull’impatto del rischio e sulla probabilità che si verifichi (Probability and Impact). Valutazione degli effetti previsti in relazione alla proprensione al rischio (Risk Appetite) dell’organizzazione.
3. Plan. Definizione e pianificazione delle azioni necessarie alla risoluzione del rischio (eliminazione o riduzione dell’impatto) o alla sua accettazione (se l’impatto è limitato talvolta è meglio gestirlo se e quando si manifesterà piuttosto che pianificarlo in anticipo). In questa fase vanno pianificate risposte anche ai rischi residuali e secondari. Inoltre è bene ricordare che la fase di pianificazione implica un tracking costante dei progressi delle azioni risolutive e dell’identificazione di nuovi rischi.
4. Implement. Implementazione delle azioni pianificate e controllo costante della risposta al rischio. In questa fase è molto importante nominare un Responsabile ed un Risolutore per ogni rischio identificato.
5. Communicate. La comunicazione non è propriamente una fase del processo quanto un’attività da portare avanti durante tutto l’arco del Risk Management. Coinvolge tutto il gruppo di progetto e viene implementata soprattutto attraverso la redazione di report periodici.

Figura 1 - Risk Management Procedure (fonte: Managing successful projects with PRINCE2)

Questo processo puó essere esteso anche all’attività di gestione delle issue di progetto. Infatti, per semplicità, molti progetti minori integrano in un solo processo la gestioni dei rischi con la gestione delle istanze di progetto (Issue).

Quali strumenti usare?

Strumenti? Il più delle volte, una penna e un foglio di carta possono essere sufficienti…

In ogni caso, tutti i computer sono dotati di suite che permettono di utilizzare fogli di testo e di calcolo come utile supporto per questa attività.

In commercio vi sono inoltre database specializzati e avanzati software di Risk Management che possono risultare indispensabili nel caso in cui vi troviate a gestire progetti complessi o di grandi dimensioni. Se è vero che un foglio di calcolo può essere adatto alla gestione dei rischi del 90% delle iniziative progettuali, pensate a cosa potrebbe succedere se ci trovassimo a dover gestire migliaia di Log! La redazione di un report settimanale diventerebbe una attività lunga e faticosa.

Al contrario, l’utilizzo di software sofisticati, laddove non ne sussista una giustificazione, potrebbe trasformarsi in un inutile investimento e in una spiacevole perdita di tempo.

Da dove iniziare?

Nella seconda parte parleró di un reale caso di applicazione e capiremo come applicare questo processo attraverso alcuni strumenti (che potrete scaricare in modo completamente gratuito) per iniziare da subito una corretta gestione dei rischi di progetto.