Guida al PMD Pro

 Guida al PMD Pro Project Management per i Professionisti dei progetti di cooperazione e sviluppo (development sector) Guida al PMD Pro i EDITORE Questo documento è pubblicato da PM4NGOs. © Copyright 2011 PM4NGOs ISBN: 978-­0-­9962090-­3-­8 PMD Pro e il simbolo PMD Pro sono marchi registrati di PM4NGOs. Informazioni sulla Versione: Questa è la versione in lingua italiana della Guida al PMD Pro. È basata sulla versione 1.7 (aprile 2013) della Guida in lingua inglese Questa versione è stata tradotta in italiano da un gruppo di lavoro dell’associazione Social Innovation Teams (SIT) www.socialinnovationteams.org coordinato da Giacomo Rossi. Il lavoro di traduzione e revisione è stato svolto da Giacomo Rossi e da Ruggero Golini, Paolo Landoni, Giacomo Marini, Dario Mozzi, Elena Perondi, Daniele Salvatore, Davide Villano. Guida al PMD Pro ii RICONOSCIMENTI Questo documento è stato realizzato con il supporto di numerosi esperti, che hanno contribuito alla creazione, revisione e modifica della guida. Tra questi, uno speciale ringraziamento va a Chris Cattaway, Roger Steele, Bernie Leadbeater, John Fisher, John Davidson, Alan Harpham, Liz Berryman, Katalin Hanniker, John Cropper, Anna Kondakchyan, Eric Berg, Richard Kondowe, Godfrey Kalibbala, Juan Manuel Palacios, Dario Mozzi, Adonis Sucalit, Jeroen Bollujit, Tracy Steuve, Bernie Leadbeater, Bob Youker, Felipe Chaparro, Lynne Curran, Gretchen Regehr, Rodolfo Siles, Naomi Jones, Geoff Reiss, Guy Sharrock, Amos Doornbos, Robert Sweatman, Marie-­Laure Curie, David Palasits, Simon Early, Vadim Usvitsky, Caren Conner, Marian Abernathy, e Terri Ise. Vorremmo inoltre ringraziare lo staff e i volontari associati alla Project Management Institute Educational Foundation, il cui supporto è stato centrale nella realizzazione del materiale didattico associato alla Guida. Siamo anche in debito con le molte organizzazioni i cui documenti sono stati citati e adattati all’interno della Guida al PMD Pro1. Vorremmo in special modo citare il Catholic Relief Services, che ha contribuito con la sua eccezionale serie di ProPack., il World Vision International per il Learning for Evaluation and Planning (LEAP), e la Commissione Europea per le sue Aid Delivery Guidelines, i cui casi studio sono stati ampiamente utilizzati in questa Guida. Ringraziamo inoltre il Project Management Institute, l’International Institute for Learning, True Solutions Inc. e la Versatile Company per averci generosamente fornito materiali didattici e supporto. Una lista completa delle fonti utilizzate è riportata alla fine di questo documento. Infine, questo risultato non sarebbe stato possibile senza l’ispirazione e il supporto di Richard Pharro e del suo team presso l’APM Group. Questo risultato è stato raggiunto solo grazie al loro supporto finanziario, organizzativo e tecnico. Michael Culligan, Stephen Marks, Trevor Nelson, Leah Radstone ed Eric Verzuh Guida al PMD Pro iii NOTE Guida al PMD Pro iv INDICE Editore ......................................................................................................................................................... ii Riconoscimenti ........................................................................................................................................... iii Note ........................................................................................................................................................... iv Indice .......................................................................................................................................................... v Introduzione ................................................................................................................................................ 1 Sezione 1 : I Progetti Nel Development sector ........................................................................................... 5 1.1 Gestire Progetti è Impegnativo! ......................................................................................................... 5 1.1. Non Sei Solo! .................................................................................................................................... 6 1.2. Terminologia ..................................................................................................................................... 8 1.3. Progetti, Programmi e Portfolio ......................................................................................................... 9 1.4. Arte e Scienza del Project Management ......................................................................................... 11 1.5. Modello delle Competenze di Project Management nel PMD Pro .................................................. 12 2. : Ciclo di vita di un Development project ............................................................................................ 15 2.1. Project Management Bilanciato durante l’intera vita del Progetto ................................................... 15 2.2. Il Modello delle Fasi di Progetto Secondo PMD Pro ....................................................................... 15 2.2.1. Fase 1: Identificazione e Design del Progetto .......................................................................... 19 2.2.1.1. Raccolta dei dati ........................................................................................................... 20 2.2.1.1.1. Identificazione delle esigenze di progetto ........................................................... 21 2.2.1.1.2. Tipi di Dati ........................................................................................................... 23 2.2.1.2. L’analisi dei dati ............................................................................................................ 25 2.2.1.2.1. Analisi dello stato attuale .................................................................................... 25 2.2.1.2.2. Analisi dello stato futuro ................................................................................... 26 2.2.1.3. Identificazione della logica di intervento del progetto ................................................... 29 2.2.1.3.1. Varianti del Logical Framework ........................................................................... 29 2.2.1.3.2. Interpretazione del Logical Framework ............................................................... 30 2.2.1.4. Gestione dei Momenti Decisionali di Progetto ............................................................. 36 2.2.2. Fase 2: Set-­up del Progetto ...................................................................................................... 39 2.2.2.1. Obiettivo ....................................................................................................................... 39 2.2.2.2. Stabilire la struttura di governance del progetto ........................................................... 39 2.2.2.3. Autorizzazione ufficiale all’inizio del progetto ............................................................... 42 2.2.2.4. Comunicare il lancio del progetto ................................................................................. 43 2.2.3. Fase 3: Pianificazione del Progetto .......................................................................................... 44 Guida al PMD Pro v 2.2.3.1. Scope ........................................................................................................................... 44 2.2.3.2. Il Piano di Implementazione è Equilibrato .................................................................... 45 2.2.3.3. Il Piano di Implementazione è Completo ...................................................................... 46 2.2.3.4. Il Piano di Implementazione è Integrato ....................................................................... 48 2.2.3.5. Il Piano di Implementazione è Partecipativo ................................................................ 48 2.2.3.6. Il Piano di Implementazione è Iterativo ........................................................................ 50 2.2.4. Fase 4: Implementazione del Progetto ..................................................................................... 51 2.2.4.1. Gestione dei problemi .................................................................................................. 51 2.2.4.2. Gestione delle risorse .................................................................................................. 53 2.2.4.3. Gestione dei controlli interni ......................................................................................... 54 2.2.5. Fase 5: Monitoraggio, Valutazione e Controllo ......................................................................... 56 2.2.5.1. Distinguere Monitoraggio, Valutazione e Controllo ...................................................... 56 2.2.5.2. Il piano di Monitoraggio e Valutazione del progetto ..................................................... 58 2.2.5.3. Approcci alla valutazione di progetto ........................................................................... 61 2.2.5.4. Controllo ....................................................................................................................... 62 2.2.5.5. Modifiche al progetto: tolleranze ed escalation delle problematiche ............................ 62 2.2.6. Fase 6: Transizione di Fine Progetto ........................................................................................ 66 2.2.6.1. Gestire la strategia di fine progetto .............................................................................. 67 2.2.6.2. Verifica dello Scope e accettazione dei risultati ........................................................... 68 2.2.6.3. Chiusura amministrativa, finanziaria e contrattuale ..................................................... 68 2.2.6.4. Apprendimento Finale .................................................................................................. 69 2.2.6.5. Celebrare i risultati ....................................................................................................... 69 3. : Le Discipline del Project Management ............................................................................................. 70 3.1. Disciplina 1: Scope Management .................................................................................................... 71 3.1.1. Definire lo Scope di Prodotto e di Progetto .............................................................................. 72 3.1.2. Strumenti per Definire lo Scope di Progetto ............................................................................. 73 3.2. Disciplina 2: Gestione dei Tempi ..................................................................................................... 76 3.2.1. Definizione della Attività e della loro Sequenza ........................................................................ 76 3.2.2. Stima delle Risorse per ogni Attività ......................................................................................... 77 3.2.3. Stima della Durata delle Attività ................................................................................................ 78 3.2.4. Sviluppo dello Schedule ........................................................................................................... 79 3.2.5. Gestire lo Schedule del Progetto .............................................................................................. 81 3.3. Disciplina 3: Gestione delle Risorse di Progetto ............................................................................. 83 3.3.1. Perchè é importante una efficace gestione delle risorse? ........................................................ 83 Guida al PMD Pro vi 3.3.2. Gestire le finanze del progetto .................................................................................................. 84 3.3.3. Lo sviluppo dei budget .............................................................................................................. 85 3.3.4. Budgeting basato sulle attività .................................................................................................. 86 3.3.5. Stimare i Costi .......................................................................................................................... 87 3.3.6. Monitoraggio delle Performance Finanziarie del Progetto ........................................................ 88 3.3.6.1. Il Monitoraggio dei costi di progetto attraverso l’Earned Value Analysis ...................... 90 3.3.7. Gestione della supply chain ...................................................................................................... 94 3.3.7.1. Gestione dell’approvvigionamento ............................................................................... 95 3.3.7.1.1. Pianificazione dell’approvvigionamento .............................................................. 96 3.3.7.1.2. Identificazione dei Fornitori ................................................................................. 96 3.3.7.1.3. Selezione, Negoziazione e Decisione ................................................................. 97 3.3.7.2. Gestione della Logistica ............................................................................................... 97 3.3.7.2.1. Gesione dell’Inventario e Magazzino .................................................................. 97 3.3.7.2.2. Trasporto Materiali .............................................................................................. 98 3.3.7.3. Gestione degli Asset .................................................................................................... 98 3.3.8. Gestione delle Risorse Umane ................................................................................................. 99 3.4. Disciplina 4: Gestione del Rischio ................................................................................................. 101 3.4.1. Identificazione del Rischio ...................................................................................................... 102 3.4.1.1. Definizione delle categorie di rischio ................................................................... 102 3.4.1.2. Identificare rischi specifici all’interno delle categorie individuate ................... 103 3.4.2. Valutazione del Rischio .......................................................................................................... 104 3.4.3. Risposta al Rischio ................................................................................................................. 105 3.4.4. Monitoraggio e Controllo del Rischio ...................................................................................... 107 3.5. Disciplina 5: Gestione della Motivazione del Progetto .................................................................. 109 3.5.1. Identificazione delle necessità con approcci basati sui problemi o sulle risorse .................... 109 3.5.2. Spostarsi dai problemi alla strategia di intervento .................................................................. 110 3.6. Disciplina 6: Gestione degli Stakeholder ....................................................................................... 114 3.6.1. Identificazione Degli Stakeholder ........................................................................................... 114 3.6.2. Analisi Degli Stakeholder ........................................................................................................ 116 3.6.3. Coinvolgimento Degli Stakeholder ......................................................................................... 119 3.6.4. Comunicazioni Tra Gli Stakeholder ........................................................................................ 121 4. : Adattare il PMD Pro ........................................................................................................................ 122 4.1. Principi dell’Adattamento ............................................................................................................... 122 4.2. Fattori da considerare mentre di adatta il PMD Pro ...................................................................... 123 Guida al PMD Pro vii 5. : APPENDICI .................................................................................................................................... 128 5.1. Appendice 1: Glossario ................................................................................................................. 128 5.2. Appendice 2: Obiettivi di apprendimento del PMD Pro ................................................................. 132 5.3. Appendice 3: Riferimenti ............................................................................................................... 147 5.4. Indice delle Figure ......................................................................................................................... 150 Guida al PMD Pro viii INTRODUZIONE CAMBIARE IL MONDO ATTRAVERSO I PROGETTI “Come sogni di cambiare il mondo?” Scaveresti pozzi per fornire acqua potabile a dei villaggi? Fonderesti delle banche di microcredito per risollevare le donne dalla povertà? Proteggeresti un ecosistema in pericolo? Ristruttureresti una scuola? Costruiresti delle cliniche per le comunità povere delle zone rurali? Distribuiresti cibo agli affamati? Poche persone risponderebbero “Gestirei dei progetti!” Eppure, mentre milioni di development workers cambiano il mondo ogni giorno attraverso attività nel campo dell’agricoltura, dell’assistenza medica, della microfinanza, della conservazione, dell’edilizia sostenibile, dell’educazione, delle infrastrutture e dei diritti umani, tutti loro condividono un’unica cosa: Cambiano il mondo attraverso progetti! Le development organization gestiscono il loro lavoro attraverso progetti. Nei loro uffici lavorano responsabili di progetto che gestiscono team di progetto, che scrivono proposte di progetto, sviluppano piani di progetto, implementano attività di progetto, monitorano progetti attivi e ne valutano l’impatto. Inoltre, ed è la cosa più importante, le comunità che beneficiano degli interventi investono tempo, energie e risorse nei progetti. Si affidano ai progetti per costruire sui loro punti di forza, per rinforzare i loro punti deboli, per affrontare sfide che altrimenti sarebbero fuori dal loro controllo. Nonostante però le condizioni di vita di centinaia di milioni di persone dipendano dall’abilità delle development organization di raggiungere efficacemente ed efficientemente i risultati dei loro progetti, il project management raramente viene identificato come una priorità strategica per queste organizzazioni. Generalmente le development organization tendono a focalizzarsi sulle aree tecniche dei loro progetti, e ad assumere specialisti (agronomi, professionisti della sanità pubblica, economisti, ecc.), a cui poi è richiesto di gestire i progetti e guidarne i project team. Questi specialisti tendono ad essere molto capaci nell’identificare protocolli per il trattamento delle patologie, nello sviluppare programmi didattici per le scuole, nel progettare avanzati sistemi agricoli, e nell’individuare le cause più profonde della povertà. Non è però così comune che abbiano ampia esperienza e abilità nel campo del project management. Le stime sul progetto sono accurate? I rischi insiti nel progetto sono stati anticipati e mantenuti costantemente sotto controllo? Il piano di progetto è comprensibile e dettagliato? Il progetto è monitorato a tutti i livelli? Le criticità del progetto sono state identificate, tracciate e affrontate? E inoltre, i vari aspetti del progetto sono stati gestiti in modo proattivo lungo tutta la vita del progetto? I cambiamenti sociali che il progetto vuole generare sono stati raggiunti? Lo scopo della Guida al PMD Pro è quello di migliorare le abilità di project management dei development professional. La Guida costituisce una risorsa contestualizzata, bilanciata, esaustiva e adattabile che ha l’obbiettivo di aiutare ad incrementare l’efficienza e l’efficacia dei development project. La Guida al PMD Pro fornisce quindi un’esplorazione introduttiva e indipendente del Project Management all’interno del development sector. È pensata per un pubblico che include: Guida al PMD Pro 1 • Project Manager e membri del project team che si avvicinano per la prima volta al project management;; • Project Manager e membri del project team che si avvicinano per la prima volta al development sector;; • Development sector professional che intendono ottenere titoli professionali nel campo del project management;; • Consulenti/specialisti a contratto che operano nel development sector. COME È ORGANIZZATO IL PMD PRO La Guida al PMD Pro è organizzata in quattro sezioni: Sezione Uno: I Progetti nel Development Sector I progetti pervadono la cultura delle development organization. Per questo le competenze di project management risultano essere critiche per i development professional. La Sezione Uno presenta una panoramica introduttiva dei progetti del settore, dando risposta a domande come: • Perché i progetti sono importanti? • Qual è la definizione di progetto e di project management? • Come si inseriscono i progetti nel più ampio disegno strategico delle development organization? • Quali sono i ruoli/responsabilità del Project Manager e del project team? • Quali competenze sono richieste per essere un Project Manager di successo? Sezione Due: Le fasi di vita di un Development Project Nel project management, così come in molti aspetti della vita, il segreto per il successo è l’equilibrio. La Sezione Due della Guida esplora l’importanza di un project management ben bilanciato, lungo l’intera vita del progetto. Dopo una breve introduzione, dove sono presentati i concetti base, viene esplorata ciascuna delle sei fasi della vita del progetto: • Identificazione e Design del Progetto • Set-­up del Progetto • Pianificazione del Progetto • Implementazione del Progetto • Monitoraggio, Valutazione e Controllo del Progetto • Transizione di Fine Progetto Sezione Tre: Le Discipline del Project Management Per avere successo, i Project Manager del development sector hanno bisogno di sviluppare un insieme di discipline da applicare lungo l’intera vita del progetto. La Sezione Tre esplora le sei aree disciplinari del project management per il development sector: • Gestione dello Scope • Gestione dei Tempi • Gestione delle Risorse del progetto • Gestione del Rischio • Project Justification Management Guida al PMD Pro 2 • Gestione degli stakeholder Sezione Quattro: Adattare il PMD Pro La Guida al PMD Pro NON è un template da applicare indiscriminatamente a tutti i progetti e a tutte le organizzazioni. È importante ricordare che ogni development organization è unica. Inoltre, all’interno di una singola organizzazione, i progetti variano considerevolmente in termini di valore, complessità e rischio. Anche in situazioni in cui due progetti potrebbero apparire simili, gli ambienti in cui tali progetti vengono implementati risultano imprevedibili e la realtà sul campo può differire significativamente dallo scenario preventivato in sede di pianificazione soltanto pochi mesi prima. Riconoscendo l’unicità delle development organization e dei loro progetti, la Sezione Quattro esamina gli approcci che i Project Manager possono impiegare per adattare le tecniche di project management del PMD Pro al contesto in cui i loro progetti vengono realizzati. I CINQUE PRINCIPI DEL PROJECT MANAGEMENT PER IL DEVELOPMENT SECTOR Leggendo la Guida al PMD Pro, i lettori troveranno dei riquadri in cui si fa riferimento ai concetti chiave che il PMD Pro identifica come i “Cinque Principi del Project Management per il Development Sector”. Ogni riquadro contiene un breve aneddoto, un caso studio o un’osservazione che mette in risalto l’importanza di includere i Cinque Principi nell’definizione, nella pianificazione e nell’implementazione dei development project. La Figura 1 presenta un breve riassunto di ciascuno dei Cinque Principi del project management inclusi nel PMD Pro. Figura 1: I Cinque Principi del PMD Pro per il Project Management I Cinque Principi del Project Management per il Development Sector Il Project Management è Bilanciato! – I progetti dovrebbero essere gestiti in maniera bilanciata, adottando lo stesso rigore in tutte le fasi della vita del progetto. Il Project Management è Inclusivo! -­ Le discipline del project management dovrebbero essere applicate per gestire in modo coerente e ponderato tutto il lavoro relativo al progetto, lungo il suo intero ciclo di vita. Il Project Management è Integrato! -­ Tutti gli aspetti del project management dovrebbero essere allineati e coordinati, in modo da garantire un’esecuzione regolare di tutte le attività di definizione, pianificazione, monitoraggio e implementazione del progetto. Il Project Management è Partecipativo! – Includere una gran varietà di stakeholder nel processo di identificazione, definizione, pianificazione, implementazione e monitoraggio del progetto aiuta a garantire trasparenza, migliorare la qualità, incrementare le capacità del personale e rafforzare il supporto esterno, ad ogni livello. Il Project Management è Iterativo! – È necessario rivedere e ripetere i processi di project management, lungo tutta la vita del progetto, per avere conferma che la definizione del progetto, la sua pianificazione e i risultati attesi siano ancora rilevanti. Questa pratica permette anche di migliorare le stime progettuali fatte e di pianificare le fasi successive del progetto. Guida al PMD Pro 3 IL PROGRAMMA DI CERTIFICAZIONE PMD PRO Figura 2: il PMD Pro è il Programma di Certificazione di PM4NGOs In un settore che fa affidamento sui progetti per portare a termine il proprio lavoro, una certificazione contribuisce a fare in modo che i Project Manager siano effettivamente preparati a gestire i loro progetti in tutto il mondo. PM4NGOs, l’editore della Guida al PMD Pro, offre un programma di certificazione su tre livelli per i professionisti dei progetti che lavorano nel development sector. I tre livelli del Programma di Certificazione di PM4NGOs sono: • Il Livello 1 della certificazione richiede che il professionista completi con successo l’esame PMD Pro1. L’esame si compone di 75 domande a risposta multipla, si svolge online e richiede che i candidati dimostrino di conoscere e comprendere i contenuti della Guida al PMD Pro. Gli obiettivi di apprendimento per l’esame PMD Pro1 sono disponibili nell’Appendice 2 della Guida al PMD Pro. • I candidati per il Livello 2 della certificazione devono sostenere l’esame PMD Pro2, che si svolge online e richiede di dimostrare l’abilità di applicare e analizzare i contenuti della Guida al PMD Pro. Ogni domanda dell’esame PMD Pro2 è basata su development project scenario ed è costruita per valutare l’acquisizione degli obiettivi di apprendimento riportati nell’Appendice 2 della Guida al PMD Pro • Il Livello 3 della Certificazione è in corso di definizione e valuterà come i candidati del PMD Pro3 riescono ad applicare ai loro progetti i contenuti della Guida al PMD Pro. Oltre al completamento della Certificazione al PMD Pro3, i candidati del Livello 3 dovranno proseguire nello sviluppo delle loro professionalità tramite il conseguimento di un titolo avanzato presso un organismo di certificazione indipendente, riconosciuto a livello internazionale. Queste includono, in modo non esclusivo, la certificazione PMP del Project Management Institute, la certificazione IPMA Level C, o la certificazione Prince2 Practitioner and Professional. Guida al PMD Pro 4 SEZIONE 1: I PROGETTI NEL DEVELOPMENT SECTOR 1.1 G ESTIRE P ROGETTI È I MPEGNATIVO ! Gestire progetti nel development sector è tutto fuorché semplice. Il contesto è complesso. Le sfide sono numerose. Le relazioni sono complicate. E il costo di un fallimento è elevato. In breve, ci sono molte cose che possono andare storte! Questa immagine illustra solo alcune delle molte sfide che potrebbero minare il successo del progetto. Ogni riquadro identifica uno dei possibili scenari che potrebbero presentarsi nel caso in cui la progettazione, la pianificazione o l’attuazione del progetto fossero concepite o implementate in modo scorretto. Sfortunatamente, la lista di problematiche presentate in Figura 3 non è esaustiva: ci sono molte altre situazioni che “possono andare storte” nei development project. Ad esempio: “I tassi di cambio resteranno stabili?”, “Le dinamiche del team sono funzionali?”, “I sistemi di monitoraggio forniscono informazioni utili, accurate e tempestive?”, “I fornitori sono affidabili?”, “C'è instabilità politica?”, “Ci sono stakeholder che stanno minando il progetto?”. Figura 3: Rischi dei Progetti nel Development Sector www.projectcartoon.com Per avere successo, il Project Manager deve gestire queste problematiche attivamente e con decisione;; troppo spesso i progetti che falliscono sono considerati vittime di circostanze “fuori dal nostro controllo”. Mentre questa spiegazione risulta essere valida a volte, troppo spesso è usata come scusa per non riconosce che i rischi avrebbero potuto essere meglio anticipati, analizzati e attivamente gestiti. Per mantenere il controllo dei loro progetti – e quindi promuoverne il successo – i Project Manager hanno bisogno di sviluppare le competenze necessarie per identificare e gestire, in modo proattivo, Guida al PMD Pro 5 le problematiche che potrebbero avere un impatto sul progetto. Queste sono proprio le competenze che esploreremo nella Guida al PMD Pro. 1.1. N ON S EI S OLO ! Anche se le sfide cui ci si trova di fronte nei development project sono ampie e complesse, esse non sono esclusive dei progetti di questo settore. Si considerino, ad esempio, le informazioni presentate in questo grafico e nella relativa tabella (Figura 4). Ogni anno lo Standish Group conduce un’indagine intitolata Chaos Report, raccogliendo risposte provenienti da oltre 10.000 progetti del settore informatico (IT). Il report identifica la percentuale di progetti IT che sono stati valutati come “Riusciti”, “Problematici” o 1
“Falliti”. Anno dopo anno, i risultati del Chaos Report indicano che la maggior parte dei progetti IT inclusi nell’analisi dello Standish Group vengono valutati come "Problematici" o "Falliti" e solo una Figura 4: Risultati del Chaos Report percentuale relativamente piccola è considerato "Riuscito”. Nel 2008, per esempio, la percentuale di progetti completati con successo era il 32%, i fallimenti (definiti come progetti abbandonati durante la realizzazione) erano il 24%, mentre il restante 44% dei progetti è completato ma ha presentato "Problematiche", come aumento dei costi, ritardi nel calendario, e/o mancata consegna di tutti i prodotti o servizi previsti dal progetto. È importante notare che il Chaos Report non riguarda i development project: il sondaggio è stato progettato e implementato da una società di servizi di project management per studiare i risultati dei progetti IT. Tuttavia, i risultati del report sono utili a sottolineare le sfide insite nella realizzazione di progetti di successo e forniscono dati che ci aiutano a rispondere alla domanda chiave: "Quali sono le principali problematiche, che si traducono poi in difficoltà o nel fallimento del progetto?". Secondo l'analisi del Chaos Report 2009, sono tre le problematiche che più frequentemente 2
disturbano l’andamento dei progetti. 1
“Riusciti” – Progetti terminati con il risultato atteso, in tempo, rispettando il budget. “Problematici” – Progetti completati ma che non sono riusciti a fornire il risultato atteso, a rispettare i tempi o il budget. “Falliti” – Progetti interrotti prematuramente. 2
Al contrario, il Chaos Report indica come più probabili fattori di successo per i progetti: il coinvolgimento degli utenti, il supporto alla gestione esecutiva e una chiara definizione dei requisiti. Guida al PMD Pro 6 1. Specifiche e requisiti di progetto incompleti;; 2. Mancanza di pianificazione per la gestione dei rischi;; e 3. Mancato apprendimento dagli errori commessi. Suona familiare? Ciò che colpisce nell'analisi dei progetti problematici nel settore IT è come le difficoltà siano le stesse anche nel development sector. Alla fine, nonostante le molteplici differenze tra i settori che gestiscono il proprio lavoro principalmente attraverso i progetti (ad esempio edilizia, telecomunicazioni, informatica, sviluppo software e altro), essi condividono anche sfide simili, tra cui: 1. 2. 3. 4. Consegnare i prodotti finali del progetto rispettando vincoli di tempo, budget, qualità, obiettivi, rischi e opportunità;; Sviluppare piani di progetto completi e dettagliati e gestirli attraverso l'intera vita del progetto;; Gestire progetti che spesso vengono implementati tramite appalti, subappalti e fornitori;; Identificare potenziali rischi e stabilire processi per evitare e affrontare questi rischi, assicurando che i risultati del progetto siano raggiunti. Tuttavia, nonostante ci siano somiglianze tra questi settori, ci sono alcune caratteristiche che rendono unica e, a volte, particolarmente impegnativa la gestione dei progetti nel development sector. Alcune di queste caratteristiche uniche sono: • I development project producono non solo risultati tangibili, ma anche obiettivi meno tangibili, legati alla promozione del cambiamento sociale e/o dei comportamenti. I development project sono meno focalizzati sulla realizzazione di prodotti concreti come obiettivo finale del progetto;; essi, invece, considerano questi prodotti come un mezzo per apportare un miglioramento alle condizioni di vita delle popolazioni destinatarie del progetto. • I development project mirano a risolvere complessi problemi di povertà, disuguaglianza e ingiustizia. • I development project tendono a operare in contesti eccezionalmente difficili (risorse limitate, rischi elevati, reti complesse di approvvigionamento, ambienti politico-­finanziari instabili, condizioni pericolose). • La realizzazione del progetto è spesso gestita attraverso una complessa rete di relazioni tra gli stakeholder (agenzie partner, ministeri, organizzazioni locali, imprenditori, consorzi globali). • L'approccio al progetto spesso è importante tanto quanto i risultati stessi (alta priorità ad un approccio basato sulla partecipazione e sui diritti). • Il trasferimento di conoscenza e l’apprendimento per la popolazione interessata sono una priorità durante ogni fase del progetto. Guida al PMD Pro 7 1.2. T ERMINOLOGIA Ma stiamo correndo troppo. Prima di qualsiasi ulteriore discussione riguardo alle sfide legate alla gestione dei progetti nel development sector, è importante innanzitutto definire alcuni termini 3
chiave. 4
Un progetto è uno sforzo temporaneo, intrapreso per creare un prodotto, servizio o risultato unico. Basandosi su questa definizione, lo scopo del project management è quello di pianificare, organizzare e gestire le risorse per raggiungere con successo gli specifici obiettivi, risultati (outcome) e output del progetto. Sono indispensabili pratiche di project management complete e di alta qualità, per aiutare le organizzazioni nella gestione di progetti focalizzati, efficaci ed efficienti. Nell'ambito del project management, il Project Manager è responsabile del successo globale del progetto. Tuttavia, mentre il Project Manager è responsabile del successo del progetto, ciò non significa che sia anche personalmente responsabile del completamento del lavoro relativo al progetto. Infatti questo accade raramente nel development sector. Invece la responsabilità del Project Manager è quella di lavorare a stretto contatto con la rete di stakeholder per fare in modo che il lavoro relativo al progetto venga completato. Questi stakeholder – che includono i membri del team di progetto, le organizzazioni responsabili dell’implementazione, gli appaltatori, i gruppi comunitari e altri – devono lavorare assieme per pianificare, implementare e controllare tutti gli aspetti del progetto. Come in molti altri settori, ai Project Manager del development sector spesso viene richiesto di gestire stakeholder con i quali non hanno alcuna relazione gerarchica formale;; non è insolito trovare all'interno di un unico progetto stakeholder di diverse etnie, lingue, culture e persino nazionalità: gestire i gruppi all'interno di questo contesto può risultare una sfida particolarmente difficile. In pratica, la sfida per il Project Manager di consegnare con successo i risultati del proprio progetto avrà sempre luogo nell'ambito dei vincoli di progetto. Storicamente, sono stati identificati tre elementi che vincolano un progetto, noti come Triplo Vincolo (Triple Constraint). Per comprendere il Triplo Vincolo, disegnate un triangolo dove ogni lato è etichettato come segue: Scope/Qualità – Quali sono i prodotti/servizi che il progetto dovrà realizzare (scope) e qual è il Figura 5: il Triangolo del Triplo Vincolo 3
Fare riferimento al Glossario per una serie di definizioni più completa dei termini utilizzati nella Guida al PMD Pro. 4
A Guide to the Project Management Body of Knowledge (PMBOK Guide), Terza Edizione, Project Management Institute. Guida al PMD Pro 8 lavoro necessario per produrre questi deliverable? Costi/Risorse – Quanti soldi, materiali e impegno lavorativo sono disponibili per realizzare il prodotto/servizio e per completare l'intera opera prevista dal progetto? Tempi/Schedule – Quanto tempo è richiesto per completare il progetto? Il lavoro del Project Manager è quello di garantire che il triangolo del Triplo Vincolo resti bilanciato;; dato che ogni vincolo è connesso agli atri due ogni volta che uno di questi viene ristretto o rilasciato, anche gli altri vincoli dovranno essere rilasciati/allargati o ristretti/ridotti di conseguenza. Il Project Manager deve comprendere le relazioni e i trade-­off che esistono tra i vincoli;; di cui esistono tre possibili classificazioni di base: Inflessibile – indica un vincolo critico, che non può essere modificato;; Adattabile – indica che il vincolo è negoziabile, ma dovrebbe essere ottimizzato il più possibile;; Modificabile – indica un vincolo dove possono essere raggiunti dei compromessi, al fine di gestire i vincoli inflessibili o ottimizzare quelli adattabili. Facendo chiarezza sulla classificazione di ciascuno dei vincoli del progetto, il Project Manager può aprire un confronto con gli stakeholder definendo lo spazio di dialogo e guidando la discussione sulla definizione delle priorità. È importante che le priorità siano definite e accettate da tutte le parti interessate nelle fasi iniziali del progetto: cercare di negoziare su queste tematiche dopo aver lanciato il progetto è difficile o impossibile. Una volta che le persone hanno consolidato il loro punto di vista sulle priorità, pianificando le operazioni e assegnando le risorse, cambiare quanto concordato diventa molto più difficile. 1.3. P ROGETTI , P ROGRAMMI E P ORTFOLIO Nel lessico della cooperazione, i termini “progetti, programmi e portfolio” vengono utilizzati molto spesso, ma non sempre in modo rigoroso e preciso. A volte vengono addirittura scambiati tra di loro. Senza una definizione precisa e coerente di questi termini, i ruoli e le responsabilità del Project Manager, legati ai diversi livelli di gestione, possono essere poco chiari e soggetti a interpretazioni errate. Il Project management è la disciplina che si occupa della pianificazione, organizzazione e gestione delle risorse necessarie per realizzare gli obiettivi specifici, i risultati e gli output del progetto. La principale sfida del project management è il raggiungimento di tutti gli obiettivi, outcome e output, rispettando i vincoli di progetto previsti, legati agli obiettivi, al budget, alla pianificazione e alla qualità del progetto stesso. Il Program management è il processo di gestione, coordinato, di un gruppo di progetti correlati, in modo da ottenere benefici e un livello di controllo altrimenti impossibile attraverso la gestione separata. I Programmi, a differenza dei progetti, spesso vengono gestiti in maniera centralizzata, con lo scopo di coordinare il gruppo di progetti in modo da raggiungere gli obiettivi strategici e i benefici previsti dal programma nel suo complesso. Il Program management è particolarmente importante all'interno del development sector perché i progetti gestiti tramite un programma coordinato hanno il potenziale per realizzare un cambiamento Guida al PMD Pro 9 (o ottenere dei benefici) che sarebbe impossibile raggiungere gestendo i progetti separatamente. Alcune potenziali aree su cui allineare un programma sono: • Area Geografica – Diversi progetti spesso lavorano fianco a fianco nella stessa regione o nello stesso paese: una delle preoccupazioni principali del program manager sarà valutare come le risorse di più progetti che operano nella stessa area geografica possano essere sfruttate perché ogni progetto abbia un impatto maggiore di quello che avrebbe se fosse gestito in modo isolato. Più frequentemente, i programmi si occupano di un singolo paese, anche se è sempre più comune trovare programmi plurinazionali o addirittura globali. • Settore d'intervento – Mentre i progetti generalmente tendono a lavorare in un singolo settore entro un breve arco di tempo, spesso i programmi comprendono molteplici settori e lavorano su un arco di tempo più lungo. • Obiettivi – Coordinando gli obiettivi di più progetti attraverso un programma coordinato, un'organizzazione ha maggiore possibilità di raggiungere i suoi obiettivi strategici. • Fonti di finanziamento – Spesso una singola organizzazione può gestire più progetti con fondi dallo stesso donatore istituzionale. In questo scenario, esiste la possibilità di coordinare tali progetti nell'ambito di un programma, in modo da ottenere delle economie di scala. • Popolazioni beneficiarie – Le organizzazioni spesso estendono a più popolazioni beneficiarie progetti in diversi settori (sanità, acqua, istruzione, ecc.). Coordinare tali progetti attraverso un programma permette all'organizzazione di collegarli attraverso indicatori comuni, risorse condivise e processi che aiutano le comunità a valutare costantemente se l’organizzazione sta conducendo gli interventi "giusti". • Management – Mentre il personale dei singoli progetti si concentrerà sull'attuazione delle attività che contribuiscono in maniera diretta agli output e ai risultati del loro obiettivo (scope), a livello di programma i manager si concentreranno sulla sfida di coordinare i progetti, sfruttando al meglio le risorse di più progetti e aumentando l'impatto del programma. Il Portfolio management sovrintende le prestazioni dell'insieme dei progetti e dei programmi dell'organizzazione. I Portfolio sono generalmente gestiti da un senior team al più alto livello di un'organizzazione o da un'unità specifica all’interno dell'organizzazione (ufficio regionale o sede centrale). La gestione di un portfolio non si occupa delle attività giornaliere di un progetto, ma si focalizza sulla selezione, avvio e gestione di un insieme di progetti, in modo da aderire agli obiettivi 5
strategici dell’organizzazione. Il Portfolio management spesso sceglie quali progetti non iniziare, quali iniziare prima o quali interrompere, al fine di ottimizzare l’orizzonte strategico dei progetti intrapresi e realizzare così la missione dell'organizzazione. Molto spesso, il portfolio non è responsabilità del Project Manager. Tuttavia, questo non significa che i team di progetto non debbano preoccuparsi di questioni legate alla gestione del portfolio. Le risorse disponibili per finanziare i progetti sono spesso scarse o limitate, e varie parti dell'organizzazione possono essere in competizione tra di loro per ottenerle. Il processo di gestione del portfolio cerca quindi di assegnare priorità e bilanciare le opportunità e i rischi, rispetto alla domanda e alla disponibilità delle risorse, in modo da garantire il raggiungimento degli obiettivi 5
In un portfolio, inoltre, c’è la possibilità di includere dei sub-­portfolio di iniziative e attività, raggruppati e gestiti insieme. Questi sub-­portfolio possono essere aggregati per area programmatica (salute, istruzione, agricoltura, ecc.) o secondo la zona geografica in cui operano. Guida al PMD Pro 10 dell’organizzazione. Data la competizione per le risorse limitate disponibili, i Project Manager e i loro team dovrebbero essere in grado di dimostrare come i loro progetti: • Supportano la strategia della loro organizzazione;; • Generano valore per i programmi e/o il portfolio dell’organizzazione. Figura 6: Relazioni tra Progetti, Programmi e Portfolio 1.4. A RTE E S CIENZA DEL P ROJECT M ANAGEMENT Quanti di noi conoscono un Project Manager non troppo in gamba? Spesso si tratta di un manager con ottime competenze tecniche di project management, ma che è impaurito o incapace di collaborare con il team o con gli stakeholder del progetto;; per esempio, questo Project Manager potrebbe essere un mago con i fogli di calcolo, organizzando abilmente il lavoro e pianificando i futuri scenari, ma essere al contempo scarsamente a proprio agio nel comunicare. Il risultato sarà un team di progetto smarrito e degli stakeholder alla disperata ricerca di leadership e comunicazione. Questo scenario fa sorgere naturalmente la domanda “Cos’è un forte project management? È un’arte o una scienza? Richiede delle abilità “artistiche” intangibili legate al comportamento umano e alle relazioni, o è una collezione di tecniche “scientifiche” tangibili sulla gestione tecnica di input e output?” Non sorprende come la risposta sia “entrambe”. Nel project management, così come in molti aspetti della vita, il segreto del successo è l’equilibrio. L’arte del project management si focalizza sugli elementi di un progetto legati alle persone, richiede abilità che permettano ai Project Manager di guidare, supportare, motivare e comunicare. Il Project Manager artistico è in grado di dirigere il team quando le sfide del lavoro si modificano, riallineare le priorità quando cambia la realtà sul campo, risolvere i conflitti quando si presentano e determinare quali informazioni comunicare, quando comunicarle e a chi. Guida al PMD Pro 11 La scienza del project management si concentra sulla pianificazione, stima, misurazione e controllo del lavoro, racchiudendo di fatto le domande chi-­fa-­cosa-­quando? • Dove siamo con il progetto? • Qual è il costo previsto del progetto? • Quali risorse devono essere gestite attivamente? • Ci sono rischi che minacciano il progetto? • Quando sarà completato il progetto? La chiave per un progetto di successo risiede nell’identificare un Project Manager equilibrato, a suo agio sia con l'arte che con la scienza del project management. 1.5. M ODELLO DELLE C OMPETENZE DI P ROJECT M ANAGEMENT NEL PMD P RO Nonostante la classificazione delle abilità di project management nelle categorie "arte" e "scienza" sia utile, è solo un primo passo verso l'identificazione delle caratteristiche di un Project Manager di successo. Un modello più completo delle competenze richieste per la gestione dei progetti aiuterà a identificare le abilità del Project Manager e, quindi, servire come strumento per valutare il livello di queste abilità, individuare le aree di miglioramento e mappare le aree su cui sviluppare la propria carriera. per i Esistono diversi modelli di competenza per i Project Manager, il modello del PMD Pro organizza le competenze in quattro aree: • Tecniche –competenze a cui ci si riferisce come alla “scienza” del project management. Il Project Manager è in grado di identificare, selezionare e impiegare i giusti strumenti e processi per garantire il successo del progetto? • Leadership/Interpersonali – spesso identificate come “l’arte” del project management. Per esempio, in che modo il Project Manager comunica, ispira e risolve i conflitti? • Personali/Self-­Management – l’abilità del Project Manager di gestire sé stesso. Per esempio, il Project Manager è effettivamente in grado di definire le priorità, gestire i tempi e organizzare il lavoro? • Specifiche del Development sector – la capacità di applicare le competenze tecniche, di leadership/interpersonali e personali/self-­management nell'ambito dei development project. Ad esempio, il Project Manager è in grado di identificare, selezionare e impiegare i giusti strumenti e processi tipici del development sector? Oltre a queste quattro aree di competenza generali, il Project Manager dovrebbe possedere anche la capacità di lavorare efficacemente nell'ambito della cultura della propria organizzazione. Il responsabile del progetto è in grado di muoversi secondo il management framework, la cultura organizzativa, i processi/sistemi di business e le reti di risorse umane specifici dell'organizzazione? La cultura di un’organizzazione definisce la sua identità (brand) e la distingue da altre organizzazioni che gestiscono progetti simili. Guida al PMD Pro 12 Figura 7: Elementi esemplificativi delle quattro Aree di Competenza Competenze Tecniche Leadership/Inter-­
Personali Personali/Self-­
Management Specifici del development sector Elementi esemplificativi ü Gestire in modo proattivo lo scope del progetto ü Identificare in modo completo le attività necessarie per il successo del progetto ü Gestire la pianificazione complessiva per garantire che il lavoro rispetti i tempi ü Definire le metriche e raccogliere i dati per misurare i progressi del progetto ü Identificare, monitorare, gestire e risolvere i problemi del progetto ü Diffondere efficacemente le informazioni sul progetto a tutti gli stakeholder ü Identificare, gestire e contenere i rischi di progetto ü Costituire i sistemi logistici ü Garantire che i risultati finali del progetto siano di qualità accettabile ü Vedere il “quadro generale” di un progetto all’interno del portfolio dell’organizzazione ü Promuovere il progetto (favorire l’inclusione degli stakeholder) ü Comunicare la visione – impostare delle aspettative sfidanti, ma ragionevoli ü Fornire feedback tempestivi e utili sulle prestazioni ai membri del team ü Favorire un ambiente di lavoro produttivo per il team ü Comunicare in modo proattivo (verbale e scritto), tra cui l’ascolto attivo ü Motivare i membri del team nel seguire le indicazioni e raggiungere gli obiettivi ü Abilità organizzative ü Attenzione al dettaglio ü Capacità di multi-­tasking ü Pensiero logico ü Pensiero analitico ü Autodisciplina ü Gestione dei tempi ü Capire i paradigmi e i valori del development sector ü Comprendere i diversi stakeholder coinvolti nei development project ü Capire e sapersi muover nei complessi ambienti del development sector ü Lavorare efficacemente con una rete di partner coinvolti nell’implementazione ü Far fronte alle pressioni uniche degli ambienti dello sviluppo ü Mostrare sensibilità culturale Come ci si aspetterebbe, il livello di abilità che un Project Manager deve possedere in ciascuna di queste aree di competenza varia in base alla dimensione, alla complessità e ai rischi del progetto. Tuttavia, nonostante le loro differenze, tutti i progetti trarrebbero vantaggio da un approccio progettuale al fine di garantire che: • le attività siano esaurientemente identificate, prioritizzate e messe in sequenza;; • la pianificazione temporale sia approfondita e identifichi gli elementi interconnessi del piano di progetto;; • i processi di approvvigionamento (sia per i materiali che per i fornitori) siano identificati e implementati;; • le norme per la comunicazione con gli stakeholder siano poste in essere e utilizzate;; • esistano sistemi di gestione del personale per lo staff, per i volontari e per i partner;; • i rischi siano anticipati e monitorati;; Guida al PMD Pro 13 • sia stabilito un sistema per garantire che il progetto raggiunga standard di qualità accettabili;; • sia stabilito e gestito un processo di gestione del cambiamento. Man mano che le responsabilità dei Project Manager aumentano, passando da progetti relativamente semplici a progetti più complessi, le conoscenze, le competenze e i comportamenti necessari in ciascuna delle aree di competenza dovranno aumentare in maniera proporzionale. Inoltre, una delle abilità più sottili che i Project Manager sviluppano nel tempo è l'arte di sapere quali alternative esistono per affrontare una problematica (sforamenti di bilancio, conflitti nella squadra, ruoli ambigui, slittamento dei tempi, rischi imprevisti) e identificare quale competenza (strumento/abilità/processo) sarebbe più appropriato per soddisfare le esigenze uniche di ogni situazione. Anche se tutte le quattro aree di competenza del project management sono fondamentali per garantire il successo di un progetto, la Guida al Pro PMD si concentra in particolare sull’ Area di Competenza Tecnica. Le Sezioni 2-­4 della Guida si focalizzano su processi, strumenti e meccanismi che possono essere utilizzati per rafforzare la progettazione, pianificazione, attuazione, monitoraggio, controllo e chiusura dei progetti. È indiscutibile come i Project Manager dovrebbero anche lavorare al rafforzamento delle loro competenze personali, interpersonali e specifiche del development sector;; tuttavia, non è l'obiettivo di questo documento elaborare in maniera estensiva queste aree di sviluppo professionale. Guida al PMD Pro 14 2. : CICLO DI VITA DI UN DEVELOPMENT PROJECT 2.1. P ROJECT M ANAGEMENT B ILANCIATO DURANTE L ’ INTERA VITA DEL P ROGETTO Per il successo dei development project, è fondamentale che l’intera gamma delle competenze di project management vengano applicate in modo equilibrato attraverso l’intera vita del progetto. A questo scopo, molte development organization hanno implementato dei diagrammi del Ciclo di Vita del progetto che utilizzano per identificare le fasi attraverso le quali evolvono i loro progetti dall’inizio alla fine. Insieme, le fasi del ciclo di vita del progetto identificano la sequenza logica delle attività che consentono di raggiungere gli obiettivi o gli scopi del progetto. Figura 8: Ciclo di Vita del Progetto secondo FAO La Figura 8, ad esempio, illustra la progettazione del ciclo di vita per la “Food and Agriculture Organization” (FAO) che, in questo caso, è rappresentato da una serie di anelli interconnessi. Questo, comunque, è solo uno degli approcci che le development organization impiegano per comunicare la definizione del ciclo di vita del progetto. Altre development organization hanno adottato cicli di vita del progetto rappresentabili mediante altre modalità, inclusi modelli circolari, lineari o a spirale modificata. L’esatta sequenza e la terminologia impiegata nei diagrammi del ciclo di vita del progetto possono variare considerevolmente fra imprese ed organizzazioni;; in ogni caso, i loro obiettivi rimangono gli stessi. Raggruppando le attività nella sequenza del ciclo di vita del progetto, i Project Manager e il team di progetto possono: • Definire le fasi che collegano l’inizio del progetto con la sua fine;; • Identificare i processi che il team di progetto dovrà implementare durante il susseguirsi delle fasi del ciclo di progetto;; • Illustrare come la gestione del ciclo di vita del progetto può essere utilizzata come modello per la gestione dei progetti;; • Modellizzare il funzionamento del progetto all’interno di un ambiente vincolato, nel quale i cambiamenti di qualsiasi vincolo possono sfociare in conseguenti variazioni degli altri parametri di progetto. 2.2. I L M ODELLO DELLE F ASI DI P ROGETTO S ECONDO PMD P RO Nonostante il riconoscimento dell’esistenza di numerosi diagrammi del ciclo di vita del progetto fra le organizzazioni nel development sector, il PDM Pro propone un proprio modello di progetto articolato in sei fasi (Error! Reference source not found.). Tale modello non è pensato per sostituire alcuno Guida al PMD Pro 15 specifico modello di ciclo di vita del progetto, né ha intenzione di divenire lo standard per il development sector. Al contrario, il suo intento è quello di fornire un modello equilibrato e completo che copra l’intera vita del progetto. Figura 9: Il Modello delle Fasi di Progetto Secondo PMD Pro Il Modello delle Fasi di Progetto del PMD Pro è stato progettato con l’esplicita intenzione di assicurarne l’equilibrio e la completezza, caratteristiche queste particolarmente rilevanti nel contesto del development sector. Molto spesso, le development organization hanno eccessivamente enfatizzato Design, Monitoraggio e Valutazione del progetto (DM&V), mettendo in ombra l’importanza delle altre fasi nella vita di un progetto. Chiaramente, l’attenzione al DM&V è necessaria, ma essa da sola non è sufficiente a garantire il successo del progetto. Il progetto non solo deve investire nel DM&V in modo ingente e coerente, ma un pari livello di sforzo e risorse deve essere impegnato in tutte le altre fasi. Nel Modello delle Fasi proposto da PMD Pro, ad esempio, le attività di monitoraggio, valutazione e controllo sono costantemente presenti nel background del progetto, ma sono solo uno dei componenti delle sei fasi in cui si articola il modello, che include: Identificazione e Design del Progetto – È durante questa fase che il team di progetto definisce i bisogni, esplora le opportunità, analizza l’ambiente di progetto e pianifica le diverse alternative di progettazione. Le decisioni prese durante la fase di Identificazione e Design del Progetto fissano una struttura strategica e operativa all’interno della quale il progetto opererà successivamente. Set-­up del Progetto -­ Durante questa fase il progetto viene ufficialmente autorizzato e vengono definiti e comunicati i suoi parametri generali ai principali stakeholder. In questa fase il team di progetto stabilisce anche la struttura di governance di alto livello. Pianificazione del Progetto – Partendo dai documenti sviluppati nelle prime fasi progettuali, durante la fase di pianificazione il team sviluppa un piano dettagliato e comprensivo di implementazione, che fornisce il modello di riferimento per tutte le attività. Questo piano viene rivisitato durante l’intera vita del progetto e aggiornato (se necessario) per adattarsi al mutevole contesto in cui si opera. Guida al PMD Pro 16 Monitoraggio, Valutazione e Controllo del Progetto – Questa fase si estende attraverso l'intera vita del progetto, misurando continuamente i suoi progressi e individuando le opportune azioni correttive in situazioni in cui le performance progettuali si discostano in modo significativo dal piano. Transizione di Fine Progetto – Questa fase comprende l'attuazione di tutte le attività di transizione che devono essere eseguite alla fine di un progetto, tra le quali, l’accettazione dei deliverable finali da parte dei beneficiari, la raccolta delle lezioni apprese, e il completamento delle attività di chiusura: finanziarie, contrattuali e amministrative. Nonostante il modello di progetto PDM Pro dia l'impressione che le fasi siano divise e sequenziali, in pratica esse interagiscono e si sovrappongono. Per esempio: Momenti Decisionali Con l’avanzamento del progetto attraverso le sei fasi, è consigliabile che il team di progetto revisioni le motivazioni e la pianificazione del progetto attraverso una serie formalizzata di momenti decisionali (rappresentati nel modello delle fasi PDM Pro da dei triangoli). La Gestione del Progetto è Iterativa Implementazione del Progetto – Il lavoro quotidiano di realizzazione prevede di eseguire e gestire l'applicazione del piano di attuazione del progetto, guidando la squadra, occupandosi dei problemi insorti, gestendo il team di progetto e integrando creativamente i diversi elementi del piano di progetto. Ad ogni momento decisionale, il team di progetto ha l’opportunità di decidere se l’iniziale motivazione del progetto risulta ancora valida, se è richiesto qualche cambiamento rilevante, o se gli investimenti nel progetto devono essere fermati interamente. Ogni progetto e organizzazione avranno un differente approccio ai momenti decisionali. I più frequentemente utilizzati tendono ad essere quelli identificati nelle prime fasi del progetto. Questi includono i documenti di ideazione e le proposte per il progetto che comprendono i documenti di input per decidere se andare avanti con potenziali progetti. È consigliabile, comunque, includere anche momenti decisionali in fasi successive del progetto. Durante la fase di attuazione, per esempio, è utile verificare occasionalmente, ma formalmente, l’esistenza dei bisogni che il progetto intende soddisfare, che la logica dell'intervento sia ancora valida, e che i piani di attuazione siano ancora accurati. • Già nella fase di Identificazione e Design del progetto, un’ampia quota di lavoro è stata completata per preparare gli elementi della pianificazione per la realizzazione del progetto;; • Durante la fase di Set-­up, saranno introdotti i sistemi che guideranno le attività nelle fasi di Monitoraggio, Valutazione e Controllo;; • Durante la fase di Implementazione, verranno svolte le attività in grado di preparare il progetto per una chiusura efficiente all’arrivo della fase di Transizione di Fine Progetto. Mentre è generalmente vero che alcune fasi del progetto hanno luogo solo dopo il completamento di altre -­ l’esempio più evidente è la realizzazione della transizione finale del progetto che avrà luogo solo dopo la pianificazione del progetto -­ alcune fasi avvengono contemporaneamente. Per esempio, come illustrato dal grafico di Error! Reference source not found., una ingente quota del Guida al PMD Pro 17 lavoro è investita nella progettazione anche prima della formale apertura del progetto. Allo stesso modo, le attività finali di transizione iniziano qualche tempo prima del completamento della fase di implementazione del progetto. Figura 10: Interazioni tra le Fasi del Progetto Guida al PMD Pro 18 2.2.1. F ASE 1: IDENTIFICAZIONE E DESIGN DEL PROGETTO Figura 11: La Fase di Identificazione e Design del progetto Il Project Management è partecipativo! Tutti i progetti iniziano come un’idea – un bisogno o un'opportunità che viene valutata, analizzata, e, infine, sviluppata in un progetto, che verrà gestito attraverso il ciclo di vita del progetto. È durante questa fase che dobbiamo rispondere alla domanda critica “Stiamo facendo il progetto giusto?”. Sbagliando in questa fase il progetto sarà sbagliato per lungo tempo -­ anche se tutto il lavoro di progetto è ben pianificato e attuato. Se operiamo bene invece, saremo già a metà dell’opera. Consultare gli Stakeholder Presto (e Spesso) La fase di Identificazione e Design del progetto offre all'inizio del ciclo di vita l’opportunità di iniziare a creare le norme per la partecipazione. Nonostante gli approcci partecipativi alla progettazione e allo sviluppo del progetto possano richiedere molto tempo e risorse, i risultati finali potranno beneficiare dei seguenti vantaggi: • Gli stakeholder hanno la possibilità di prendere il controllo del proprio processo di sviluppo;; • La progettazione finale del progetto sarà più forte e • Aumenta la percezione di sentirsi parte del progetto tra gli stakeholder. In molti settori che si basano su una cultura di gestione del progetto, il progetto inizia formalmente con la sua approvazione ufficiale. Nel development sector, questa non è la norma, e la vita del progetto più comunemente inizia con la fase di Identificazione e Design. Durante questa fase, tempo / risorse / sforzi vengono investiti per definire le esigenze, esplorare le opportunità, analizzare l'ambiente di progetto, instaurare relazioni, costruire fiducia, sviluppare partnership e progettare alternative per la pianificazione del progetto. Le decisioni prese durante la fase di Identificazione e Design del progetto si collegano a strategie esistenti e determinano il quadro generale entro il quale il progetto successivamente evolverà. Guida al PMD Pro 19 Una delle ragioni per cui la fase di Identificazione e Design è fondamentale è l'opportunità che essa offre di rispondere nella maniera più efficiente, alle domande fondamentali circa i parametri di progetto. Come illustrato in Error! Reference source not found., il momento più favorevole per apportare modifiche a un progetto è all'inizio della sua vita. Se un team di progetto vuole modificare gli obiettivi, la calendarizzazione delle attività o il bilancio, è più facile farlo PRIMA che il progetto venga avviato (spendendo denaro, saturando il calendario e investendo risorse per completare il lavoro). Durante il ciclo di vita del progetto ci saranno altre occasioni per rivedere questioni di qualità/scope, budget/risorse e tempi/schedule. Tuttavia, una volta iniziata la realizzazione del progetto (il personale è assunto, le attività iniziate, i budget assegnati, e i risultati finali iniziano a diventare tangibili) il costo per il cambiamento di questi parametri aumenta e questi cambiamenti, a loro volta, diventano molto più difficili da gestire. Pertanto, è importante che il responsabile del progetto raccolga ed elabori i dati per prendere queste decisioni consapevolmente durante la fase di Identificazione e Design del progetto e che l'approccio generale a questa fase sia aperto ad una esplorazione creativa, al brainstorming, alla visione e al dibattito circa la strategia da implementare. Figura 12: Opportunità di gestire efficientemente il cambiamento Sebbene ci siano una serie di attività che possono essere completate in questa fase, in termini generali, il lavoro può essere classificato in tre categorie generali: 1. Raccolta dei dati;; 2. Analisi dei dati;; 3. Identificazione della logica progettuale di intervento. 2.2.1.1. Raccolta dei dati Il primo passo per determinare se stiamo "facendo il progetto giusto" è raccogliere i dati. Lo scopo di questa raccolta è quello di esplorare un elevato numero di argomenti differenti, fornendo Guida al PMD Pro 20 informazioni che, quando analizzate, consentiranno di definire le priorità e di individuare gli interventi che permetteranno di affrontare le sfide nell’area in oggetto. 2.2.1.1.1. Identificazione delle esigenze di progetto Come parte di questo ampio processo di esplorazione, il team di progetto avrà bisogno di raccogliere i dati che identificano le esigenze della comunità nell'area di intervento potenziale. Tuttavia, i dati non dovrebbero limitarsi ad esaminare esclusivamente le questioni relative alle esigenze della comunità. Altri argomenti da esplorare dovrebbero comprendere lo stato attuale della fornitura di servizi, i punti di forza esistenti all'interno della comunità, un esame degli stakeholder presenti nell'area di intervento ed altro ancora. Una delle difficoltà nella raccolta dei dati è che tale processo può essere altamente soggettivo. Persone (intese come individui e come membri di gruppi sociali e di interesse) possono avere idee radicalmente diverse su ciò che dovrebbe essere definito come una “necessità” e ciò che non dovrebbe esserlo. Di conseguenza, il processo di definizione del bisogno in un unico ambiente può portare a risultati significativamente diversi a seconda della persona che viene consultata e dell’approccio impiegato. Un modo per limitare la soggettività nella definizione del problema, e lavorare così da diverse prospettive di bisogni "reali", è quello della triangolazione dei dati di valutazione. La triangolazione è una tecnica che facilita la validazione dei dati attraverso la verifica incrociata tra più di due fonti. Ad esempio, se uno studio utilizza solo un metodo/prospettiva di raccolta dei dati, la tentazione di credere nei risultati è forte. Se un ricercatore utilizza due metodi/prospettive, i risultati possono risultare discordanti. Tuttavia, utilizzando tre metodi/prospettive per rispondere ad una domanda, la speranza è che i risultati di almeno due dei tre si rafforzino reciprocamente. D'altro canto, se si sono prodotte tre risposte contrastanti, il ricercatore sa che la questione deve essere nuovamente inquadrata, devono essere riconsiderati i metodi, o entrambe le cose. Sostanzialmente, gli approcci di triangolazione aumentano la validità dei risultati dello studio e la fiducia in essi. Grazie alla combinazione di molteplici prospettive e metodi, i ricercatori possono sperare di superare le debolezze o dati intrinseci non obiettivi ed i problemi che derivano dal metodo unico o un unico punto di vista dell'osservatore -­ aumentando così la credibilità e la validità dei risultati. Un modo per triangolare il processo di identificazione dei bisogni è quello di utilizzare un approccio introdotto dal sociologo americano Jonathan Bradshaw, il quale riteneva che la valutazione delle esigenze dovrebbe esplorare quattro tipi di bisogni in una comunità e che la presenza di tutte le tipologie di esigenze indicherebbe un bisogno “reale”. Guida al PMD Pro 21 Figura 13: Triangolazione dei bisogni attraverso la Classificazione di Bradshaw Come illustrato in Error! Reference source not found., le quattro categorie di bisogno sociale di Bradshaw includono: • Bisogni Normativi -­ confrontare la situazione attuale con standard forniti da professionisti o esperti. Spesso, queste esigenze sono identificate da professionisti o esperti -­ medici, ingegneri, professionisti della sanità pubblica, ecc. Per esempio, un esperto di servizi igienico-­
sanitari potrebbe indicare che i tassi di materia fecale nell’acqua di una famiglia sono al di sopra dello standard stabilito dal Ministero della Salute. • Bisogni Comparativi– confrontare la situazione attuale con la situazione altrui. Uno degli usi più comuni di questo approccio è stato il confronto fra l’accesso alle risorse da parte delle persone. Questo approccio riconosce che il bisogno è un concetto relativo e quindi qualsiasi dibattito su di esso deve avvenire nell'ambito di un confronto tra le persone. Ad esempio, i membri della cooperativa di pescatori possono osservare che le riserve ittiche sono più alte in un paese vicino con servizi igienici. • Bisogni Percepiti – focalizzarsi sui pensieri e sui sogni della comunità stessa. Che cosa le persone credono dovrebbe essere la priorità. Un bisogno percepito è probabile sia soggettivo e potrebbe essere meglio descritto come un “voglio”. Esso è necessariamente influenzato dalla conoscenza e dalle aspettative individuali, che possono essere realistiche e/o inaccessibili. Ad esempio, le madri potrebbero esprimere disappunto per il disordine e le condizioni nauseanti che derivano dalla mancanza di servizi igienico-­sanitari -­ ma potrebbero non essere a conoscenza di alternative esistenti per cambiare lo stato attuale. • Bisogni Espressi – sono dedotti dalla osservazione delle azioni della comunità. Per esempio, se ci sono lunghe liste di attesa per un servizio, allora vi è un'indicazione che la comunità dà la priorità a tale esigenza. A volte, i bisogni espressi sono coerenti con ciò che la comunità ha espresso (il loro bisogno percepito). Tuttavia, a volte, queste esigenze possono non essere concretamente identificate pubblicamente (come un bisogno percepito) come Guida al PMD Pro 22 risultato di pressioni politico/culturali o perché nessuno lo ha mai chiesto. Ad esempio, le famiglie potrebbero non aver espresso verbalmente il loro disappunto per la mancanza di servizi igienico-­sanitari, ma ora stanno iniziando a identificare i luoghi dove smaltire i propri rifiuti domestici (pozzi di immondizia). Il modo in cui le organizzazioni esplorano i bisogni di una comunità garantirà che il processo di identificazione dei bisogni sia accurato ed sincero. Spesso gli individui e i gruppi hanno già un'idea, basata sulle proprie osservazioni ed esperienze, circa le tipologie di progetto o servizio che una particolare development organization predilige. Per questo tali organizzazioni devono premunirsi contro dinamiche nelle quali gli incentivi portano individui e gruppi a mostrare i loro bisogni in modo che si adattino alle priorità della development organization, al fine di essere selezionati per partecipare ai progetti dell’organizzazione e riceverne i benefici. Per esempio, se una development organization è nota per supportare principalmente water projects, allora i partecipanti al progetto saranno più propensi a esprimere i loro problemi, e le soluzioni, in modi che ci si aspetta si adattino meglio ai potenziali interventi che questa development organization preferisce: un progetto idrico. 2.2.1.1.2. Tipi di Dati Il processo di raccolta dei dati, tuttavia, non si limitata esclusivamente alla definizione dei bisogni. Per comprendere appieno il contesto, il team di progetto avrà bisogno di raccogliere i dati relativi ad un certo numero di settori legati all'ambiente di progetto, tra cui, ma non solo: • Stakeholder di progetto • Punti di forza, opportunità e idee della comunità • Successi e capacità • Ambiente fisico/biologico • Reti organizzative • Infrastrutture • Istituzioni giuridiche, normative e politiche • Condizioni sociali e culturali In ciascuna di queste aree, esistono tre tipi di dati che possono essere raccolti: • Dati Secondari – Informazioni disponibili attraverso fonti edite ed inedite, tra cui revisioni della letteratura, indagini, valutazioni, rapporti di ONG, agenzie delle Nazioni Unite, organizzazioni internazionali ed uffici governativi. I dati secondari possono essere molto efficaci e dovrebbero essere le prime fonti a cui si accede per la valutazione dei dati. Sfortunatamente, l'accesso ai documenti secondari è spesso limitato ed è necessaria cautela nell'interpretazione dei dati secondari. A volte, una raccolta selettiva dei dati primari sarà necessaria per verificare l'affidabilità e la pertinenza dei dati secondari rispetto al contesto specifico, o per ottenere maggiori e più approfondite informazioni specifiche. • Dati Primari quantitativi – Nelle situazioni in cui le fonti secondarie non forniscono sufficienti informazioni valutative, le organizzazioni possono raccogliere dati attraverso approcci di valutazione quantitativi (indagini, questionari, test, strumenti di osservazione standardizzati) che si concentrano sulle informazioni che possono essere valutate e sottoposte ad analisi statistica. I punti di forza dei metodi di raccolta di dati quantitativi sono: Guida al PMD Pro 23 o Scalabilità -­ L'elaborazione dei risultati di un gran numero di soggetti tale da consentire una generalizzazione dei risultati;; o Obiettività e accuratezza dei risultati -­ Meno pregiudizi personali nella raccolta ed interpretazione dei dati;; o Standardizzazione – Gli incaricati della raccolta dei dati utilizzano approcci standard i cui risultati possono essere confrontati tra loro. Il limite dei dati quantitativi è che questo approccio a volte manca di profondità nell’analisi della situazione e può essere difficile raccogliere informazioni essenziali sul contesto. • Dati Primari qualitativi – In contrapposizione all’approccio ai dati quantitativi, l’approccio di tipo qualitativo cerca di carpire le esperienze dei partecipanti con parole, immagini e oggetti (anche segnali non verbali forniti dai providers di dati). I punti di forza della raccolta di dati qualitativi sono: o Profondità e Dettaglio: I dati qualitativi spesso forniscono descrizioni dettagliate delle situazioni, evidenziando la complessità del contesto che manca dai dati quantitativi. Se tecniche qualitative sono utilizzate parallelamente alla raccolta di dati quantitativi, è possibile spiegare il perché di una particolare risposta;; o Creazione di aperture: incoraggiare le persone ad ampliare le loro risposte può aprire nuove aree tematiche inizialmente non considerate;; o Simulazione di esperienze individuali: può essere costruito un quadro dettagliato sul perché le persone agiscono in un certo modo e quali sono le loro percezioni riguardo a queste azioni. I dati qualitativi sono spesso raccolti come racconti di tipo aperto, a differenza del formato domanda e risposta tipico di sondaggi, questionari o test. Figura 14: Strumenti per la raccolta dei dati Dati secondari • Review della letteratura • Review di archivi • Statistiche esistenti • Indici • Documenti governativi • Altri documenti ONG Dati primari quantitativi • Knowledge, practice e coverage surveys • Indagini nei centri abitati • Test e indagini standardizzate • Strumenti di osservazione standardizzati • Misurazioni antropometriche Dati primari qualitativi • Brainstorming • Affinity diagrams • Focus groups • Historical narratives • Timelines • Empowerment circles • Visioning • Locality mapping • Interviste semi-­strutturate • Interviste ai Key Informant • Ranking exercises Bisognerebbe selezionare con attenzione gli strumenti e gli approcci più adatti (e convenienti) per raccogliere le informazioni. L’opinione prevalente talvolta indica che alcuni approcci per la raccolta dei dati sono migliori di altri. Ad esempio, i dati primari sono spesso percepiti come preferibili ai dati secondari. Tuttavia, nella pratica è chiaro che c'è spazio per molteplici fonti di dati e metodi misti in quasi ogni processo di valutazione. Guida al PMD Pro 24 Mentre la raccolta dei dati primari può essere mirata alle precise esigenze del progetto proposto, la raccolta di dati primari può richiedere molto tempo e denaro e coinvolgere molte persone. Per tale motivo, molte organizzazioni raccomandano che una prima valutazione si basi su dati secondari, e che fasi successive utilizzino approcci di raccolta dei dati primari per colmare le lacune non coperte dai dati secondari. Inoltre, mentre spesso i dati qualitativi vengono percepiti come meno rigorosi rispetto a quelli quantitativi, gli approcci quantitativi sovente comportano il rischio di creare aspettative tra le comunità locali ed i partner, e possono risultare particolarmente costosi. Valutazioni basate su dati qualitativi, a loro volta, possono essere rigorose se pianificate e realizzate con competenza, e possono portare alla comprensione delle ragioni che stanno dietro alle tendenze identificate attraverso approcci secondari e quantitativi. Una combinazione, nello stesso processo di raccolta dati, di metodi secondari e primari (includendo sia strumenti qualitativi che quantitativi) è in grado di fornire un quadro integrato più completo da cui partire per prendere decisioni. Tutto è finalizzato nell’ottica di prendere delle decisioni. Prima di avviare la raccolta dei dati, è necessario chiedersi: “Come saranno utilizzati questi dati?" Se non si trova una risposta accettabile a questa domanda, non bisogna procedere. Il tempo e le risorse sono troppo preziosi per essere sprecati in inutili esercizi. Purtroppo, molti esercizi di valutazione hanno raccolto ingenti quantità di dati che hanno prodotto voluminosi documenti, che spesso rimangono sullo scaffale “a prendere polvere”. Questi documenti sono il risultato di un cattivo uso delle risorse, possono essere un’intrusione nella vita degli stakeholder, e creare false aspettative che potrebbero danneggiare i rapporti con un importante partner e/o il beneficiario. 2.2.1.2. L’analisi dei dati Mentre lo scopo della raccolta dati è esplorare ampiamente un elevato numero e un’alta varietà di aspetti, lo scopo dell’analisi dei dati è di ordinare e organizzare i dati grezzi in modo che da essi possano essere estratte informazioni utili. Nello specifico, i development project tendono a concentrarsi su due grandi categorie di analisi: 1. Analisi dello stato attuale. 2. Analisi dello stato futuro. 2.2.1.2.1. Analisi dello stato attuale L’ analisi dello stato attuale è il punto di partenza per una buona progettazione. E’ il processo di comprensione dello stato, della condizione, delle tendenze e delle questioni chiave che, in un determinato contesto geografico, interessano le persone e i loro mezzi di sostentamento, ecosistemi o istituzioni. Esiste una grande varietà di strumenti per condurre tale tipologia di analisi. Ognuno di essi è progettato per uno scopo specifico e il team del progetto deve selezionare le tecniche/strumenti in base all'obiettivo da perseguire. Guida al PMD Pro 25 Figura 15: Strumenti di analisi Obbiettivo Organizzare le informazioni Assegnare le priorità ai dati di valutazione Tool Vulnerability matrices Mind mapping Affinity diagrams Ranking exercises and matrices Gap assessment analysis Mapping Group discussions Focus Group Workshop Force field analysis Problem trees Identificare lo stato attuale della fornitura dei servizi Promuovere la revisione critica da parte degli stakeholder del progetto Ricercare relazioni causa-­effetto Ciascuno degli strumenti di analisi riportato in Figura 15 è importante e tutti possono essere utilizzati per elaborare le informazioni raccolte. Ad esempio, se ci si propone di organizzare e classificare le informazioni di valutazione, sarà richiesto uno strumento di analisi diverso da quello richiesto se l'obiettivo è quello di promuovere una revisione critica da parte degli stakeholder del progetto. In pratica è improbabile che un team di progetto utilizzi tutti gli strumenti di analisi a sua disposizione per ogni progetto che implementa. Pur non essendo negli obiettivi di PMD Pro esaminare approfonditamente tutte le tecniche di analisi e gli strumenti, i responsabili di progetto dovrebbero prendere confidenza con: • identificare i diversi strumenti esistenti utilizzabili per realizzare i differenti obiettivi che sono parte dell’analisi del problema;; • scegliere lo strumento migliore per ogni obiettivo riguardante l’analisi del problema;; • sviluppare (nel tempo) le competenze e i comportamenti necessari per utilizzare i diversi strumenti di analisi del problema con diversi gruppi. 2.2.1.2.2. Analisi dello stato futuro Una volta completata l'analisi dello stato attuale, il passo successivo sarà quello di analizzare lo stato futuro del progetto. Questo comporta porsi delle domande su come il progetto migliorerà le fonti di sostentamento, gli ecosistemi o le istituzioni degli stakeholder di progetto. L’analisi dello stato futuro aiuta a sviluppare un quadro o una descrizione di dove il progetto porterà: • Che cosa sarà diverso in futuro se il progetto riuscirà a soddisfare le aspettative? • Che cosa i beneficiari del progetto saranno in grado di fare che ad oggi non possono fare? • Quale cambiamento sociale sarà attivato? Nella pratica, l'analisi dello stato futuro raramente è semplice. Infatti, mentre tale tipologia di analisi potrebbe individuare una vasta gamma di potenziali interventi, raramente un’organizzazione è in grado di implementare tutte le attività delineate nell’analisi. A questo punto, le development organization dovrebbero prendere in considerazione tre questioni strategiche fondamentali: Guida al PMD Pro 26 • Quali elementi saranno inclusi nell’intervento del progetto? • Quali elementi non saranno inclusi nello scope del progetto? • Quali sono i criteri che saranno utilizzati per prendere queste decisioni? Queste domande si riveleranno inevitabilmente di difficile risposta e le organizzazioni si confronteranno con numerose alternative. Avranno bisogno di prendere decisioni concrete concernenti lo scope del progetto. Dove il progetto interverrà? Quali servizi saranno forniti? Chi sarà servito? Il consenso su tali questioni può essere difficile da ottenere e il processo decisionale può potenzialmente diventare molto complesso e controverso. Di conseguenza, è importante che il team di progetto identifichi chiaramente e dia priorità alle molteplici considerazioni che entrano in gioco al momento di decidere che cosa sarà incluso nell’eventuale progetto, e che cosa sarà invece lasciato fuori. Figura 16: Criteri per determinare cosa includere negli Interventi di Progetto Categoria Esigenze di priorità Considerazioni esterne al programma Appropriatezza Capacità istituzionale Disponibilità di risorse Fattibilità Finanziaria/Economica Fattibilità tecnica e sostenibilità Considerazioni interne al programma Considerazioni di Project Portfolio Criteri illustrativi Quali necessità sono state più enfatizzate durante il processo di valutazione/analisi? Quali esigenze, se soddisfatte, sembrerebbero avere il più alto potenziale di impatto? Chi altro sta lavorando nell'area di intervento proposta? Quali sono i punti di forza del loro programma? Quali tra le attività in essere completano l’analisi dell’albero degli obiettivi? L’approccio proposto è accettabile per la popolazione target e per i principali gruppi di stakeholder? Per esempio, un reproductive health program sarebbe adeguato e coerente con le norme religiose e culturali? Quali sono i punti di forza della vostra organizzazione? Quali sono le capacità dei partner coinvolti nell’implementazione del progetto? E’ disponibile un finanziamento? Esiste un potenziale di crescita? Quali opportunità esistono per sfruttare le risorse? Il tasso di rendimento dell’investimento è accettabile? Il lavoro proposto può essere realisticamente realizzato? Il lavoro del progetto può essere sostenuto e mantenuto nel tempo? Quali sono le priorità strategiche per la vostra organizzazione nella regione? Nel paese? Altro? Quali sono i punti di forza del programma della vostra organizzazione? Quali sono le priorità della vostra organizzazione in riferimento all’area geografica? Ai beneficiari? Altro? Il progetto si inserisce organicamente all’interno del più ampio portfolio di progetti dell’organizzazione? E’ possibile organizzare le categorie esposte in due gruppi. Il primo gruppo di categorie (priorità delle esigenze, considerazioni esterne al programma, appropriatezza, capacità istituzionale) utilizza le informazioni raccolte, attraverso l’attività di valutazione e analisi dei bisogni, per decidere se/come l'organizzazione interverrà. Queste categorie esaminano la presenza di esigenze prioritarie che devono essere affrontate, se ci sono altri programmi che forniscono servizi complementari;; se esistono dei partner per l’implementazione del progetto che hanno la capacità di eseguirlo, e se le attività proposte sono appropriate. Guida al PMD Pro 27 Il secondo gruppo di categorie (la disponibilità delle risorse, la fattibilità finanziaria/economica, fattibilità tecnica, considerazioni interne al programma) si concentra meno sui risultati della valutazione dei bisogni e più sui criteri connessi alle considerazioni organizzative. Ad esempio, ci sono donatori interessati a finanziare il progetto? Ci sono risorse disponibili? L'organizzazione ha le capacità di intervenire in quell’area specifica? Il progetto rientra nel portfolio dei progetti dell'organizzazione? La gestione del progetto è iterativa! Una volta chiarito che i potenziali obiettivi del progetto rispondono ai criteri di cui alla tabella precedente, il design di un progetto di alto livello può essere messo in atto. Come indicato in precedenza, non tutti i potenziali obiettivi possono essere affrontati in un unico progetto. Quelle aree che non soddisfano i criteri verranno escluse dal mix di interventi. Raccolta e analisi dei dati durante la vita del progetto Mentre la raccolta e l’analisi dei dati sono normalmente associate alla fase di Identificazione e Design, queste attività possono/dovrebbero essere condotte in diverse fasi del progetto. Per esempio strumenti per la raccolta e l’analisi sono particolarmente utili durante: Prendete come esempio un caso di studio basato su una comunità immaginaria, la Municipalità di Delta • Espansione o variazione dello scope di un progetto esistente;; River. Una recente valutazione nella • Svolgimento di attività di monitoraggio Municipalità ha riscontrato che il e valutazione;; deterioramento della qualità delle acque • Completamento di attività di ha portato ad un esaurimento delle apprendimento durante la fase di Transizione di Fine Progetto. riserve di pesce, ad una riduzione nella pesca, ad una diminuzione del reddito tra le famiglie di pescatori, ad una sempre più alta incidenza di affezioni e di malattie trasmesse dall'acqua, in particolare tra le famiglie povere e nei bambini al disotto dei cinque anni. Si riscontrano alti livelli di scarichi fognari, domestici e industriali nel fiume che scorre a fianco della comunità;; alcuni dei numerosi fattori che contribuiscono al problema includono: • Bassa consapevolezza all’interno della comunità dei pericoli dello scarico dei rifiuti domestici;; • Basso accesso e utilizzo di impianti igienico-­sanitari per lo smaltimento delle acque nere;; • Debole controllo (sia inefficace che corrotto), da parte dell'Agenzia per la Protezione dell'Ambiente, sull'industria tessile locale;; • Inadeguato budget governativo, che comporta un inefficace trattamento dei rifiuti industriali (dove esistono i servizi) e delle acque reflue che non soddisfano gli standard ambientali. E' evidente in questo scenario come ci siano molte aree potenziali in cui un progetto può intervenire (presa di coscienza, smaltimento dei rifiuti, trattamento dei rifiuti industriali, appoggio per aumento dei budget, sistemi di smaltimento delle acque reflue, etc.). Realisticamente, tuttavia, un progetto deve concretamente identificare dove si interverrà, e dove non si interverrà. In definitiva, si tratta di decisioni strategiche e di allocazione delle risorse, che devono essere prese individuando criteri di intervento a più alta priorità. In questo caso di studio, tali criteri sono: Guida al PMD Pro 28 • Bisogni Prioritari – Le famiglie indicano che una necessità richiede un intervento urgente. • Considerazioni esterne al programma – Lavorare sui servizi sanitari si adatta sia alla politica del governo locale che dell'organizzazione che implementa l’intervento. • Considerazioni sulle capacità esistenti – L'organizzazione che implementa l’intervento manca di capacità nel settore tecnico del trattamento delle acque reflue, ma ha una vasta esperienza nel cambiamento dei comportamenti, come ad esempio le modalità di smaltimento dei rifiuti domestici. • Disponibilità delle risorse – Il piano quinquennale per la regione di importanti donatori internazionali comprendeva risorse per migliorare la salute nella regione. Sulla base di queste considerazioni, è stata presa la decisione per delineare un progetto focalizzato su impianti igienico-­sanitari e su una maggiore consapevolezza dei pericoli dello scarico dei rifiuti. 2.2.1.3. Identificazione della logica di intervento del progetto Ora che la raccolta e i processi di analisi dei dati sono completi, il passo successivo è quello di iniziare a identificare la logica di progetto. Uno dei principali strumenti utilizzati per stabilire la logica dei development project è la matrice Logical Framework (LogFrame). La LogFrame è uno strumento analitico utilizzato per pianificare, monitorare e valutare i progetti. Il suo nome deriva dai legami logici definiti dal/dai progettista/i per collegare i mezzi di un progetto con i suoi fini. 2.2.1.3.1. Varianti del Logical Framework Esistono diverse varianti di modelli di Logical framework che vengono utilizzate nel development sector. Molti di questi modelli usano termini diversi per identificare i risultati ottenibili di un progetto. Alcuni identificano traguardi e obiettivi, altri identificano risultati ed esiti. Analogamente, non vi è consenso unanime sul numero di livelli in una matrice Logical Framework. Alcune organizzazioni sottoscrivono matrici a quattro livelli, altre a cinque. La tabella in Figura 17 può servire come mezzo per il confronto tra modelli di Logical Framework di diversi donatori internazionali e development organization. Ciò che appare subito evidente esaminando la tabella sono le differenze nel numero di livelli in ciascun modello, e le variazioni nell'uso della terminologia. Tuttavia, nonostante tali differenze, essi sono tutti destinati ad ottenere gli stessi obiettivi, fungendo da: • Strumento sistematico per organizzare il progetto, prendendo in considerazione ed identificando le relazioni tra risorse, attività e risultati del progetto;; • Procedimento visivo di presentazione e condivisione della logica di intervento del progetto;; • Strumento per identificare e valutare i rischi inerenti al progetto proposto;; • Strumento per misurare i progressi compiuti attraverso indicatori e strumenti di verifica. Guida al PMD Pro 29 Figura 17: Terminologia del Logical Framework da una analisi trasversale delle development organization AusAid Cambiamento finale Goal CARE Program Goal EU Overall Objective Overall Goal FAO NORAD USAID World Bank World Vision 2.2.1.3.2. Cambiamento intermedio Purpose Component Objective Project Final Intermediate Goal Objective Project Specific Purpose Objective Intermediate Purpose Goal Purpose Intermediate Result Goal Strategic Objective Impact/Goal/Development Objective Program Goal Project Goal Outcome/ Purpose Outcome Cambiamento Tangibile Output Interventi Specifici Output Activity Input Expected Result Output Activity Input Activity Input Output Output Activity Activity Input Input Output Process/ Activity Activity Input Output Work Program/Task Input Interpretazione del Logical Framework La matrice Logical Framework identifica e comunica le relazioni logiche in un progetto, tracciando il ragionamento che collega i livelli della matrice in senso verticale ed orizzontale. Il rapporto tra gli elementi su ogni livello del Logical Framework illustra la logica in senso verticale che si tradurrà nel raggiungimento dell’obiettivo finale del progetto. Nonostante le molte versioni, il PMD Pro condivide un modello di Logical Framework a quattro livelli che riassume i seguenti risultati ottenibili: 1. Attività: sono le azioni intraprese attraverso le quali gli input (risorse finanziarie, umane, tecniche, materiali e tempo) sono impegnati per produrre i risultati desiderati (formazione, la costruzione, ecc) di un progetto per il quale il personale può essere ritenuto responsabile e che, sommate, producono gli output 2. Output: sono i risultati desiderati e tangibili derivanti dalle attività del progetto. Essi comprendono prodotti, beni, servizi e cambiamenti (ad esempio persone formate con maggiore conoscenza e abilità) che compongono e contribuiscono ai risultati (outcome). 3. Outcome: sono ciò che il progetto prevede di realizzare per il beneficiario (ad esempio utilizzo nella pratica di conoscenze e competenze apprese, il trasporto di merci sulle strade costruite) e che contribuisce ai cambiamenti nella popolazione (riduzione della malnutrizione, miglioramento dei redditi, maggiori rendimenti, etc.), che permette il raggiungimento dei traguardi e un impatto nel tempo. 4. Obiettivi: sono il livello più alto di risultati e impatti finali desiderati (trasformazione, sostenibilità, mezzi di sussistenza, benessere, ecc) a cui il progetto contribuisce (in molti Logical Framework sono l'obiettivo finale). Guida al PMD Pro 30 Figura 18: Logica Verticale del Logical Framework Dopo aver definito l’obiettivo del progetto, gli outcome, gli output e le attività, la domanda successiva che viene posta è: 'Quali rischi esterni (al di fuori del controllo del progetto) possono potenzialmente interferire con la logica verticale del progetto?' Ad ogni livello del Logical Framework, ci sono fattori esterni che possono influenzare il successo del progetto. Per esempio, un anno di siccità, non permette ai semi di germinare e quindi l'output (il raccolto) non può essere realizzato. Oppure, se i bambini hanno la diarrea a causa della scarsità di acqua potabile, possono mangiare di più, ma rimarranno comunque malnutriti. Questi importanti fattori esterni devono essere annotati nella colonna “Presupposti”. Potreste non essere in grado di fare nulla circa alcuni rischi (è improbabile che una ONG locale possa fermare lo scoppio di una guerra), ma è importante prevenire eventuali problemi. L'elenco dei rischi e dei presupposti può anche aiutare a spiegare perché un progetto non ha raggiunto tutti i suoi obiettivi. I presupposti definiscono la logica orizzontale della matrice, creando una relazione 'se-­allora' per la quale, se i presupposti in ogni livello della matrice sono validi, allora la via di sviluppo verticale del progetto ha buone probabilità di avere successo, come illustrato nel grafico seguente. Guida al PMD Pro 31 Figura 19: Logica orizzontale nel Logical Framework E' particolarmente importante mettere a fuoco i presupposti presenti nella cella a destra del livello di Output del Logical Framework. Le ipotesi che si trovano in questa cella costituiscono il punto cruciale della logica di intervento del progetto. E' qui che viene stabilita la connessione tra i risultati tangibili ottenuti a livello di Output e il cambiamento sociale che è desiderato al livello di Outcome. Per esempio, se gli output del progetto sono: 1. Costruire latrine. 2. Condurre una campagna di sensibilizzazione per aumentare l'uso delle latrine. Allora il presupposto a livello Output è che una maggiore disponibilità di latrine e una maggiore consapevolezza delle latrine aumenterà in modo significativo il loro utilizzo -­ migliorando così la qualità dell'acqua e la salute della comunità. Dopo aver stabilito gli obiettivi, individuato i rischi associati e i presupposti, l'elemento finale del Logical Framework sono gli indicatori di realizzazione e gli strumenti di verifica per ciascun livello del Logical Framework. Un indicatore è una misura quantitativa o un’osservazione qualitativa utilizzata per descrivere il cambiamento. Per misurare il cambiamento l'indicatore deve avere una base di riferimento (una misura o una descrizione delle prestazioni attuali e/o un elemento di comparazione) come punto di riferimento iniziale. La base di riferimento deve essere definita all’inizio o in prossimità dell'inizio di un progetto. La performance durante l'attuazione del progetto è misurata rispetto ad un obiettivo (il miglioramento, il cambiamento o la realizzazione prevista nel corso dell'attuazione del progetto), tenendo in considerazione la base di riferimento iniziale. Gli indicatori descrivono la misura in cui un progetto sta realizzando i suoi input, output, risultati e traguardi. Essi comunicano in termini specifici e misurabili la performance da raggiungere per Guida al PMD Pro 32 ciascun livello di cambiamento. Gli indicatori aiutano inoltre a rimuovere dichiarazioni vaghe e imprecise su cosa ci si può aspettare dagli interventi progettuali. La Error! Reference source not found. fornisce le linee guida per lo sviluppo di indicatori per ciascun livello del Logical Framework. Figura 20: Linee guida per gli indicatori dei livelli del Logical Framework Elementi Obiettivi – I fini ultimi o i risultati finali di più alto livello o gli impatti ai quali il progetto contribuisce Linee guida per gli indicatori Gli indicatori misurano gli impatti a lungo termine che non sono specifici di un singolo progetto. Piuttosto, sono gli obiettivi di programmi, sotto-­settori o settori, cui contribuiranno diversi altri progetti e variabili. Esempi: trasformazione, sostenibilità, qualità di vita e benessere. Outcome – Ciò che il progetto Gli indicatori per questo livello sono fondamentali, ma possono prevede di realizzare a livello essere più difficili da determinare. Il cambiamento viene ricercato di beneficiari, che aggregati tra i beneficiari in senso ampio, tra le popolazioni interessate, contribuiscono al nelle istituzioni che collaborano al progetto e tra i partner locali. raggiungimento degli obiettivi Esempi: uso delle conoscenze e competenze nella pratica reale e dell'impatto nel tempo. nel tempo;; trasporto di merci sulle strade costruite nel tempo, ridotta malnutrizione, miglioramento dei redditi e dei rendimenti. Output – I risultati finali Indicatori a questo livello sono più facili da specificare che a livello tangibili derivanti da attività del di outcome perché rappresentano beni tangibili e servizi che progetto e che sono in gran devono essere consegnati dal progetto. Tutti gli output devono parte sotto la gestione del essere realizzati entro la fine del periodo di implementazione del progetto – che formano e progetto e secondo lo schedule incluso nel piano del progetto. contribuiscono agli outcome. Esempi: persone formate che hanno incrementato conoscenze e abilità;; strade di qualità costruite, merce consegnata e servizi offerti. Attività – Le azioni attraverso Non tutte le development organization definiscono indicatori a cui gli input utilizzati per livello di attività. Indicatori a questo livello sono quasi direttamente produrre risultati tangibili, per connessi alla descrizione dell'attività stessa. Gli esempi cui il personale è ritenuto includono: attività del personale, spese effettive rispetto al responsabile – e che, una budget, uso delle attrezzature, elementi di formazione ed elementi volta aggregati, producono gli di costruzione. output. Nello sviluppo degli indicatori, la norma è quella di utilizzare criteri SMART per guidare la concettualizzazione della performance dell’indicatore. SMART è un acronimo con il seguente significato: • Specifico –Che cosa il progetto intende cambiare? Gli indicatori forniscono parametri dettagliati per quanto riguarda: o Quantità – le rappresentazioni numeriche attese di ciò che deve essere realizzato;; o Qualità – il resoconto o la descrizione visiva dei risultati attesi;; o Localizzazione – il confine geografico dei risultati attesi. • Misurabile – L'indicatore deve essere quantificabile e misurabile. L'indicatore può essere valutato in modo oggettivo e indipendente? • Achievable (realizzabile) – Gli indicatori devono essere realizzabili entro i limiti definiti dal triangolo dei vincoli del progetto (budget/risorse, tempo/budget e scope/qualità). Guida al PMD Pro 33 • Rilevante – Gli indicatori devono misurare con precisione il cambiamento che il progetto aspira a generare. L'indicatore misura in modo pratico e conveniente ciò che il team di progetto ha bisogno di sapere? • Time-­bound (correlato al tempo)– L'indicatore dovrebbe identificare una data e un'ora specifiche. A partire da quando l’indicatore sarà misurato? L'indicatore può essere ottenuto entro il termine stabilito? La tabella in Error! Reference source not found. illustra una parziale costruzione del Logical Framework del progetto relativo al caso di studio “Delta River” introdotto precedentemente. I contenuti di questo Logical Framework forniscono sia esempi di logica verticale e orizzontale del progetto che esempi delle ipotesi e degli indicatori disponibili a ciascun livello. Guida al PMD Pro 34 Descrizione Indicatori Modalità di verifica Presupposti Miglioramento della salute dei bambini sotto i 5 anni, specialmente nelle famiglie che vivono vicino al fiume Incidenza di malattie derivanti dalla qiualità dell’acqua ridotta nei bambini sotto i 5 anni del 30% entro il 2012. Registri dell’ospedale cittadino e delle cliniche, raccolti dalle squadre mediche mobili Riduzione del volume dei rifiuti fecali scaricati nel fiume Concentrazione di Escherichia Coli ridotta del 20% (in riferimento ai livelli del 2003) e raggiungimento degli standard sanitari per il 2012 Il 60% dei rifiuti fecali domestici viene smaltito tramite latrine o fognatura Indagini mensili sulla qualità dell’acqua condotte dall'autorità fluviale e dall’Agenzia per l’Ambiente. Indagine a campione annuale condotta dal comune tra il 2009 e il 2012 La qualità dell’acqua a monte rimane invariata. La pulizia dell’acqua deli fiume è un fattore determinante per lo stato di salute dei bambini < 5 anni. Latrine di qualità costruite e utilizzate dai membri della comunità Ecc. Numero di latrine completate. Numero di latrine che hanno passato il controllo di qualità. Numero di donne, uomini, ragazze & ragazzi che utilizzando regolarmente le latrine. Ecc. Dati di inventario derivanti dal modulo utilizzato dai volontari igienico-­sanitari della comunità. Interviste agli informatori chiave. Ecc. Una maggiore consapevolezza assicurerà l’adozione e l’utilizzo costante delle latrine. L’uso delle latrine ridurrà in maniera adeguata il volume di rifiuti scaricati nel fiume. Ecc. Attivare la campagna pubblica di sensibilizzazione all’igiene. Mobilitare le comunità per la costruzione delle latrine. Preparare le specifiche tecniche. Individuare siti ottimali per la costruzione delle latrine. Ecc. Numero di incontri pubblici. Numero di persone che hanno ricevuto informazioni. Numero di persone negli incontri di sensibilizzazione. Piani tecnici completati. Piani approvati dal Ministero dei lavori pubblici. Numero di siti individuati. Soddisfazione del cliente per i siti proposti. Ecc. Bollettino delle attività del personale e dei volontari. Registri delle presenze agli eventi. Copia del piano verificato. Modulo di approvazione del Ministero dei lavori pubblici. Mappa dei siti con indicazioni che documentano gli input dei clienti. Ecc. Attività Output Outcome Obiettivi Figura 21: Il Logical Framework del progetto Delta River Guida al PMD Pro 35 2.2.1.4. Gestione dei Momenti Decisionali di Progetto "A questo punto abbiamo già investito una considerevole quantità di tempo/denaro/sforzi per l'individuazione e l’ideazione del progetto senza avere alcuna garanzia che esso riceverà finanziamenti. Non è questo un rischio significativo? " Questa è una domanda pertinente e le preoccupazioni conseguenti sono valide al 100%. C'è sempre il rischio che una organizzazione investa ingenti risorse nella individuazione e nella definizione del progetto per poi scoprire che quest’ultimo non è ufficialmente approvato. La gestione del Progetto è Partecipativa! Aspetta! A questo punto, il lettore più attento si pone la seguente domanda: Consultare gli Stakeholder Man mano che il team sviluppa i documenti associati a ogni momento decisionale (come un caso documentato, un concept, una lettera di interesse, la proposta di progetto, ecc.), dovrà anche coinvolgere gli stakeholder per esplorare le domande principali legate al potenziale progetto. Queste domande includono (ma non sono limitate a) le seguenti: Lo scope del progetto è stato valutato e accettato dai beneficiari ultimi del progetto? • Lo schedule di alto livello è consistente con le aspettative e i vincoli degli stakeholder? • Gli stakeholder si sono accordati su un livello minimo della qualità? • Lo scope di alto livello, lo schedule e il budget sono stati valutati con l’organizzazione che condurrà le attività del progetto? Queste domande, e altre come loro, costituiscono dei punti di controllo nelle prime fasi del processo di definizione del progetto, aiutando a garantire che la proposta di progetto ufficiale sia fattibile e appropriata. • In un mondo ideale, il team di progetto vorrebbe mettere a punto un sistema attraverso il quale ricevere una chiara indicazione del supporto che il progetto riceverà (o non riceverà) PRIMA che notevoli risorse siano investite nella individuazione e nella definizione del progetto stesso. I team di progetto vogliono evitare lo scenario "perfetto, ma respinto", in cui le organizzazioni hanno già speso migliaia (e anche decine di migliaia) di dollari nell'identificazione dei progetti e nelle attività di definizione, ma al progetto manca alla fine il supporto dei principali stakeholder (all'interno dell'organizzazione, nella comunità, tra lo staff di governo, o dai donatori previsti). Una delle "buone pratiche" utilizzate per gestire il rischio di uno scenario “perfetto, ma respinto”, è definire dei paletti nel processo decisionale che consistono in una serie di autorizzazioni per le varie fasi del progetto. Utilizzando i momenti decisionali, le organizzazioni identificano una serie di punti nel progetto che richiedano di decidere se procedere con la fase successiva, modificare lo Scope, lo Schedule o il Budget del progetto o di terminare il progetto a titolo definitivo. Ogni successivo momento decisionale si basa sul lavoro che è stato sviluppato nella fase precedente. Gestire un gruppo numeroso di stakeholder mediante una serie di momenti decisionali spesso richiede molto tempo e comporta il rischio di problemi di comunicazione. Nonostante questa complessità e rischio, tuttavia, i vantaggi di muoversi attraverso momenti decisionali progressivi sono i seguenti: • Aiuta a garantire che l'organizzazione non investa grandi quantità di tempo, denaro, capacità del personale e capitale organizzativo nello sviluppo di proposte di progetti che mancano di impegni e sostegno da parte di importanti decisori (donatori, partner esecutivi, decisori interni all’organizzazione) Guida al PMD Pro 36 • Supporta una robusta analisi dell’idea del progetto, fornendo prospettive multiple e incoraggiando una responsabilità collettiva del progetto una volta iniziata la sua realizzazione. Delinea il processo attraverso le esigenze del progetto che devono essere esaminate al fine di garantire che esso abbia il sostegno (sia interno che esterno) richiesto perché possa essere infine approvato. Nel contesto della Fase progettuale del PMD Pro, i momenti decisionali sono rappresentati dai triangoli situati tra le fasi del progetto. Figura 22: Un esempio di Momento Decisionale nella vita di un Progetto Come evidenziato in precedenza, il numero di momenti decisionali in un progetto può variare a seconda del tipo di progetto, della sua complessità, e dei principali stakeholder. Per tale motivo, la fase di definizione del progetto è destinata a fungere da modello esemplificativo di dove potrebbero essere collocati i diversi momenti decisionali. Alcuni progetti potrebbero avere più momenti decisionali di altri. Quello che dovrebbe essere chiaro, tuttavia, è che un sistema di momenti decisionali aiuterà a garantire che gli investimenti sul progetto non vengano fatti senza l’approvazione dei principali stakeholder. Posizionare i momenti decisionali a intervalli regolari (per esempio, all'inizio di ogni anno di esecuzione del progetto), aiuta a: • Mantenere il progetto focalizzato sul bisogno per cui esso è stato originariamente intrapreso;; • Assicurarsi che il contesto e le ipotesi che inizialmente hanno portato all'approvazione del progetto continuino a sussistere;; • Fornire un’opportunità per il team di progetto e per i principali stakeholder di decidere se: o Continuare il progetto così come è attualmente concepito;; o Modificarne il piano;; o Terminare il progetto (soluzione da non considerare necessariamente come un fallimento qualora l'intervento non risultasse più adeguato, fattibile o necessario). Guida al PMD Pro 37 L'esempio sotto riportato identifica tre momenti decisionali che sono stati stabiliti per il Progetto Delta River durante la fase di Identificazione e Design del progetto. NOTA: E 'importante riconoscere che la sequenza dei momenti decisionali per il Caso di studio rappresenta solo UNA delle TANTE sequenze che potrebbero esistere per un progetto di sviluppo e che questo esempio identifica solo i momenti decisionali stabiliti durante la fase di Identificazione e Design. R
Caso: Momenti Decisionali nel progetto “Delta River”
In questo caso, i prodotti finali della fase di Identificazione e Design sono i seguenti: Momento Decisionale 1: Documento di concept. Questo documento è presentato agli stakeholder interni per autorizzare internamente le attività di valutazione e analisi esplorativa e per ricevere feedback sul potenziale sviluppo di una proposta. Momento Decisionale 2: Manifestazione di interesse. Questo documento è presentato ai potenziali donatori per ottenere una prima approvazione dai principali stakeholder esterni. Il documento è destinato ad essere sviluppato in un periodo di tempo relativamente breve, utilizzando risorse limitate ed è destinato a generare un confronto circa il design di alto livello del progetto e a ricevere feedback per il progetto PRIMA che risorse importanti siano dedicate allo sviluppo di una proposta di progetto più ampia. Momento Decisionale 3: Project Proposal. In questo passaggio viene sviluppato un documento formale necessario per ricevere l'approvazione per una richiesta di finanziamento del progetto. Questo documento deve essere più chiaro e preciso nella descrizione del CSSQ (costo, scope, schedule e qualità) del progetto. Il formato del processo di sviluppo della proposta di progetto può variare considerevolmente a seconda delle dimensioni del progetto e dei requisiti del donatore. Guida al PMD Pro 38 2.2.2. FASE 2: SET-­UP DEL PROGETTO Figura 23: Fase di Set-­up del progetto 2.2.2.1. Obiettivo Ogni progetto di successo inizia con una fase di Set-­up (messa a punto) accuratamente pianificata e attuata. Gli obiettivi della fase di Set up del progetto sono: 1. Stabilire la struttura di governance del progetto. 2. Autorizzare ufficialmente l’inizio del progetto. 3. Comunicare il lancio del progetto. 2.2.2.2. Stabilire la struttura di governance del progetto Purtroppo, il termine "governance" evoca spesso immagini di processi burocratici e protocolli. Questo non è l'intento o la finalità della governance di un progetto. Nel contesto della gestione del progetto, la governance definisce il quadro di gestione nel quale vengono prese le decisioni per il progetto. Una solida struttura di governance chiarisce: Autorità: Chi ha il potere di prendere decisioni ed entro quali livelli di tolleranza;; Responsabilità: Chi è responsabile per il successo del progetto? Senza una chiara responsabilità per il successo del progetto, non c'è nessuno che possa modificare un programma per risolvere i problemi. Le strutture di governance possono assumere svariate modalità. Nella sua forma più semplice, una struttura di governance, composta da un singolo individuo -­ lo sponsor del progetto -­ potrebbe essere sufficiente. In questo scenario, la responsabilità dello Sponsor del progetto sarebbe di: • Garantire l'impegno organizzativo e la responsabilità del progetto;; • Decidere sulle modifiche progettuali proposte (scope, budget, calendario o altro) che vadano oltre le tolleranze concordate dal Project Manager;; • Supervisionare il progetto, fornendo risorse, direttive ed idee, ove necessario;; Guida al PMD Pro 39 • Monitorare la fattibilità nel corso del progetto, prendendo decisioni per porre fine al progetto, se necessario;; • Sostenere e consigliare il Project Manager per la gestione del progetto, in particolare sulle questioni che vanno oltre l’area di controllo del Project Manager;; • Promuovere il sostegno organizzativo e di risorse per il progetto;; e • Assicurare che l'organizzazione " sia responsabile" del processo e dei risultati del progetto. Tuttavia, mentre una struttura di gestione composta da un unico sponsor, potrebbe risultare semplice, spesso non riesce a rappresentare le molte prospettive di sviluppo del progetto. Sappiamo tutti, però, che i development project raramente sono semplici. Il team di progetto deve gestire i programmi con molteplici stakeholder, tra cui (ma non solo) il donatore del progetto, la o le organizzazioni responsabili dell’implementazione, le comunità beneficiarie, e fornitori del progetto. In questi contesti complessi, un unico sponsor del progetto non fornirà il supporto che al team di progetto è necessario per avere successo. Invece, una struttura di governance più efficace sarebbe un Comitato di progetto che comprenda rappresentanti dei vari stakeholder coinvolti nel progetto stesso. Non esiste un’unica, universale regola per definire un Comitato di progetto. Tuttavia, le seguenti linee guida forniscono approfondimenti su come possono essere strutturate e gestite: Dimensione Non c’è un numero standard di partecipanti al Comitato di progetto. Come minimo, ci dovrebbero essere due persone ed è comune trovarne di composti da tre, quattro o cinque rappresentanti. Come accennato in precedenza, la dimensione più piccola del gruppo facilita un’efficiente collaborazione ed il processo decisionale. Tuttavia, è spesso utile espandere le dimensioni del Comitato quando la gestione degli stakeholder è complessa. Ad esempio, in presenza di più donatori, più gruppi di beneficiari, o più organizzazioni che lavorano sullo stesso progetto Composizione I membri del Comitato dovrebbero rappresentare i seguenti aspetti di conoscenze/ gestione/ esperienza: Guida al PMD Pro • La Executive Perspective – che valuta se il progetto genera valore nel suo insieme, e fornisce i finanziamenti e le risorse necessarie per ottenere tale valore. C'è solo un rappresentante con Executive Perspective nel Comitato. • La Senior User Perspective – il Senior User stabilisce se il progetto soddisfa le esigenze delle persone che lavoreranno direttamente con gli output del progetto. Ci può essere più di un rappresentante con Senior User Perspective nel Comitato. Un'alternativa potrebbe essere quella di istituire un "gruppo di senior user" per il progetto, che individua a turno un unico rappresentante nel Comitato per portare le opinioni di tutti i membri del gruppo. • La Senior Supplier Perspective – il quale garantisce che gli output del progetto (dai quali scaturirà il valore) possono essere realizzati con le risorse disponibili, e al livello di qualità richiesto. Ci può essere più di un 40 rappresentante della Senior Supplier Perspective nel Comitato. Un'altra alternativa sarebbe quella di istituire un "gruppo di senior supplier" per il progetto, che individua a turno un unico rappresentante nel Comitato per portare le opinioni di tutti i membri del gruppo. Ciascuna perspective dei membri del Comitato riflette una diversa dimensione del progetto in termini di risorse allocate;; comprensione dei bisogni (per il processo decisionale sulla fattibilità del progetto in corso) dell’organizzazione, degli utenti e degli sviluppatori;; e rilevanza dei risultati del progetto. Ognuno ha la propria valutazione su cosa significa "successo" -­ e tutte le prospettive nel loro insieme definiscono il successo del progetto. Responsabilità Riunioni Collettivamente, il Comitato del progetto ha la responsabilità del progetto la quale include: • Decidere sulle modifiche progettuali proposte (scope, budget, calendario o altro) che vadano oltre le tolleranze concordate del Project Manager;; • supervisionare il progetto, se necessario fornendo risorse, direttive ed idee • Monitorare la fattibilità in corso del progetto, se necessario prendendo la decisione di terminarlo;; • Sostenere l'interesse della prospettiva di cui sono rappresentanti;; • Supportare e consigliare il Project Manager nella gestione del progetto, in particolare sulle questioni che vadano oltre il raggio di controllo di un responsabile di progetto;; e • Promuovere sostegno e risorse necessarie per il progetto. Si consiglia che il Comitato indica riunioni pianificate regolarmente in cui l'ordine del giorno sia stabilito dal Project Manager, in collaborazione con il rappresentante dell’Executive Perspective. Punti importanti all'ordine del giorno figurano includono la revisione di Risks Log e Issue Log che saranno discussi più avanti. Inoltre, una riunione del Comitato di progetto è necessaria anche per tutti i momenti decisionali. Può a volte generarsi confusione quando il Comitato di progetto si comporta come una semplice democrazia nella quale ogni membro ha uguale peso nel momento di votare le decisioni più importanti. E' importante riconoscere che non tutti i membri del Comitato hanno pari autorità su tutte le decisioni. Se, ad esempio, vi è la necessità di richiedere un aumento del budget o di una estensione dei tempi del progetto, è possibile che tutti i membri del Comitato di progetto vengano consultati, ma l’autorità ultima per la decisione spetta esclusivamente ad un unico membro del Comitato (molto probabilmente in questo esempio, l’Executive Perspective) o ad un piccolo gruppo di membri dello stesso. Ricordate che l’efficacia del processo decisionale di un gruppo può essere pensato come inversamente proporzionale alle dimensioni del gruppo stesso. Non solo è possibile che i grandi gruppi non riescano a prendere decisioni tempestive, ma la qualità delle decisioni può essere influenzata dalle problematiche di gestione del gruppo. Guida al PMD Pro 41 2.2.2.3. Autorizzazione ufficiale all’inizio del progetto Se un progetto ha seguito il modello dei momenti decisionali, una serie di decisioni go/ no-­go saranno già sono state prese prima di entrare nella fase di Set Up del progetto -­ per esempio, quando il documento preliminare è stato sviluppato, quando una dichiarazione di interesse è stata presentata, o quando una proposta di progetto è stata esaminata ed approvata. Durante il Set Up è importante garantire che il progetto sia formalmente autorizzato dall’organo di Controllo del progetto stesso (sia quando questo è composto da un solo sponsor che quando è rappresentato da un Comitato di progetto). Tale approvazione deve essere documentata attraverso lo redazione di una Project Charter, un documento che fornisce una descrizione di alto livello del progetto firmato dall’organo di governo del progetto. I contenuti della Project Charter del progetto possono variare, ma di solito comprendono dichiarazioni riguardanti: • Obiettivo – include una dichiarazione sui bisogni che il progetto affronterà. • Risultati finali – descrivendo lo scope del progetto, incluso l’obiettivo, gli outcome, ed i principali output. • Stime di alto livello – includono dichiarazioni di alto livello su: o Le attività di progetto;; o La pianificazione del progetto;; o Il budget del progetto, e o Un elenco preliminare dei ruoli e delle competenze richieste per eseguire il lavoro necessario. • Rischi – identifica potenziali problemi/rischi che il progetto potrebbe incontrare. • Tolleranza – articola le tolleranze di progetto per quanto pertiene ai risultati, al programma, ai costi e ai rischi. • Change Control – crea un processo di gestione delle eccezioni nei casi in cui il progetto superi la tolleranza in una delle aree sopra citate. Una volta sviluppata e firmata, è importante che la Project Charter non sia messa su una mensola e dimenticato. E’ un documento estremamente utile che può essere utilizzato per realizzare i seguenti obiettivi: • Autorizzare ufficialmente l'inizio delle attività di progetto e l'utilizzo delle risorse per l'attuazione dello stesso;; • Assicurare che ci sia una comprensione condivisa dei parametri di progetto tra gli stakeholder chiave e gli sponsor (sia interni che esterni);; • Documentare un impegno condiviso sugli obiettivi del progetto ed sulle risorse/attività necessarie per il suo successo. Inoltre, la Project Charter dovrebbe essere considerata un documento sempre vivo. Se l’organo di governo del progetto approva importanti modifiche al progetto (scope, bilancio, calendario o altro), la Project Charter dovrebbe essere aggiornata e firmata nuovamente per riflettere i nuovi parametri. In sintesi, la Project Charter serve come “alleato” del Project Manager, e in mancanza di questa, il team di progetto corre il rischio che: Guida al PMD Pro 42 • Il team inizi a spendere tempo, denaro, materiali, personale e capitale organizzativo nell’esecuzione di un progetto che manca di impegno e sostegno dai principali decisori (donatori, partner esecutivi, decisori interni all'agenzia);; • I principali stakeholder non condividano una visione comune del progetto (scope, budget, pianificazione, benefici e rischi). 2.2.2.4. Comunicare il lancio del progetto Uno degli obiettivi principali della fase di Set Up del progetto è quello di comunicare l'avvio delle attività di progetto ai molti stakeholder che hanno interessi nell'intervento. Questi soggetti potrebbero includere le comunità beneficiarie, le ONG che lavorano nella zona di intervento, i rappresentanti dei ministeri, il pubblico in generale e molti altri. Ci sono molteplici strumenti di comunicazione che possono essere utilizzati per annunciare il lancio del progetto alla comunità di stakeholder. Tuttavia, indipendentemente dal meccanismo impiegato, lo scopo delle attività di comunicazione del lancio del progetto rimane invariato: • Riconoscere formalmente l’inizio del progetto;; • Garantire che i principali stakeholder abbiano una comprensione coerente del progetto;; • Far conoscere il progetto agli stakeholder. Da più punti di vista, la Project Charter firmata è un documento ideale con cui comunicare ufficialmente l'avvio del progetto ai numerosi soggetti coinvolti. Grazie al suo format breve e conciso la Project Charter è particolarmente utile per comunicare i parametri di alto livello del progetto. Di conseguenza, questo documento risulterà spesso essere molto comodo quando si tratta di rapporti con alcune persone che hanno “la memoria corta”, più o meno involontariamente. Condividere la Project Charter con il più vasto numero di stakeholder non è solo una pratica di comunicazione efficace, ma è anche un modo per promuovere la trasparenza e la responsabilità nel progetto. Se, tuttavia, ci sono ragioni per cui il team di progetto preferisce non condividere tutti gli elementi della Project Charter con tutta la comunità di stakeholder, esistono altre opzioni per i meccanismi di comunicazione. Se ci sono informazioni sensibili, queste possono essere incluse in una versione modificata della Project Charter che può essere condivisa con il pubblico. Inoltre, articoli di giornali, conferenze stampa, visite sul campo, meetings e party per il lancio possono anche essere utilizzati per comunicare con la comunità più allargata. I messaggi per tali comunicazioni possono variare, a seconda del pubblico e del loro collegamento con il progetto. E 'importante, tuttavia, che almeno i parametri di alto livello del progetto siano condivisi con gli stakeholder prima di iniziare l'attuazione del progetto. Guida al PMD Pro 43 2.2.3. FASE 3: PIANIFICAZIONE DEL PROGETTO Figura 24: Fase di Pianificazione del Progetto 2.2.3.1. Scope Solitamente dal momento in cui un progetto entra ufficialmente nella fase di pianificazione, il gruppo di progetto ha già sviluppato una serie di documenti (ad esempio il Project Logical Framework, la Proposta di Progetto, la Project Charter etc.) che contengono un elevato livello di dettaglio su: • Obiettivi, risultati e output • Ambiti di applicazione ed attività • Indicatori e mezzi di verifica • Budget • Programma E’ importante, tuttavia, non confondere la Proposta di Progetto, il Project Logical Framework, o gli altri documenti sviluppati nel corso delle fasi di identificazione e avvio, con il Piano di Progetto. Il Piano di Progetto si differenzia significativamente dagli altri documenti rispetto al formato, allo scopo, ai destinatari, al livello di dettaglio, alla partecipazione, ai tempi e ai vincoli di programma. Mentre alcuni sostengono che il Project Logical Framework e/o la Proposta di Progetto forniscano una quantità accettabile di informazioni utilizzabili come un Piano di Progetto, questi documenti raramente forniscono il livello di dettaglio richiesto per realizzare un progetto. Questo perché tali documenti sono scritti per servire scopi differenti. Prendiamo, per esempio, la Proposta di Progetto, confrontandola con il Piano di Implementazione. La Error! Reference source not found. delinea le differenze tra i due documenti in termini di finalità, formato, e livello di dettaglio (notare che un confronto simile potrebbe essere fatto tra il Logical Framework e il Piano di Implementazione). Guida al PMD Pro 44 Figura 25: Proposta di Progetto vs. Piano di Implementazione Scopo Proposta di Progetto Per ottenere l'approvazione e il finanziamento per il progetto, sottolineando una comunicazione chiara e concisa di idee in modo da 'vendere' il progetto ai finanziatori. Formato Il formato è spesso determinato dalle esigenze dei donatori o degli stakeholder dell’agenzia responsabile delle decisioni di investimento. Livello di Spesso limitato -­ per lo scopo, il dettaglio formato, l'anticipazione, il calendario e la tempistica della proposta. Partecipazione Spesso è scritto da un piccolo team a causa dei vincoli di tempo che limitano la partecipazione. Pubblico di riferimento Tempistiche e pianificazione E’ incentrato sui donatori e gli stakeholder che conferiscono risorse. E’ spesso scritto sotto vincoli di tempo stringenti, a volte mesi (o addirittura anni) prima della realizzazione del progetto. Piano di Implementazione Per garantire che il progetto si svolga nel rispetto delle tempistiche, dello scope e del budget e in base ai parametri di qualità stabiliti;; per sottolineare una pianificazione logica e omnicomprensiva e per adattare il progetto alla revisione del team di progetto e degli altri stakeholder Il formato è determinato dal gruppo di progetto e dai principali stakeholder. Il livello di dettaglio è determinato dal gruppo di progetto e dai principali stakeholder. Vi è la possibilità di allargare la partecipazione per includere una serie di stakeholder, compresi esperti e consulenti tecnici. E’ focalizzato sulle esigenze del team che implementa le attività di progetto. Esiste la possibilità di rivedere le proposte per il migliorare/ rivedere / aggiornare i piani al momento di inizio del progetto o nelle principali tappe intermedie nel corso del ciclo di vita. Tuttavia, mentre ci sono notevoli differenze tra la finalità, il processo e il contenuto della Proposta di Progetto e del Piano di Implementazione, molte development organization usano la Proposta di Progetto come un Piano di Implementazione. Questo è in particolare il caso in cui il formato della proposta si basa sulle richieste dei donatori che vengono formalizzate in proposte che si avvicinano al Piano di Progetto in termini di lunghezza e livello di dettaglio. Attenzione -­ anche le Proposte di Progetto più dettagliate (molte possono superare le 100 pagine di lunghezza) presentano punti deboli che limitano la loro efficacia nella pianificazione per la realizzazione del progetto. Il formato e gli elementi del Piano di Implementazione varieranno a seconda dell’organizzazione, dei donatori e/o del progetto. Tuttavia, indipendentemente dal formato del documento, tutti i piani di attuazione del progetto (rispetto ai deliverable iniziali creati durante le fasi precedenti) dovrebbero essere sicuri di conformarsi ai Principi del PMD Pro di Project Management: -­ Il Piano di Implementazione è Equilibrato! -­ Il Piano di Implementazione è Completo! -­ Il Piano di Implementazione è Integrato! -­ Il Project Management è Partecipativo! -­ Il Project Management è Iterativo! 2.2.3.2. Il Piano di Implementazione è Equilibrato Ricorda! Ci sono sei fasi nel modello PMD Pro del ciclo di vita del progetto! La gestione dei progetti dovrebbe essere bilanciata per garantire che tutte le attività, i budget e gli schedule necessari per Guida al PMD Pro 45 eseguire il lavoro associato a ciascuna fase venga eseguito. Ovviamente, il Piano di Implementazione includerà le informazioni necessarie per completare il lavoro in fase di realizzazione. E' anche importante, però, che il piano includa il piano richiesto per eseguire il lavoro necessario per gestire le altre fasi del progetto, tra cui: • • Pianificare per il Set Up del Progetto – Al momento in cui viene sviluppato il Piano di Implementazione, la maggior parte delle attività di Set Up sono già state completate. Tuttavia, non va dimenticato che le attività di governance dei progetti avviate nella fase di Set Up, devono essere mantenute nel corso di tutta la vita del progetto. Questo potrebbe significare, ad esempio, la pianificazione del calendario e di budget per le riunioni del Comitato di progetto. Pianificare per il Piano di Progetto – Il Piano di Progetto non è statico. Come Best Practice, i piani dovrebbero essere rivisitati in maniera regolare e aggiornati per riflettere i più recenti dati di monitoraggio disponibili. Se questo accadesse, la pratica della rivisitazione del Piano di progetto dovrebbe comunque comprendere le opportunità e le risorse per il team di progetto e per i principali stakeholder per rivisitare il piano assicurandosi che sia adeguato, accurato e realistico. • Pianificare per l’Implementazione del Progetto – Chiaramente l'attuazione dei piani occuperà la maggior parte del documento di programmazione. Il piano dovrà fornire una pianificazione di dettagliato con scadenze precise di attuazione per ogni componente del progetto, comprese le azioni specifiche necessarie per conseguire gli obiettivi del progetto in termini di sviluppo. • Pianificare per il Monitoraggio e la Valutazione del Progetto – Attività legate al monitoraggio e alla valutazione sono fondamentali per il successo del progetto. Tuttavia, queste attività devono essere definite nel piano di progetto per garantire che trovino applicazione. Le domande critiche a cui il piano deve dare risposta potrebbero riguardare "Chi è responsabile della raccolta dei dati, dell’elaborazione dei dati di monitoraggio, dell’analisi dei dati, di documentare i risultati e di comunicare i messaggi?", “Quando andranno svolte queste attività”, “Come verranno utilizzati i dati?”, “Ci sarà una valutazione? Se sì, quando e di che tipo?”, “Quali risorse saranno necessarie per completare la valutazione?”. • Pianificare per la Fase di Transizione del Progetto – Quali passi devono essere completati alla fine del progetto? Quali attività devono trovare compimento per far sì che avvenga la chiusura delle attività amministrative e contrattuali? Il progetto sarà delegato gradualmente ad altri stakeholder? Se questo accade, quali investimenti devono essere realizzati per garantire che il trasferimento avvenga con successo? 2.2.3.3. Il Piano di Implementazione è Completo Oltre ad essere bilanciato, il Piano di Progetto dovrebbe affrontare globalmente tutto il lavoro necessario per garantire il successo del progetto. Un Piano di Progetto globale comprenderà tutti gli elementi di pianificazione necessari per fornire i risultati diretti del progetto (latrine costruite, operatori sanitari addestrati, tecniche agricole adottate, ecc), così come gli elementi di pianificazione necessari per completare il lavoro indiretto relativo al progetto. Più specificamente, un Piano di Progetto globale includerà dettagli riguardanti ciascuno dei seguenti elementi di gestione del progetto: Guida al PMD Pro 46 Figura 26: Elementi di un Progetto completo • Pianificazione della gestione dello Scope – Come lo scope del progetto (i prodotti, i servizi e il lavoro necessario per realizzare questi risultati) sarà gestito e controllato per tutta la durata del progetto? • Pianificazione della gestione dei Tempi – Quali processi e strumenti devono essere utilizzati per stimare le esigenze di tempo del progetto e come gli schedule saranno gestiti e controllati per tutta la durata del progetto? • Pianificazione della gestione della Motivazione del Progetto – Qual è il bisogno che il progetto affronterà e le risorse consumate dal progetto (denaro, tempo, prestigio dell’organizzazione, sforzo) nel contribuire in modo efficace ed efficiente alla realizzazione di detta prestazione? • Pianificazione della gestione degli Stakeholder – Chi sono gli individui, i gruppi e le istituzioni i cui interessi potrebbero essere positivamente o negativamente influenzati dalla realizzazione o completamento del progetto? Come potranno questi stakeholder essere coinvolti per tutta la durata del progetto? • Pianificazione della gestione del Rischio – In che modo il progetto identificherà, analizzerà, monitorerà e gestirà i rischi del progetto? • Pianificazione della gestione delle Risorse – Quali processi e sistemi esistono per l'acquisizione e la gestione di attrezzature e materiali, per la gestione delle finanze e per la gestione delle risorse umane? Quali parametri logistici è necessario soddisfare perché la programmazione abbia successo? Il Piano di Coordinamento è posto al centro di questi sei elementi di un progetto globale. Il piano di progetto dovrebbe anche fornire un modello di come i differenti stakeholder lavoreranno insieme. Quali sono le norme di collaborazione? I ruoli e le responsabilità sono chiari? In che modo il team di progetto aggiornerà gli stakeholder? Quali meccanismi di comunicazione saranno utilizzati? Chi è responsabile per le comunicazioni? Guida al PMD Pro 47 Il formato dei piani di attuazione varierà notevolmente. In alcuni casi, gli elementi di un piano globale sono inclusi in un unico documento di implementazione del progetto. In altri casi, il Piano di implementazione è costituito da più documenti. In alcuni contesti, il piano di progetto di base è completato da piano(i) a parte, che forniscono un più profondo livello di dettaglio su una specifica area di pianificazione. Per esempio, un progetto potrebbe avere SIA un piano di attuazione di base CHE un piano specifico per il monitoraggio e la valutazione del progetto. Allo stesso modo, a seconda delle dimensioni, della complessità e del rischio di un progetto, un team può scegliere di avere documenti separati indirizzati al Project Procurement, Project Communications, Project Human Resource Management, ecc. Ciascuno di questi piani dovrebbe essere coerente (e collegato) con gli altri documenti che compongono il piano globale di attuazione del progetto. L’intento del Piano di implementazione è quello di fornire un modello del progetto. Esso fornisce ai membri del team di progetto un ambito a basso rischio, a basso costo in cui esplorare e sperimentare alternative di progetto;; identifica 'what if' scenari, e prende in considerazione approcci alternativi -­ PRIMA che le risorse del progetto siano state spese e prima che sia trascorso del tempo. 2.2.3.4. Il Piano di Implementazione è Integrato Ricordate il Triangolo del Triplo Vincolo? Uno dei messaggi di principio dell'immagine del triangolo è che i vincoli di progetto siano connessi, rendendo impossibile cambiarene uno senza influire sugli altri. Questa dinamica si estende nel contesto del piano di implementazione del progetto: ciascuno degli elementi del piano è collegato agli altri. Ciò è evidente nelle vaste connessioni che esistono tra i diversi elementi di un piano di implementazione completo, tra cui: -­ Le decisioni relative al budget dipendono da scelte che devono essere effettuate in relazione allo scope. -­ Le decisioni relative al calendario dipendono da scelte che devono essere effettuate in relazione alla logistica. -­ Le decisioni relative alle comunicazioni dipendono da scelte che devono essere effettuate in relazione alle risorse umane. -­ Le decisioni relative al monitoraggio dipendono da scelte relative al rischio. Questo elenco fornisce solo alcuni esempi dei molti rapporti che esistono all’interno di un piano di progetto completo. Ciò che questi esempi sottolineano, tuttavia, è l'importanza di garantire che tutte queste aree siano integrate nel piano di implementazione. 2.2.3.5. Il Piano di Implementazione è Partecipativo La partecipazione e i processi partecipativi sono incoraggiati e viene data loro priorità durante ogni fase del ciclo di vita di un progetto nel development sector. Tuttavia, durante la fase di Identificazione e Design del progetto, non è raro trovare situazioni in cui il processo di sviluppo della proposta di progetto preveda una partecipazione limitata delle parti interessate. Si tratta di uno scenario indesiderabile, ed è spesso imputabile a vari motivi: Guida al PMD Pro 48 • Lo sviluppo della proposta di progetto viene spesso accelerato a causa di vincoli di tempo. Spesso, i donatori danno alle organizzazioni solo un mese o due tra la presentazione di un'opportunità di finanziamento e la data di invio della proposta (in contesti di emergenza questo lasso di tempo può anche essere di sole 24 ore). In tali situazioni, le organizzazioni sono sotto pressione per completare tutti i passaggi presenti nella valutazione del progetto, nell’analisi e nel design;; e per farsi strada tra la validazione del progetto, necessaria per sviluppare e presentare la proposta vera e propria. Una delle molte conseguenze di questi vincoli temporali è impedire alle organizzazioni di consultare e collaborare diffusamente con gli stakeholder chiave del progetto durante la fase di Identificazione e Design. • Le proposte di progetto sono spesso sviluppate da piccoli gruppi di persone. Dato che chi valuta le proposte di progetto sono di solito gli stakeholder che hanno autorità di decidere riguardo al finanziamento (donatori esterni o gruppi interni all'organizzazione), il team di sviluppo della proposta spesso è più focalizzato sul modo migliore di 'vendere' il progetto – ed è composto da persone che sono più brave a scrivere e seguire il processo di presentazione della proposta. Ciò può causare una diminuita attenzione sulla comunicazione e la collaborazione con i principali stakeholder. • Le proposte di progetto non sono destinate a essere usate come documenti di pianificazione globale. Mentre è incluso nella proposta di progetto un certo livello di approfondimento (da medio ad alto), spesso i dettagli del progetto non sono definiti fino a quando non si è sviluppato il piano di implementazione. A questo punto, le persone più coinvolte nell'attuazione del progetto possono risultare preziose per valutare in maniera accurata l’impegno (tempo, denaro, risorse e personale) necessario per completare il lavoro del progetto. Per tutte queste ragioni, è importante che il team di progetto approfitti dell'opportunità che offre il processo di pianificazione per coinvolgere gli stakeholder in maniera più diffusa e completa di quanto non sia possibile durante la fase di Identificazione e Design del progetto. La pianificazione dovrebbe coinvolgere tutti i membri del team, insieme agli stakeholder più appropriati, sulla base della loro influenza sul progetto e sui suoi outcome. La partecipazione nel processo di pianificazione ha molti vantaggi, tra cui: 1. Gli stakeholder hanno competenze e conoscenze che possono essere utilizzate quando vengono sviluppate stime accurate riguardo budget, requisiti di tempo, livelli di impegno e altre risorse necessarie per completare il lavoro del progetto. 2. Gli stakeholder sono spesso nella posizione migliore per identificare i rischi potenziali del progetto e definire piani per ridurre il loro impatto. 3. Il nuovo personale e/o eventuali partner possono beneficiare di un migliore orientamento riguardo al progetto quando partecipano alla pianificazione delle attività. Questo aiuta a garantire una comprensione comune degli outcomes, degli output e del progetto nel suo insieme. 4. Stakeholder coinvolti nel processo di pianificazione del progetto hanno maggiori probabilità di assumere leadership, responsabilità e di sentirsi coinvolti nelle attività di implementazione del progetto. Allo stesso tempo, gli stakeholder che si oppongono al progetto possono Guida al PMD Pro 49 essere persuasi dal team di progetto a superare i loro dubbi, ascoltando le loro preoccupazioni e rimodellando quindi lo scope (o altri elementi del progetto). 2.2.3.6. Il Piano di Implementazione è Iterativo Nel corso del progetto, è importante trattare il piano di implementazione come un documento “vivo”, non statico e immutabile. Il modello delle Fasi del Pro PMD rappresenta espressamente La Fase di Pianificazione del progetto come parte di un ciclo insieme alla Fase di Implementazione e a quella di Monitoraggio, Valutazione e Controllo. Insieme, queste tre fasi forniscono continuamente informazioni e occasioni di apprendimento che raffinano e aggiornano il piano di implementazione del progetto. Nel corso del tempo, le modifiche al piano di implementazione del progetto aiutano a fornire maggiori dettagli su schedule, costi e risorse necessari per raggiungere lo scope definito. Questo processo iterativo nel tempo che fornisce livelli crescenti di dettaglio per il piano di implementazione del progetto è spesso chiamato “rolling wave planning”. Iterazione, per definizione, è l'atto di ripetere un compito due, tre o più volte, fino a ottenere il risultato desiderato. Il “rolling wave planning” può essere particolarmente utile in situazioni in cui è difficile raccogliere informazioni sul progetto o cambia molto rapidamente (per esempio, operando in contesti di emergenza o ad alto rischio). In queste situazioni, come vengono raccolte nuove informazioni, si identificano vincoli, requisiti, rischi, opportunità, ipotesi e dipendenze aggiuntivi. Cambiamenti significativi in una qualsiasi di queste aree, che si verificano durante il ciclo di vita del progetto, possono far scattare la necessità di cambiare uno o più elementi del piano di implementazione. Il “rolling wave planning”, tuttavia, non è limitato esclusivamente ai contesti d'emergenza. Un'organizzazione che utilizza un criterio di questo tipo nei suoi development project è l'Inter-­
American Development Bank. Ciascuno dei suoi progetti è approvato attraverso una proposta pluriennale, tuttavia ai destinatari del progetto è richiesto di presentare dei piani operativi per ogni anno di attività del progetto. Questi piani annuali servono non solo per assicurare stime precise e pertinenti, ma anche come momenti decisionali per valutare se continuare con il progetto come originariamente concepito nel piano pluriennale o se è necessario ridefinirlo. Il processo di revisione e approvazione per i piani annuali è un'opportunità per verificare le ipotesi su cui si è basato il design iniziale del progetto, confermare la disponibilità delle risorse necessarie, valutare il contesto e i rischi e monitorare la logica verticale del progetto. Guida al PMD Pro 50 2.2.4. F ASE 4: IMPLEMENTAZIONE DEL PROGETTO Figura 27: Fase di Implementazione del Progetto Il lavoro quotidiano di realizzazione di un progetto consiste nel guidare e gestire la realizzazione del piano di implementazione. Questa operazione può essere relativamente semplice oppure può diventare complicata in base alla natura del progetto. Come in tutte le fasi di Project Management raggiungere il successo durante la fase di implementazione è sia arte (gestione delle risorse e del team, comunicazione chiara) che scienza. Nella sua forma semplice, la responsabilità del Project Manager è di implementare il piano. Ciò nonostante, con un’analisi più accurata, diventa chiaro che il Project Manager deve applicare una serie di competenze tecniche per raggiungere il successo. Queste competenze tecniche sono: • Gestione dei problemi • Gestione delle risorse • Gestione dei controlli interni 2.2.4.1. Gestione dei problemi Nel mondo della box si dice: ‘tutti hanno un piano…finché non si viene colpiti’. La stessa dinamica può essere applicata nella gestione di un progetto. Come un pugile sul ring, la vita del Project Manager è rischiosa e complicata. Anche con un piano ben dettagliato e complessivo, ci può essere un ‘colpo’ (problema) che potrebbe mettere alla prova l’implementazione del progetto. Come un buon pugile, il Project Manager deve imparare a gestire problemi, analizzare situazioni complicate e adattare il piano in modo tale che rifletta la realtà più recente. Un problema è una decisione, una situazione o una questione non risolta che avrà impatti anche significativi sul progetto e che il team potrebbe non riuscire a risolvere nell’immediato. La gestione dei problemi consiste nell’avere un processo di identificazione e gestione delle problematiche fino a che non vengano risolte. La risoluzione dei problemi spesso va oltre la responsabilità del team. Nonostante ciò, anche se il problema deve essere risolto ad un livello più alto o necessiterà il Guida al PMD Pro 51 coinvolgimento di altre risorse, ha comunque sempre bisogno di essere analizzato e identificato dal Project Manager. Il Project Manager deve essere pronto lungo tutta la fase di implementazione del progetto e deve dedicare risorse per la risoluzione del problema. La gestione delle problematiche è uno sforzo collaborativo. Ogni risorsa è quindi responsabile delle seguenti attività: • Identificazione del problema;; • Contribuire alla risoluzione del problema (Nota: l’esperienza insegna che spesso le risorse più vicine al progetto conoscono meglio come risolvere il problema. Quindi il lavoro del Project Manager consiste nel creare un ambiente di lavoro nel quale ogni membro sia in grado di risolvere il più alto numero di problemi in base alle responsabilità e competenze);; • Riferire al Project Manager le problematiche più rilevati il prima possibile. Nonostante la gestione delle problematiche richieda collaborazione, il Project Manager è il responsabile ultimo della gestione (ricordate che nel diagramma di RACI c’è un solo responsabile per ogni attività). Avere una buona gestione del problema è un aspetto cruciale per la comunicazione e per il rafforzamento del processo all’interno del team. Se il problema non viene risolto, le conseguenze saranno: • Incapacità di rispettare i tempi, i costi del progetto e il suo svolgimento programmato;; • Scarsa qualità del progetto;; • Cattiva reputazione presso i donatori o le comunità interessate, etc;; • Discussioni a valle dell’implementazione;; Il Project Manager deve gestire tutti i processi della gestione del problema: 1 2 3 4 Identificazione e tracciatura dei problemi – identificare questioni, decisioni e altri problemi prima che questi possano influenzare il progetto. L’identificazione e tracciatura dei problemi è strettamente collegata alla gestione del rischio (come è dettagliato nel capitolo relativo al Monitoraggio, Valutazione e Controllo di questo documento) per cui la fase di implementazione e quella di monitoraggio, valutazione e controllo sono strettamente collegate e lavorano in parallelo. Analisi del problema – la conoscenza del problema è sufficiente per capire le conseguenze future dei piani di azione progettati al fine di risolverli. Comunicare il problema – comunicare la problematica al corretto livello organizzativo aiuta a risolvere il problema. È anche importante comunicare come e quando il problema è stato risolto. Controllo del problema – il Project Manager è responsabile della creazione di un ambiente nel quale il team e i collaboratori possano portare avanti azioni risolutive in modo efficace ed efficiente. Il processo di controllo del problema è collegato alle attività di monitoraggio, valutazione e controllo e dovrebbe includere la tracciatura di un piano per la risoluzione dei problemi. Lo strumento più importante è la ‘Tabella dei Problemi’ la quale raccoglie le problematiche, descrive il loro stato corrente e identifica chi è il responsabile di tale problema. La ‘Tabella dei Problemi’ può assumere Guida al PMD Pro 52 diverse forme, da cartaceo ad un database integrato. Un esempio di formato può essere la tabella sotto: Figura 28: Tabella dei Problemi Riferimento al Problema Riportato da Descrizione Data Assegnato a Segnalazione Data Assegnazione Stato Data Stato Risoluzione Ricordatevi che un sistema di gestione dei problemi è molto costoso, se non impossibile da implementare. È normale accettare un ragionevole livello di imperfezione basato sul calcolo del trade-­off tra valore e costo, beneficio, rischio e tempo. 2.2.4.2. Gestione delle risorse L’importanza di una gestione accurata delle risorse non può essere sottovalutata. I Project Manager lavorano in team e spesso riescono a raggiungere il loro obiettivo attraverso un lavoro di impegno, collaborazione e somma di diversi contributi delle risorse che formano il team. Come risultato la gestione del team può diventare il lavoro più importante e difficile per un Project Manager. Quando si pensa ad un Project Manager particolarmente capace nella gestione del team si tende a concentrarsi sulle competenze ‘soft’ di gestione delle risorse. Questi sono i Project Manager che risultano essere più efficaci nel motivare, dare forza ai membri del team, comunicare la prospettiva del progetto, riconoscere il raggiungimento di obiettivi, nell’ascoltare, nel guidare dando l’esempio, nel risolvere i conflitti e nel costruire fiducia. Tutte queste competenze ‘soft’ sono collegate a capacità interpersonali del Project Manager e sono estremamente importanti per il successo del progetto. Inoltre, il Project Manager dovrebbe impegnarsi ad aumentare la propria capacità di: guidare, motivare, mediare, comunicare e incoraggiare il team. Questo non significa che non ci devono essere anche competenze ‘hard’ nella gestione delle risorse. Un piano di progetto che sia chiaro non si può basare solo sulle capacità interpersonali per garantire il successo nella gestione delle risorse, anzi un piano deve identificare le attività in modo chiaro e concreto per garantire una gestione proattiva del team. Tali attività si realizzano durante la fase di implementazione e includono: • Reclutamento del personale – il team leader deve essere trasparente nell’identificazione del sistema di reclutamento dei candidati, intervistandoli, definendo criteri di selezione e infine selezionando le risorse che compongono il team. • Definire le Job Description dello staff – le job description includono la lista dei doveri, ruoli e responsabilità dei membri del team;; non sono solo usate in fase di reclutamento, orientamento e gestione dello staff ma anche per valutare i membri del team. Guida al PMD Pro 53 • Definire l’organigramma del progetto – l’organigramma del progetto rappresenta le relazioni gerarchiche tra i vari componenti del team. • Sviluppo dello staff – quali capacità sono necessarie? Quali corsi sono necessari? Sono richieste delle certificazioni? • Condurre valutazioni delle prestazioni – consiste nel condurre valutazioni formali o informali sui membri del team. Dopo aver analizzato le informazioni il Project Manager può identificare e risolvere problemi, ridurre conflitti e migliorare il lavoro del team. • Definire le norme di comunicazione del team – come un leader il Project Manager deve stabilire concretamente un piano di comunicazione (attraverso incontri, lavori di gruppo, blog, ecc…) che permetta al team di condividere informazioni o lavorare attivamente all’identificazione di problemi e conflitti e ad interagire concretamente nel risolvere tali problemi. 2.2.4.3. Gestione dei controlli interni Uno dei compiti del Project Manager è quello di monitorare le risorse più preziose che sono state dedicate alla conduzione del lavoro. Un sistema di controllo interno potrebbe essere creato per assistere il Project Manager in questo compito, garantendo un uso responsabile delle risorse del progetto. I processi di controllo interno dovrebbero essere progettati con l’obiettivo di: • Promuovere l’efficacia e l’efficienza delle operazioni;; • Incrementare l’affidabilità dei risultati di progetto;; • Promuovere il rispetto di leggi e regolamenti;; • Proteggere le risorse organizzative sia fisiche (es. proprietà e macchinari) che intangibili (es. proprietà intellettuale, reputazione);; • Ridurre il rischio di frode e corruzione. I controlli interni includono i processi attraverso i quali le risorse dell’organizzazione sono dirette, monitorate e misurate. Essi giocano un ruolo importante nel prevenire e difendere da frodi e proteggere le risorse dell’organizzazione, sia fisiche (es. proprietà e macchinari) che intangibili (es. reputazione o proprietà intellettuale come i marchi). A livello organizzativo, l’obiettivo del controllo interno si riduce all’affidabilità del report finanziario, dei resoconti sul raggiungimento di obiettivi strategici o operativi e al rispetto di leggi e regolamenti. Una componente chiave per l’organizzazione di un progetto è la creazione di controlli interni che portino al successo la fase di implementazione attraverso un sistema di supporto amministrativo e logistico. Le aree che beneficiano del controllo interno sono: • Capacità e sistema di risorse umane ü Le politiche sulle risorse umane sono documentate e in accordo con le leggi locali e con i regolamenti dell’organizzazione? ü Esiste un sistema di rilevazione delle presenze, di mappatura delle performance e di identificazione dei ruoli? • Approvvigionamento ü Esiste un sistema di selezione dei fornitori? ü Esiste un criterio di selezione dei fornitori? ü Esiste un sistema di gestione dei fornitori? Guida al PMD Pro 54 ü Esiste un sistema simile per la gestione dei consulenti? • Finanziario ü Esiste un sistema di gestione della cassa? Gestione delle spese? Reportistica finanziaria? ü C’è una separazione delle responsabilità per i ruoli finanziari? • Magazzino ü Esiste un sistema per l’identificazione e il monitoraggio del magazzino? ü Esiste un sistema per l’utilizzo/trasferimento/smaltimento delle giacenze di magazzino successivamente alla chiusura del progetto? • Contratti e accordi ü Esiste un sistema di gestione delle donazioni? ü Esiste un sistema di gestione delle relazioni con le organizzazioni di implementazione? • Infrastrutture ü Esiste un sistema di comunicazione (telefoni, internet, radio ecc…)? ü Esiste un sistema di gestione dei veicoli e dei trasporti? • Protocolli di sicurezza ü C’è la necessità di misure di sicurezza particolari? Programmi di accompagnamento, altro? • Gestione della flotta ü Esiste un registro che controlla l’uso dei veicoli di servizio? • Gestione delle informazioni ü È stato istituito un registro elettronico o cartaceo? ü Esistono politiche o standard per la gestione delle informazioni? ü Documenti, contratti e ricevute sono accessibili in modo tale da soddisfare le richieste dell’Audit? Riassumendo, è importante riconoscere che i controlli interni possono assicurare (non in senso assoluto) il raggiungimento degli obiettivi dell’organizzazione. Un eccessivo o un carente sistema di controllo riduce la produttività, aumenta la complessità del sistema, incrementa il tempo richiesto per completare i processi e non aggiunge valore alle attività. Esso inoltre aumenta efficacia ed efficienza nel raggiungimento degli obiettivi del progetto e aiuta a proteggere le risorse e i lavoratori. Guida al PMD Pro 55 2.2.5. FASE 5: MONITORAGGIO, VALUTAZIONE E CONTROLLO Figura 29: Monitoraggio, Valutazione e Controllo di un Progetto Anche i progetti ben concepiti, pianificati nella loro interezza, dotati di risorse e meticolosamente eseguiti, si troveranno ad affrontare delle sfide. Queste sfide possono manifestarsi in qualsiasi momento della vita del progetto, e il team di progetto deve lavorare per riesaminare costantemente design, pianificazione e attuazione per confermarne la validità e determinare quando devono essere prese azioni correttive nel caso in cui la performance del progetto si discosti significativamente dal suo design e dal suo piano. Questo è lo scopo della Fase di Monitoraggio, Valutazione e Controllo. Non a caso, le tre categorie principali di attività che si svolgono durante la fase di monitoraggio, valutazione e controllo sono: • • • Monitoraggio del Progetto Valutazione del Progetto Controllo del Progetto Queste attività hanno lo scopo di verificare costantemente e continuamente il progetto, svolgendosi attraverso la sua intera durata (da qui il motivo per cui il modello del PMD Pro include la fase di monitoraggio, valutazione e controllo come sfondo che si estende dai primi compiti della fase di Identificazione e Design, attraverso tutto il suo percorso sino alle ultime attività della fase di Transazione di Fine Progetto). Ad esempio, le prime iterazioni degli indicatori di progetto sono sviluppate già durante la fase di Identificazione e Design;; il piano di monitoraggio si sviluppa in fase di Pianificazione;; delle visite di controllo sono condotte durante la fase di Implementazione, e molte attività di valutazione sono svolte durante la Fase di Transazione di Fine Progetto. 2.2.5.1. Distinguere Monitoraggio, Valutazione e Controllo Prima di esaminare nel dettaglio ciascuna delle tre categorie di attività della Fase di Monitoraggio, Valutazione e Controllo, è prima di tutto importante distinguerle tra loro. Il monitoraggio dei progressi traccia il lavoro operativo del progetto. Questo risponde a domande quali "le attività si sono concluse come previsto?" "Gli Output attesi, sono stati prodotti?" "Il lavoro Guida al PMD Pro 56 del progetto procede come pianificato?" Fondamentalmente, si tratta di un processo passivo, che non attua cambiamenti. Tuttavia, indica al responsabile del progetto la performance in termini di denaro, tempo, rischio, qualità, e nelle altre aree di avanzamento del progetto. In sostanza, gli obiettivi, i tempi e le attività di monitoraggio sono più facilmente identificabili tramite la seguente tabella: Figura 30: Il Cosa, Come, Quando e Perché del Monitoraggio Cosa Una revisione continua di avanzamento del progetto a livello di attività e di output che permette di identificare le necessarie azioni correttive Perché Analizzare la situazione corrente Identificare le problematiche e trovare le soluzioni Individuare le tendenze e i modelli Mantenere le attività di progetto nei tempi previsti Misurare i progressi rispetto agli output Prendere decisioni in merito alle risorse umane, finanziarie e materiali Quando Continuamente Come Visite sul campo Dati registrati Rapporti Esaminando gli indicatori presenti nel quadro logico, le attività di monitoraggio sullo stato di avanzamento corrispondono principalmente ai due livelli minori (attività e output). La seguente tabella fornisce alcuni potenziali indicatori di monitoraggio provenienti da tre diverse aree programmatiche d’intervento (agricoltura, micro finanza e acqua). Figura 31: Esempi di indicatori di Monitoraggio Output – Prodotti o servizi tangibili Attività -­ lavori o azioni adottate per l'attuazione degli interventi di progetto Agricoltura Numero di gruppi di agricoltori creati -­ Competenze acquisite dai partecipanti ai corsi di formazione Numero di missioni presso comunità agricole Numero di sessioni di formazione organizzate Micro finanza Numero di beneficiari che ricevono e usano correttamente il credito Numero di beneficiari che partecipano a programmi di risparmio Numero di missioni presso i villaggi Numero di sessioni di formazione bancarie WASH Numero di nuovi sistemi idrici installati e correttamente funzionanti Numero di comunità organizzate per l'installazione di sistemi idrici -­ Competenze acquisite dai partecipanti ai corsi di formazione La Valutazione del progetto tende a concentrarsi sui progressi del monitoraggio ai livelli più alti del quadro logico -­ cioè sui risultati del progetto. Le valutazioni tendono ad approfondire domande come: "Il progetto è riuscito a raggiungere i suoi risultati?" "Il progetto contribuisce al raggiungimento degli obiettivi?". I dati di valutazione vengono raccolti e analizzati meno frequentemente, e spesso richiedono un intervento più formale, solitamente fornito da consulenti tecnici o valutatori esterni, per indicare i risultati del progetto. Guida al PMD Pro 57 Figura 32: Esempi di indicatori di valutazione Obiettivi -­ 'I risultati del progetto contribuiscono a un maggiore impatto nelle comunità?' Agricoltura Percentuale di famiglie che producono sufficiente cibo per sopperire ai periodi di carestia Diminuzione in percentuale di bambini malnutriti Risultati – I risultati Percentuale di famiglie del progetto che adottano tecniche rispecchiano gli output migliori pianificati? Percentuale di ettari lavorati con tecniche migliori Micro finanza Aumento del reddito netto delle famiglie Variazioni positive dei modelli di consumo domestici WASH Riduzione dell’indice di infettività e della mortalità per malattie legate all'acqua Percentuale di famiglie con un aumento del capitale circolante Percentuale di famiglie con fornitura di acqua potabile Aumento del consumo di acqua pro capite * Nota -­ Mentre i progetti sono tenuti a contribuire al raggiungimento degli indicatori a livello dell’obiettivo generale, NON è responsabilità del progetto ottenere (o monitorare) l’obiettivo generale. Il Controllo richiede la creazione di sistemi e di processi decisionali per la gestione degli scostamenti tra i piani di progetto (in termini di scope, costi, tempi, ecc.) e la realtà di attuazione del progetto. Questo implica anche lo stabilire come gestire le varianze di progetto, e le sue modifiche, oltre al come documentarle e comunicarle agli stakeholder. Il piano di Monitoraggio e Valutazione del progetto Un elemento cruciale di un piano di attuazione completo è il piano di monitoraggio e valutazione, che identifica il sistema per il monitoraggio e la misurazione dei progressi, delle prestazioni e dell'impatto. Il momento opportuno per svilupparlo è in seguito all’approvazione del finanziamento, ma prima dell'inizio delle attività. Tuttavia, il lavoro preparatorio che contribuirà alla definizione del piano dovrà iniziare molto prima. Una progettazione ben fatta rende più facile creare e allineare i sistemi di valutazione e di monitoraggio. Il Piano di Monitoraggio e Valutazione amplia gli indicatori di avanzamento iniziali, previsti Guida al PMD Pro Il Project Management è iterativo! 2.2.5.2. 58 Il legame tra il Quadro Logico e il Piano di Monitoraggio e Valutazione Come indicato nel modello delle fasi di progetto PMD Pro, la Fase di Monitoraggio, Valutazione e Controllo si estende per tutto il ciclo di vita del progetto. Il Quadro Logico è il primo passo su cui soffermarsi per sviluppare un minuzioso piano di monitoraggio e valutazione. Gli indicatori e gli strumenti di verifica che sono inclusi nel quadro logico, in definitiva, diventeranno le basi per un intero piano di monitoraggio e valutazione del progetto. nel quadro logico e nella proposta di progetto, e fornisce ulteriori dettagli per ognuno dei livelli del quadro logico. Anche se il formato adottato può variare, questo, solitamente, comprende le seguenti informazioni: • • • • • • • Quali indicatori sono monitorati e valutati? Quali informazioni sono necessarie per controllare l’indicatore? Quali sono le fonti delle informazioni? Quali sistemi di raccolta dati sono appropriatati? Chi si occupa della raccolta delle informazioni? Ogni quanto le informazioni sono raccolte? Chi riceverà e utilizzerà i risultati? Mentre ci sono molte considerazioni (bilancio, risorse, requisiti dei donatori, ecc.) da tenere in conto al momento di individuare i dati da raccogliere nel piano di monitoraggio e valutazione, la considerazione più importante dovrebbe essere quella relativa all’utilità dei dati. Al momento dell’individuazione degli indicatori, il team di progetto dovrebbe sempre chiedersi "Cosa può dirci questa informazione? " e "Nel processo decisionale, quali sono i miglioramenti nel processo decisionale che è possibile ottenere da questi dati?" Figura 33: Esempio di un piano di Monitoraggio e Valutazione di progetto Gerarchia Definizione dei termini principali Indicatori Informazioni necessarie Origine dei dati Metodi di raccolta dei dati Chi raccoglie i dati Obiettivi Risultati Output Attivitá Input* Frequenza di raccolta Utilizzatori * Si noti che alcuni piani di monitoraggio e di valutazione, non solo monitorano il progresso delle attività, dei risultati, degli output e degli obiettivi relativamente alla loro coerenza con il quadro logico, ma anche degli input necessari per l’attuazione delle attività del progetto. Il metodo di raccolta dei dati, relativi agli indicatori, dipenderà da molteplici criteri, due dei quali sono i seguenti: Che tipo di dati il progetto sta cercando di raccogliere? ü I metodi quantitativi si concentrano sull'ampiezza dell'intervento, fornendo informazioni oggettive e affidabili che consentano la generalizzazione dei risultati a una popolazione più ampia. Il metodo quantitativo più comunemente utilizzato è un questionario standardizzato che viene somministrato a un campione casuale di singoli o famiglie all'interno di una fascia di popolazione. ü I metodi qualitativi si concentrano sull’interazione diretta e approfondita con i partecipanti, fornendo dati ricchi e dettagliati. I metodi qualitativi comunemente utilizzati includono tecniche Guida al PMD Pro 59 di valutazione partecipative rurali, gruppi di discussione, interviste a comunità o a informatori chiave, e l'osservazione. Qual è il livello accettabile di costi e di complessità per la raccolta dei dati? ü Il costo e la complessità della raccolta di dati possono variare notevolmente in base al metodo utilizzato per raccogliere le informazioni. Il grafico sottostante mette a confronto diversi metodi di raccolta dati (quantitativi e qualitativi), in termini di costi e complessità. Figura 34: Compromesso tra costo e complessità dei dati del monitoraggio Indipendentemente dal formato finale che un progetto impiega per stabilire il suo piano di monitoraggio e valutazione, questo dovrebbe almeno includere sei elementi essenziali: Figura 35: I sei elementi di un sistema di monitoraggio Indicatori Cronogramma e bilancio Personale e partner Ciclo completo dei dati Gestione dei dati Collegamento gerarchico Guida al PMD Pro Chiaramente definiti Riferibili a standard Misurati sistematicamente Tempo e risorse assegnati alle attività di monitoraggio Programmazione dettagliata dei processi per la raccolta, la revisione, la sintesi, l’analisi e il feedback dei dati Responsabilità di monitoraggio chiaramente identificate Competenze Pianificazione delle attività di monitoraggio con la comunità Rafforzare la capacità dei membri della comunità sui sistemi di monitoraggio Utilizzo di tecniche di monitoraggio partecipative Raccolta e verifica Trattamento dei dati Includere un ciclo completo per la gestione dei dati 1. Raccolta;; 2. Revisione;; 3. Sintesi;; 4. Analisi;; 5. Valutazioni Esistono, e vengono utilizzate, delle procedure per assicurare l'integrità e la corretta archiviazione dei dati. Il sistema di monitoraggio è legato al livello superiore gerarchico del progetto / programma. 60 Il monitoraggio dell’avanzamento E del rischio di progetto Il Project Management è completo! Mentre l'attenzione del Piano di Monitoraggio e di Valutazione si concentra sul monitoraggio dell’avanzamento del progetto rispetto agli indicatori in ciascuno dei livelli del quadro logico, il team di progetto deve anche monitorare il rischio di progetto per tutta la sua durata. Il monitoraggio del rischio, in confronto al monitoraggio dello stato di avanzamento implica il sorvegliare costantemente l'orizzonte del progetto e anticipare la possibilità che qualcosa possa andare male, o non evolva come previsto. Il Project Manager deve sorvegliare continuamente e in modo esaustivo i rischi che hanno il potenziale per minacciare il successo del progetto, e controllare queste minacce durante tutta la sua durata. La pratica della gestione del rischio è una delle sei discipline di gestione dei progetti, che vengono trattate più ampiamente nel terzo capitolo di questo manuale. 2.2.5.3. Approcci alla valutazione di progetto Durante la pianificazione delle attività di valutazione dei progetti da includere nel piano di monitoraggio e valutazione, le organizzazioni devono scegliere il proprio metodo di valutazione in base ai loro obiettivi di apprendimento. I tre approcci di valutazione maggiormente utilizzati nel development sector sono le valutazioni finali, valutazioni intermedie, e le valutazioni ex post. Valutazione Finale: sono spesso richieste dal donatore o previste dalle politiche interne delle development organization;; sono effettuate verso la fine del progetto. Le domande più comuni possono includere: ü ü ü ü Il progetto è riuscito a realizzare i risultati, gli obiettivi e l’impatto desiderato? Il progetto è stato pertinente, efficace ed efficiente? Il progetto ha il potenziale per essere sostenibile nelle sue azioni e nel suo impatto? La teoria espressa nel quadro logico, è stata confermata? Valutazioni Intermedie: offrono il vantaggio di rispondere a molti degli stessi interrogativi posti attraverso le valutazioni finali, ma offrono anche la possibilità di fornire suggerimenti per migliorare l'efficienza e l'impatto del progetto mentre le attività sono ancora in corso. Valutazioni ex-­post: esaminano l'impatto di un progetto in un determinato periodo successivo al suo completamento, a volte un anno dopo la chiusura ufficiale. Chiamata anche valutazione d'impatto sostenibile, una valutazione ex-­post indica la misura in cui i risultati e gli impatti del progetto vengono ottenuti tramite la gestione diretta da parte dei beneficiari. Il risultato di una valutazione ex-­post può essere un modo particolarmente valido di usare i risultati di un progetto per promuovere un miglior approccio di sviluppo. Ad esempio, una relazione ex post è stata utilizzata da Guida al PMD Pro 61 una development organization per contribuire a convincere un donatore a sostenere delle classi di alfabetizzazione e di aritmetica di base all'interno di un programma di micro finanza. 2.2.5.4. Controllo Quando rifletteva sull'evoluzione, Charles Darwin osservò che 'non è la più forte delle specie che sopravvive, né la più intelligente, ma la più sensibile al cambiamento'. Allo stesso modo, i responsabili di progetto devono anche riconoscere che il cambiamento sarà spesso, o quasi sempre, necessario per il successo dei loro progetti. Questi cambiamenti sono normali, accettabili e (a volte) addirittura auspicabili. I piani di progetto non sono destinati a essere documenti statici, e un accurato impegno deve essere investito per garantire che non siano considerati immutabili, o eccessivamente difficili da cambiare. I team di progetto devono ricordare che un piano di attuazione è "un mezzo per ottenere uno scopo", e non uno scopo esso stesso! Più specificamente, la squadra ha bisogno di riconoscere le insidie che si presentano quando i piani di progetto sono trattati come documenti statici, tra cui: • • • • Incapacità di riconoscere che i piani originali sono imperfetti;; Paura di comunicare ai donatori esterni (e interni) che il piano originale non è più attuabile;; Mancanza di volontà di rivedere i documenti originali per sviluppare un nuovo e più appropriato piano;; e Mancanza di chiarezza circa quale processo deve essere seguito per aggiornare i documenti di progetto. Tuttavia, quando si tratta di gestire le richieste di modifica, il Project Manager deve soppesare abilmente due considerazioni. Da un lato, i documenti di progetto non dovrebbero essere considerati immutabili indipendentemente dal cambiamento della realtà progettuale;; d'altra parte, si deve prestare attenzione a non apportare modifiche sbadatamente o senza rigore. Per gestire questo equilibrio, i responsabili di progetto devono stabilire delle norme che consentano loro di integrare in modo flessibile, quando necessario, delle modifiche, ma hanno anche bisogno di fare in modo che le modifiche progettuali proposte siano gestite attraverso un processo rigoroso e integrato di controllo del cambiamento, che assicuri che tutte le modifiche siano: a. regolate da un processo formale di gestione del cambiamento;; b. analizzate al fine di garantire che le implicazioni del cambiamento siano accuratamente ponderate;; c. documentate per illustrare il loro impatto su tutti gli elementi integrati del progetto;; d. comunicate ai principali stakeholder. 2.2.5.5. Modifiche al progetto: tolleranze ed escalation delle problematiche Una questione che deve essere risolta nel gestire le problematiche è se la modifica proposta del progetto sia nell’ambito dell’autorità del responsabile di progetto. Se la problematica e la modifica proposta ricadono all'interno della sua autorità, il passo successivo sarà -­per lui-­ quello di intervenire per risolvere il problema. Se invece il Project Manager non ha l'autorità per attuare il cambiamento proposto, questo ha invece bisogno di essere sottoposto al livello competente. Guida al PMD Pro 62 La sfida sarà quella di distinguere quali questioni e quali reazioni proposte siano nell’autorità del Project Manager, e quali non lo sono. Per rispondere a questa domanda, è importante esplorare in primo luogo il tema della tolleranza e identificare i livelli di tolleranza fissati per il progetto. Le tolleranze di progetto definiscono i limiti delle prestazioni entro i quali il Project Manager può mantenere l'autonomia. Quelle più comuni sono le tolleranze positive (i valori che possono essere superati). Tuttavia, le tolleranze negative sono altrettanto importanti. Ad esempio, trovarsi sotto budget significa che dei fondi disponibili sono inutilmente bloccati per un periodo di tempo. Le tolleranze sono una parte fondamentale dell’autonomia lavorativa di un Project Manager. Avere una tolleranza significa che il responsabile del progetto possiede una certa flessibilità per quanto riguarda i vincoli progettuali. In pratica, questo vuol dire che il progetto può essere un po’ sopra o un po’ sotto certi parametri e non deve continuamente rifarsi al comitato di progetto (o al donatore) per richiedere l'approvazione di certe modifiche. Le due tolleranze più adottate sono quelle concernenti il budget e il tempo, ma possono essere di svariati tipi: Tolleranza di tempo -­ la quantità di tempo per cui il completamento del progetto può essere posticipato o anticipato rispetto alla data prevista. Tolleranza di costo -­ la percentuale, o l’importo, per il quale il progetto può essere superiore o inferiore al budget previsto. Tolleranza di scope -­ è misurata come variazione concordata dalla descrizione del prodotto;; qualsiasi potenziale variazione deve essere documentata nella Product Breakdown Structure Tolleranza di rischio -­ fornisce un punto di riferimento oltre il quale i rischi dovrebbero essere gestiti dal comitato di progetto. Tolleranza di qualità – sono gli intervalli che definiscono le prestazioni accettabili per un prodotto, documentati nella Product Breakdown Structure Tolleranza dei benefici – gamme di prestazioni accettabili a livello di risultati. Nel corso della fase di Set Up del progetto, dovrebbero essere stabilite le tolleranze per identificare i parametri entro i quali la consegna può essere ritenuta accettabile: i livelli generali di tolleranza di progetto. Le tolleranze devono essere stabilite e approvate dalla struttura di governo del progetto. Questa potrebbe essere il comitato di progetto, tuttavia, se non esiste alcun comitato, le tolleranze dovranno essere stabilite dal promotore del progetto o dal donatore. Se in qualsiasi momento durante il monitoraggio, il Project Manager percepisce che un livello di tolleranza potrebbe essere stato superato, si dovrebbe consultare l'organo di governo del progetto. Mappatura del processo di approvazione delle richieste di cambiamento Una volta chiarito quale livello di autorità è richiesto per decidere su una richiesta di modifica del progetto, il passo successivo è quello di rispondere alle seguenti domande: • • La richiesta di variazione è ammissibile in virtù degli accordi già esistenti? Gli impatti del cambiamento richiesto sulla pianificazione, risorse, costi, e qualità sono stati esaminati e approvati? Guida al PMD Pro 63 • • Gli stakeholder sono stati consultati per quando riguarda la modifica proposta? Il piano di progetto globale e integrato è stato modificato per documentare le implicazioni della modifica proposta? Ci sono le risorse (tempo, materiali, fondi, risorse umane) per attuare la modifica proposta? • Una mappa di richiesta di cambiamenti come quella presentata nella Figura 36 può fornire una risorsa utile per l'identificazione e il controllo del processo di gestione delle modifiche al piano di progetto. Figura 36: Mappa illustrativa del processo di richiesta di cambiamenti di progetto Tuttavia, nonostante uno schema come quello della Figura 36 sia utile, è estremamente importante riconoscere che la mappa varierà notevolmente a seconda della struttura di governance del progetto, dei rapporti con i donatori, dei requisiti contrattuali, dei partner di attuazione, etc.. É importante quindi personalizzare il diagramma secondo la realtà del proprio contesto operativo. Guida al PMD Pro 64 Indipendentemente dal tipo di schema, è particolarmente importante che le eventuali modifiche siano gestite in modo integrato. Ossia assicurando che le eventuali revisioni del piano di progetto identifichino chiaramente le implicazioni che un cambiamento può avere sulle altre sezioni del piano della gestione del progetto. Le persone che hanno familiarità con ciascuna delle aree del piano di progetto (portata, costi, tempi, rischi, approvvigionamenti, qualità, ecc.) dovranno necessariamente valutare l'impatto delle modifiche proposte sull'intero piano di progetto. Quando si è convenuto che la modifica proposta sarà utile e che le implicazioni siano accettabili, la richiesta di modifica potrà essere approvata. Una volta approvato il piano di progetto rivisto, questo dovrebbe essere comunicato a tutto il team di progetto in modo che tutti possano lavorare seguendo il nuovo piano aggiornato. Utilizzare modelli di pianificazione iterativi per gestire il cambiamento Questo scenario vi suona familiare? Un progetto triennale è entrato nel secondo anno della sua fase di attuazione. In generale, il progetto sta andando bene. La logica d’intervento del progetto è ancora valida, e i risultati finali sono ancora raggiungibili. Vi è, tuttavia, un problema rilevante con il piano di progetto. La realtà sul campo del secondo anno di attuazione ha poco in comune con quanto era stato previsto quando, 20 mesi prima, i piani di progetto sono stati sviluppati. E’ sempre più chiaro che certe previsioni di bilancio sono state significativamente sottovalutate, mentre altre voci non sono più necessarie a causa di modifiche nei ruoli dei partner d’attuazione. Mentre queste sfide possono essere affrontate attraverso una combinazione di gestione dei rischi e di richieste di cambiamenti, alcuni progetti le affrontano attraverso una strategia di progettazione iterativa. In un modello iterativo di pianificazione, il piano di progetto iniziale viene stabilito nel momento in cui il progetto è approvato. Tuttavia, riconoscendo che la realtà sul campo di attuazione del progetto può/possa variare nel corso del tempo, i dettagli del piano di progetto non vengono riportati che in seguito. Invece di creare un singolo piano di attuazione dettagliato, i progetti sottostanno a un modello di pianificazione che comprende aggiornamenti periodici dei piani di attuazione. Nei development project, questi piani periodici di solito sono fatti su base annuale e sono chiamati Annual Operating Plans. In un progetto di emergenza, il lasso di tempo per un piano aggiornato potrebbe essere molto più breve. ECHO, la direzione generale per gli Aiuti Umanitari e la Protezione Civile della Commissione Europea, per esempio, permette un aggiustamento progettuale ogni tre mesi, sulla base di un’intesa che stabilisce chi deve autorizzare le modifiche per ciascuno dei livelli dello schema logico. Con l'adozione di un approccio di progettazione iterativa, le organizzazioni hanno una maggiore flessibilità per adattarsi al cambiamento. Il team di progetto è in grado di rivedere il piano di attuazione del progetto all'inizio di ogni periodo stabilito, al fine di: 1. Confermare la logica, i rischi, le opportunità, le ipotesi e i vincoli. 2. Aggiornare e rivedere le attività, i tempi e le risorse del progetto. 3. Garantire che le attività d’intervento si concentrino su come affrontare i rischi e le questioni che pongono le minacce più immediate al successo del progetto. Guida al PMD Pro 65 2.2.6. FASE 6: TRANSIZIONE DI FINE PROGETTO Figura 37: Fine del Progetto Un progetto, per definizione, è uno sforzo temporaneo, con una fine e un inizio ben definiti (normalmente vincolati dai tempi, ma anche da fondi o deliverable). La natura temporanea dei progetti li differenzia dai normali processi di business di una organizzazione (detti anche “processi continuativi”, che si riferiscono a un lavoro funzionale ripetitivo, permanente o semi-­permanente, che realizza prodotti o servizi). Nel development field, tuttavia, si possono trovare progetti che sono rimasti operativi per anni – con una fase del progetto che continua il lavoro della fase precedente. Questa osservazione sott’intende la realtà di come la fine di un progetto nel development sector è spesso meglio descritta come una fase di transizione piuttosto che come una chiusura rigorosamente definita. In pratica, esistono quattro scenari possibili di transizione di fine progetto, nel development sector. Questi quattro scenari sono presentati nella tabelle seguente: * La conclusione potrebbe includere un trasferimento delle attività di progetto ad un partner locale, un’istituzione o una comunità. Sfortunatamente la transizione è di grande importanza ma spesso sottostimata e/o le vengono assegnate poche risorse. Con la necessità di lavorare su nuovi progetti e riassegnare le risorse in Guida al PMD Pro 66 altre attività, la via più pratica per assicurare una completa chiusura del progetto è di includerla nel piano stesso del progetto. 2.2.6.1. Gestire la strategia di fine progetto Come citato in precedenza nella discussione della Fase di Pianificazione, un piano di progetto per essere completo deve includere un piano di transizione di fine progetto, il quale descriva come il progetto potrà evolvere una volta completato e al contempo come potrà assicurare il perseguimento degli obiettivi. Un piano di transizione potrebbe includere diversi scenari che considerino gli eventuali rischi e potrebbe anche allocare ulteriori risorse nel caso in cui non si riesca a concludere il progetto completamente. Nel development sector la transizione è di particolare importanza, in quanto i risultati ottenuti devono esser sostenibili dopo la fine del progetto. Uno strumento usato per pianificare la sostenibilità in essere del progetto è la Matrice di Pianificazione della Transizione, descritta sotto. Figura 38: Matrice di Transizione del Progetto Componente Domande chiave Principi Guida Problematiche 1. Piano per la transizione dalle prime fasi del progetto ü Che tipo di transizione è prevista? ü Quali sono i tempi e i parametri di riferimento? v Bilanciare gli impegni con la flessibilità;; v Fornire un tempo sufficiente per sviluppare le capacità. 2. Sviluppare partenariati e collegamenti locali ü Stiamo selezionando il partner giusto? ü Che apporto danno i partner? 3. Costruire capacità locali organizzative e umane ü Quali capacità sono necessarie? ü Quali capacità esistono? Ø Valutazione e revisione durante il progetto Ø Trasparenza;; specialmente riguardo i fondi Ø Diversità: potrebbero essere necessari altri input Ø Obiettivi chiari e condivisi Ø Costruire sulle capacità presenti, se possibile Ø Creare situazioni che supportino le capacità 4. Mobilitare le risorse locali ed esterne ü Quali input sono necessari per mantenere i servizi? ü I benefici possono essere mantenuti senza continui input? ü Quali sono gli elementi chiave del progetto? ü Quali elementi sono dipendenti da altri? 5. Trasferimento progressivo di alcune attività 6. Permettere ai ruoli e alle relazioni di evolvere dopo la transizione ü Quali tipi di supporto post progetto (consulenza, tutoraggio, assistenza tecnica, ecc.)? ü Come sarà finanziato il supporto post progetto? Guida al PMD Pro 67 Ø Trovare risorse localmente, se possibile Ø Portare sempre più le risorse esterne sotto controllo locale Ø Flessibilità;; la sequenza progressiva può cambiare durante l’implementazione Ø Evitare lo slittamento dei risultati attesi includendo un’espansione, estensione o ridefinizione del progetto. v Allineare le esigenze e gli obiettivi dei diversi stakeholder v Supportare i partner locali v Definire il monitoraggio in modo da tenere traccia dei miglioramenti nelle capacità v Fornire incentivi e trattenere il personale con esperienza v Difficoltà a trovare risorse locali adeguate o disponibili v Altri finanziatori non coinvolti dagli obiettivi originari v Dare abbastanza tempo, durante il progetto, per iniziare a vedere l’impatto e gli outcome desiderati v Disponibilità di fondi per il supporto continuativo post progetto v Disponibilità di personale che possa dedicare sufficiente tempo ed energie al supporto post progetto. 2.2.6.2. Verifica dello Scope e accettazione dei risultati Quando un progetto entra nella sua fase finale il Project Manager dovrebbe contattare gli attori interni ed esterni al progetto (compresa la direzione di progetto e lo sponsor) in modo tale da verificare che lo scope sia stato raggiunto e che i risultati siano soddisfacenti. Spesso la verifica degli obiettivi è svolta per ogni valutazione finale del progetto. Comunque in situazioni dove una valutazione finale non venga svolta, la verifica dei risultati prodotti dovrebbe essere svolta in ogni caso. Questo si svolge solitamente attraverso un processo a due fasi. • Il gruppo d’implementazione confronta il lavoro eseguito con il piano di implementazione. Ci potrebbero essere ad esempio attività rimandate e rimaste incompiute. • Incontro con gli attori coinvolti (fondatori, comunità) per: ü Revisionare i lavori compiuti rispetto al piano e successivamente ottenere una documentazione formale di accettazione;; ü Assicurarsi che essi siano soddisfatti, non solo sotto l’aspetto tecnico del progetto, ma anche in riferimento agli obiettivi generali (questo è spesso più una percezione che non l’effettivo raggiungimento di risultati). 2.2.6.3. Chiusura amministrativa, finanziaria e contrattuale Se il progetto fosse controllato due anni dopo la chiusura cosa succederebbe? Esiste un sistema che assicuri che gli elementi amministrativi, finanziari e contrattuali del progetto siano completati? Questi sistemi sono critici non solo perché aiutano ad evitare problemi con i controlli del progetto, ma anche perché riducono i rischi di controversie con fornitori, lavoratori e finanziatori in riferimento allo stato dei resoconti. Essi dovrebbero essere identificati in modo da assistere ognuna delle tre aree di attività seguenti: Chiusura contrattuale • Sono chiusi tutti i contratti? Fornitori? Sub fornitori? Finanziatori? Altri? Società committenti? • Il finanziatore ha revisionato e accettato i risultati del progetto? Chiusura finanziaria • Sono stati ricevuti tutti i fondi? • Sono stati trasferiti tutti i crediti ad altri progetti o commesse? • Tutti i pagamenti sono stati saldati? Chiusura amministrativa • I contratti del personale del progetto sono stati chiusi oppure le risorse sono state allocate su nuovi progetti? • Le risorse, i veicoli, gli uffici sono stati riutilizzati, venduti o trasferiti? • I documenti di chiusura e i report del progetto sono stati completati? • L’archivio del progetto è stato aggiornato? Guida al PMD Pro 68 2.2.6.4. Apprendimento Finale Gli insegnamenti sono la memoria storica di un’organizzazione. Idealmente, durante la Fase di Inizio del Progetto o durante i momenti in cui si effettua una valutazione del progetto, il team dovrebbe sviluppare una lista di ‘insegnamenti’ che tracci tutto ciò che viene appreso. Quando il progetto entra nella fase di chiusura è importante assicurare che gli insegnamenti siano adeguatamente dettagliati, archiviati e facilmente accessibili. Inoltre è molto importante che il Project Manager divulghi gli insegnamenti a chi né può beneficiare. Senza un sistema di codificazione degli insegnamenti dei progetti, l’organizzazione “reinventerà la ruota” ogni volta che decide si implementare un progetto simile.. I finanziatori sono spesso interessati che le conoscenze vengano divulgate in tutto il settore in modo tale che nuovi progetti, da loro finanziati, possano beneficiare degli insegnamenti già sperimentati. Oggi giorno le ONG pubblicano spesso documentazione riassuntiva di tutte le esperienze raccolte nei vari progetti. Il riesame degli insegnamenti è un’attività facile e veloce per identificare e registrare nuove conoscenze. Il riesame è inoltre facile da organizzare e implementare. Durante la revisione alcune domande possono aiutare i partecipanti a capire se quanto pianificato è coerente con quello che sta succedendo: • Cosa abbiamo deciso di fare? • Cosa abbiamo raggiunto? Maggiore attenzione ai fatti rispetto alle opinioni. • Cosa è andato veramente bene? Ancora una volta, guarda ai fatti. Perché è andato bene? Confronta i piani con la realtà. • Cosa poteva andare meglio? Cosa ci ha ostacolato nel fare di più? • Cosa possiamo imparare da questo? Il vantaggio del riesame degli insegnamenti è che ci permette di recuperare informazioni utili in modo relativamente veloce, senza spendere risorse onerose. Esso deve essere veloce e disponibile e non focalizzato su discussioni o ragionamenti complicati. Lo scopo primario è di fornire assistenza nelle decisioni strategiche, politiche e operative in riferimento a programmi di investimento futuri o in corso. 2.2.6.5. Celebrare i risultati Così come è fondamentale riconoscere l’inizio di un progetto lanciando le attività pianificate, un Project Manager dovrebbe anche celebrare in modo appropriato e comunicare la fine del progetto attraverso: • il riconoscimento degli sforzi dei membri di progetto;; • il riconoscimento del contributo di tutti gli attori convolti nel progetto;; • l’apprezzamento verso gli individui o i gruppi che sono stati di importanza cruciale per il raggiungimento del successo del progetto. Il riconoscimento dei risultati all’interno dell’organizzazione e con il mondo esterno può aiutare a stabilire relazione pubbliche e facilitare future opportunità di lavoro. Guida al PMD Pro 69 3. : LE DISCIPLINE DEL PROJECT MANAGEMENT Non c'è una singola strada per la gestione dei progetti. Ogni progetto è unico, con i propri obiettivi e il proprio contesto;; le proprie risorse, relazioni e sfide. Nonostante questo, mentre non esistono due progetti uguali, gestire con successo un progetto richiede che tutti i team di progetto applichino, attivamente e in modo completo, un insieme diversificato di discipline di project management, lungo l'intera vita del progetto. Il PMD Pro identifica sei discipline di project management che sono particolarmente importanti nella gestione dei progetti nel development sector. Queste includono: • Scope Management • Time Management • Project Resource Management • Risk Management • Project Justification Management • Stakeholder Management La Sezione 3 della guida esplora ciascuna di queste aree disciplinari, fornendo dettagli su strumenti e meccanismi che sono particolarmente utili quando ci si trova a gestire ciascuna area disciplinare. Inoltre, riconoscendo che ogni disciplina ha interazioni con tutte le altre, la Guida esplora anche approcci integrati alla gestione delle discipline, allineandole in modo opportuno e collegandole tra loro. Guida al PMD Pro 70 3.1. D ISCIPLINA 1: S COPE M ANAGEMENT La leggenda Americana del baseball, Yogi Berra, disse: “Se non sai dove stai andando, finirai da un’altra parte.” Questo è il motivo per cui la gestione dello scope è così importante per progetti di successo. Un ben definito scope, non solo comunica al team di progetto dove andrà, ma spiegherà anche come il progetto intende arrivarci. Fondamentalmente, la gestione dello scope si articola in due componenti: Scope di prodotto – Include tutti i deliverable del progetto richiesti, incontrando le specifiche concordate. (Cosa sta per essere consegnato?) Scope di progetto – Include tutto il lavoro richiesto per consegnare lo scope di prodotto. (Come verranno creati e consegnati i deliverable?) • • Aspettative non chiare: Ambiguità nello scope portano a confusione fra gli stakeholder del progetto circa quanto atteso – e quanto non atteso – da esso. Uno scope identificato chiaramente aiuta gli stakeholder a condividere una comune comprensione dei benefici del progetto e del lavoro richiesto per consegnare con successo i risultati e gli output del progetto. Gli stakeholder devono avere chiaro al 100% lo scope così da garantire che essi non abbiano aspettative errate o irrealistiche circa quanto i prodotti/servizi forniranno. Una nota di avvertimento sulla Definizione dello Scope La gestione di progetto è completa (e dettagliata) Entrambe queste componenti sono critiche per il successo del progetto e devono essere gestite diligentemente. In assenza di una chiara definizione dello scope, possono sorgere i seguenti problemi: Nonostante il Project Manager possa essere tentato di pensare che i documenti sviluppati durante la fase di Identificazione e Design (logical framework, Proposta di Progetto, ecc.) siano sufficienti a definire lo scope del progetto, raramente questo è il caso! Ricorda, il logical framework e la Proposta di Progetto sono redatti per scopi molto diversi. Nonostante essi siano adatti ad identificare la logica di alto livello del progetto ed a vendere il progetto ai donatori, essi non sono progettati per guidare il team nell’implementazione di quest’ultimo. Prima che inizi il reale lavoro del progetto, il Project Manager deve confermare che lo scope sia omnicomprensivo e dettagliato. Una speciale attenzione deve essere posta nell’assicurare che l’informazione circa il lavoro indiretto del progetto sia incluso nello scope, per esempio, i dettagli riguardanti l’approvvigionamento, il coordinamento, la comunicazione, le risorse umane e la gestione del rischio. Stime non accurate: Gli errori nella definizione dello scope si riscontrano spesso in progetti nei quali non si è identificato tutto il lavoro necessario per il loro completamento (in alternativa, uno scope sviluppato male può risultare in del lavoro non necessario incluso nel progetto). Questi errori di valutazione possono sovrapporsi, sfociando in un’errata stima di tempi e costi. Questo fallimento nella Guida al PMD Pro 71 stima può essere visibile in slittamenti della schedulazione e di conseguenza in uno sforamento dei costi. • Scope Creep – L’obiettivo di definire lo scope è quello di descrivere in modo chiaro e di ottenere consenso circa i confini del lavoro e i deliverable di progetto. Il fallimento nel controllo di tali limiti conduce al cosiddetto “scope creep” – causa principale dei ritardi del progetto e potenzialmente di progetti “senza fine”. Per evitare questo fenomeno, lo scope deve essere documentato e gestito lungo tutta la durata del progetto attraverso un processo formale di cambiamento. 3.1.1. DEFINIRE LO SCOPE DI PRODOTTO E DI PROGETTO Riconoscendo la sottile ma significativa differenza fra i due elementi dello scope del progetto, esaminiamo queste due definizioni più da vicino: -­ LO SCOPE DI PRODOTTO descrive i deliverable del progetto. Una esaustiva definizione dello scope di prodotto sarà una non ambigua e omnicomprensiva descrizione e specificazione dei prodotti/servizi che stanno per essere consegnati. Il livello di dettaglio fornito nello scope di prodotto dovrebbe essere sufficiente a replicare ad ogni potenziale futuro disaccordo su quanto è programmato. Lo scope di prodotto è customer-­oriented, il che significa che la sua definizione deve essere concordata dai clienti (i finanziatori e gli utilizzatori) dei deliverable di progetto. -­ LO SCOPE DI PROGETTO descrive il lavoro del progetto. Una esaustiva definizione dello scope di progetto fornisce una omnicomprensiva e dettagliata descrizione del lavoro che deve essere completato per consegnare i deliverable di progetto. Lo scope di progetto è provider-­
oriented, il che significa che dipende da quello che il project team decide che sarà il modo migliore per consegnare lo scope di prodotto. Una volta che il team di progetto ha definito lo scope di prodotto e di progetto, Il Project Manager dovrebbe rivedere la definizione dello scope per i seguenti elementi: • Completezza – il team ha esattamente capito cosa gli si chiede di consegnare? • Ambiguità – i diversi stakeholder hanno la stessa comprensione di ciò che viene chiesto? • Risorse – la richiesta di risorse è compresa e definita? • Consenso – il team ha concordato i deliverable? • Fattibilità – il team è in grado di produrre quanto concordato? • Accettazione – ognuno (membri del team e stakeholder) è d’accordo su ciò che costituisce un prodotto accettabile? Guida al PMD Pro 72 3.1.2. STRUMENTI PER DEFINIRE LO SCOPE DI PROGETTO La Work Breakdown Structure è lo strumento principale che i Project Manager utilizzano per definire lo scope di progetto. Essa è una scomposizione gerarchica del lavoro di un progetto. In parole povere, la WBS organizza lo scope del progetto in una struttura o gerarchia di 'work packages' Il formato della WBS normalmente assume uno di questi due stili: Il formato grafico fornisce un layout visivo di facile lettura dei livelli relativi al lavoro di un progetto. Questa immagine consente ai partner e al personale di vedere le relazioni tra gli elementi della WBS e come le componenti più piccole del progetto si aggregano in quelle più grandi. Inoltre, il formato grafico può essere facilmente sviluppato in un contesto di gruppo usando post-­it cartacei facilmente spostabili da un luogo all'altro. Ai fini della presentazione della proposta, questo formato facilita inoltre la regolazione della profondità di dettaglio a seconda delle differenti tipologie di pubblico. Il formato indentato ha il vantaggio di essere più facile da creare e modificare su un computer. È anche un formato più facile da caricare su strumenti software di gestione progettuale come ad esempio Microsoft Project, oltre che per la stampa di report e il monitoraggio computerizzato. Partendo dal formato grafico di Error! Reference source not found., la WBS in Error! Reference source not found. fornisce un esempio di come sarebbe il parziale sviluppo della WBS per il progetto Delta River nel formato indentato. Figura 39: WBS del progetto Delta River (parziale sviluppo in formato grafico) Guida al PMD Pro 73 Figura 40: WBS del Progetto Delta River (sviluppo parziale in formato indentato) 1. Sistema di gestione dei rifiuti fecali 1.1. Sistema di monitoraggio del livello fecale 1.2. Campagne di pubblica consapevolezza 1.3. Costruzione della latrina 1.3.1.Preparazione pre-­costruzione 1.3.1.1. Approvazione ministeriale del piano 1.3.1.2. Approvazione delle specifiche ingegneristiche 1.3.1.3. Studio delle acque sotterranee 1.3.2.Preparazione dei proprietari delle case 1.3.3.Approvvigionamento 2. Sistema di gestione dei rifiuti domestici 2.1. Ecc. Connettere il LogFrame con la WBS La gestione di progetto è integrata Mentre la WBS è uno strumento centrale dei Project Manager nella maggior parte dei settori, essa è relativamente sconosciuta nel development sector. Quando i Project Manager inizieranno ad adottare la WBS come strumento per identificare i prodotti / servizi e il lavoro del progetto, ci saranno un certo numero di domande che inevitabilmente si presenteranno. Si noti che le principali categorie di lavoro nella WBS sono coerenti con i contenuti del logical framework. Tuttavia, la WBS includerà un livello di completezza e di dettaglio che è spesso assente dal logical framework. Ci potrebbero essere ulteriori categorie di lavoro incluse nella WBS, che non sono state incluse nel logical framework. La WBS è destinato anche a fornire il livello di dettaglio che spesso manca nel logical framework. Che Formato? Alla fine, le preferenze che il team di progetto e gli stakeholder mostreranno circa l'interpretazione delle informazioni sono quelle che con estrema probabilità influenzeranno la scelta del formato della WBS. Alcune persone possono elaborare i dati più facilmente quando li visualizzano graficamente, altri preferiscono le liste. A volte è una buona idea creare entrambi. Spesso il formato grafico è sviluppato per primo come esercizio di gruppo. Un formato con l’indentatura viene poi sviluppato durante l’implementazione del piano di progetto per la sua gestione. Chi dovrebbe essere coinvolto? È importante la partecipazione di tutto il team di progetto e dei principali stakeholder durante il processo di definizione della WBS. Nessuna persona o piccolo gruppo di persone può avere conoscenze sufficienti a fornire il livello di completezza e di dettaglio richiesto nella WBS. Ad esempio, si raccomanda che i membri del team responsabili delle attività di gestione e approvvigionamento finanziario del progetto siano coinvolti non solo per dare informazioni sulla qualità della WBS, ma anche per fare in modo che venga garantita la comprensione delle attività per le quali sono responsabili. Quanti Livelli? Le WBS possono differire anche in modo significativo nel numero di livelli di cui sono composte. Nonostante non ci siano regole che fissano un numero esatto di livelli, la WBS deve Guida al PMD Pro 74 essere sufficientemente dettagliata in modo che i sub-­deliverable possano essere controllati e monitorati con successo. Cosa dovrebbe essere incluso nella WBS? E' fondamentale che la WBS sia omnicomprensiva, comprendendo tutte le attività necessarie per il successo del progetto. Ciò include le attività di gestione che sono spesso omesse nelle proposte di progetto e nei logical framework (progetto di pianificazione e controllo, formazione degli stakeholder, comunicazioni, reporting, approvvigionamento e attività di transizione al termine del progetto). Verbi o Nomi? Comunemente, la WBS è definita come un diagramma orientato al prodotto, il che significa che in essa le attività sono scritte in forma di sostantivi. Tuttavia, alcune impostazioni della WBS consentono alle attività di essere orientate al processo, ovvero poste in forma verbale. Dal punto di vista del PMD Pro, le attività della WBS possono essere scritte sotto entrambe le forme, sostantivi o verbi. Ciò che è importante è garantire che i contenuti della WBS siano completi e dettagliati. Una WBS ben costruita può essere utilizzata per: • Guidare il processo di identificazione e sequenzializzazione delle attività;; • Fornire una base per: o una stima accurata della durata del progetto;; o una stima accurata del costo del progetto;; o una stima accurata delle risorse (mezzi, persone, forniture, materiali da costruzione);; • Identificare le richieste dei dipartimenti, della subfornitura, dei servizi dei fornitori;; • Comunicare e concordare la definizione del prodotto e del progetto con gli stakeholder;; • Visualizzare la gerarchia del lavoro necessario per completare un progetto e indicare le interfacce tra gli elementi;; • Delegare i pacchetti di lavoro ai membri del team di progetto, ai partner di implementazione o ai fornitori. Guida al PMD Pro 75 3.2. D ISCIPLINA 2: G ESTIONE DEI T EMPI Completare un progetto rispettando le scadenze prefissate è una delle più grandi sfide nell’ambito del project management. Per poter gestire accuratamente la risorsa “tempo”, il Project Manager deve avere l’abilità di sviluppare precise schedulazioni da implementare successivamente lungo il ciclo di vita del progetto Il primo passo per una gestione di successo del tempo è un’adeguata pianificazione, che includerà i seguenti passi: La Gestione dei Tempi non avviene nel vuoto! Il Project Management è integrato! Immaginate un progetto con problemi di pianificazione. Qual è stato il problema? Sono state allocate al progetto risorse insufficienti per il raggiungimento dei deliverable? Le attività chiave del progetto sono state completate in ritardo? La pianificazione del progetto è stata fatta su una stima delle risorse irrealistica? Ricordate il Triangolo dei Vincoli di progetto? I lati del triangolo sono tutti connessi tra loro ed è impossibile gestire uno dei vincoli chiave del progetto (tempo/schedule, costi/risorse, scope/qualità) senza prendere in considerazione gli altri. Per esempio, se il vostro progetto ha un vincolo di tempo inflessibile – “DEVE essere concluso in un anno!” – allora fate in modo che quanto richiesto dallo scope e le risorse (denaro, persone e materiali) siano pianificati in modo da garantire uno schedule realistico. Al contrario, se uno degli altri vincoli di progetto è bloccato (Budget? Scope? Entrambi?), allora bisogna riconoscere che probabilmente queste limitazioni impatteranno sullo schedule del progetto. Definizione delle Attività – identificare le attività che devono essere svolte per produrre i deliverable di progetto. Sequenzializzazione delle Attività – identificare le relazioni esistenti tra le diverse attività previste. Stima delle risorse richieste dalle Attività – Allocare la quantità e la qualità di risorse necessarie e disponibili per poter svolgere l’attività pianificata. Stima dei tempi delle Attività – Stimare il tempo richiesto per il completamento delle attività. Sviluppo dello Schedule – Creare una pianificazione del progetto basandosi sulle attività, le relative sequenze, le durate, le risorse e i vincoli. 3.2.1. D EFINIZIONE DELLA ATTIVITÀ E DELLA LORO SEQUENZA Partendo dalla WBS, il team di progetto sviluppa una lista delle attività che descrive e raccoglie tutte le attività previste per il raggiungimento dello scopo del progetto (o relativamente a un work package specifico). Successivamente il project team crea un diagramma di rete che esprime graficamente la sequenza, le relazioni e le dipendenze tra le varie attività presenti nella WBS. Ritornando al caso di studio Delta River Project, la figura 41 offre una visione parziale del diagramma di rete relativo alla costruzione di una latrina. È da notare come il diagramma in figura 41 è incompleto perché sono mancanti le unità di tempo in relazione ad ogni attività di progetto. Guida al PMD Pro 76 Ogni riquadro del diagramma di rete identifica una singola attività del progetto. Questi box sono collegati con frecce che indicato la relativa dipendenza, specificando quindi come le attività di progetto sono relazionate alle altre secondo una linea temporale oltre ad illustrare la sequenza con cui devono essere svolte. In alcuni casi la sequenza è lineare, che significa che un’attività per iniziare deve aspettare il completamento della precedente, in altri invece i cammini si sviluppano parallelamente, permettendo così ad attività di essere svolte indipendentemente. Figura 41: Utilizzo di un diagramma di rete per pianificare la sequenza di attività necessarie alla costruzione di una latrina Dal grafico si possono ricavare diverse informazioni: -­ Il project team dovrà attendere il completamento della “copertura” per poter procedere all’installazione. -­ Il project team non deve necessariamente aspettare il completamento della “copertura” per poter scavare il “buco” della latrina. -­ Le attività di formazione possono essere svolte indipendentemente dalle attività di costruzione della latrina. NB: se l’addestramento fosse stato richiesto come prerequisito per le attività di costruzione, il riquadro riguardante l’attività di formazione avrebbe dovuto essere posizionato su un ramo differente del cammino. 3.2.2. STIMA DELLE RISORSE PER OGNI ATTIVITÀ Una volta identificata la sequenza delle attività, è logico procedere alla stima delle durate delle attività. Tuttavia bisogna procedere prima con la stima delle risorse per poter passare solo successivamente a quella delle attività. Il legame esistente tra la stima delle risorse e la stima delle durate è di primaria importanza. Tutti sanno che scavare una fossa con una persona richiederebbe più tempo che svolgere la stessa attività con 5 persone. Inoltre la durata della stessa attività può variare notevolmente in base al macchinario utilizzato. Riassumendo, le risorse hanno un ruolo primario. Sono uno dei fattori principali che influenza la stima della durata di un progetto. Inoltre le decisioni riguardanti l’allocazione delle risorse sono da prendere prima che possano essere fatte le stime della durata delle attività. Le decisioni relative alla Guida al PMD Pro 77 quantità e qualità di risorse da impegnare in una data attività sono influenzate da diversi fattori, tra i quali: Tempo – Se l’intervallo di tempo disponibile per il progetto è ridotto, sarà opportuno allocare staff, materiali ed equipaggiamenti di primo livello con lo scopo di rispettare i vincoli di tempo. Al contrario se l’intervallo di tempo del progetto non è vincolante, sarà sufficiente utilizzare risorse di minor livello. Budget – se il budget è una risorsa scarsa, potrebbe essere opportuno dedicare al progetto un mix di risorse a basso costo, privilegiando per esempio lavori manuali rispetto a macchinari specifici. Ovviamente questa decisione avrà effetti negativi sulla durata del progetto stesso. Regole e policy dell’organizzazione – spesso i progetti devono rispettare vincoli relativi alla regolamentazione del lavoro e/o policy interne che possono limitare la pianificazione delle attività (ore giornaliere, giorni alla settimana, vacanze annuali, policy familiari). Questi vincoli influenzano la disponibilità delle risorse e quindi la stima dei tempi. Altri fattori che influenzano la disponibilità delle risorse – Altri fattori possono influenzare la disponibilità delle risorse e quindi aver effetti sulla durata delle attività. Alcuni esempi sono: Vincoli Meteorologici: durante il periodo del raccolto, è difficile ottenere la collaborazione di una comunità rurale. Vincoli sui Materiali: spesso materiali di scarsa qualità rendono necessarie strategie alternative che richiedono maggior tempo. Vincoli Logistici: progetti d’aiuto per situazioni d’emergenza, possono influenzare l’accesso a infrastrutture, anche in questo caso influenzando negativamente la durata del progetto. Vincoli sulle Risorse Umane: la difficolta d’accesso a risorse qualificate rende arduo il completamento di attività dall’elevata complessità, estendendo così la durata del progetto. 3.2.3. STIMA DELLA DURATA DELLE ATTIVITÀ Una volta completata la stima delle risorse, il diagramma di rete deve essere rivisto aggiungendo la stima delle durate di ogni attività. Tornando al progetto Delta River, la Figura 42 mostra il diagramma di rete aggiornato con i vincoli di tempo. Figura 42: Utilizzo di un Diagramma di Rete per sequenziare le attività di costruzione di una latrina Guida al PMD Pro 78 A questo punto il diagramma di rete è completo e può essere utilizzato dal team di progetto per identificare: Il cammino critico – Il cammino critico è la sequenza delle attività che determinano la minima durata richiesta per il completamento delle attività di progetto. Nella Figura 42, il cammino critico è la sequenza di box colorati in azzurro. Perché questa sequenza di attività? Perché questa sequenza rappresenta il percorso più lungo tra la data di inizio e fine del progetto, in questo caso 23 giorni. In questo esempio il cammino critico mostra come sia impossibile completare il progetto in meno di 23 giorni senza che cambino altri vincoli di progetto illustrati nel triangolo dei vincoli di progetto (risorse/obiettivi/qualità). Float (o Slack) di progetto – all’interno della disciplina del project management, il float o slack è la quantità di tempo che un’attività può ritardare senza influenzare la data di completamento del progetto. Tornando all’esempio della costruzione della latrina, lungo il cammino critico il float è pari a zero. Invece l’attività “Costruzione della copertura” può essere ritardata di 8 giorni senza impattare la pianificazione di progetto. Lo stesso vale per le attività di formazione che possono essere posticipate di 20 giorni senza influenzare l’avanzamento del progetto. Se un’attività che non fa parte del cammino critico viene posticipata oltre la sua data di “late start”, vuol dire che il cammino critico determinato nel diagramma di rete non è più valido. 3.2.4. SVILUPPO DELLO SCHEDULE Basandosi sulle stime effettuate lungo i punti precedenti, il team di progetto a questo punto può procedere con la pianificazione del progetto. Nel development sector, lo strumento preferito per questa attività è il diagramma di Gantt. Pianificare e implementare un progetto è molto più semplice se scomposto in piccole sezioni illustrandone le interdipendenze, i processi in parallelo e se si tiene traccia della pianificazione d’insieme. Il diagramma di Gantt utilizza delle barre per rappresentare graficamente le attività di un progetto, includendo la data di inizio, di fine e la durata attesa. La complessità e la comprensività di un diagramma di Gantt può variare notevolmente. Da notare come la preparazione di questo diagramma sia piuttosto semplice come altrettanto ne è l’utilizzo. Tuttavia bisogna notare come le attività di progetto possono essere complesse e possono quindi esistere notevoli interdipendenze tra queste. Un metodo per mantenere semplice il diagramma di Gantt anche quando la pianificazione di progetto è complessa, è includere diversi livelli nell’illustrazione: un primo livello corrisponde a un diagramma di Gantt generale dell’intero progetto, senza scendere eccessivamente nel dettaglio delle singole attività. I dettagli invece vengono elaborati successivamente in una pianificazione di dettaglio. Il diagramma di Gantt generale non solo si distinguerà da quello di dettaglio per la profondità di analisi, ma anche per il suo obiettivo. Infatti il diagramma generale sarà estremamente utile per la discussione dell’avanzamento di alto livello con gli stakeholder di progetto (membri del Comitato di progetto, stakeholder principali, donatori, ecc). Invece i diagrammi dettagliati sono meno focalizzati sulla comunicazione di alto livello, ma sono incentrati sulla pianificazione operativa, l’implementazione e il controllo delle singole attività. I principali beneficiari dei diagrammi di Gantt di dettaglio sono il team di progetto, i partner per l’implementazione e i fornitori coinvolti nella realizzazione delle singole attività e deliverable. Guida al PMD Pro 79 Figura 43: Diagramma di Gantt per il progetto “Delta River” In questo esempio i singoli pacchetti di lavoro, le attività e le sotto attività sono rappresentate lungo l’asse y, mentre la variabile tempo lungo l’asse x. Le barre illustrano quando un’attività dovrebbe iniziare e finire. Le barre bianche forniscono un sommario delle sotto attività che la compongono. Le barre più scure rappresentano le attività completate, mentre le più chiare mostrano le attività che devono ancora essere compiute. Da notare come il diagramma di Gantt sia fatto per essere aggiornato e non solo per offrire una fotografia della pianificazione di progetto: infatti il team di progetto potrà tener traccia dell’andamento delle singole attività e verificare quale attività sia completa e quale da completare. Il diagramma di Gantt del progetto “Delta River” è stato creato utilizzando un apposito software. Tuttavia possono essere utilizzate soluzioni alternative, e possono essere facilmente disegnati a mano, sia su carta che su lavagne. Un’altra opzione per la creazione del diagramma di Gantt è utilizzare software di project management come Microsoft Project o simili, facilmente rintracciabili sul mercato. Bisogna tener in considerazione diversi fattori per decidere quale strumento sia più adatto alla creazione del diagramma di Gantt. I principali sono: • • • • Possibilità di accesso a software specifici Disponibilità di computer e adeguate competenze informatiche Il valore e la complessità del progetto Flessibilità nel gestire cambiamenti e aggiornamenti del progetto Spesso i criteri che guidano la scelta nei development project sono il punto uno e due: infatti nel development sector spesso la disponibilità di software specifici e le abilità richieste non sono disponibili. Per questo motivo il team di progetto tende a gestire i propri progetti utilizzando fogli di calcolo o diagrammi disegnati manualmente. Bisogna considerare che software di project management offrono degli strumenti specifici che possono rivelarsi estremamente utili per progetti ad elevata complessità e/o rischio. Ad esempio diagrammi di Gantt disegnati con software dedicati permettono al team di progetto di: Guida al PMD Pro 80 • Identificare le dipendenze di progetto – identificare automaticamente quale attività deve essere completata per permettere l’inizio di un’altra. Inoltre individuare gli impatti che i ritardi su singole attività hanno sulla pianificazione di progetto. • Monitorare l’avanzamento della attività sul cammino critico – segnalare automaticamente quando un’attività critica è in ritardo segnalando i possibili impatti sulla pianificazione di progetto. • Collegare il diagramma di Gantt con altri strumenti chiave di gestione di progetto – identificare e segnalare automaticamente quando modifiche del diagramma di Gantt richiedono l’aggiornamento di altri documenti di progetto come il Budget o la WBS. 3.2.5. GESTIRE LO SCHEDULE DEL PROGETTO I Project Manager dovrebbero monitorare la pianificazione regolarmente così da garantire che il calendario di progetto rimanga allineato. Se si verificano scostamenti, il team di progetto avrà a disposizione diverse opzioni per riportare il progetto alla pianificazione iniziale. Ad esempio le scadenze possono essere ritardate o lo scopo di progetto può essere ridimensionato. Tuttavia, se le scadenze del progetto sono fisse e lo scope non può essere modificato, può non essere possibile per il progetto rientrare nei tempi attraverso le tecniche tipiche di gestione dello schedule. In alternativa, in scenari dove scope e schedule sono inflessibili, si possono considerare due tecniche alternative: il “fast tracking” e il “crashing”. Il “Fast tracking” consiste nello svolgere in parallelo attività che normalmente andrebbero svolte in sequenza. Per poter trarre il maggior beneficio da questa tecnica, il team di progetto dovrà concentrarsi prima di tutto sul cammino critico, dato che offre il maggior potenziale per accelerare le tempistiche del progetto. Ad esempio nel diagramma di rete del progetto di costruzione della latrina, il piano originale prevedeva la costruzione della struttura della latrina solo DOPO che il buco fosse stato terminato. Nello scenario “fast tracking” (figura 44), il diagramma di rete (e quindi il diagramma di Gantt) è cambiato, infatti la struttura della latrina viene costruita contemporaneamente allo scavo della fossa. Completando le attività in parallelo, il cammino critico di progetto si riduce dai 23 giorni iniziali a soli 17, permettendo così il completamento del progetto rispettando le scadenze. Guida al PMD Pro 81 Figura 44: “Fast Tracking” della pianificazione del progetto “Delta River" Il "Crashing" della pianificazione consiste nel ricorrere a risorse addizionali per completare le attività lungo il cammino critico, senza però garantire la massima efficienza di progetto. Ad esempio, ipotizziamo che il piano di progetto preveda una persona che lavori 14 giorni per completare lo scavo della fossa. Per diminuire (crash) la durata dell’attività può essere allocata un’ulteriore persona all’attività, permettendone cosi il completamento in minor tempo. Bisogna tener in considerazione che raddoppiare le risorse non si traduce in un raddoppio della produttività;; spesso infatti la produttività addizionale della seconda risorsa è minore. La produttività marginale di risorse addizionali dipende da vari fattori, come ad esempio la mancanza di spazio sufficiente per permettere alle risorse di lavorare efficientemente, la mancanza di materiale aggiuntivo, ecc. Nel caso del progetto “Delta River”, aggiungere un secondo scavatore riduce il tempo dell’attività SCAVARE IL BUCO da 14 a 10 giorni, riducendo così la durata complessiva di progetto da 23 a 19 giorni. Figura 45: "Crashing" della pianificazione del progetto "Delta River" Guida al PMD Pro 82 3.3. D ISCIPLINA 3: G ESTIONE DELLE R ISORSE DI P ROGETTO Come sug gerisce il nome, la gestione delle risorse è la disposizione e la distribuzione delle risorse disponibili per un progetto. Tali risorse includono tipicamente le finanze, le forniture e l’inventario, il tempo umano, le competenze e l'input, le attrezzature e le tecnologie dell'informazione. 3.3.1. PERCHÈ É IMPORTANTE UNA EFFICACE GESTIONE DELLE RISORSE? In qualsiasi momento, un Project Manager deve sapere come destreggiarsi efficacemente tra le numerose risorse del progetto. Il manager deve sapere come creare e rispettare un budget in modo che i fondi siano assegnati dove necessario ed organizzare efficacemente lavoratori e personale di progetto in modo che le persone giuste vengano assegnate alle mansioni adeguate. Inoltre, è necessario disporre di una efficace distribuzione e flusso dei servizi, delle forniture e delle scorte, in modo che il progetto abbia accesso a ciò di cui ha bisogno, quando e dove ne ha bisogno ed al prezzo più adeguato. Collaborare con lo staff di supporto La Gestione di Progetto è Integrata! Uno dei lavori più importanti e più impegnativi per un Project Manager è quello di organizzare efficacemente ed efficientemente tutte le risorse coinvolte in un progetto. Va da sé che la complessità di questo compito dipende fortemente dallo scope e dalla natura del progetto che si ha tra le mani. Ma in tutti i casi, si tratta di un FATTORE CRITICO PER IL SUCCESSO O IL FALLIMENTO. Una delle sfide più importanti per la gestione delle risorse del progetto è garantire che il responsabile del progetto, insieme con il personale di supporto (cioè la finanza, risorse umane, IT, e di filiera) e i loro dirigenti, siano strettamente allineati e integrati. La costruzione di questo rapporto dovrebbe iniziare durante la fase di Identificazione e Design. Quando la pianificazione iniziale del progetto è formulata, il personale di supporto appropriato dovrebbe essere coinvolto nella creazione dei parametri di bilancio di alto livello, nell’individuazione delle competenze e nella specifica delle esigenze di approvvigionamento. Come progetto entra nella fase di pianificazione, il personale di supporto può essere particolarmente utile nel garantire che i formati del bilancio siano corretti, che le stime siano accurate, che l'elenco delle voci di bilancio sia globale e che il bilancio sia dettagliato. Essi garantiscono che i piani della supply chain siano accurati e che il reclutamento e lo sviluppo pianificato delle competenze sia incorporato nei piani di progetto. Più tardi, con l’ingresso del progetto nella fase di monitoraggio, valutazione e controllo, il personale di supporto sarà fondamentale per garantire che i documenti contabili del progetto siano accurati, tempestivi e utili. Solo con queste informazioni, il team di progetto sarà in grado di ottenere una piena comprensione di dove il progetto si trova per quanto riguarda il suo avanzamento. Una comunicazione efficace e fluida con i servizi di supporto è vitale per il successo del progetto. Si è spesso affermato che "la gestione del progetto è troppo importante per essere lasciata al solo personale di progetto". I membri del personale di supporto hanno competenze ed esperienze critiche. Essi hanno bisogno di essere impegnati nel progetto il più presto possibile. Il loro mancato coinvolgimento provoca solitamente pianificazioni inesatte e / o incomplete e, di conseguenza, una non adeguata implementazione e consegna. Guida al PMD Pro 83 Il PMD Pro si concentra su tre delle aree di gestione delle risorse di progetto: la gestione delle finanze, la gestione della catena di approvvigionamento e la gestione delle risorse umane. Queste tre formano il nucleo dei servizi di supporto al progetto. E 'importante che sia chiaro che la responsabilità ultima per le finanze di progetto, la supply chain e la gestione delle risorse umane è del Project Manager. Questo è vero anche se quest’ultimo non può avere la responsabilità diretta della gestione di queste tre aree. E’ compito del Project Manager assicurarsi che le finanze di progetto siano ben amministrate, che beni, servizi e materiali siano gestiti in modo efficace ed efficiente, e che il personale di progetto abbia tutte le competenze necessarie per avere successo. 3.3.2. GESTIRE LE FINANZE DEL PROGETTO Le organizzazioni del development sector di solito si affidano per i programmi di finanziamento a donatori individuali o organizzazioni -­ e si aspettano che le donazioni siano ben gestite. Esse hanno inoltre un obbligo verso le comunità e i partner a cui sono di aiuto, essendo responsabili di assicurare che le risorse ottenute per loro conto siano utilizzate in maniera ottimale al fine di massimizzare l'impatto. Per esercitare una prudente gestione finanziaria del progetto, il Project Manager dovrà sviluppare competenze in questi tre settori: • Sviluppo dei Budget • Stima dei costi • Monitoraggio di budget e spese Nella realtà, per la maggior parte dei progetti, un manager non possiederà il pieno controllo su tutti i processi finanziari. Per avere successo, egli avrà bisogno di collaborare e di coordinarsi strettamente con un Finance Manager, più una serie di altre persone in tutte le fasi del processo di amministrazione delle finanze. Tuttavia, anche se ci saranno elementi della gestione finanziaria nei quali mancherà di piena autorità e controllo sui processi, il Project Manager rimane sempre il responsabile. Queste sei aree di coordinamento e di collaborazione nel campo della finanza sono particolarmente critiche: • Accesso ai dati storici per i report finanziari • Spiegazione delle variazioni di bilancio • Emissione di assegni • Autorizzazione di spese • Gestione dei saldi di cassa • Implementazione delle politiche di acquisto Come discusso in precedenza, il mandato del Project Manager è quello di assumersi la responsabilità di garantire il successo complessivo del progetto. Nel caso degli elementi finanziari, un Project Manager deve assicurare che i ruoli e le responsabilità di tutti i soggetti coinvolti nei processi finanziari siano chiare e che i destinatari siano all'altezza dei loro impegni. Guida al PMD Pro 84 3.3.3. LO SVILUPPO DEI BUDGET Un budget è una descrizione del piano finanziario del progetto che comprende un elenco di stime di costo dello stesso. Come per tutti i componenti del piano di progetto, la chiave per budget precisi è garantire che siano completi e dettagliati. Bilanci completi -­ Tutti gli elementi del budget necessari per consegnare i prodotti ed i servizi devono essere inclusi. Come primo passo, il team di progetto ha bisogno di identificare le spese necessarie per consegnare i prodotti e i servizi di progetto. Si tratta di spese relative al lavoro diretto, inclusi gli stipendi, i veicoli, i materiali, le forniture, le attrezzature, ecc. Tuttavia, è importante non fermarsi a questo punto, ma ricordare che un bilancio globale deve anticipare anche le spese relative al lavoro indiretto. Un Project Manager deve porre una domanda importante: "Quali risorse saranno necessarie per i processi di supporto che sono vitali per il successo del progetto?" Queste ultime includono le risorse necessarie per la comunicazione, la gestione del rischio, il monitoraggio, la valutazione, i servizi di project management, la gestione delle risorse umane, i processi di appalto, l'integrazione di progetto e la sua struttura generale. Bilanci dettagliati -­ così come lo scope del progetto dovrebbe essere disaggregato per individuare le attività specifiche necessarie per implementare con successo un progetto, anche il budget deve essere trattato allo stesso modo. Mentre i bilanci di alto livello sono utili per comunicare i parametri generali alle varie parti interessate, il team di progetto richiede una identificazione più precisa e specifica dei costi al fine di implementare con successo le attività. Alcuni esempi del livello di dettaglio che deve essere raggiunto nel progetto sono: Costi di transazione: per esempio, quando si identifica il costo di approvvigionamento, il budget del team non deve limitarsi ad identificare il costo del servizio o del prodotto, ma anche i costi di gestione del processo di approvvigionamento. Il livello di dettaglio del budget potrebbe includere spese necessarie per avviare un progetto (controlli interni, sistemi di contabilità, processi di assunzione, etc…) e il costo di conclusione dei progetti (chiusura dei contratti, scioglimento dello staff, etc…). Servizi comuni: Un altro livello di dettaglio spesso mancante nei budget di progetto riguarda il costo dei servizi ad esso destinati da parte della stessa development organization. Ad esempio, il bilancio deve includere le spese per la percentuale di tempo assegnato al progetto da parte del responsabile finanziario, di un autista, del personale informatico o di altri? Se il progetto non riesce a includere un sufficiente livello di dettaglio del budget, si corre il rischio di non essere in grado di accedere alla gamma completa di servizi e alla supervisione, necessari per la realizzazione di un progetto di successo. Il formato e la struttura di un documento di budget spesso dipende dalla fonte del finanziamento del progetto. Per esempio, in situazioni in cui i development project ricevono soldi dai donatori esterni, i parametri di bilancio seguono più frequentemente le linee guida del donatore. Come risultato, i budget dei progetti variano considerevolmente per quanto riguarda il piano dei conti e dei tempi. Piano dei conti – le voci di bilancio del progetto sono raggruppate in categorie di costo che aiutano il team di progetto a individuare e analizzare le transazioni per area del programma, fonte di finanziamento, locazione, reparto, ecc. A loro volta, queste categorie di costi sono Guida al PMD Pro 85 raggruppate in sub-­elementi forniti di codici linea-­oggetto. Anche se è una pratica comune per i budget l’utilizzo dell’approccio basato sul piano dei conti che identifica tutti i conti del progetto, le categorie di costo e gli elementi della linea non sono standardizzati e variano tra i donatori, le organizzazioni di realizzazione e/o i partner di progetto. Tempificazione: tutti i bilanci devono definire il periodo temporale al quale sono riferiti. Esistono molteplici approcci alla gestione della tempificazione dei budget: Bilancio rispetto alla vita-­del-­progetto (o bilancio pluriennale) -­ Qui è sviluppato il bilancio globale per l'intera durata del progetto e serve come documento finanziario ufficiale che accompagna il piano di progetto. Budget di progetto annuale -­ Alcuni progetti adottano la prassi di rivisitare regolarmente il bilancio inerente la vita-­del-­progetto e richiedono che un team di progetto presenti un budget annuale al compimento di ogni anno del progetto. Nonostante i bilanci pluriennali tendano ad essere lo standard nel development sector, richiedere un budget annuale di progetto riduce il rischio di imprecisione sulle stime di budget basate su orizzonti pluriennali, di soffrire per la variabilità dei prezzi, o della mancanza di flessibilità per regolarsi rispetto ai cambiamenti nel contesto operativo. 3.3.4. BUDGETING BASATO SULLE ATTIVITÀ Il budget per attività si concentra sull'identificazione dei costi delle attività che si svolgono in ogni ambito di un progetto e sulla determinazione di come queste siano connesse tra loro – considerando sia il lavoro diretto che indiretto. I sostenitori considerano il budget per attività come più realistico rispetto ad altri approcci di budgeting, in quanto esso implica la comprensione di quanto le attività verranno effettivamente a costare. Se un Project Manager è in grado di sviluppare un elenco completo (sia comprensivo che disaggregato) delle attività e delle relative stime dei costi, allora un budget si rivelerà esatto. Il budget per attività offre anche maggiori opportunità per il personale di linea di mettersi in gioco, rendendone più probabile l’accuratezza. Nonostante esistano una serie di possibili formati per il budget basato sulle attività nei quali vengono aggiunti dettagli come i codici di account, i codici dei donatori, e dei costi unitari -­ tutti presentano due esigenze simili: 1) Sviluppare una lista completa di attività durante la pianificazione dello scope. 2) Capire cosa sarà necessario per eseguire ogni attività e valutare quanto costerà ognuna di esse. Con il soddisfacimento di questi due requisiti, il budget fornirà dettagli per ogni attività e mostrerà i costi associati che possono, a loro volta, essere monitorati. Se il monitoraggio mostra che le spese effettive hanno superato le stime di costo, allora un Project Manager saprà che il progetto difficilmente fornirà lo scope completo. In questo caso deve essere studiata una riprogettazione del lavoro per trovare modalità più efficaci per l’implementazione delle attività rimanenti. In alternativa, il manager può richiedere un Comitato di Progetto, o un’altra struttura di governance del progetto, per regolare lo scope. Guida al PMD Pro 86 Figura 46: Esempio di un semplice budget basato sulle Attività Activities
Q1
1.1
Establish Plannning Unit
EQUIPMENT
1. Computers
2. Fax modems
3. Office furniture
RECRUITMENT
1. Counterparts
2. Office staff
Costs per quarter
Q2
Q3
2000
500
3000
2000
800
200
800
300
Q4
Total
Activity
Total
4000
500
3000
800
300
800
300
3200
1100
11800
1.2
Establish l ink with Government
LIAISON MEETINGS
1. Prepare written presentation materials
2. Prepare video
2. Stationery
Stationary
3. Refreshments
1000
5000
1000
4000
200
100
200
100
5000
6000
400
200
11600
3.3.5. STIMARE I COSTI Indipendentemente dal progetto o dal formato del suo budget, un piano finanziario è valido solamente rispetto alle stime su cui si basa. In una certa misura, esisterà sempre il rischio associato alle stime di progetto. La stima non sarà mai una scienza esatta che produce risultati accurati al 100%. I Project Manager non possono predire il futuro. Ci saranno sempre delle variabili di progetto che esulano dal controllo del team di progetto. Eppure, mentre esistono numerose ragioni che rendono l'elaborazione di stime precise una sfida, le stime possono essere sufficientemente accurate per sostenere valide decisioni di progetto. Inoltre, ci sono delle best practice che aiutano i Project Manager a migliorare l'accuratezza delle loro previsioni di budget: 1. Scegliere il giusto approccio per effettuare la stima -­ Le stime sono normalmente sviluppate attraverso una combinazione delle seguenti tre tecniche: Le stime Top-­Down iniziano con una stima globale per il costo di un progetto e successivamente assegnano una percentuale di quest’ultima a diverse fasi o pacchetti di lavoro del progetto. Le percentuali assegnate ai componenti sono generalmente identificate da individuo/i che non hanno precedenti esperienze su progetti simili. Questo approccio alla stima tende ad essere più esclusivo e coinvolge un gruppo relativamente piccolo di persone considerate "esperti" sulla base della loro esperienza passata. Le stime Bottom-­Up non cominciano con una valutazione globale dei costi del progetto. Al contrario, le attività sono stimate e aggregate. In questo modello, le stime sono suggerite dalle persone che hanno conoscenza della realtà del progetto, e che sono spesso le stesse che saranno responsabili per la realizzazione delle sue attività (inclusi i partner, i fornitori, i membri della comunità, ecc) La stima Bottom-­Up tende a coinvolgere un numero maggiore di partecipanti e richiede uno sforzo maggiore da gestire. Hanno però più probabilità di Guida al PMD Pro 87 essere precise in quanto il personale del settore avrà probabilmente una migliore consapevolezza dei vincoli sulle risorse che incidono sulle stime dei costi. A titolo di esempio, possono sapere esattamente quanto comunità con risorse differenti sono in grado di fornire un aiuto per lo scavo di una latrina – fornendo una migliore stima rispetto al considerare che tutte le comunità siano in grado di fornire la stessa risorsa. Le stime parametriche fanno meno affidamento su persone e utilizzano invece una relazione statistica tra i dati storici ed altre variabili (ad esempio, la metratura in costruzione, i metri di strada, ecc). Le stime parametriche tendono ad essere utilizzate per progetti e componenti di progetto che producono risultati concreti (per esempio, la costruzione di infrastrutture, i servizi di spostamento per la costruzione di strade, ecc). Qui la stima è effettuata identificando i dati storici da progetti che hanno fornito output simili (per esempio, chilometri di strada, metratura in costruzione) e utilizzano questi ultimi per calcolare le stime di scope/qualità, costi/risorse, e/o di tempi/calendarizzazione. Questa tecnica può produrre livelli elevati di precisione, ma dipende dalla qualità dei dati sottostanti integrati nel modello. 2. Elaborare stime per la fase (quando possibile) -­ All'inizio dell’implementazione del progetto, i donatori spesso richiedono un impegno aziendale per la vita del budget di progetto. Nonostante questa pratica sia spesso considerata una buona strategia per gestire budget fuori controllo, essa funziona solo nella misura in cui i budget di progetto siano realistici. Spesso è difficile sviluppare bilanci accurati durante le prime fasi della vita del progetto. La realtà del contesto cambia spesso durante l'implementazione. Sorgeranno spese impreviste. Si evolverà. Prezzi e inflazione cambieranno. Per questo motivo, i team di progetto spesso preferiscono lavorare attraverso un processo di stima per fasi, che consente di sviluppare una serie di bilanci in momenti diversi lungo il calendario del progetto (quest’ultimo potrebbe essere, per esempio, una stringa di budget annuali). Questa strategia aiuta a garantire che i bilanci dei progetti siano precisi all’inizio della fase successiva del progetto. Esso fornisce anche un punto logico per l'organo di gestione del progetto per controllare la giustificazione del progetto ed assicurare che esso abbia ancora "senso" prima di dedicarvi ulteriori fondi. 3.3.6. MONITORAGGIO DELLE PERFORMANCE FINANZIARIE DEL PROGETTO Durante il monitoraggio delle performance finanziarie del progetto, la prima domanda di solito è: "Il progetto è sopra o sotto il budget?" Per rispondere a questa domanda, la maggior parte dei team di progetto utilizzano i dati di bilancio più recenti, confrontano i Costi Cumulativi Pianificati per il progetto fino ad una certa data con i Costi Cumulativi Effettivi. Sfortunatamente, questo calcolo è spesso limitato nella sua utilità. Nonostante possa fornire una fotografia della possibilità che un progetto abbia speso più o meno soldi di quanto stimato in un dato periodo di tempo, non fornisce dati utili a spiegare il perché possa esistere qualsiasi variazione. Prendete, per esempio, i dati forniti in Figura 47. La prima analisi dei dati provenienti da tre mesi di progetto indicherebbe che esso è fuori budget. Questo perché il Costo Cumulativo Previsto alla fine del mese tre (1100) è inferiore al Costo Cumulativo Effettivo (1300). Guida al PMD Pro 88 Figura 47: Budget illustrativo per un progetto di sei mesi (inclusi i costi effettivi fino al Mese 3) Attività Costi Pianificati Mese Uno Mese Due Mese Tre Mese Quattro Mese Cinque Mese Sei A 100 100 B 200 200 C 100 100 D 400 400 E 100 100 F 200 200 G 200 200 H 100 100 I 300 300 J 100 100 Costo Totale Pianificato per mese 100 300 700 300 300 100 Costo Cumulativo Pianificato 100 400 1100 1400 1700 1800 Costo Totale Effettivo per mese 150 350 800 Costo Effettivo Cumulativo 150 500 1300 Purtroppo, questo rapido calcolo non fornisce il quadro completo della situazione finanziaria del progetto. È vero che il progetto ha speso 200 (11%) in più di quanto preventivato per i primi tre mesi del progetto, tuttavia, nonostante si sia tentati di supporre che la varianza dei costi alla fine del mese tre significhi che il progetto è "fuori budget", fate attenzione a non saltare alle conclusioni! I costi superiori a quelli attesi potrebbero essere riconducibili a una delle due ragioni: • Scenario A: Da un lato, il progetto potrebbe essere più costoso di quanto inizialmente stimato. In questo caso, le attività del progetto sono in programma, ma costano di più di quanto previsto nel bilancio. Analisi: Lo scenario A è decisamente problematico. Esso indica una tendenza che, se continuasse, si tradurrebbe in un progetto che sarà al di fuori del budget. In questa situazione dovrà essere implementata un’azione correttiva per garantire che il progetto eviti buchi di bilancio. • Scenario B: D'altro canto, il progetto potrebbe stare spendendo più di quanto stimato perché in anticipo sui tempi previsti. Di conseguenza, il progetto sta spendendo più nei primi tre mesi. Guida al PMD Pro 89 Analisi: Lo scenario B non è necessariamente un problema. Sì, il progetto nello Scenario B sta spendendo più soldi al mese rispetto a quanto inizialmente previsto, tuttavia, sta anche completando più lavoro di quello pianificato. In questo scenario, il progetto ha bisogno di raccogliere ulteriori informazioni per decidere se il progetto sta spendendo più denaro di quanto non avesse previsto per la quantità di lavoro che ha completato. Nota -­ In entrambi gli scenari, il progetto avrà bisogno di assicurarsi di avere abbastanza denaro in cassa (cash flow) per continuare le operazioni poiché si stanno spendendo più soldi al mese rispetto a quanto inizialmente preventivato. Lo scenario B fornisce una interessante sfida per un team di progetto. Esso sottintende l'importante messaggio che non è sufficiente guardare solo se in un bilancio si è speso più o meno di quanto stimato in un determinato periodo di tempo. Il monitoraggio delle prestazioni finanziarie deve anche guardare a due indicatori distinti, ma collegati: il monitoraggio dei flussi di cassa e quello dei costi, attraverso l’Earned Value Analysis. 3.3.6.1. Il Monitoraggio dei costi di progetto attraverso l’Earned Value Analysis Per meglio monitorare i costi di progetto, è preferibile valutare il costo del lavoro completato durante un periodo di tempo. L’Earned Value Analysis è uno strumento che mette a confronto i costi previsti quelli effettivi per ogni attività che è stata svolta e CONTEMPORANEAMENTE il tasso di avanzamento di ogni attività rispetto a quanto previsto nel piano di progetto. Ciò significa che, al fine di condurre l’Earned Value Analysis, il Project Manager avrà bisogno di una serie più completa di dati che combini elementi sia del bilancio del progetto sia del suo calendario. La Guida al PMD Pro 90 fornisce una visione aggiornata del progetto di sei mesi introdotto in precedenza, includendo ora due nuove colonne che forniscono il costo effettivo di ogni attività e la percentuale di lavoro completato per ogni attività. Guida al PMD Pro 91 Figura 48: Esempio di bilancio per un progetto di 6 mesi (inclusi i dati dell’Earned Value) Attività Costi Pianificati Costi Effettivi Percentuale Mese Completata Uno Mese Due Mese Tre Mese Quattro Mese Cinque Mese Sei A 100 150 100% 100 B 200 200 100% 200 C 100 100 100% 100 D 400 400 100% 400 E 100 0% 100 F 200 100 50% 200 G 200 200 100% 200 H 100 50 50% 100 I 300 100 50% 300 J 100 0% 100 Costo Tot Pianificato per mese 100 300 700 300 300 100 Costo Cumulativo Pianificato 100 400 1100 1400 1700 1800 Costo Totale Effettivo per mese 150 350 800 Costo Effettivo Cumulativo 150 500 1300 Analizzando le informazioni in Guida al PMD Pro 92 , si possono trarre dai dati due importanti conclusioni: • Dopo tre mesi il progetto ha pienamente o parzialmente completato otto attività. Confrontando i costi pianificati di ciascuna di queste attività con il loro costo effettivo di esecuzione, si può dimostrare che il progetto rispetta ESATTAMENTE il bilancio in merito al lavoro svolto (Il progetto ha speso 1300 per ottenere un valore di 1300 di lavoro svolto). • Il piano di progetto prevede un valore di 1100 dal lavoro da compiere in tre mesi. Invece, è stato effettuato lavoro per 1300. Ciò significa che il progetto è del 18% in anticipo sulla schedulazione. Quali conclusioni quindi possono essere tratte da tali analisi? • Se il progetto continuasse con l’attuale tasso di avanzamento, verrà completato in anticipo;; • Se il trend del progetto non mutasse, esso rispetterebbe il budget. Si noti che le conclusioni dell’Earned Value Analysis differiscono dalle conclusioni dell’analisi sulla varianza dei costi cumulativi nella sezione precedente. Questo perché l’Earned Value Analysis sta fornendo, a livello di attività del progetto, dati più ricchi che integrano dati sullo scope, sul bilancio e il calendario. Come risultato, l’Earned Value Analysis aiuta a sottolineare che non tutti gli scenari in cui i costi cumulativi superano il budget del progetto sono "cattivi". Viceversa, non tutti gli scenari in cui i costi cumulativi di un progetto sono sotto budget sono "buoni". Il Project Manager deve esplorare ulteriormente per avere una più chiara comprensione della situazione di bilancio rispetto al completamento previsto dei deliverable di progetto. La Error! Reference source not found. fornisce una panoramica delle combinazioni di risultati che possono verificarsi quando viene condotta l’Earned Value Analysis e identifica le implicazioni dei diversi scenari. Si noti che le celle della tabella forniscono alcune combinazioni di budget/schedulazione "buone", altre "cattive" e alcune che richiedono più dati per capire lo stato del progetto. Figura 49: Combinazione dei Risultati in un’Analisi dell’ Earned Value Anticipo sullo Schedule Rispetto dello Schedule Ritardo sullo Schedule Sotto il Budget Necessari più dati Positivo Positivo Rispetto del Budget Negativo Positivo Positivo Superamento Budget Negativo Negativo Necessari più dati Nonostante la classificazione degli stati in Figura 49 sia utile, a prescindere da essa i Project Manager devono utilizzare la classificazione degli stati per iniziare un approfondimento del "Il nostro Guida al PMD Pro 93 attuale stato di Earned Value Analysis è quello che deve essere? Lo stato attuale è il risultato delle decisioni che il progetto ha preso per quanto riguarda la gestione della qualità, la gestione del rischio, la gestione degli stakeholder o di uno qualsiasi dei molti altri temi che influenzano il bilancio e il calendario? Al termine di questa esplorazione del monitoraggio finanziario, vi è un'ultima osservazione che è importante sottolineare. Mentre l’ Earned Value Analysis è in grado di fornire dati ricchi che aiutano meglio a monitorare lo stato finanziario del progetto, essa richiede anche un accurato sistema di contabilità di progetto che integra i costi basati sulle attività e i dati di pianificazione. Insieme, questi dati possono essere utilizzati per calcolare i valori dell’Earned Value per il costo complessivo e per le performance temporali del progetto. Il sistema di contabilità dovrà essere fondato su una Work Breackdown Structure pratica e guidata dalle attività e dovrà includere le informazioni sui costi tempificati. Qualsiasi ritardo nella rendicontazione dei costi è un ritardo nella capacità di valutare il costo e lo stato della pianificazione attuale del progetto. Questi presupposti sono spesso assenti dai sistemi delle development organization, il che rende difficile l'adozione di questo strumento di gestione nel contesto dei development project. 3.3.7. GESTIONE DELLA SUPPLY CHAIN Immagina di stare costruendo una casa. Come potresti affrontare le complesse sfide legate alla gestione del flusso di merci e servizi tra il loro punto di origine e quello di eventuale impiego nella costruzione della casa? Come pianifichi l'acquisto di materiali, stabilisci i programmi di consegna, l’acquisto di attrezzature, individui le strutture di stoccaggio per i materiali, ottieni i permessi, tieni traccia dello stato di tutti i materiali ... l'elenco va avanti! Ora immagina la costruzione della stessa casa in una comunità remota, povera di risorse. Come Project Manager, dovrai ora gestire tutte le complesse sfide della gestione della fornitura sopra elencate, ma dovrai anche affrontare una serie di rischi che sono specifici per il development context. I fornitori sono affidabili? C'è corruzione nel sistema degli appalti? Esistono dei meccanismi per il trasporto di materiali? Ci sono problemi di sicurezza? La sicurezza del personale è una preoccupazione? Quali sono i vincoli sulle risorse? Anche questo breve elenco dei rischi permette di comprendere la sfida di gestire forniture nei development project. Ritardi causati da una gestione difettosa della catena di fornitura portano non solo alla perdita di controllo sul progetto, ma anche alla perdita di reputazione e di soddisfazione del beneficiario. Si tratta di elementi di inestimabile valore, quasi impossibili da recuperare una volta persi. Ancor di più, a causa della natura critica dei servizi forniti dalle development organization, mancanze e sviste possono portare a gravi conseguenze per i beneficiari che potrebbero letteralmente fare la differenza tra la vita e la morte. Inoltre, la gestione della supply chain può rappresentare una percentuale significativa di un budget di progetto. Questo è il motivo per cui è importante che l'approvvigionamento sia gestito nel modo più efficiente ed efficace possibile. E’ probabile che il Project Manager non avrà la responsabilità della gestione operativa per la catena di fornitura. Ci può essere un gruppo di logisti che forniscono l'approvvigionamento e il supporto Guida al PMD Pro 94 logistico ad una serie di progetti. Nonostante questo, il Project Manager è responsabile di assicurare che il progetto abbia accesso ai beni e servizi giusti al momento giusto e, di conseguenza, ha bisogno di collaborare e coordinarsi strettamente con la funzione di supporto della supply chain per garantire il successo. Il PMD Pro identifica tre elementi nella gestione della supply chain: Gestione dell’approvvigionamento -­ include l'individuazione di quali materiali e servizi sono necessari, quando sono richiesti, e identifica come devono essere acquistati e da chi. Il piano di approvvigionamento ha anche bisogno di essere integrato con tutti gli altri elementi del piano di progetto per garantire che tutte le decisioni in materia di appalti siano in linea con i parametri di bilancio, calendario, della qualità e del rischio del progetto. Gestione della Logistica – include la pianificazione, l'attuazione e il controllo di un efficiente ed efficace flusso e stoccaggio delle materie prime, dei work-­in-­progress, dei prodotti finiti e delle relative informazioni, dal punto di origine al punto di consumo, al fine di conformarsi alle esigenze del cliente. Gestione degli Asset -­ include il sistema nel quale gli asset di valore per il progetto vengono monitorati, mantenuti e smaltiti. Il Project Manager è responsabile di assicurare che questi elementi siano gestiti in modo corretto. 3.3.7.1. Gestione dell’approvvigionamento L’approvvigionamento include il processo completo per l’ottenimento di beni e servizi, dalla preparazione e lavorazione di una richiesta fino al ricevimento e all’approvazione della fattura per il pagamento. Il Project Manager può essere responsabile per l’effettivo approvvigionamento dei servizi o dei prodotti necessari per sviluppare ed implementare il progetto, o può dirigere queste attività per mezzo di un Responsabile dei contratti o della fornitura. Rispetto al preciso ruolo e alle responsabilità del Project Manager, queste attività di approvvigionamento possono avere un impatto significativo sul budget di progetto e sulla schedulazione, pertanto esse devono essere integrate all’interno del piano generale di progetto, nel budget e nello schedule. Esempi di acquisti tipici associati ad un progetto includono: • Materiali: Questi possono variare da prodotti tipici, come mobilio o PC, a prodotti per il progetto ad elevata specificità come equipaggiamento medico, macchinari per la perforazione, o materiali per la costruzione di strade. Il Project Manager può essere responsabile per l’effettivo approvvigionamento dei servizi o dei prodotti necessari per sviluppare ed implementare il progetto, o può dirigere queste attività per mezzo di uno specialista degli acquisti. • Consulenti: Frequentemente, nonostante siano disponibili risorse in-­house per eseguire una parte significativa del lavoro di un progetto, sono necessarie risorse aggiuntive per completare il progetto in tempo o per fornire delle competenze necessarie. Una strategia è quella di ottenere le risorse all’esterno, solitamente consulenti, per ampliare lo staff di progetto. Guida al PMD Pro 95 • Fornitori: In questo caso, il fornitore si assume la responsabilità di eseguire tutti gli aspetti del servizio selezionato, solitamente per specifici standard o per un costo fissato. In questo tipo di scenario, il progetto acquista un servizio specifico. Esempi possono includere i servizi di demolizione, di trasporto, di sicurezza e di costruzione. Nella gestione dell’approvvigionamento sono presenti tre passi: • La pianificazione dell’approvvigionamento • L’identificazione dei fornitori • La selezione, la negoziazione e la decisione. 3.3.7.1.1. Pianificazione dell’approvvigionamento E’ consigliabile creare un piano dell’approvvigionamento qualora il progetto richieda che gli elementi siano acquistati da fornitori. Un Piano della Logistica identifica i prodotti o i servizi che il progetto deve ricevere da fornitori esterni. Un buon Piano dell’Approvvigionamento deve essere un passo oltre, descrivendo il processo che si sta per affrontare per incaricare contrattualmente questi fornitori. I passi nella pianificazione dell’approvvigionamento includono: • • • Definizione dei componenti che devono essere acquistati;; Definizione del processo di acquisto di tali componenti;; Schedulazione dei periodi di consegna. 3.3.7.1.2. Identificazione dei Fornitori Diversi documenti per l’approvvigionamento possono essere utilizzati per ottenere informazioni dai potenziali fornitori di servizi e materiali. Stime: Stime indipendenti dal tempo e dal costo per fornire il servizio o i materiali sono in generale fornite quando il criterio di valutazione per la scelta del fornitore è relativamente semplice ed esso sarà deciso principalmente/esclusivamente in base al prezzo. Nonostante il prezzo sia una elemento particolarmente importante quando si valutano le stime, si dovrebbe aver cura di considerare che il costo proposto è una stima realistica e non eccessivamente ottimistica che prende in considerazione le tecnologie e le competenze coinvolte nel progetto. Se sono presenti variazioni significative tra le stime di costi fra le diverse proposte presentate, l'offerta più bassa non può essere sempre quella di valore superiore. Se l'offerta più bassa è significativamente inferiore rispetto alle altre stime, dovrebbe essere valutata molto attentamente. Se il contratto non è redditizio, esso può generare molti problemi sia per il contraente che per l'organizzazione. Proposte: Quando i criteri di selezione per i potenziali fornitori sono già complessi, i documenti di stima non necessariamente raccolgono tutte le informazioni necessarie per prendere una decisione informata. Questi tipi di fornitura possono raccogliere informazioni aggiuntive attraverso un processo di Invitation for Bid (IFB -­ Invito all’Offerta) o una Request for Proposal (RFP -­ Richiesta di Proposta). La RFP dovrebbe contenere un rendiconto comprensivo e conciso del lavoro (Statement of Work -­ SOW) che definisca chiaramente il prodotto desiderato, i suoi requisiti funzionali, le Guida al PMD Pro 96 caratteristiche operative e di performance e le interfacce richieste con gli altri sistemi dell’agenzia e con i processi. 3.3.7.1.3. Selezione, Negoziazione e Decisione Il processo di approvvigionamento dovrebbe essere progettato per consentire all’organizzazione di ottenere e valutare le stime/proposte da diversi fornitori, utilizzando una varietà di criteri che possa essere rilevante per la decisione. Il criterio di selezione può essere limitato al prezzo e al calendario se il materiale o il servizio è già disponibile e relativamente semplice nella sua configurazione. Generalmente, comunque, la selezione del fornitore si basa su una combinazione di considerazioni finanziarie e tecniche. Qualunque criterio di selezione venga impiegato, il gruppo decisionale dovrebbe avere chiaro il criterio utilizzato per prendere le decisioni e il loro relativo peso. Tale comprensione renderà consapevole la loro scelta definitiva così da facilitare la valutazione delle risposte. 3.3.7.2. Gestione della Logistica Poiché molti progetti dipendono dalla consegna dei materiali, una logistica di supporto appropriata è una necessità importante. Logistica significa avere le cose giuste, nel luogo giusto, al momento giusto. Nel suo significato più limitato, essa coinvolge il trasporto dei beni, ma c’è più di questo. In un senso più ampio, la logistica include tutte le attività richieste per consegnare gli oggetti in modo accurato, efficiente e con tempi precisi, al luogo ed alla persona cui essi sono destinati. Questa definizione allargata di una logistica efficace include: • La gestione dell’inventario e del magazzino • Il trasporto dei materiali 3.3.7.2.1. Gesione dell’Inventario e Magazzino In relazione al progetto, l’inventario può rappresentare un costo ingente rispetto al valore totale del progetto. Questo valore deriva dal costo dell’inventario stesso, a cui si somma il costo di trasporto dei beni, il costo della loro gestione (lavoro, packaging, ecc.) e lo stoccaggio dei beni nel magazzino. Il team di progetto deve stabilire una gestione dell’inventario che assicuri che le scorte siano disponibili per andare incontro alle necessità del progetto come e quando necessario. A questo fine, il Project Manager deve coordinarsi con i membri del team direttamente responsabili della gestione dell’inventario, collegando costantemente le richieste dell’inventario con i bisogni mutevoli e le priorità del progetto. Come parte di questa sfida, il progetto deve trovare un bilanciamento fra la fornitura e la domanda stabilendo un livello minimo di scorte per coprire i lead time. Mentre il team di progetto crea questo equilibrio, il Project Manager deve assicurare che le politiche in atto siano adeguate per stabilire le norme e i controlli per la gestione di tutti gli elementi per il controllo del magazzino e dello stoccaggio. Guida al PMD Pro 97 3.3.7.2.2. Trasporto Materiali L’obiettivo del trasporto è di muovere fisicamente la fornitura verso la sua destinazione in modo affidabile e sicuro, in tempo, con efficienza ed efficacia di costo. Una strategia di trasporto non dipende solo dai bisogni del progetto;; può variare da situazione a situazione. 3.3.7.3. Gestione degli Asset Tutto l’equipaggiamento del progetto, le forniture e le altre proprietà finanziate o fornite dal progetto dovrebbero essere considerate come asset del progetto stesso. Come tale, quest’ultimo deve individuare una politica di gestione dei beni in cui i materiali di valore vengono monitorati, mantenuti e smaltiti in modo coerente con le esigenze dell'organizzazione e/o del donatore/i. Questa politica dovrebbe includere indicazioni sui seguenti argomenti: Definizione degli Asset: Ogni organizzazione avrà bisogno di impostare una propria definizione di valore e di vita utile, che definisce ciò che è un asset. Questa definizione varierà a seconda dell'organizzazione, il donatore e/o il progetto. L'UNDP, ad esempio, individua la soglia per le immobilizzazioni ad almeno $1000 USD, e una vita utile di almeno tre anni. La tabella seguente fornisce una panoramica di alcune delle principali categorie di beni che essa gestisce, e la durata della vita di ciascuna di queste categorie. Figura 50: Categorie dei beni secondo UNDP CATEGORIA VITA UTILE Tipica oggettistica d’ufficio elettrica (es, stampanti) 3 anni Grandi Macchinari: (es, generatori, condizionatori d’aria) 20 anni Mobilio 10 anni Veicoli 5 anni ALTRI FATTORI Più di 100,000 chilometri (62,000 miglia) Registrare gli Asset -­ I Progetti dovrebbero tenere traccia completa ed accurata di tutte le acquisizioni di beni. Tutti I beni acquistati per un progetto (attraverso acquisti, trasferimenti o donazioni) devono essere registrati. Categorizzare gli Asset – I beni del progetto dovrebbero essere etichettati per facilitare la loro supervisione e controllo. Qualsiasi convenzione appropriata può essere utilizzata per l’etichettatura a condizione che sia applicata in modo coerente ed abbia lo scopo di monitorare gli asset. Monitoraggio e Registrazione dei Beni – Le informazioni sugli asset dovrebbero essere aggiornate regolarmente come giustificazione per acquisizioni, aggiustamenti, trasferimenti e informazioni dispositive. Questo includerà un conteggio fisico e le discrepanze devono essere indagate, comprese e documentate nell’ issue log del progetto. Guida al PMD Pro 98 Salvaguardare gli asset: istituire controlli adeguati in modo che le immobilizzazioni siano adeguatamente mantenute e salvaguardate. Questi controlli possono variare a seconda dei beni e del rischio. Ad esempio, un'organizzazione potrebbe richiedere che i computer portatili siano assicurati con un cavo di blocco appropriato e collocati in modo sicuro in un cassetto o chiusi a chiave in un armadietto quando non in uso. Un altro esempio potrebbe essere la richiesta che le apparecchiature per ufficio in prestito ai membri del personale debbano essere sempre registrate nelle apparecchiature di registrazione/prestito. Dismissione degli asset -­ dovrebbero essere stabilite, per la dismissione dei beni, procedure chiare che comprendano i requisiti relativi alle approvazioni, la pubblicità, le richieste dei donatori e la reportistica. Se necessario, la norma dovrebbe includere tutti i requisiti speciali relativi al valore del bene o il tipo di asset gestito (veicoli, computer, altri). L’eliminazione di asset poveri può avere un grande impatto sulla finanza di progetto, in quanto i donatori possono rifiutare le spese per gli asset che non sono stati smaltiti correttamente e possono richiedere il rimborso o ridurre i fondi dai pagamenti stabiliti nel contratto definitivo. 3.3.8. GESTIONE DELLE RISORSE UMANE La gestione delle risorse umane è sia una scienza che un’arte. L’arte dipende dalle capacità interpersonali e di leadership del Project Manager. Può il Project Manager motivare gli stakeholder? Ispirare fiducia? Gestire i conflitti? Aumentare il morale del team? La scienza della gestione delle risorse umane dipende dall’efficacia della pianificazione. La pianificazione delle risorse umane è elemento integrante del piano di realizzazione del progetto complessivo. La gestione delle risorse umane del progetto identifica le attività e le risorse richieste per gestire il team di progetto. I suoi componenti includono: Procurarsi lo staff di progetto – Come parte dei compiti di gestione di un team, il team leader di progetto deve essere chiaro sul sistema di identificazione dei candidati per lo staff, intervistando I candidati, identificando i criteri di selezione ed effettuando la scelta finale dello staff di progetto. Identificare i compiti dello staff di progetto – I compiti dello staff di progetto sono la lista degli obblighi del progetto, dei ruoli e delle responsabilità per i membri del team. I compiti dello staff sono spesso utilizzati durante i processi di monitoraggio e controllo per valutare individualmente i membri del team. Documentare l’organigramma del Progetto – Gli organigrammi di progetto rappresentano le relazioni di reportistica fra il team di progetto. Sviluppare lo Staff di Progetto – Che capacità sono necessarie? Quali sono le esigenze di formazione? Ci sono requisiti di certificazione? Quali sono problemi di conformità? Eseguire delle valutazioni delle performance – La valutazione delle performance sono la valutazione documentata, formale o informale, delle prestazioni dei membri del team di progetto. Dopo aver analizzato le informazioni, il Project Manager è in grado di identificare e risolvere i problemi, ridurre i conflitti e migliorare il lavoro complessivo di squadra. Guida al PMD Pro 99 Promuovere un ambiente di squadra altamente produttivo – Come capo di un team di progetto, il Project Manager deve attivamente lavorare per identificare problemi e conflitti e lavorare creativamente per risolverli. Molte delle attività coinvolte nella gestione del team di progetto (l’implementazione del piano dello staff di progetto, l'acquisizione di personale, l’individuazione dei compiti del personale, la documentazione degli organigrammi) sono di natura tecnica -­ spesso descritta come la 'scienza' della gestione del team di progetto. Le abilità, gli atteggiamenti e i comportamenti necessari per promuovere un ambiente di team altamente produttivo, tuttavia, dipendono dalla capacità del Project Manager di andare oltre la 'scienza' della gestione del progetto e di impegnarsi nell’ 'arte' della disciplina. Al fine di promuovere un ambiente di team altamente produttivo, il Project Manager deve essere abile nel comunicare la visione, incoraggiando una proprietà condivisa, spostando agende all'interno e all'esterno dell'organizzazione, e gestendo situazioni in cui non vi è alcuna autorità gerarchica diretta. Guida al PMD Pro 100 3.4. D ISCIPLINA 4: G ESTIONE DEL R ISCHIO Esplorando le tematiche tipiche del project management, l’attenzione converge rapidamente verso la gestione del rischio. Ma cos’è un rischio? Il termine è spesso utilizzato con leggerezza e alcune volte anche scorrettamente. Nel contesto del PMD Pro, il rischio è l’effetto potenziale derivante da un’incertezza che può influenzare gli obiettivi di progetto. Quando si considera la definizione del rischio, è necessario tenere in considerazione i seguenti due aspetti: Probabilità – il rischio è da considerare in relazione alla probabilità di accadimento di possibili eventi incerti futuri (in opposizione ai problemi che invece hanno a che fare con eventi realmente accaduti e quindi è necessario gestirli immediatamente). Come già spiegato nella sezione due “Implementazione del Progetto”, un problema è un rischio che si è manifestato. Impatto – il rischio potenzialmente può influenzare il progetto. Molti team di progetto si concentrano sui rischi negativi che possono minacciare l’avanzamento del progetto (pianificazione, costi e risorse, qualità, obiettivi, etc…), cercando di evitarli. Dall’altro lato, invece, i rischi positivi sono meno conosciuti e compresi. Un gruppo di progetto può considerare un rischio come positivo se individua una potenziale opportunità legata al rischio, oltre che al possibile problema. Questo approccio al rischio è considerato la maniera migliore per affrontare un rischio. La gestione del rischio, tuttavia, è una disciplina core del project management e l’obiettivo di questo capitolo è di fornire una guida concisa sul tema applicato al development sector. Con rischio si intende un evento che potrebbe accadere e che potrebbe influenzare il progetto. Con “potrebbe accadere” si vuole sottolineare come la probabilità di accadimento sia inferiore al 100%. Quando l’evento invece ha probabilità di accadimento pari al 100% (quindi accadrà sicuramente) l’evento è da considerare un problema (vedi la discussione sulla gestione delle problematiche nella Sezione Due). Durante le prime fasi della identificazione e definizione del progetto, il team inizierà a raccogliere informazioni riguardanti i rischi potenziali che potrebbero affliggere il progetto. Per esempio, in un progetto d’agricoltura delle interviste preliminari con le famiglie contadine possono aiutare a cogliere problemi riguardo i canali di marketing e distributivi. Con l’evolversi del progetto, alcuni rischi saranno risolti o ridotti, mentre potrebbero emergerne altri che andranno a sommarsi a quelli già presenti. È quindi importante tener sempre aggiornato l’elenco dei rischi durante l’intero ciclo di vita del progetto, dalle fasi iniziali fino all’implementazione. I rischi sono gestiti attraverso un processo in 4 fasi: • Identificazione del rischio – identificare e doocumentare tutti i rischi che possono influenzare il progetto. • Valutazione del rischio – determinare la probabilità di accadimento e stimare il potenziale impatto del rischio così da poter prioritizzare i rischi di progetto. Guida al PMD Pro 101 • Pianificazione delle contromisure al rischio – decidere quali azioni dovranno essere intraprese per ridurre o annullare le minacce, in particolare quella che ha alta probabilità di accadimento e alto impatto potenziale. • Monitoraggio e gestione del rischio – gestire tempestivamente il rischio appena si manifesti, assicurandosi di seguire le procedure prestabilite e pianificate. 3.4.1. IDENTIFICAZIONE DEL RISCHIO Ci sono due passaggi nel processo di identificazione del rischio: Rischi Positivi e Negativi Una gestione completa del rischio si concentrerà sia sui rischi negativi che su quelli positivi. 2. Identificare i rischi specifici raggruppabili nelle categorie di rischio. Un rischio negativo è rappresentato da potenziali eventi che potrebbero danneggiare il progetto. In generale, questi rischi sono da evitare. Un rischio positivo, d'altra parte, si riferisce a un rischio cui diamo origine noi stessi perché vediamo una potenziale opportunità, insieme ad un potenziale fallimento. 3.4.1.1. Definizione delle categorie di rischio La categorizzazione del rischio può essere paragonata a una visita medica. Se il dottore chiede “Come ti senti?” il paziente potrebbe rispondere “Bene”. Tuttavia la visita è molto più efficace se il dottore chiedesse “Come vanno le ginocchia? I polmoni? Dolori alla schiena?”;; infatti a seguito di queste domande il paziente inizierà a pensare specificamente alle aree del corpo nominate dal medico. Le categorie comunque non dovranno essere né troppo ampie né troppo Il Project Management è completo! 1. Definire le categorie di rischio del progetto. Prendete, ad esempio, un progetto di agricoltura che si stima necessiterà di sei mesi per essere completato. Il team di progetto si accorge che se si aggiungono alcuni nuovi partner di implementazione, il progetto potrebbe essere completato in metà del tempo. Naturalmente, nuovi partner significa nuovi rischi. Cosa succede se la loro capacità è scarsa? Se ci sono ritardi dovuti all’adozione di nuovi sistemi? Etc… Ecco il dilemma: cogliere un’opportunità e introdurre nuovi rischi per ottenere un guadagno positivo? O continuare con i partner tradizionali e accontentarsi di consegnare il progetto tra sei mesi? specifiche. Se nell’esempio sopra il dottore avesse chiesto informazioni riguardo la parte superiore e inferiore del suo corpo, la categorizzazione non avrebbe aiutato molto. Dall’altro lato se il dottore avesse nominato ogni singolo osso, legamento e organo, il paziente si sarebbe sentito frustrato per la perdita di tempo. Concludendo, il dottore deve trovare il giusto equilibrio di categorie significative per aiutare il paziente. Quando si identificano le categorie di rischio per development project, è importante considerare che ogni progetto è unico ed è quindi impossibile identificare un set di categorie che vada bene per tutti i progetti. Il team di progetto dovrà analizzare attentamente il contesto intorno al quale si costruisce il Guida al PMD Pro 102 progetto, identificando le categorie in base alle necessità specifiche. Alcune delle possibili categorie sono elencate di seguito: Strategiche/commerciali • Mancato rispetto dei termini contrattuali dei fornitori • Frodi/furti • Partners nell’implementazione falliscono nella consegna dei deliverable pattuiti Economiche/finanziarie/di mercato • Fluttuazioni del tasso di cambio • Instabilità dei tassi d’interesse • Inflazione • Evoluzione del mercato non prevedibile Legale e regolamentazione • Nuove legislazioni o modifiche possono rendere non più valide le basi del progetto • Fallimento nell’ottenere approvazioni adeguate • Soluzioni contrattuali non soddisfacenti Fattori gestionali e organizzativi • Mancanza di leadership • Inadeguata autorità delle figure principali • Procedure di selezione del personale inadeguate • Mancanza di chiarezza nell’assegnazione di ruoli e responsabilità • Mancanza di supporto operativo Fattori politici • Cambio del governo o delle sue politiche • Guerre o disordini • Opinione pubblica/media avversi • Interferenza di esponenti politici in decisioni di sviluppo Ambientale • Disastri naturali • Cambiamenti climatici improvvisi Fattori tecnici/operativi/infrastturali • Progettazione inadeguata • Aspettative non chiare Gestione dei rischi di progetto • Mancanza di pianificazione, analisi del rischio e contingency • Monitoraggio e azioni di risposta inadeguate • Pianificazione irrealistica • Logistica scarsamente organizzata • Ritardi nell’approvazione di documenti di progetto 3.4.1.2. Identificare rischi specifici all’interno delle categorie individuate Una volta che le categorie di rischio vengono identificate, il team di progetto dovrebbe collaborare con i principali stakeholder con il fine di identificare dei rischi specifici per ogni categoria individuata. Il team e gli stakeholder dovranno iniziare ad analizzare i documenti specifici di progetto;; sono disponibili numerose tecniche a supporto dell’identificazione dei rischi, tra cui il brainstorming, i focus group, la comparazione di scenari e il supporto di esperti. Una volta identificati i rischi, bisognerebbe elencare i rischi specificando tre fattori per ognuno, cosi da facilitare il compito per chi dovrà gestire il rischio: • • • La causa, l’origine del rischio;; Il rischio stesso;; L’impatto del rischio sul progetto. Guida al PMD Pro 103 Ad esempio, “dato che il trasporto di materiali nell’area considerata può essere influenzato da allagamenti, esiste il rischio che la consegna del cemento non venga effettuata secondo le tempistiche pianificate, cosi da influenzare la costruzione della base della latrina, rendendo impossibile rispettare le tempistiche”. Descrivere il rischio secondo questi tre fattori, permette all’interlocutore di comprenderlo a fondo. Molti dei rischi iniziali saranno identificati durante le fasi di Identificazione e Design del progetto. Il team di progetto iniziando ad analizzare il contesto durante la valutazione e l’analisi delle attività di progetto, inizierà ad individuare i primi rischi potenziali. Il processo di identificazione dei rischi tuttavia deve essere sempre attivo durante l’intero ciclo di vita del progetto, infatti i rischi si evolvono con il tempo. Ad esempio durante le prime fasi di progetto, i rischi possono essere maggiormente focalizzati nell’acquisizione di finanziamenti e nella gestione degli stakeholder. Passando poi alla fase di implementazione invece i rischi diventeranno di natura più operativa riguardando maggiormente tematiche di tempistiche, pianificazione, stima e monitoraggio dei costi. Tutto questo sottolinea come sia importante che l’identificazione del rischio non venga considerata come una singola attività da svolgere all’inizio del progetto, ma un processo lungo l’intero ciclo di vita che necessita della consapevolezza e impegno del team di progetto al fine di gestire i vari rischi potenziali che si possono trasformare in minacce per il conseguimento degli obiettivi di progetto. 3.4.2. VALUTAZIONE DEL RISCHIO La valutazione del rischio è il processo di quantificazione dei rischi individuati e documentati durante la fase di identificazione. La valutazione del rischio si basa su due attività sfidanti da svolgere: • Prioritizzazione dei rischi: Utilizzando criteri individuati dal team di progetto e dagli steakeholder principali, i rischi devono venire classificati in base alla probabilità di accadimento e al possibile impatto. • Identificazione delle tolleranze: il team di progetto, collaborando con gli stakeholder chiave, dovrà identificare il livello di tolleranza al rischio con il fine di indentificare quale rischio sia accettabile e quale invece dovrà essere gestito attivamente. Uno strumento utile durante la fase di valutazione dei rischi è la Matrice di Valutazione dei Rischi. La tabella sottostante può essere utilizzata per valutare i rischi individuati in un progetto di sviluppo. Figura 51: Matrice di valutazione dei rischi Alta Rischio B Media Rischio C Rischio A Basso Medio Alto PROBABILITÀ che il rischio si Bassa verifichi Guida al PMD Pro IMPATTO potenziale sul progetto 104 Nella tabella presentata, il processo di valutazione dei rischi si basa su due passi: Classificazione della priorità ei rischi: il team di progetto e gli stakeholder assoceranno ai rischi una probabilità di accadimento e impatto classificandoli in tre gruppi Alto, Medio o Basso. Identificazione della linea di tolleranza al rischio: i rischi sono classificati utilizzando dei colori (rosso, arancione, giallo, nessun colore). In questo esempio il Rischio B dovrà essere gestito attivamente, il Rischio A è caratterizzato da un livello di preoccupazione minore e quindi sarà sufficiente monitorarlo;; infine il Rischio C non influisce sulle priorità di progetto e rientra nelle tolleranze stabilite, quindi non dovrà essere gestito. La matrice di valutazione dei rischi è solo all’apparenza uno strumento semplice. Infatti per essere utilizzata correttamente il team di progetto e gli stakeholder chiave devono padroneggiare i criteri base per la prioritizzazione e identificazione dei livelli di tolleranza del rischio. Per arrivare a questo livello di consapevolezza, il Project Manager deve collaborare con gli stakeholder per completare il processo di valutazione dei rischi, tenendo sempre in considerazione le seguenti domande: • Quali criteri saranno usati per prioritizzare i rischi? I tempi? Gli obiettivi? I costi? Altri fattori come ad esempio il valore per i beneficiari del progetto? Le regolazioni che riguardano le donazioni? La sicurezza dei lavoratori? • Quale processo sarà usato per identificare le tolleranze al rischio? 3.4.3. RISPOSTA AL RISCHIO L’identificazione e la valutazione del rischio forniscono le basi per poter individuare le opzioni in risposta al rischio. Una volta che un rischio è stato identificato e considerato oltre la soglia di tolleranza, il team di progetto dovrà definire una strategia di risposta al rischio. Attenzione! L’obiettivo del risk management NON è ELIMINARE TUTTI i rischi di progetto. Infatti l’obiettivo è riconoscere le situazioni che possono portare un rischio ad eccedere il livello di tolleranza al rischio. Ad esempio i progetti “intolleranti” al rischio tenteranno attivamente di gestire tutti i rischi indipendentemente dal fatto che essi rientrino o meno nella matrice di valutazione. Dall’altro lato un progetto “tollerante” al rischio tenderà ad accettare una buona percentuale dei rischi individuati senza gestirli attivamente. Se si decide di gestire attivamente i rischi, le strategie di risposta includono le seguenti opzioni (o una loro combinazione): • Evitare il rischio – modificare in parte gli obiettivi di progetto che possono causare rischi dall’alto impatto o probabilità di accadimento. Ad esempio, un progetto potrebbe decidere di escludere un’area geografica caratterizzata da elevata insicurezza. • Trasferire il rischio – trasferire o condividere il rischio con enti esterni al progetto. L’esempio più comune in questo caso è un’assicurazione: infatti un’assicurazione permette di trasferire i danni economici e gli impatti alla compagnia assicuratrice. • Riduzione o mitigazione – azioni volte a ridurre la probabilità e/o l’impatto del rischio potenziale. Ad esempio in caso di rischio di furto di merce si potrebbe agire come segue: o La probabilità del possibile furto può essere ridotta incrementando il livello dei sistemi di sicurezza dell’edificio (personale di guardia, nuove porte e finestre) Guida al PMD Pro 105 o L’impatto del potenziale furto può essere ridotto stipulando accordi in modo che verranno mantenute in deposito solamente le merci necessarie per una settimana di lavori • Accettazione del rischio – se l’impatto e la probabilità legata al rischio sono considerate accettabili, un’organizzazione può decidere di non agire. Ad esempio, un progetto può considerare la possibilità di una stagione delle piogge in ritardo che causerebbe l’interruzione del ciclo di coltivazione come accettabile e non intraprendere contromisure. “Ignorare” il rischio non è una soluzione accettabile come strategia di risposta al rischio. Accettare il rischio non significa ignorarlo: infatti la decisione si basa su processi logici di identificazione, valutazione e pianificazione della strategia di risposta, che in questo caso individua come soluzione adatta l’accettazione del rischio. A questo punto il team di progetto dovrà sviluppare un piano d’azione per le strategie di risposta al rischio selezionate. Il documento di gestione del rischo deve comprendere: • Un piano globale dei rischi di progetto, comprensibile e organizzato;; • I metodi che saranno utilizzati durante l’implementazione delle strategie di risposta al rischio;; • Un piano delle risorse necessarie per garantire le strategie di risposta. Ogni piano di rischio deve essere documentato, ma il livello di dettaglio può variare il base al progetto considerato. Grandi progetti o progetti con alto livello d’incertezza trarranno notevoli benefici da piani di rischio dettagliati e formali che contengono tutti gli aspetti riguardanti le fasi di identificazione, valutazione e risposta al rischio. Progetti più piccoli o caratterizzati da un livello d’incertezza basso, invece potranno sfruttare un registro di stato dei rischi (una lista di eventi e un indicatore di stato, rosso, giallo o verde) in concomitanza delle milestone critiche lungo lo sviluppo e l’implementazione del progetto. Il registro di stato dei rischi viene creato durante le fasi iniziali di progetto e mantenuto aggiornata lungo l’intero ciclo di vita del progetto. Elencando gli elementi che possono impattare il progetto (tempi, costi, pianificazione, scopo e qualità, etc…) e tenendo la lista aggiornata, il team di progetto avrà una visione più chiara dei rischi. Per progetti più complessi, il registro dei rischi sarà caratterizzato da un’identificazione più dettagliata e formale dei rischi e conterrà anche i piani d’implementazione delle strategie di risposta. Sarà comunque simile alla lista di elementi del caso precedente, infatti garantirà al team di progetto una visione aggiornata dei rischi di progetto. In questo caso però verranno incluse anche informazioni riguardo la probabilità di accadimento e l’impatto atteso;; può contenere anche proposte di mitigazione al rischio, l’owner del rischio e lo stato corrente del rischio. Infine può contenere anche informazioni riguardanti i costi e gli impatti sulla pianificazione dei rischi considerati Il registro dei rischi può variare notevolmente da organizzazione o progetto, tuttavia di seguito ne viene fornito un esempio. Guida al PMD Pro 106 Quando Responsabile Risposta Punteggio Impatto Probabilità Status Nome del Rischio Categoria di Rischio Figura 52: Registro dei Rischi Strategico Partner manca di capacità Rischio 3/5 presente-­ il rischio è attivamente monitorato 4/5 7 Mitigare – stanziare budget per la formazione Marian Q1 Naturale La pioggia rallenta le attività Ritirato – rischio risolto 2/5 3/5 5 Evitare – rimandare le attività fino alla stagione secca PM Q1 Politico Insicurezza minaccia le consegne Ritirato – rischio risolto 2/5 5/5 7 Trasferire – assumere trasportatori per assorbire il rischio di perdita MV Q2 Etc... 3.4.4. MONITORAGGIO E CONTROLLO DEL RISCHIO Il passo finale del processo di gestione del rischio è monitorare costantemente i rischi, identificare tempestivamente ogni cambiamento nel loro stato e verificare se si sono manifestati, trasformandosi quindi in problematiche. È una buona soluzione effettuare periodicamente delle revisioni dei rischi al fine di identificare la probabilità e l’impatto dei rischi, eliminare dalla lista i rischi superati e identificare nuovi rischi. Si raccomanda inoltre che il registro dei rischi venga istituito durante le prime fasi del progetto. Se non viene creato durante la fase di “Set Up” del progetto, allora dovrà essere sviluppato contestualmente alla definizione di altri sistemi di controllo del progetto. Dato che i rischi sono di natura dinamica, il registro deve essere mantenuto aggiornato: infatti la lista dei rischi cambierà durante l’evoluzione del progetto, scompariranno alcuni rischi e ne compariranno degli altri. Delle revisioni periodiche e pianificate al registro dei rischi possono contribuire a una buona gestione dei Guida al PMD Pro 107 rischi. Infatti se si manifestassero dei rischi inattesi o l’impatto fosse superiore a quello previsto, la strategia di risposta potrebbe risultare non adeguata. In questi casi, il team di progetto dovrà sfruttare strategie addizionali per controllare e gestire il rischio. Guida al PMD Pro 108 3.5. D ISCIPLINA 5: G ESTIONE DELLA M OTIVAZIONE DEL P ROGETTO I progetti sono intrapresi per varie ragioni, ma, in fondo, gli investimenti vengono fatti per il potenziale che il progetto può portare agli attori coinvolti. Per esempio: • Il finanziatore deve essere convito che l’investimento nelle attività da realizzare siano utili;; • La comunità coinvolta deve percepire che la sua partecipazione porterà dei benefici;; • La dirigenza dell’organizzazione deve essere assicurata che il successo del progetto contribuirà al raggiungimento degli obiettivi. Un gestione accurata della giustificazione del progetto aiuta a dimostrare il senso di un progetto per l’organizzazione, per il finanziatore e per la comunità beneficiaria. I Project Manager devono avere le capacità e le competenze per: • Identificare le giustificazioni per i propri progetti;; • Comunicare tali giustificazioni ad un pubblico il più ampio possibile;; • Tracciare gli sviluppi del progetto in modo da raggiungere i risultati che ne giustificano l’esistenza. 3.5.1. IDENTIFICAZIONE DELLE NECESSITÀ CON APPROCCI BASATI SUI PROBLEMI O SULLE RISORSE Nei progetti tradizionali (information technology;; telecomunicazioni, etc.) la giustificazione è spesso associata al Ritorno di Investimento (ROI) e ai benefici commerciali. Le domande che più spesso si pongono gli sponsor di progetto sono riferite ad una giustificazione finanziaria dello stesso: “Quanto ci vorrà per recuperare l’investimento?”. Il ROI è uno strumento estremamente efficace nel dare una giustificazione al progetto, ma ne esistono molti altri che possono essere utilizzati a supporto di una decisione di investimento. Nel contesto del development sector lo studio della giustificazione parte da un’analisi delle necessità. Mentre il project team inizia a raccogliere i dati preliminari per la progettazione, una domanda che dovrebbe sorgere è come tali necessità vengano identificate: se tramite un approccio basato sui problemi o sulle risorse. In un approccio basato sui problemi, la prima domanda da porsi è: “Quale problema abbiamo?”. Questa domanda serve per identificare le mancanze che possono essere risolte. La sfida con questo approccio tradizionale è che se si va alla ricerca dei problemi, questi si troveranno certamente e a volte attraverso la giusta domanda potrebbero nascere problematiche che altrimenti non avrebbero dato alcun tipo di preoccupazione. Un approccio basato sulle risorse è molto più positivo ed enfatizza le opportunità piuttosto che i problemi. Le domande iniziali sono rivolte alle risorse e ai punti di forza esistenti. Per esempio “Cosa va bene? Quali aree o eccellenze ti piacerebbe condividere?”. Identificando i vantaggi e le risorse che esistono in una comunità, questo approccio fa passare in secondo piano la necessità di risolvere i problemi e permette di concentrarsi nel replicare e rinforzare ciò che già funziona. Guida al PMD Pro 109 Figura 53: Approccio Basato sui Problemi Vs Approccio Basato sulle Risorse Approccio basato sui Problemi Definire il problema Riparare i danni Focus sui fattori negativi Approccio basato sulle Risorse Ricerca di soluzioni/risorse esistenti Rinforzare ciò che funziona Focus sui fattori positivi 3.5.2. SPOSTARSI DAI PROBLEMI ALLA STRATEGIA DI INTERVENTO Gran parte del lavoro di gestione della giustificazione ha luogo nella fase di Identificazione e Design. Se il team decide di seguire un approccio basato sui problemi per definire le esigenze, il passo successivo consiste nello sviluppo di un albero dei problemi. Questo strumento garantisce una visone semplice ma robusta della realtà, identificando non solo il problema da risolvere, ma anche i suoi effetti e le cause che hanno contribuito a generare tale stato. Quando si sviluppa un albero dei problemi è importante iniziare il processo identificando il problema iniziale, attraverso una analisi collettiva con gli stakeholder coinvolti oppure basandosi su una analisi preliminare delle informazioni esistenti. Una volta identificato il problema, il processo di elaborazione dei problemi consequenziali si completa (preferibilmente attraverso la partecipazione collettiva) usando le seguenti indicazioni: • Le cause sono indicate sotto il problema iniziale • Gli effetti sono posizionati sopra il problema iniziale La linea guida sottostante la logica dell’albero dei problemi è “Cosa ha causato questo problema?”. Se ci fossero due o più cause che combinate producono un effetto esse sono messe sullo stesso livello del diagramma. Frecce di causa-­effetto sono usate per connettere i livelli dell’albero. Il grafico sotto illustra un esempio che fu realizzato dalla comunità ‘Delta River’, esso esamina le cause e gli effetti del peggioramento della qualità dell’acqua del fiume. Da notare che il diagramma è una rappresentazione semplificata della situazione ed è usuale avere causa-­effetto multipli per ogni livello. Ciò porta ad avere diagrammi spesso molto complessi. Guida al PMD Pro 110 Figura 54: Albero dei Problemi del progetto "Delta River" Una volta completato il diagramma, la fase successiva è quella di sviluppare un albero degli obiettivi, che identifichi i potenziali interventi che potrebbero risolvere le questioni emerse nel diagramma dei problemi. Nella forma più semplice l’albero degli obiettivi è speculare all’albero dei problemi, dove ogni problema è trasformato in un elemento dal connotato positivo. Mentre il diagramma dei problemi raffigura relazioni di causa-­effetto, quello degli obiettivi esprime relazioni di comprensione-­
soluzione. Usando l’esempio del peggioramento della qualità dell’acqua il diagramma dei problemi si trasforma come segue: Guida al PMD Pro 111 Figura 55: Albero degli Obiettivi del progetto "Delta River" Una volta identificato un ampio numero di bisogni, il passo successivo è quello di analizzare e valutare se la motivazione del progetto è giustificata. A questo punto una development organization deve porsi due domande strategiche: • Quali elementi dell’albero degli obiettivi saranno inclusi nel progetto? • Quali elementi non saranno inclusi nello scopo del progetto? Trovare risposte unanimi a queste domande potrebbe essere impossibile e il processo decisionale potrebbe diventare complicato e controverso. Non si deve dimenticare la lezione imparata nella sezione 2 di questa guida. Nella discussione della fase di Identificazione e Design erano stati identificati una serie di criteri che potevano essere usati per decidere lo scopo del progetto. Tali criteri aiuteranno il team e gli stakeholder a decidere quali interventi effettuare, i servizi da fornire, chi ne usufruirà e come. Ritornando al progetto ‘Delta River’, la selezione dei criteri include la disponibilità di risorse, la capacità d’implementazione dell’organizzazione, le priorità del governo locale e i bisogni delle famiglie. Basandosi su questi criteri il team sviluppa un albero delle alternative comunicando risultati, scopi e obiettivi (far riferimento alle caselle colorate in chiaro nell’immagine sotto) che l’organizzazione intende perseguire. È importante notare che l’albero delle alternative inserisce Guida al PMD Pro 112 anche elementi che non verranno considerati nello scopo del progetto (far riferimento alle caselle colorate di scuro nell’immagine sotto). Figura 56: Albero delle Alternative del progetto "Delta River" Guida al PMD Pro 113 3.6. D ISCIPLINA 6: G ESTIONE DEGLI S TAKEHOLDER I progetti sviluppati nel contesto della cooperazione per lo sviluppo coinvolgono sempre un largo numero di stakeholder: individui, gruppi e organizzazioni, i quali sono attivamente coinvolti nel progetto o i cui interessi possono influenzare positivamente o negativamente l’esecuzione e il completamento del progetto. L’esperienza ha dimostrato che se gli stakeholder sono scarsamente compresi nella fase di progettazione, oppure nel caso in cui i loro interessi non siano stati considerati durante la pianificazione e implementazione del progetto, si possono generare risultati che non riflettono ciò che era stato previsto. Al contrario, i progetti che identificano e considerano tutti gli attori coinvolti possono beneficiare di: • Una chiara comprensione dell’influenza di individui, gruppi e istituzioni, che può generare benefici alle attività di progetto;; • Una miglior indicazione sulle capacità di tali stakeholder;; • Informazioni più dettagliate su chi potrebbe influenzare e contribuire alla pianificazione e implementazione del progetto;; • Una più ampia visione delle alternative da implementare nella fase di progettazione e delle possibilità di risolvere dei conflitti. Per raggiungere il successo del progetto il team deve sviluppare dei meccanismi di gestione delle relazioni tra stakeholder coinvolti. I membri del team devono: capire la realtà e la complessità degli interessi e delle relazioni in gioco;; valutare e prevedere tutti i possibili impatti (sia positivi sia negativi) su tutti i gruppi di stakeholder;; progettare ed implementare dei piani di coinvolgimento che incoraggino la partecipazione e la comunicazione tra gli attori coinvolti. Il sistema di gestione degli stakeholder include: • Identificazione degli stakeholder • Analisi degli stakeholder • Coinvolgimento degli stakeholder • Comunicazioni tra gli stakeholder 3.6.1. IDENTIFICAZIONE DEGLI STAKEHOLDER Durante le fasi preliminari del progetto (Identificazione e Design), è chiaro che numerosi stakeholder influenzeranno il progetto. Uno dei primi passi da compiere in queste fasi è l’identificazione di tali attori. Ad assistere tale attività, la guida PDM Pro ha generato sei categorie di stakeholder che aiutano la loro identificazione: Utenti: sono le persone che beneficeranno direttamente dei prodotti o servizi generati dal progetto. Per esempio, nel progetto di gestione dello spartiacque, i membri della comunità e le famiglie saranno gli utenti che beneficeranno dal miglioramento della qualità del terreno e dalla garanzia all’accesso all’acqua. Guida al PMD Pro 114 Stakeholder governativi: sono le persone e i gruppi di persone che hanno interesse su come verrà gestito il progetto. Questa categoria potrebbe includere: • Comitato direttivo, gruppi di gestione o gli sponsor: governano la struttura del progetto;; • Struttura di valutazione e regolazione: garantiscono l’osservanza delle richieste e del contesto normativo del progetto;; • Finanziatori (individui o organizzazioni) i quali garantiscono i finanziamenti del progetto. Collaboratori: sono gli individui che partecipano direttamente alle attività. Dirigenti, membri del team, organizzazioni di implementazione, appaltatori e fornitori possono ricadere in questa categoria. Influencer: sono persone che possono cambiare, positivamente o negativamente, il corso di un progetto. Ad esempio possono essere i media, gli ufficiali di governo, interessi commerciali o capi di comunità. Dependent: sono quelli che vorrebbero qualcosa oltre ai prodotti o servizi pianificati. Tipicamente ricadono in questa categoria altri progetti o altre unità funzionali dell’organizzazione coinvolta, le quali richiedono uno dei risultati generati dal progetto. Ritornando all’esempio della gestione dello spartiacque, un progetto di costruzione di case per persone a basso reddito, il quale lavora nella stessa comunità, potrebbe aspettare il completamento dello spartiacque per iniziare le sua attività di costruzione. Sostenitori: sono gruppi a supporto del sostentamento dei prodotti o servizi dopo il completamento del progetto. Utilizzando nuovamente l’esempio del progetto di gestione dello spartiacque, ci si potrebbe aspettare che il ministero dei lavori pubblici e il ministero dell’agricoltura assumano la proprietà delle attività di gestione dello spartiacque nel medio-­
lungo periodo, dopo la conclusione del progetto. Alcune considerazioni da tenere a mente quando vengono classificati gli stakeholder in categorie: -­ Riconoscere quando le categorie di utenti si sovrappongono. Ci sono molti casi in cui un individuo o un gruppo ricadono in più di una categoria. Ad esempio, una comunità potrebbe trovarsi sia tra gli utenti che tra i sostenitori. -­ Considerare di suddividere le categorie. Le categorie possono essere suddivise in sotto-­categorie. La categoria di stakeholder relativi alla governance, per esempio è già suddivisa in tre sotto-­categorie. Allo stesso modo, potrebbe essere particolarmente utile suddividere la categoria in ulteriori sottogruppi. -­ Riconoscere che gli stakeholder del progetto cambiano con il tempo. Nuovi stakeholder possono entrare nella zona di intervento, mentre altri perdono la loro influenza o interesse. L’identificazione degli stakeholder è quindi un processo continuo e dovrebbe essere rivisito ad intervalli regolari per tutta la durata del progetto. Guida al PMD Pro 115 3.6.2. ANALISI DEGLI STAKEHOLDER Una volta identificati gli stakeholder, il passo successivo consiste nella loro analisi. Tale processo comprende: • Esplorare gli interessi degli stakeholder: cosa potrebbero guadagnare o perdere gli stakeholder attraverso il progetto? Quali sono le loro attese (positive e negative)? Quali risorse potrebbero impegnare? Quali sono i loro ruoli potenziali? Quali capacità hanno a disposizione? Sono sostenitori o persone in conflitto con il progetto? • Mappare l’influenza degli stakeholder: con influenza si intende il potere decisionale che gli attori coinvolti esercitano sul progetto con effetti positivi o negativi. Qual è l’entità di cooperazione o conflitto nelle relazioni tra gli stakeholder? Chi ha il potere per risolvere problemi immediati e per agire sulle cause scatenanti? Sono presenti molti strumenti che possono essere utilizzati per condurre analisi sulle attività degli stakeholder, questa guida si concentra su due di questi: • Diagramma di Venn • Matrice di Analisi degli Stakeholder I diagrammi di Venn sono creati per analizzare e illustrare la natura delle relazioni tra i gruppi chiave coinvolti nel progetto. Tale diagramma è sviluppato rispetto alla prospettiva di un singolo attore (o gruppo). Ogni cerchio rappresenta uno stakeholder coinvolto. La dimensione del cerchio indica il potere / influenza di ogni attore, mentre la distanza tra ogni elemento esprime la forza o debolezza delle relazioni/interazioni tra gruppi e organizzazioni. Il diagramma di Venn è comunemente usato come strumento partecipativo di pianificazione con gruppi target per supportarli nel tracciare un profilo di queste relazioni. L’immagine sotto fornisce un esempio dell’uso del diagramma di Venn per identificare il potere e l’influenza di una serie di attori di una comunità coinvolta nella gestione del mercato del pesce. La prima cosa da notare è che il diagramma è stato creato secondo la prospettiva di uno specifico stakeholder: una famiglia di pescatori. La dimensione e la distanza “dell’Industria X” dimostrano quanto essa sia influente ma ‘lontana’ dagli interessi dell’elemento di riferimento. Allo stesso modo “l’Agenzia per la Protezione Ambientale” è chiaramente molto lontana e allineata con gli interessi dell’industria. Le “Cooperative di pescatori” rappresentano gli interessi dei pescatori e hanno delle relazioni molto strette con i rivenditori. La piccola dimensione del cerchio che rappresenta il “Dipartimento della Pesca” indica che ha poca influenza. Guida al PMD Pro 116 Figura 57: Diagramma di Venn per il progetto "Delta River" La Matrice di Analisi degli Stakeholder utilizza i risultati del diagramma di Venn (o altri strumenti di mappature degli stakeholder) per indentificare, elaborare e comunicare gli interessi e le capacità degli attori coinvolti nel progetto. Diversamente dal diagramma di Venn la matrice permette di descrivere ogni elemento, fornendo informazioni addizionali sugli stakeholder, sui loro interessi, sulla loro influenza e sulle azioni potenziali che possono essere effettuate per intervenire sugli interessi degli stakeholder. La tabella sottostante fornisce una matrice di analisi degli stakeholder per un progetto di gestione del mercato del pesce introdotto con il diagramma di Venn. La matrice aiuta ad identificare le metodologie di coinvolgimento in modo tale da far partecipare gli attori in tutte le fasi del ciclo di vita del progetto. Per esempio la tabella identifica i potenziali rischi che potrebbero scaturire dalla scarsa regolazione di un’industria tessile e che potrebbero compromettere il successo del progetto. Riconoscendo questa possibile minaccia, il team di progettazione può intraprendere azioni per assicurare il successo del progetto, per esempio organizzando incontri con l’industria tessile per negoziare soluzioni, o per trovare delle strade per coinvolgere anche loro nel progetto. Guida al PMD Pro 117 Figura 58: Matrice di Analisi degli Stakeholder Stakeholder e loro caratteristiche di base Interessi e come sono influenzati dal problema Capacità e motivazione nel portare avanti il cambiamento Possibili azioni per allineare gli interessi dello stakeholder Famiglie di pescatori 20,000 famiglie, basso reddito, attività economiche famigliari su piccola scala, organizzate in cooperative informali. Mantenere e migliorare le condizioni di vita Vivo interesse per misure di controllo dell'inquinamento Sostenere la capacità di organizzarsi e aggregarsi Influenza politica limitata, data la debole struttura organizzativa Ridurre l'inquinamento Hanno risorse tecniche e finanziarie da impiegare in nuove tecnologie più pulite Accrescere la loro consapevolezza dell'impatto sociale e ambientale. Corrente motivazione a cambiare limitata Mobilitare la pressione politica per influenzare il comportamento delle industrie. Donne attivamente coinvolte nella lavorazione del pesce. Industrie tessili Operazioni industriali di medie dimensioni, scarsamente regolamentate e assenza di sindacati. Ben collegate con il partito al governo. Scarsi risultati ambientali Famiglie 45.000 famiglie scaricano le acque reflue e i rifiuti nel fiume, usato anche come fonte di acqua potabile e per la pesca. Agenzia Protezione dell’Ambiente: Etc. L'inquinamento colpisce volume e qualità del pescato La salute delle famiglie sta peggiorando, in particolare quella dei bambini e delle madri. Mantenere e aumentare i profitti Qualche preoccupazione per la propria immagine pubblica Preoccupazione per i costi derivanti dall’applicazione delle normative ambientali Rafforzare e far rispettare le norme ambientali. Consapevoli dell’inquinamento e dell’impatto sulla qualità dell'acqua da parte dell’industria tessile. Limitata comprensione dell'impatto sulla salute causato dallo smaltimento dei propri rifiuti/acque reflue. Sensibilizzare le famiglie riguardo le implicazioni delle proprie pratiche di smaltimento rifiuti. Desiderano smaltire i propri rifiuti lontano da casa. Sembrano disposti a pagare per migliori servizi di gestione dei rifiuti. Lavorare con le comunità e il governo per affrontare i problemi legati all'acqua e ai servizi igienico-­sanitari. Vogliono accesso all'acqua potabile. Etc. Etc. Guida al PMD Pro Identificare e sviluppare fonti alternative di reddito. 118 Etc. 3.6.3. COINVOLGIMENTO DEGLI STAKEHOLDER Un Project Manager raramente lavora da solo. Anche i progetti più piccoli dipendono dalla rete degli stakeholder. All’aumentare della complessità del progetto si espande anche la rete di relazioni che include comunità, organizzazioni, ministeri governativi, fornitori, ONG locali, università, organizzazioni religiose e altri. Una delle sfide principali quando si gestisce una rete di stakeholder è quello di assicurare che ci sia chiarezza nei ruoli, responsabilità, autorità e comunicazioni tra i differenti attori. Uno strumento utile a questo scopo è il grafico RACI, una matrice composta da un asse verticale (colonna a sinistra) con le attività e i risultati e da una asse orizzontale (la prima riga) con i ruoli. Il nome di tale grafico deriva dall’acronimo dei ruoli chiavi che più tipicamente compongono la matrice: Responsible (responsabile): chi lavora per realizzare un’attività. Tipicamente, per ogni attività c’è una persona che è responsabile del completamento del lavoro, sebbene altri possano essere delegati ad aiutare. Accountable (approvatore): colui che deve approvare (firmare) il lavoro che la persona responsabile produce. Ci deve essere una sola persona assegnata all’attività di approvazione per ogni attività o risultato. Consulted (consultato): colui a cui sono richieste delle opinioni e con il quale ci sono comunicazioni bi-­direzionali. Informed (informato): colui che viene aggiornato dei progressi, spesso solo quando viene completata un’attività o raggiunto un risultato e con il quale ci sono comunicazioni mono-­direzionali. Il grafico sottostante fornisce un esempio semplificato della matrice RACI per il progetto ‘Delta River’: Guida al PMD Pro 119 Figura 59: Matrice RACI per il progetto "Delta River" Attività del Progetto Chi deve fare il lavoro associato all’attività? Chi firma per certificare il risultato finale associato all'operazione? Chi deve essere sollecitato attivamente perché fornisca un input? Nota di Progetto Guida: Project Manager Project Manager Consulente tecnico sulla gestione delle acque reflue Chi deve essere informato? Chi deve essere informato attraverso copie di relazioni, e-­
mail, ecc.? Incaricati del Ministero della Sanità locale Partecipanti al progetto, Ministero della Sanità (locale), donatori Incaricati del Ministero della Sanità (livello nazionale) Incaricati del Ministero della Sanità (livello locale), Donatori Partecipanti al progetto Partecipanti al progetto, Ministero della Sanità (locale), Consulente tecnico, donatori Responsabile del programma Incaricati del Ministero della Sanità (livello nazionale) Consulente tecnico regionale Incaricati del Ministero della Sanità (livello nazionale) Tipo di partecipazione Valutazione del Design, Logical Framework & Piano di M&V Chi è responsabile? Chi deve approvare? Chi deve essere consultato? Assistono: Organizzazioni che si occupano dell’implementazione Guida: ONG che realizza i Project Manager lavori Assistono: ONG che realizza i lavori Consulente tecnico: Project Manager Lavoratori locali I ONG che realizza i lavori, Consulente tecnico sull’AIDS, Project Manager, Quartier Generale dell’organizzazione Guidano: Project Manager, ONG che realizza i lavori Project Manager, ONG che realizza i lavori, lavoratori locali Implementazione Guidano: Project Manager, ONG che realizza i lavori Monitoraggio e Responsabile del Valutazione programma, Donatori Project Manager, ONG che realizza i lavori, Partecipanti al progetto Partecipanti al progetto, responsabile di progetto Scrittura e invio della proposta Piano di progetto dettagliato Assistono: ONG che realizza i lavori Guida: Project Manager Donatori Una volta sviluppata la matrice RACI può essere condivisa tra tutto il team e con gli attori coinvolti nel progetto per aiutare ad assicurare la comprensione, e le aspettative, sui ruoli di progetto e i responsabili. Guida al PMD Pro 120 3.6.4. COMUNICAZIONI TRA GLI STAKEHOLDER Una volta che i ruoli e le responsabilità degli stakeholder sono stabiliti, la sfida successiva consiste nella gestione delle comunicazioni tra i gruppi di progetto. Una buona comunicazione è sia un’arte sia una scienza. Da una parte, l’arte di una comunicare con successo dipende dalle capacità interpersonali e di leadership del Project Manager. D’altra parte, la scienza delle comunicazioni richiede pianificazione ed esecuzione. Parte della scienza per una buona comunicazione consiste nell’identificare in modo accurato una appropriata strategia di comunicazioni in relazione alla dimensione e complessità del progetto. Per esempio, nel caso di un piccolo progetto, una comunicazione eccessivamente formale potrebbe portare velocemente ad ostacoli amministrativi, interferendo con altre attività di progetto. Nel caso di progetti grossi, pratiche di comunicazione informali e ad hoc possono trasformare rapidamente il successo in un disastro se importanti questioni e opportunità vengono perse a causa di una pianificazione e implementazione trascurata della comunicazione. Ci deve essere, dunque, chiarezza per definire “cosa”, “perché”, “chi”, “come” e “quando” delle comunicazioni. Queste informazioni possono essere raccolte in una tabella, come quella sottostante: Figura 60: Piano di Comunicazione Comunicazione Scopo Destinatari Autore Assegnato Mezzo di a comunicazione Frequenza Una volta identificato il modo di comunicare, il meccanismo deve accordarsi ai messaggi e agli stakeholder del progetto. Come guida, qui sotto sono elencate una serie di domande da porsi per determinare il meccanismo usato per la comunicazione del progetto: • Quale meccanismo o metodologia aumenterebbe la probabilità che un messaggio sia ricevuto, compreso e seguito? • Quante informazioni saranno incluse e a quale livello di dettaglio? • Quale meccanismo è il più appropriato per il tipo di messaggio? • Quale meccanismo è preferito dagli stakeholder? • Che livello di interazione è richiesto (mono o bi-­direzionale)? È importante inoltre differenziare tra comunicazioni regolari o in corso con i membri del team, gli sponsor e altri stakeholder chiave. I metodi selezionati includono rapporti sullo stato del progetto, incontri periodici programmati, aggiornamenti mensili, eventi, sessioni per problematiche critiche, incontri con i fornitori, organizzazione di corsi di formazione e programmi di implementazione. Guida al PMD Pro 121 4. : ADATTARE IL PMD PRO "Come si può rendere il PMD Pro adatto ai vostri bisogni? " Gli strumenti, le tecniche, le metodologie, e così via, non portano a nessun risultato se un team di progetto non può metterli a frutto nel proprio ambiente di lavoro. Questa sezione esamina come adattare i vari strumenti e le tecniche che sono state presentate, al fine di renderli efficaci per il Project Manager e per il team di implementazione del progetto. 4.1. P RINCIPI DELL ’A DATTAMENTO Come accennato in precedenza in questa guida, "non esiste un unico sistema per la gestione dei progetti. Ogni progetto – con i propri obiettivi specifici – è unico". Applicare semplicemente degli strumenti e delle tecniche, senza considerare il contesto, le risorse, le relazioni e le sfide che si presenteranno, porterà, nella migliore delle ipotesi, a realizzare un progetto “automatizzato“ e orientato unicamente ad un modello. Oltre a creare un sacco di lavoro inutile, l'aggiunta di strumenti e tecniche, senza una reale motivazione ragionata, rischia di confondere e demoralizzare lo staff di progetto e del partner di attuazione. Due responsabili di progetto hanno completato una formazione PMD Pro acquisendo una chiara comprensione della metodologia progettuale. Le organizzazioni di cui fanno parte, sfortunatamente, non dimostrano una vera comprensione della gestione di progetti ne riconoscono il suo valore. Al suo rientro in sede a un Project Manager è stato detto: "questi strumenti PMD Pro vanno bene, ma noi qui lavoriamo in modo diverso". All’altro è stato detto da un suo superiore: "quando si gestisce un progetto, dovresti poter decidere quali strumenti e tecniche vuoi utilizzare e poi svilupparli in modo autonomo". Mentre un Project Manager deve essere disposto a prendere l'iniziativa nonostante eventuali vincoli organizzativi, scenari come quelli descritti nell’esempio sopra dovrebbero essere, per quanto possibile, sempre evitati. Utilizzare delle tecniche di PMD Pro dovrebbe comportare la valutazione degli strumenti e delle tecniche già in uso, decidere quale sarà più utile in una situazione particolare, e poi pensare come questi strumenti possono essere integrati nei processi e nei sistemi organizzativi. Per esempio, la fotografia qui sotto mostra i risultati di un semplice esercizio d’indagine conoscitiva che un team di progetto ha prodotto, al termine di un corso di PMD Pro, per tentare di collegare i nuovi strumenti di PM a quelli già in loro possesso. Guida al PMD Pro 122 Quando possibile, i Project Manager dovrebbero coinvolgere le loro organizzazioni per affrontare le seguenti domande: § § § Un nuovo strumento può completare o rimpiazzare uno già in uso? In che modo le informazioni ottenute da un nuovo strumento possono adattarsi ai processi esistenti? Abbiamo bisogno di apportare delle modifiche ai processi esistenti in seguito all’integrazione di nuovi strumenti o di nuove tecniche? Ancora più concretamente, un Project Manager deve esaminare tutti gli strumenti e le tecniche, e chiedersi: "Sono in grado di utilizzare questi strumenti -­ oppure ho bisogno di un maggior sostegno organizzativo"? Error! Reference source not found. illustra un esempio di un piano di adattamento. É redatto con informazioni che denotano lo stato e indicano se saranno necessari ulteriori cambiamenti organizzativi per arrivare ad un’attuazione effettiva degli strumenti. Figura 61: Esempio di adattamento degli strumenti di Project Management strumenti Sono in grado di utilizzarli? Ho bisogno di maggior supporto? WBS Si No Diagramma di Rete Documento di Progetto Matrice di assegnazione responsabilità (RACI) Controllo dei Cambiamenti Si No No Si Si No Si Si Quali cambiamenti organizzativi devono essere effettuati prima di poter correttamente adattare e utilizzare questo strumento? Essere sicuro che il mio team e i miei collaboratori apportino le loro esperienze specifiche. Essere sicuro che il mio team comprenda sia lo scopo sia il processo in se. Incoraggiare la nostra organizzazione affinché concordi su un formato approvato. Dovrebbe essere usato per sollecitare input e condividere le informazioni con i nostri stakeholder. Deve integrarsi ed essere collegato con il nostro sistema di governance di progetto. 4.2. F ATTORI DA CONSIDERARE MENTRE DI ADATTA IL PMD P RO Nessun progetto esiste “a se stante”. I progetti "vivono" all'interno di programmi e portfoli. Inoltre, i progetti sono gestiti all’interno di un contesto di sistemi organizzativi e delle strutture dei donatori. In un certo senso, questi sono l'ambiente operativo esteso dei progetti. Di conseguenza, dal momento che tutti questi fattori impattano sulle prestazioni dei progetti, dovrebbero quindi essere presi in considerazione per l'adeguamento del PMD Pro. C ONSIDERAZIONI SUI P ROGRAMMI -­ Come affermato in precedenza in questa guida, i programmi sono costituiti da un gruppo di progetti correlati, che sono gestiti, in modo coordinato, per ottenere dei benefici e da sistemi di controllo non disponibili attraverso una loro gestione singola. Le tempistiche di un programma sono più lunghe e i suoi risultati, solitamente, più complessi rispetto ad Guida al PMD Pro 123 ogni singolo progetto concepito per dare un contributo al raggiungimento degli obiettivi comuni. Chiaramente, in un programma ben gestito, si avrà coerenza di strumenti, metodi e approcci. Alcune ONG hanno un dipartimento o un’unità di gestione dei programmi (PMU o PMO), il cui ruolo è quello di garantire la coerenza degli approcci e delle norme, lo sviluppo delle competenze, degli strumenti e dei manuali operativi. In tali situazioni, i responsabili di progetto e i loro teams devono uniformarsi alle linee guida della propria organizzazione. Inoltre, per quanto riguarda il collegamento tra programmi e progetti, le ONG che operano a livello internazionale nel development sector tendono a elaborare progetti grandi e complessi quando potrebbe essere più opportuno costruire un programma formato da una serie di progetti più piccoli e più semplici. C ONSIDERAZIONE SUL M ETODO – Raramente un Project Manager ha l'opportunità di influenzare la scelta dei sistemi organizzativi. Indipendentemente da ciò, il Project Manager deve fare in modo che il flusso di informazioni da e verso la sua organizzazione soddisfi le esigenze del suo team di progetto. I due esempi che seguono illustrano come un Project Manager debba esaminare e comprendere i sistemi organizzativi, al fine di trovare un sistema che meglio gli permetta di lavorare per il bene del progetto. Rendicontazione / reportistica finanziaria: i bilanci, nei bandi dei donatori, sono espressi generalmente in forma di bilanci di attività. Molte ONG, in realtà, non hanno sistemi finanziari che possono produrre rapporti basati su attività -­ ma utilizzano sistemi che riportano singole voci o codici. In tale caso, un Project Manager deve assicurare che il lavoro necessario per tradurre le informazioni finanziarie da un formato a un altro sia pianificato e attuato in modo tempestivo. Valuta del budget e tassi di cambio: Non è insolito per un Project Manager essere informato che "un progetto ha una perdita di 20.000 dollari dovuta al tasso di cambio, e che quindi ha bisogno di ridurre le attività per compensarla." Mentre le organizzazioni possono utilizzare delle strategie di copertura del rischio per cercare di ridurne l’impatto, le oscillazioni dei tassi di cambio non possono essere evitate. Ciò nonostante, un Project Manager può selezionare e utilizzare gli approcci di gestione più idonei per ridurre al minimo le perdite. Dato che la scelta della valuta da usare nel budget di progetto è spesso compiuta dal personale del reparto finanziario, o di raccolta fondi, questi spesso scelgono la valuta indicata nel contratto. Se le spese sono in una valuta diversa, questo complica immediatamente la vita al personale di progetto, che si trova con un bilancio in una valuta e le spese in un’altra. Anche se non sempre è possibile, un Project Manager insistere sul fatto che il bilancio e le spese debbano essere nella stessa valuta. Nel caso in cui la scelta della valuta non sia negoziabile, il Project Manager può insistere sull’applicazione di un tasso di cambio effettivo valido per tutta la durata del progetto, al posto di utilizzare un valore contabile facile da calcolare. Anche se tali strategie di gestione non ridurranno le fluttuazioni valutarie, aiutano a ridurre la variazione del tasso di cambio. C ONSIDERAZIONI SULLA DIMENSIONE , COMPLESSITÁ E RISCHIO -­ Il buon senso suggerisce che un progetto piccolo e semplice non richieda gli stessi riguardi di un progetto milionario effettuato in un contesto incerto, articolato su più zone, gestito da più teams e che interessa diversi stakeholder. Guida al PMD Pro 124 Indipendentemente da questa consapevolezza, ai fattori associati alle dimensioni, complessità e rischi vengono date, troppo spesso, insufficienti attenzioni da parte dei responsabili di progetto e dalle organizzazioni che lavorano nel development sector. Due ambiti importanti e correlati sono citati di seguito a titolo di esempio: Pianificazione e Gestione del Rischio -­ Un registro dei rischi è sempre utile. In un progetto non complesso e di basso valore, un semplice registro qualitativo del rischio può essere sufficiente. In un progetto con un profilo di rischio molto più elevato, un manager avrà probabilmente bisogno di un registro quantitativo del rischio. Inoltre, le norme di progetto per l'utilizzo e la modifica del registro del rischio saranno diverse. Chi può modificarlo? Chi può suggerire modifiche? Quando ci si deve rifare al registro? Come per tutti gli strumenti di PMD Pro, il Project Manager ha bisogno di pensare a come utilizzare al meglio gli strumenti e garantire che supportino il suo team di progetto. Governance di Progetto -­ Un settore chiave che necessita particolare attenzione nei progetti più complessi è la governance. I progetti piccoli e più semplici potrebbero condividere una governance con una serie di progetti simili -­ forse sotto un Comitato di Programma o sotto la responsabilità di un comitato dei progetti del Paese o di una struttura simile. Un progetto milionario, sviluppato in più zone e attraverso diversi team, avrà bisogno di un proprio Comitato di Progetto con un Responsabile Senior, un Rappresentate dei Fornitori e un Responsabile di Progetto che rappresenta gli stakeholder. Il Comitato di Progetto avrà bisogno di norme di riferimento e di funzionamento chiare e ben definite. I suoi membri devono capire bene i loro ruoli e responsabilità. Inoltre, può essere necessario modificare il profilo del Comitato che si occupa di un progetto di lunga durata, al fine di garantire che le siano rappresentate le adeguate prospettive. C ONSIDERAZIONI SULL ’ APPRENDIMENTO E SULLE COMPETENZE -­ Mentre il Project Manager è responsabile di assicurare che i membri del personale e i partner di implementazione abbiano le giuste competenze, comprese le conoscenze, le attitudini e le capacità, a lui non spetta, almeno nell’immediato, il compito di sviluppare le capacità necessarie per affrontare eventuali carenze. Una parte fondamentale dell’adattamento del PMD Pro sarà quella di valutare l'attuale livello delle competenze del personale e dei partner di progetto per poi promuovere un percorso di apprendimento per colmare le lacune che sono state identificate. Uno strumento chiamato diagramma a ragnatela, illustra il rapporto tra le attuali competenze (riferimento) e quelle desiderate (obiettivi) entro un dato periodo di tempo. La Figura 62 mostra come può essere usato un diagramma a regnatela. Si ricorda che ci sono molti altri strumenti utilizzabili per ottenere lo stesso risultato. Guida al PMD Pro 125 Figura 62: Diagramma a Ragnatela che mostra il rapporto tra i valori di riferimento e gli obiettivi per alcune competenze individuate dal PMD Pro Se, ad esempio, un Project Manager cerca di attuare una Work Breakdown Structure (WBS) senza fare in modo che ogni singolo membro del team e partner di attuazione ne capisca le basi, ne apprezzi il valore, e possa effettivamente utilizzare una WBS in una situazione reale, c’è la seria possibilità che la sua attuazione sia destinata al fallimento. Le organizzazioni che sviluppano il PMD Pro, avranno probabilmente già preso in considerazione molte delle esigenze di apprendimento e delle competenze necessarie. Tuttavia, un Project Manager deve comunque verificare che tutto il personale di progetto e i suoi partner possano utilizzare correttamente ognuno degli strumenti scelti nella pratica reale. Le mancanze/lacune che sono identificate in termini di prestazioni devono essere affrontati attraverso la formazione o altri interventi gestionali. C ONSIDERAZIONI SULLA PERFORMANCE -­ Il Project Manager non deve solo garantire che il personale di progetto accresca progressivamente le sue competenze ma che, soprattutto, le prestazioni sul posto di lavoro contribuiscano effettivamente a produrre l’impatto previsto dall’organizzazione. Va ricordato che i cambiamenti, per le organizzazioni che operano nel development sector, sono di solito orientati verso la qualità della vita, il benessere personale, la sostenibilità, la riduzione della povertà, la coscienza sociale, l’arricchimento della coscienza sociale o il miglioramento ambientale. Un corso di PMD Pro non deve essere visto come un evento "una tantum", ma deve essere l'inizio di un processo dinamico che grazie all’apprendimento permette un miglioramento delle prestazioni e, soprattutto, contribuisce ad un miglioramento continuo del progetto. Collegando il PMD Pro ai i risultati di un progetto e chiedendo che il personale sia responsabile di mettere in pratia quello che ha appreso, si offre ai Responsabili di Progetto la possibilità di vedere dei cambiamenti che siano significativi e al centro stesso degli obiettivi del progetto. Una ONG , dopo aver organizzato alcuni corsi di PMD Pro , ha deciso che tutti i partecipanti avrebbero dovuto sviluppare un piano individuale e continuo di apprendimento e di attuazione di PMD Pro (possibilmente coinvolgendo anche un team di progetto). Il modello richiedeva i Guida al PMD Pro 126 dettagli sull’applicazione di tecniche di Gestione di Progetto e sugli strumenti impiegati sul campo nell’arco di 12 mesi. Una persona, dell’ufficio gestione progetti della ONG, è stata designata per mantenere i rapporti con ogni singolo partecipante al corso e con il suo/a diretto superiore ad intervalli di 3 mesi per valutarne la conformità, il contributo offerto al raggiungimento dei risultati, e per raccogliere e condividere le best practice. L’ONG offre anche ai parteciapanti l’accesso virtuale (tramite telefono, e-­mail, social media, ecc) ad esperti della gestione di progetti in grado di consigliarli sull'uso / adattamento di strumenti di gestione e/o relativamente a problemi che possono presentarsi. Hanno anche deciso di iniziare con un’introduzione progressiva di strumenti di PM in un modo da permetterne una sperimentazione sul terreno, l'adattamento e un apprendimento contestualizzato. L’associazione ha stabilito che il primo “assaggio” di strumenti di lavoro doveva comprendere i 4 ritenuti piú importanti nella fase di sviluppo iniziale: hanno scelto la Matrice di assegnazione responsabilità (RACI), il Registro dei Rischi, Work Breakdown Structure (WBS), e il Registro dei Problemi. I N SINTESI -­ L'adattamento PMD Pro, come specificato in precedenza, è davvero essenziale. Tuttavia vogliamo sottolineare che il lavoro di un responsabile di progetto non deve essere ridotto a una serie di rigide regole da applicare sconsideratamente in ogni progetto, programma o portfolio. Ricordate, come affermato in precedenza in questa guida, che il project management è tanto un'“arte” quanto una “scienza”. Ci saranno circostanze in cui potrebbero essere utilizzati una tecnica o uno strumento di gestione, ma, per un qualsiasi numero di buone ragioni, questa potrebbe non essere la scelta più intelligente. In altre parole, essere troppo entusiasta nel richiedere l'adozione obbligatoria e uniforme di strumenti e tecniche in tutti i progetti, programmi o portfolio potrebbe rivelarsi un errore enorme. Ogni responsabile di progetto deve imparare a essere organizzato e attento, deve apprendere ad analizzare ogni singolo progetto prima di selezionare attentamente, e in modo collaborativo, il meglio del PMD Pro. Guida al PMD Pro 127 5. : APPENDICI 5.1. A PPENDICE 1: G LOSSARIO Attività Le azioni attraverso cui gli input (risorse finanziarie, umane, tecniche, materiali e di tempo) sono impiegati per produrre i deliverable (formazione, costruzione, ecc.) di un progetto, su cui il personale ha una responsabilità e che una volta aggregati producono gli output finali. Asset-­based Metodologia che cerca di scoprire e portare alla luce i punti di forza presenti all’interno delle comunità, come mezzo per uno sviluppo sostenibile Valutazione post operativa Una semplice, rapida e versatile attività di apprendimento che può essere utilizzata per identificare e registrare gli insegnamenti e le conoscenze emerse da un progetto Presupposti Ipotesi sulle le condizioni necessarie, interne ed esterne, identificate in fase di design di un progetto, per assicurare che le presunte relazioni di causa-­effetto funzionino come previsto e che le attività pianificate producano i risultati attesi Baseline Un punto di riferimento oggettivo riguardo le condizioni o le prestazioni presenti prima dell'inizio di un intervento – necessario come riferimento per il monitoraggio, la valutazione e il controllo del progetto. Tassonomia di Bloom Una classificazione dei livelli di conoscenze/abilità, per fornire una strutturazione dell’apprendimento. Stima Bottom-­Up Questa tecnica di valutazione consulta le stesse persone responsabili delle attività del progetto e aggrega le loro stime in un bilancio globale complessivo. Capacità Abilità, competenze, conoscenze, attitudini, valori, relazioni, comportamenti, motivazioni, risorse e condizioni che permettono agli individui, alle organizzazioni, alle reti/settori e al sistema sociale in generale di svolgere le proprie funzioni e raggiungere nel tempo i propri obiettivi. Certificato Un documento rilasciato a una persona, al completamento di un corso di studi. Competenze Un set integrato di competenze, conoscenze, atteggiamenti e comportamenti necessari per operare in modo efficace in un determinato lavoro, ruolo o situazione. Concept Note Una descrizione generale di un progetto, scritta per richiedere un feedback prima di impegnare risorse nello sviluppo di una proposta più dettagliata. Crashing Aggiunta di ulteriori risorse al progetto per accelerarne il progresso secondo la pianificazione Credenziali Prova di qualificazione, competenza o abilitazione, collegata a una Guida al PMD Pro 128 persona. Cammino Critico La sequenza di attività che identifica il percorso più lungo tra l'inizio del progetto e la sua fine. Momento Decisionale Punti di controllo principali, utilizzati per concludere e accettare i prodotti di una particolare fase del progetto e per passare alla fase successiva. Scomposizione Una tecnica per separare o suddividere i deliverable di un progetto elementi, componenti o parti più piccole. DM&V Design, Monitoraggio e Valutazione Development Organization Una varietà di organizzazioni i cui progetti e pratiche spaziano su un ampio ventaglio che varia tra il supporto nelle emergenze e lo sviluppo: da un lato facilitano development project partecipati e a lungo termine, in aree come l’ambiente, la salute, l’educazione e l’agricoltura;; all’altro lato implementano direttamente progetti di aiuto, rapidi e temporanei, per popolazioni che si trovino ad affrontare fame, mancanza di riparo o miseria in seguito a improvvisi disastri naturali o conflitti. Fast Tracking Accelerare le scadenze del progetto eseguendo attività che normalmente sarebbero state completate in sequenza, completandole invece in parallelo. Float (o Slack) La quantità di tempo di cui una attività può essere ritardata sul diagramma di progetto, senza causare un ritardo nela data di completamento del progetto stesso. Diagramma di Gantt Un grafico a barre che rappresenta graficamente la pianificazione delle attività di progetto. Obiettivo Il risultato finale o impatto desiderato di più alto livello (trasformazione, sostenibilità, mezzi di sussistenza, benessere ecc.), a cui contribuisce il progetto – l'obiettivo finale in molti Logical Framework. Initiation Il processo utilizzato per descrivere e autorizzare l’inizio di un progetto, permettendo al Project Manager di impegnare risorse, energie e denaro. Impatto Un effetto o risultato di lungo termine significativo (identificato con il livello dei risultati o degli obiettivi in molti Logical Framework). Input Le risorse che il progetto deve mobilitare e che si applicano alle sue attività (risorse umane e finanziarie, attrezzature, ecc.). Problema Un rischio che si è ormai verificato. Può assumere la forma di una decisione irrisolta, di una situazione o di un problema che avrà un impatto significativo sul progetto. Issue Control Log Un documento o un database che riepiloga i problemi, il loro stato attuale, e qual è la persona attualmente responsabile della loro risoluzione. Iterazione L'atto di ripetere un processo per due, tre o più volte, in modo da raggiungere lo scopo, l’obiettivo o il risultato desiderati. Guida al PMD Pro 129 Logistica Il processo di pianificazione, attuazione e controllo, in maniera efficiente e contenendo i costi, del flusso e stoccaggio delle materie prime, della gestione dell’inventario, dei prodotti finiti e delle relative informazioni dal punto di origine al punto di consumo, in maniera conforme alle esigenze del cliente. Diagramma di Rete Sintesi grafica delle decisioni e dei flussi che compongono una procedura o un processo dal suo inizio alla fine. Outcome Che cosa ci si aspetta di realizzare grazie al progetto, a livello dei beneficiari (ad es. uso di conoscenze e competenze nella pratica reale nel corso del tempo;; trasporto di merci sulle strade costruite, ecc), per creare cambiamenti a livello della popolazione (malnutrizione ridotta, miglioramenti dei redditi, maggiori rendimenti, ecc.) che aggreghino e contribuiscano a portare alla realizzazione degli obiettivi e dell'impatto desiderato nel tempo. Output I risultati finali tangibili derivanti dalle attività di progetto, compresi prodotti, beni, servizi e cambiamenti (ad es. persone addestrate con maggiori abilità e conoscenze;; costruzione di strade di qualità, ecc) che aggreghino e contribuiscano al raggiungimento dei risultati desiderati. Stima Parametrica Utilizzo dei dati storici di precedenti progetti simili, per dare una stima delle attività del progetto attuale. Questa tecnica di stima si basa meno sulle persone e più sui dati statistici. Portfolio Un mix di programmi/progetti attivi, e il relativo personale e budget assegnati a ciascuno di essi. Portfolio Management Avvio e gestione del portfolio complessivo dei programmi/progetti. Approvvigionamento Pianificazione e realizzazione di tutti gli aspetti legati all'acquisizione delle risorse, compreso sviluppo delle specifiche richieste, ricerche di mercato tra i fornitori, trattative, attività di acquisto, gestione dei contratti e controllo dell’inventario. Product Scope Tutti i necessari deliverable del progetto, conformi alle specifiche concordate. (Ciò che deve essere consegnato). Programma Un gruppo di progetti correlati, gestiti in modo coordinato per ottenere benefici e controllo non altrimenti possibili attraverso una loro gestione autonoma. Progetto Un insieme di attività che permettano il raggiungimento di obiettivi concordati, entro un determinato periodo di tempo, attraverso un insieme di risorse stabilito. Project Charter Un documento che descrive il progetto ad alto livello di dettaglio e che viene utilizzato per autorizzare il Project Manager ad iniziare i lavori. Controllo Progetto Il processo di misurazione e reporting sullo stato di avanzamento del progetto e l’adozione di azioni correttive per garantire che gli obiettivi siano soddisfatti. Guida al PMD Pro 130 Piano di Implementazione Una presentazione completa e logica del piano dettagliato del progetto, che contribuisce a garantire il rispetto dei vincoli temporali, di obiettivo, e di budget. Project Management Pianificazione, organizzazione e gestione delle risorse per realizzare con successo gli obiettivi specifici di progetto, i suoi risultati e i suoi output. Project Manager Un professionista nel campo el Project Management che ha la responsabilità di pianificare, implementare e concludere progetti per raggiungere gli obiettivi specifici del progetto, i suoi risultati e i suoi output. Proposta di Progetto Un'offerta chiara e concisa da sottomettere all’approvazione di un potenziale finanziatore, per la consegna di prodotti e/o servizi in risposta alle richieste del finanziatore o di bisogni individuati. Scope del Progetto Tutto il lavoro necessario per consegnare il prodotto finale. (Come i deliverable finali saranno realizzati e consegnati). Rischio L’effetto potenziale dell’incrtezza sugli obiettivi del progetto. Pianificazione Rolling Wave Processo iterativo per fornire livelli crescenti di dettaglio al progetto. Preparazione per l’implementazione nel tempo. Stima Top-­Down Questa tecnica di stima si basa su un gruppo relativamente piccolo di "esperti", che lavorano per stabilire una stima globale di progetto, per poi scomporlo in pacchetti di lavoro più piccoli. Work Breakdown Structure (WBS) Un elenco di attività gerarchico creato dalla scomposizione del progetto nelle sue parti componenti e la suddivisione del percorso del progetto in attività sempre più dettagliate. Guida al PMD Pro 131 5.2. A PPENDICE 2: O BIETTIVI DI APPRENDIMENTO DEL PMD P RO L'obiettivo dell'Appendice 2 è quello di identificare gli obiettivi di apprendimento associati alla guida al PMD Pro, che forniscono ai candidati all’esame (e agli enti di formazione) una definizione dettagliata di ciò che gli esami PMD Pro1 e PMD Pro2 andranno a valutare. Il Modello di Valutazione degli Obiettivi di Apprendimento del PMD Pro identifica quattro livelli: l’Esame PMD Pro1 misura i Livelli 1 e 2, mentre l’Esame PMD Pro2 misura i Livelli 3 e 4. Figura 1: Il Modello di Valutazione degli Obiettivi di Apprendimento del PMD Pro Modello di Valutazione degli Obiettivi di Apprendimento del PMD Pro 1. Conoscenza Definizione generica dal Modello di Valutazione degli Obiettivi di apprendimento dell’APMG Conoscere i fatti fondamentali, la terminologia e i concetti della guida/manuale 2. Comprensione 3. Applicazione Comprendere i Essere in grado di concetti chiave della applicare i concetti guida/manuale chiave delle aree del Syllabus ad un determinato scenario 4. Analisi Essere in grado di identificare, analizzare e distinguere tra uso appropriato e inappropriato del PMD Pro Figure 2: Learning Outcomes for the Guide to the PMD Pro Syllabus Area Code PR Level Area di Studio: Progetti nel development sector Topic Conoscere fatti, termini e concetti relativi all’Area di Studio: Progetti nel development sector. 01 01 PMD Pro1 PMD Pro2 Definire i termini del project management nell'ambito del contesto internazionale dello sviluppo, compresi progetti, programmi, portfolio e project management. Riferimento principale nel manuale 1.3, 1.4 01 02 Identificare i tre lati del triangolo del Triplo Vincolo definito nel PMD Pro. 1.3 01 03 Ricordare le competenze dei Project Manager nel development sector. 1.6 01 04 Ricordare le responsabilità del Project Manager nel development sector. 1.3 Comprendere l’Area di Studio: Progetti nel development sector. 02 01 Spiegare come la cultura dei progetti nel development sector differisca da quella di altri settori. 02 02 Mappare le competenze e le responsabilità dei Project Manager nel development sector. 02 03 Spiegare la relazione tra i lati del triangolo del Triplo Vincolo e le sue implicazioni sul project management. Essere in grado di applicare e adattare all’interno di uno scenario i concetti dell’Area di Studio: Progetti nel development sector. 03 01 Gestire le prestazioni del personale con diversi livelli di competenza nella gestione di progetti. Guida al PMD Pro 132 1.2 1.6 1.3 1.6 03 02 Identificare i vantaggi della gestione di un gruppo di progetti nell'ambito di un programma. 03 03 Identificare lo sviluppo di competenze richiesto affinché un membro del team di progetto progredisca da Project Manager di livello base a program manager. Dato uno scenario in cui i vincoli del progetto sono in continuo mutamento, individuare alternative per gestire il triangolo del Triplo Vincolo. 03 04 Essere in grado di identificare, analizzare e distinguere tra applicazione appropriata e inappropriata a uno scenario dei concetti dell’Area di Studio Progetti nel development sector. 04 01 Identificare le differenze nelle competenze di project management richieste all’aumentare della dimensione, complessità e rischio di uno scenario di progetto. 1.4 1.6 1.3 1.6 04 02 Confrontare e contrapporre contenuti, scopo e processi nei progetti, programmi e portfolio del development sector internazionale. 04 03 Identificare le implicazioni dei cambiamenti nei vincoli di progetto nella gestione del triangolo del Triplo Vincolo. 1.4 1.3 Syllabus Area Code PM Level Area di Studio: Modello delle Fasi di Progetto del PMD Pro PMD Pro1 Topic PMD Pro2 Conoscere fatti, termini e concetti relativi al Modello delle Fasi di Progetto del PMD Pro. 01 01 Identificare le sei fasi del Modello delle Fasi di Progetto del PMD Pro. 01 02 Ricordare i fatti, termini e concetti relativi alle sei fasi del generico ciclo di vita del progetto nel development sector internazionale Comprendere il Modello delle Fasi di Progetto del PMD Pro 02 02 02 02 01 02 03 04 01 2.2 2.2 2.2 Spiegare l'importanza di integrare i principi di project management in tutta la vita di un progetto. 133 2.2 Comprendere lo scopo e i vantaggi della gestione dei momenti decisionali attraverso il Ciclo di Vita del Progetto del PMD Pro. Guida al PMD Pro Spiegare la differenza tra definizione del progetto, monitoraggio e valutazione, e gestione del progetto nell'ambito del development sector internazionale. Capacità di applicare le sei fasi allo scenario di un determinato progetto, adattando ove appropriato le attività e le azioni consigliate. 2.2 Spiegare i modi in cui le fasi di progetto nel Modello del PMD Pro interagiscono tra loro. Essere in grado di applicare e adattare il Modello delle Fasi di Progetto del PMD Pro a uno scenario. 03 Riferimento principale nel manuale 2.2 2.2 Essere in grado di identificare, analizzare e distinguere tra appropriata e inappropriata applicazione a uno scenario dei concetti del Syllabus Modello delle Fasi di Progetto del PMD Pro. 04 01 2.2 Capacità di valutare l'applicazione delle sei fasi a un dato scenario di progetto, valutando se le attività rilevanti del processo siano state applicate correttamente. Area di Studio: Identificazione e Design del Progetto PMD Pro1 PMD Pro2 Syllabus Area Code ID Level Topic Conoscere fatti, termini e concetti relativi all’Area di Studio Identificazione e Design del Progetto. Riferimento principale nel manuale 01 01 Ricordare le tre categorie generali di lavoro nella Fase di Identificazione e Design del Progetto. 01 02 Identificare le finalità della raccolta e analisi dei dati. 2.2.1.1, 2.2.2.2 01 03 Identificare metodologie, approcci e strumenti per la raccolta dati. 2.2.1.2 01 04 Identificare metodologie, approcci e strumenti per l’analisi dei dati. 2.2.1.2 01 05 Identificare gli scopi del Logical Framework. 2.2.1.3 01 06 Definire le 5 caratteristiche di un indicatore SMART. 2.2.1.3 01 07 Richiamare i parametri chiave del progetto descritti nel Logical Framework. 2.2.1.3 01 08 Ricordare esempi di momenti decisionali nella vita di un progetto. 2.2.1.4 Comprendere la Fase di Identificazione e Design del Progetto. 02 01 Spiegare il concetto di riduzione delle opportunità per gestire efficacemente i costi di cambiamento durante la vita del progetto. 02 02 Identificare le differenze tra le quattro categorie di bisogni sociali. 02 03 Spiegare l'importanza della triangolazione nella fase di Identificazione e Design del Progetto. 02 04 Identificare le differenze tra dati primari (qualitativi e quantitativi) e dati secondari. 02 05 Spiegare le categorie di criteri che determinano ciò che è incluso negli interventi del progetto. 02 06 Capire la logica verticale e orizzontale del Logical Framework 02 07 Spiegare i vantaggi della gestione dei momenti decisionali nell'ambito del project management. Essere in grado di applicare e adattare la Fase di Identificazione e Design del Progetto. 03 01 Selezionare lo strumento più appropriato per gli obiettivi previsti di raccolta e analisi dei dati. Guida al PMD Pro 134 2.2.1 2.2.1 2.2.1.1 2.2.1.1 2.2.1.1 2.2.1.2 2.2.1.3 2.2.1.4 2.2.1.1, 2.2.1.2 03 02 Individuare gli elementi da includere negli interventi di progetto, basandosi su categorie di criteri decisionali chiaramente identificate. 03 03 Dato uno scenario, utilizzare criteri di go/no-­go per capire se un progetto debba essere autorizzato o meno. Essere in grado di identificare, analizzare e distinguere tra l’applicazione appropriata e inappropriata ad uno scenario dell’Area di Studio Identificazione e Design del Progetto. 2.2.1.2 2.2.1.4 Nello specifico: 04 01 Distinguere i vantaggi di ciascuna tipologia di raccolta dati. 04 02 Confrontare e contrapporre i deliverable e gli indicatori in ciascuno dei quattro livelli del Logical Framework del PMD Pro. 04 03 Spiegare le variazioni nella opportunità per gestire in modo conveniente il cambiamento durante la vita di un progetto. 04 04 Dato uno scenario di progetto, mostrare le differenze fra le 4 categorie di esigenze di progetto. 04 05 Interpretare la logica verticale e orizzontale di un Logical Framework. 04 06 Valutare la qualità degli indicatori di progetto basandosi sull'utilizzo dei criteri SMART. 2.2.1.1 2.2.1.3 2.2.1 2.2.1.1 2.2.1.3 2.2.1.3 Syllabus Area Code SU Level Area di Studio: Set-­up del Progetto PMD Pro1 PMD Pro2 Topic Conoscere fatti, termini e concetti relativi all’Area di Studio Set-­up del Progetto. Riferimento principale nel manuale 2.2.2.1 01 01 Conoscere gli obiettivi della fase di Set-­up del Progetto 01 02 Identificare le tre prospettive che devono essere rappresentate in un Comitato di progetto. 01 03 Identificare lo scopo della comunicazione di avvio del progetto. 2.2.2.4 Comprendere la fase di Set-­up del Progetto. 2.2.2.2 02 01 Comprendere lo scopo del Documento di Progetto. 2.2.2.3 02 02 Spiegare l'importanza di istituire una struttura di governance del progetto. 2.2.2.2 02 03 Spiegare la connessione tra le tolleranze di progetto e la governance del progetto 02 04 Spiegare le responsabilità dello Sponsor del progetto e del Comitato di progetto. Essere in grado di applicare e adattare ad uno scenario la Set-­up del Progetto. 03 01 Dato uno scenario di progetto, creare o aggiornare un Documento di Progetto. Guida al PMD Pro 135 2.2.2.1 2.2.2.2 2.2.2.3 03 02 Basandosi su uno scenario di progetto, identificare strategie per migliorare le prestazioni del progetto attraverso migliori processi di governance del progetto. Essere in grado di identificare, analizzare e distinguere tra l’applicazione appropriata e inappropriata ad uno scenario dell’Area di Studio Set-­up del Progetto. 04 01 Capacità di valutare l'applicazione delle azioni della fase di Set-­up del Progetto, in un dato scenario. 2.2.2.2 2.2.2 Syllabus Area Code PP Level Topic Area di Studio Pianificazione del Progetto PMD Pro1 PMD Pro2 Riferimento principale nel manuale Conoscere fatti, termini e concetti relativi all’Area di Studio Pianificazione del Progetto. 01 01 Ricordare fatti, termini e concetti relativi all'importanza e alla tempestività del piano di implementazione del progetto. 01 02 Identificare le otto componenti di un piano di progetto completo. 01 03 Identificare i vantaggi derivanti dallo sviluppare il piano di progetto attraverso un processo partecipativo. Comprendere la Fase di Pianificazione del Progetto. 2.2.3 2.2.3.3 2.2.3.5 2.2.3.2 -­2.2.3.6 2.2.3.6 2.2.3 Nello specifico: 02 01 Spiegare l'importanza di incorporare ciascuno dei principi di gestione di progetto del PMD Pro nel processo di pianificazione del progetto. 02 02 Comprendere i vantaggi della pianificazione Rolling Wave. 02 03 Confrontare e contrapporre il Logical Framework, la proposta e il piano di implementazione di un progetto. Essere in grado di applicare e adattare ad uno scenario la Fase di Pianificazione del Progetto. Nello specifico: 03 01 Identificare scenari dove occorre utilizzare un approccio Rolling Wave nella pianificazione del progetto. 2.2.3.6 03 02 Basandosi su diversi scenari, identificare i punti di forza e le debolezze nella pianificazione del progetto in termini di equilibrio, completezza, integrazione, partecipazione e iteratività. 2.2.3.2 – 2.2.3.6 Essere in grado di identificare, analizzare e distinguere tra l’applicazione appropriata e inappropriata ad uno scenario dell’Area di Studio Pianificazione del Progetto Nello specifico: Guida al PMD Pro 136 04 01 Confrontare e contrapporre le finalità del Logical Framework, della Proposta di progetto e del Piano di implementazione del progetto, in termini di finalità, contenuti, destinatari e processo. 2.2.3.3 04 02 Spiegare il rapporto tra le varie aree della teoria della gestione dei progetti e un Piano di progetto completo. 2.2.3.3 04 03 Spiegare la relazione che intercorre tra il triangolo dei vincoli di progetto e un Piano di progetto integrato. 2.2.3.4 Syllabus Area Code PI Area di Studio: Implementazione del Progetto PMD Pro1 PMD Pro2 Level Topic Conoscere fatti, termini e concetti relativi alla fase di Implementazione del Progetto. 2.2.4.1 – 2.2.4.3 01 Definire i termini relativi all’implementazione del progetto, comprese le problematiche, la loro registrazione e i controlli interni. 01 02 Identificare i quattro processi fondamentali del processo di gestione dei problemi. 01 03 Identificare le attività utilizzate per gestire il personale durante la realizzazione del progetto. 2.2.4.1 2.2.4.2 02 01 Capire l'importanza della gestione dei problemi nell’implementazione dei development project. 02 02 Spiegare la sequenza e la relazione che sussiste tra i quattro processi fondamentali della gestione delle problematiche. 02 03 Identificare i vantaggi di un sistema di controllo interno ben gestito. Essere in grado di applicare e adattare ad uno scenario la Fase di Implementazione del Progetto. 2.2.4.1 2.2.4.1 2.2.4.3 03 01 Sviluppare un registro delle problematiche basato su uno scenario di progetto. 03 02 Applicare le quattro fasi del processo di gestione dei problemi in uno scenario di progetto. Essere in grado di identificare, analizzare e distinguere tra l’applicazione appropriata e inappropriata ad uno scenario dell’Area di Studio Implementazione del Progetto. 04 01 Identificare alternative per sistemi di controllo interno basati su categorie di sistemi amministrativi, finanziari e logistici. 01 Comprendere la Fase di Implementazione del Progetto Riferimento principale nel manuale 2.2.4.1 2.2.4.1 2.2.4.3 Syllabus Area Code ME Area di Studio: Monitoraggio, Valutazione e Controllo del Progetto Guida al PMD Pro 137 PMD Pro1 PMD Pro2 Riferimento principale nel manuale Level Topic Conoscere fatti, termini e concetti relativi a Monitoraggio, Valutazione e Controllo del Progetto. 01 01 01 02 Ricordare fatti, termini e concetti relativi ai diversi approcci per la valutazione dei progetti. 01 03 Ricordare fatti, termini e concetti relativi al piano di monitoraggio e valutazione del progetto. 01 04 Ricordare fatti, termini e concetti relativi al sistema di gestione del cambiamento. Comprendere la Fase di Monitoraggio, Valutazione e Controllo del Progetto. Ricordare fatti, termini e concetti relativi ai livelli di monitoraggio/valutazione dei progetti e il loro collegamento con il Logical Framework del progetto. 2.2.5.1 – 2.2.5.3 2.25.2 2.2.5.2 02 01 Identificare i sei elementi di un sistema di monitoraggio del progetto. 2.25.2 02 02 Identificare le sei aree di tolleranza del progetto 2.2.5.5 02 03 Spiegare il compromesso tra costo e complessità durante la raccolta dei dati per il monitoraggio. Essere in grado di applicare e adattare ad uno scenario la Fase di Monitoraggio, Valutazione e Controllo del Progetto. 2.2..5.2 03 01 Spiegare l'importanza del piano di monitoraggio e come il suo contenuto si differenzi da quanto incluso nel Logical Framework e nel piano di progetto. 03 02 Comprendere gli elementi che dovrebbero contribuire al monitoraggio del progetto e al piano di valutazione. 03 03 Spiegare le ragioni per cui si valutano i progetti. Essere in grado di identificare, analizzare e distinguere tra l’applicazione appropriata e inappropriata ad uno scenario dell’Area di Studio Monitoraggio, Valutazione e Controllo del Progetto. Confrontare e contrapporre i contenuti, il processo e la scopo degli indicatori quantitativi e qualitativi. 04 02 Confrontare e contrapporre il costo e la complessità di diversi approcci al monitoraggio. 04 03 Confrontare le differenze tra il monitoraggio, la valutazione e il controllo di un progetto. 04 04 Spiegare la relazione tra la valutazione e monitoraggio del progetto e il processo iterativo di pianificazione. 04 05 Differenziare gli indicatori di monitoraggio e valutazione ai diversi livelli del Logical Framework del progetto. 138 2.2.5.3 01 Guida al PMD Pro 2.2.5.2 04 2.2.5.2 2.2.5.2 2.2.5.2 2.2.5.1 2.2.5.1 2.2.5.1 Syllabus Area Code EP Area di Studio: Transizione di Fine Progetto PMD Pro1 PMD Pro2 Level Topic Conoscere fatti, termini e concetti relativi all’Area Transizione di Fine Progetto. 2.2.6.1 01 Ricordare le 4 opzioni per la transizione di fine progetto. 01 02 Ricordare le attività legate alla chiusura amministrativa, contrattuale e finanziaria dei progetti. 01 03 Identificare il processo in due fasi per la verifica dei risultati finali del progetto. 2.2.6.3 2.2.6.2 02 01 Differenziare tra riesame degli insegnamenti appresi e valutazione finale del progetto. 02 02 Spiegare lo scopo e il contenuto di una matrice di pianificazione della transizione di fine progetto. Essere in grado di applicare e adattare ad uno scenario la Fase di Transizione di Fine Progetto. 2.2.6.4 2.2.6.1 03 01 Sviluppare una strategia per la transizione di fine progetto. 03 02 Scegliere i migliori strumenti per l’apprendimento di fine-­di-­progetto, basandosi su vincoli di progetto e obiettivi di apprendimento. Essere in grado di identificare, analizzare e distinguere tra l’applicazione appropriata e inappropriata ad uno scenario dell’Area di Studio Transizione di Fine Progetto. 01 Comprendere la Fase Transizione di Fine Progetto. Riferimento principale nel manuale 2.2.6.1 2.2.6.4 04 01 Distinguere tra appropriata e inappropriata chiusura amministrativa, contrattuale e finanziaria di un progetto. 04 02 Confrontare e contrapporre le diverse opzioni per l'apprendimento di fine progetto. 04 03 Distinguere tra appropriata e inappropriata chiusura amministrativa, contrattuale e finanziaria. 2.2.6.4 2.2.6.5 3.3.6.4 Syllabus Area Code DO Area di Studio: Overview delle Discipline di Project Management PMD Pro1 PMD Pro2 Level Topic Conoscere fatti, termini e concetti relativi all’Area Overview delle Discipline di Project Management. 01 01 Conoscere le sei discipline del project management. Comprendere l’argomento Overview delle Discipline di Project Management. 02 01 Capire come il ciclo di progetto del PMD Pro è supportato dalle sei discipline del project management. Guida al PMD Pro 139 Riferimento principale nel manuale 3.0 3.0 02 02 Spiegare come le sei discipline possono essere applicate all'interno del ciclo di progetto del PMD Pro. Essere in grado di applicare e adattare ad uno scenario l’argomento Overview delle Discipline di Project Management. 03 01 Capacità di applicare le sei discipline a uno specifico scenario di progetto. Essere in grado di identificare, analizzare e distinguere tra l’applicazione appropriata e inappropriata ad uno scenario dell’argomento Overview delle Discipline di Project Management. 04 01 Capacità di valutare l’applicazione delle sei discipline a uno specifico scenario di progetto. 3.0 3.0 3.0 Syllabus Area Code SM Area di Studio: Gestione dello Scope PMD Pro1 PMD Pro2 Level Topic Conoscere fatti, termini e concetti relativi alla Gestione dello Scope. Riferimento principale nel manuale 01 01 Ricordare fatti, termini e concetti relativi alla gestione dello scope, tra cui scope del prodotto, scope del progetto e WBS. 01 02 Identificare i benefici della Work Breakdown Structure. 3.1.2 3.1.1 Comprendere la Gestione dello Scope. 3.1.1 – 3.1.2 02 01 Capire la differenza tra scope di prodotto e scope di progetto. 02 02 Comprendere che lo scope di progetto deve essere confermato e deve essere definito in modo completo e dettagliato. 02 03 Capire i tre problemi più comuni che derivano dall'assenza di uno scope ben definito. 02 04 Capire la composizione di una WBS (Work Breakdown Structure). 3.1.2 02 05 Spiegare i vantaggi dei due formati di WBS. 3.1.2 Essere in grado di applicare e adattare ad uno scenario la Gestione dello Scope. 3.1.1 3.1.1 03 01 Produrre una semplice Work Breakdown Structure in formato indentato, sulla base di uno scenario di progetto. 03 02 Produrre una semplice Work Breakdown Structure in formato grafico, sulla base di uno scenario di progetto. Essere in grado di identificare, analizzare e distinguere tra l’applicazione appropriata e inappropriata della Gestione dello Scope ad uno scenario. 01 Spiegare in maniera completa e dettagliata lo scope di prodotto e lo scope di progetto attraverso l'uso di un dato scenario di progetto. 04 02 Valutare una Work Breakdown Structure in termini di completezza e dettaglio per un dato scenario di progetto. Guida al PMD Pro 140 3.1.2 04 3.1.2 3.1.1 3.1.2 Syllabus Area Code TM Area di Studio: Gestione dei Tempi PMD Pro1 PMD Pro2 Level Topic Conoscere fatti, termini e concetti relativi alla Gestione dei Tempi 3.2.0 01 01 Conoscere i 5 passi della pianificazione dello schedule. 01 02 Definire i termini relativi alla gestione dei tempi, inclusi diagramma di rete, cammino critico, diagramma di Gantt, float del progetto, “fast tracking” e “crashing”. Comprendere la Gestione dei Tempi. Riferimento principale nel manuale 3.2.1-­3.2.5 02 01 Capire i cinque passi del processo di pianificazione dello schedule. 3.2.0 02 02 Spiegare la relazione tra stima delle risorse e sviluppo del calendario. 3.2.2 – 3.2.3 02 03 Comprendere la relazione tra il triangolo dei vincoli di progetto e lo sviluppo dello schedule. 02 04 Capire lo scopo, la struttura e il contenuto di un diagramma di Gantt. 3.2.4 02 05 Capire lo scopo, la struttura e il contenuto di un diagramma di rete. 3.2.1 02 06 Spiegare lo scopo e il processo di “crashing” e “fast tracking”. Essere in grado di applicare e adattare ad uno scenario la Gestione dei Tempi. 3.2..0 03 01 Capacità di costruire un semplice diagramma di rete, in un dato scenario di progetto. 03 02 Capacità di costruire un semplice diagramma di Gantt, in un dato scenario di progetto. 03 03 Capacità di identificare i fattori determinanti la potenziale durata del progetto, in un dato scenario di progetto. 03 04 Capacità di individuare il percorso critico di un progetto in un diagramma di rete, in un dato scenario di progetto. Essere in grado di identificare, analizzare e distinguere tra l’applicazione appropriata e inappropriata della Gestione dei Tempi ad uno scenario. 01 Discriminare quali attività in un diagramma di rete specificato fanno parte del percorso critico di un progetto e quali invece hanno uno slack. 04 02 Capacità di spiegare quando viene utilizzato un diagramma di Gantt di sintesi e quando un diagramma di Gantt. 04 03 Identificare le opportunità di gestire progetti in ritardo attraverso “crashing“ e “fast tracking”. 04 03 Dato un budget, analizzare la variazione dei costi cumulati di un progetto. 04 03 Dato un budget e i dati sui tempi, analizzare lo stato dell’Earned Value di un progetto. Guida al PMD Pro 141 3.2.1 – 3.2.4 3.2.4 3.2.3 3.2.3 04 3.2.5 3.2.3 3.2.4 3.2.5 3.3.3 3.3.3 Syllabus Area Code FM Area di Studio: Gestione delle Risorse PMD Pro1 PMD Pro2 Level Topic Conoscere fatti, termini e concetti relativi alla Gestione delle Risorse Finanziarie. 01 01 01 02 Riferimento principale nel manuale 3.3.1 – 3.3.3 Definire i termini relativi alla gestione finanziaria, compresi costi diretti, costi indiretti, costi di transazione, servizi condivisi, piano dei conti, varianza e analisi dell’earned value. Definire I tre approcci per determinare le stime di progetto. 3.3.5 Comprendere la Gestione delle Risorse Finanziarie. 02 01 Spiegare il vantaggio di sviluppare la fase di bilancio previsionale. 3.3.5 02 02 Capire i vantaggi e gli svantaggi delle tre tecniche di stima. 3.3.5 02 03 Spiegare l'importanza di monitorare il flusso di cassa. 3.3.6 02 04 Comprendere il significato dell'analisi dell’earned value. Essere in grado di applicare e adattare ad uno scenario la Gestione delle Risorse Finanziarie. 3.3.6 03 01 Capacità di costruire un semplice budget. 3.3.6 03 02 Spiegare il processo di misurazione dell’Earned Value. 3.3.6 03 03 Spiegare lo scopo e la costruzione di un piano dei conti. 3.3.3 03 04 Dato uno scenario di progetto, selezionare tra le stime Top-­down, Bottom-­
up e basate su dati parametrici. Essere in grado di identificare, analizzare e distinguere tra l’applicazione appropriata e inappropriata della Gestione delle Risorse Finanziarie ad uno scenario. 3.3.5 04 01 Capacità di valutare l'applicazione di sviluppo del budget per un dato scenario di progetto. 04 02 Identificare i vantaggi dell'analisi dell’Earned Value. 3.3.6 04 03 Dato un budget, analizzare la varianza di costo complessivo di un progetto. 3.3.6 04 03 Dato un budget e I dati sui tempi, analizzare l’earned value di un progetto. 3.3.6 Conoscere fatti, termini e concetti relativi alla Gestione della Supply Chain. 3.3.6 01 01 Identificare i 3 componenti che compongono la gestione della supply chain. 3.3.7 01 02 Identificare i 3 passi nella gestione dell’approvvigionamento. 3.3.7.1 3.3.7.2 Comprendere la Gestione della Supply Chain. 02 01 Spiegare i 2 elementi della gestione logistica. 02 02 Identificare alternative per identificare fornitori durante il processo di approvvigionamento. Essere in grado di applicare e adattare ad uno scenario la Gestione della Supply Chain. 03 01 Capacità di applicare i principi della Gestione della Supply Chain a uno scenario di progetto. Guida al PMD Pro 142 3.3.7.1 3.3.7 Essere in grado di identificare, analizzare e distinguere tra l’applicazione appropriata e inappropriata della Gestione della Supply Chain ad uno scenario. 04 01 Capacità di valutare, utilizzando i contenuti consigliati, l'uso dei seguenti processi di Supply Chain in un dato scenario di progetto: gestione degli approvvigionamenti;; gestione della logistica;; gestione patrimoniale;; e gestione delle informazioni. 3.3.7 Syllabus Area Code RM Area di Studio: Gestione del Rischio PMD Pro1 PMD Pro2 Level Topic Conoscere fatti, termini e concetti relativi alla Gestione del Rischio. Riferimento principale nel manuale 3.4.0 01 01 Identificare le quattro fasi del processo di gestione del rischio. 01 02 Definire i termini relativi alla gestione dei rischi, compresi rischi positivi, rischi negativi, registro dei rischi, matrice di valutazione del rischio e tolleranze di rischio. Identify the four risk response strategies. 3.4.3 01 03 Comprendere la Gestione del Rischio. 3.4.1 -­ 3.4.4 02 01 Spiegare il significato di probabilità e impatto nel contesto della gestione del rischio. 02 02 Spiegare la natura iterativa della gestione del rischio e la sua importanza durante tutta la vita del progetto. 02 03 Comprendere i contenuti e la struttura di un registro dei rischi. 02 04 Spiegare lo scopo, la struttura e il contenuto di una matrice di valutazione del rischio. Essere in grado di applicare e adattare ad uno scenario la Gestione del Rischio. 3.4.2 3.4.4 3.4.1 3.4.2 03 01 Applicare la matrice di valutazione del rischio ad un dato scenario di progetto. 03 02 Organizzare i rischi di progetto secondo categorie di rischio. 03 03 Capacità di applicare le quattro strategie di gestione del rischio a diversi scenari. Essere in grado di identificare, analizzare e distinguere tra l’applicazione appropriata e inappropriata della Gestione del Rischio ad uno scenario. 04 01 3.4.2 3.4.1 3.4.1 – 3.4.4 3.4.2 Interpretare una matrice di valutazione del rischio per differenziare i rischi che possono essere tollerati dai rischi che possono essere eliminati in un semplice scenario di progetto. 04 02 Categorizzare le strategie di risposta ai rischi. 3.4.3 04 03 Interpretare il contenuto di un registro dei rischi. 3.4.1 Guida al PMD Pro 143 Syllabus Area Code JM Area di Studio: Gestione della Motivazione del Progetto PMD Pro1 PMD Pro2 Level Topic Conoscere fatti, termini e concetti relativi alla Gestione della Motivazione del Progetto. 01 01 02 01 Capire l'importanza di motivare il progetto sia con il team di progetto, che con gli stakeholder del progetto. 02 02 Differenziare tra approcci basati sulle problematiche e approcci basati sulle risorse nell’identificazione dei bisogni. 02 03 Comprendere la relazione tra un albero dei problemi e un albero degli obiettivi. 02 04 Identificare e spiegare i livelli gerarchici nel processo di definizione di un albero dei problemi. Essere in grado di applicare e adattare ad uno scenario la Gestione della Motivazione del Progetto. 3.5.1 – 3.5.2 Definire i termini relativi alla gestione della motivazione del progetto, compreso identificazione dei bisogni sulla base dei problemi, identificazione dei bisogni sulla base delle risorse, albero dei problemi e albero degli obiettivi. Comprendere la Gestione della Motivazione del Progetto. Primary Manual Reference 3.5.0 3.5.1 3.5.2 3.5.2 03 01 Creare un semplice albero dei problemi, dato uno scenario di progetto. 3.5.2 03 02 Creare un albero degli obiettivi basandosi su un dato albero dei problemi. 3.5.2 03 03 Determinare come gli interventi di progetto proposti sono allineati con I criteri che giustificano il progetto, in un dato scenario. Essere in grado di identificare, analizzare e distinguere tra l’applicazione appropriata e inappropriata della Gestione della Motivazione del Progetto, in un dato scenario. 3.5.2 04 01 Capacità di valutare se c'è un'adeguata giustificazione per un intervento di progetto, basandosi su un approccio basato sui bisogni. 3.5.2 04 02 Interpretare le relazioni di causa ed effetto in un albero dei problemi. Confrontare e contrapporre gli approcci basati sui problemi dagli approcci basati sulle risorse nell’identificazione dei bisogni. PMD Pro1 PMD Pro2 3.5.2 3.5.1 Syllabus Area Code SM Area di Studio: Gestione degli Stakeholder Level Topic Conoscere fatti, termini e concetti relativi alla Gestione degli Stakeholder. Guida al PMD Pro 144 Riferimento principale nel manuale 01 01 Elencare le sei categorie di stakeholder. 3.6.1 01 02 Conoscere i componenti del grafico RACI. 3.6.3 01 03 Sapere che la comunicazione con gli stakeholder è essenziale e richiede pianificazione e messa in pratica. 01 04 Ricordare gli strumenti utilizzati per identificare gli stakeholder in termini di influenza, rischio e dipendenza dal progetto. Comprendere la Gestione degli Stakeholder. 3.6.4 3.6.2 02 01 Capire i quattro ruoli chiave identificati in un grafico RACI. 3.6.3 02 02 Capire i componenti di un piano di comunicazione. 3.6.4 02 03 Spiegare lo scopo e la costruzione degli strumenti di analisi degli stakeholder, inclusi il grafico RACI, il diagramma di Venn, le matrici di analisi degli stakeholder e i piani di comunicazione. Essere in grado di applicare e adattare ad uno scenario la Gestione degli Stakeholder. 3.6.1 – 3.6.4 03 01 Classificare i gruppi di stakeholder in un dato scenario di progetto. 3.6.1 03 02 Costruire un diagramma di Venn per un dato scenario di progetto. 3.6.2 03 03 Costruire una matrice RACI per un dato scenario di progetto. 3.6.3 03 04 Costruire una matrice di analisi degli Stakeholder per un dato scenario di progetto. 03 05 Applicare le componenti consigliate per il piano di comunicazione in un dato scenario di progetto. Essere in grado di identificare, analizzare e distinguere tra l’applicazione appropriata e inappropriata della Gestione degli Stakeholder, in un dato scenario 2.6.2 3.6.4 Nello specifico: 04 01 Interpretare il contenuto degli strumenti di gestione degli stakeholder, inclusi il grafico RACI, il diagramma di Venn, le matrici di analisi degli stakeholder e i piani di comunicazione. 3.6.1 – 3.6.4 Syllabus Area Code AD Area di Studio: Adattare il PMD Pro PMD Pro1 PMD Pro2 Level Topic Conoscere fatti, termini e concetti relativi all’area di studio Adattare il PMD Pro. 01 01 Ricordare i principi dell'adattamento. Comprendere l’area di studio Adattare il PMD Pro. 4.1 4.2 01 Comprendere i fattori da considerare nell'adeguare il PMD Pro ai progetti. 02 02 Comprendere il ruolo dei sistemi nell'adattare strumenti e tecniche del PMD Pro. 145 02 Guida al PMD Pro Riferimento principale nel manuale 4.2 02 03 Comprendere la relazione tra il profilo di rischio di un progetto e la scelta strumenti e tecniche del PMD Pro. 02 04 Riconoscere il valore delle considerazioni che è necessario fare durante l'implementazione dei progetti utilizzando il PMD Pro, attraverso dei partner coinvolti nell’implementazione. Essere in grado di applicare e adattare ad uno scenario l’Adattamento del PMD Pro. 4.2 4.2 03 01 Adattare le discipline del PMD Pro a specifici scenari di progetto. 03 02 Formulare raccomandazioni per applicare i principi del PMD Pro ai programmi e in senso più ampio all'organizzazione. Essere in grado di identificare, analizzare e distinguere tra l’applicazione appropriata e inappropriata di questa Area di Studio a uno scenario. 01 Interpretare le applicazioni di strumenti e tecniche del PMD Pro ad un progetto specifico. 04 02 Collegare strumenti e tecniche del PMD Pro ai processi di business. Guida al PMD Pro 146 4 04 4 4 4 5.3. A PPENDICE 3: R IFERIMENTI Blackman, Rachel, 2003, Project cycle management, Teddington: Tearfund. Boston University Corporate Education Center, Project Management Competency Development Process. Britton, Bruce, Heaney, Deborah, Sterne, Rod, 2001, The Partnership Toolbox, London: WWF. Council of Europe and European Commission, 2000, Project Management T-­Kit, Strasbourg: Council of Europe publishing. Dearden, Philip N., 2001, Program and Project Cycle management (PPCM): Lessons from DFID and other organizations, Tokyo: CIDT. Deming, W. Edwards, 1986,. Out of the Crisis, Boston: MIT Center for Advanced Engineering Study. Department for International Development (DFID), 2002, Tools for Development – version 15, DFID, Impact Assessment & Project Management Cycle (PMC). Emergency Capacity Building Project (ECB), 2007, Impact Measurement and Accountability in Emergencies The Good Enough Guide. London: Oxfam Publishing. Erwin, James, Smith, Michael L., Role & Responsibility Charting (RACI). European Commission, 2004, Aid Delivery Methods volume 1 Project Cycle Management Guidelines, Brussels: European Commission. Foundation Terre des Hommes, 2001, Project Cycle Handbook, Le Mont-­sur-­Lausanne: Foundation Terre des Hommes. Gardner, Alison, Greenblott, Kara, Joubert, Erika, 2005, What We Know About Exit Strategies Practical Guidance For Developing Exit Strategies in the Field, C-­SAFE Regional Learning Spaces Initiative. GB Equal Support Unit, A Project Cycle Management and Logical Framework Toolkit – A practical guide for Equal Development Partnerships, Herefordshire: Local Livelihoods Ltd. Geyer, Yvette, 2005, Project Management, Pretoria: IDASA. GTZ, Manual of Project Management for Development Practitioners. International Fund for Agricultural Development (IFAD), Participatory Approaches for an Impact-­
Oriented Project Cycle International Fund for Agricultural Development, 2002, A Guide for Project M&E, Rome: IFAD. Levine, Carlisle J., 2007, Catholic Relief Services’ (CRS) Guidance for Developing Logical and Results Frameworks, Baltimore: CRS. Lipczinsky, Malte, 1996, Getting to Know PEMT, Berne: SDC, Evaluation Section. Guida al PMD Pro 147 McMillan, Della E., Willard Alice, 2006, Preparing for the Evaluation Guidelines and Tools for Pre-­
Evaluation Planning, Baltimore: CRS. Mercy Corps, 2005, Design, Monitoring and Evaluation – Guidebook, Portland: Mercy Corps. Novartis Foundation for Sustainable Development, Project Management Handbook, A Working Tool for Project Managers. Pataki, George E., Dillon, James T., 2003, McCormack Michael, Project Management, Guidebook Release 2, New York: New York State Office for Technology. Picard, Mary, 2001, Course Materials for the Design, Monitoring and Evaluation (DME) Course, Kosovo: CARE. Plan International, 2002, Project Management Methodology Project Management Institute. 2004. A Guide to the Project Management Body of Knowledge: PMBOK® Guide – Third Edition. Rugh, J. 2002, Comparisons between Terminologies of Different Donor Agencies for Results/ Logical Frameworks, Atlanta: CARE International and InterAction’s Evaluation Interest Group. Saldanha, Cedric D., Whittle, John F., 1998, Using the Logical Framework for Sector Analysis and Project Design: A User’s Guide, Manila: Asian Development Bank. Siles R. 2004, Guidelines for Planning, Implementing and Managing a DME Project Information System. Atlanta: CARE. Standish Group. 1995. The Chaos Report. Boston: The Standish Group. Stetson, G. Sharrock, and S. Hahn, 2004, Propack The CRS Project Package: Project Design and Proposal Guidance for CRS Project and Program Managers. Baltimore: CRS. Stetson, S. Hahn, D. Leege, D. Reynolds and G. Sharrock, 2007, Propack II The CRS Project Package: Project Management and Implementation Guidance for CRS Project and Program Managers. Baltimore: CRS. The Centre for Development and Population Activities, 1994, Project Design for Program Managers, Washington, D.C.: The Centre for Development and Population Activities. United Nations Environment Program, 2005, UNEP project manual: formulation, approval, monitoring and evaluation. VCP, 2003, Facts for Projects (draft version). Verzuh, Eric, 2008, The Fast Forward Project Management-­Third Edition, New Jersey: John Wiley & Sons, Inc. Wheelwright, S.C., Clark, K.B. 1995, LEADING Product Development: A Senior Manager's Guide to Creating and Shaping the Enterprise, New York: Free Press. Wideman, Max, 2001, Project Management Simply Explained A Logical Framework to Help Your Understanding, Vancouver: AEW Services Guida al PMD Pro 148 World Bank, 2006, Managing the Implementation of Development Projects – New Edition. World Vision Development Resource Team, 2007, Learning through Evaluation with Accountability and Planning: World Vision’s Approach to Design, Monitoring and Evaluation (LEAP) – Second Edition, Washington, DC: World Vision International. World Vision Development Resource Team, 2009, LEAP Lexicon – Second Edition, Washington, DC: World Vision International. Youker, Robert, 1989, Managing the project cycle for time, cost and quality: lessons from World Bank experience, Butterworth & C. (Publishers) Ltd.. Guida al PMD Pro 149 5.4. I NDICE DELLE F IGURE Figura 1: I Cinque Principi del PMD Pro per il Project Management ...................................................... 3 Figura 2: il PMD Pro è il Programma di Certificazione di PM4NGOs ..................................................... 4 Figura 3: Rischi dei Progetti nel Development sector ............................................................................ 5 Figura 4: Risultati del Chaos Report ...................................................................................................... 6 Figura 5: il Triangolo del Triplo Vincolo .................................................................................................. 8 Figura 6: Relazioni tra Progetti, Programmi e Portfolio ........................................................................ 11 Figura 7: Elementi esemplificativi delle quattro Aree di Competenza .................................................. 13 Figura 8: Ciclo di Vita del Progetto secondo FAO ................................................................................ 15 Figura 9: Il Modello delle Fasi di Progetto Secondo PMD Pro ............................................................. 16 Figura 10: Interazioni tra le Fasi del Progetto ...................................................................................... 18 Figura 11: La Fase di Identificazione e Design del progetto ................................................................ 19 Figura 12: Opportunità di gestire efficientemente il cambiamento ....................................................... 20 Figura 13: Triangolazione dei bisogni attraverso la Classificazione di Bradshaw ................................ 22 Figura 14: Strumenti per la raccolta dei dati ......................................................................................... 24 Figura 15: Strumenti di analisi .............................................................................................................. 26 Figura 16: Criteri per determinare cosa includere negli Interventi di Progetto ..................................... 27 Figura 17: Terminologia del Logical Framework da una analisi trasversale delle development organization .......................................................................................................................................... 30 Figura 18: Logica Verticale del Logical Framework ............................................................................. 31 Figura 19: Logica orizzontale del Logical Framework .......................................................................... 32 Figura 20: Linee guida per gli indicatori dei livelli del Logical Framework ............................................ 33 Figura 21: Il Logical Framework del progetto Delta River .................................................................... 35 Figura 22: Un esempio di Momento Decisionale nella vita di un Progetto ........................................... 37 Figura 23: Fase di Set-­up del progetto ................................................................................................. 39 Figura 24: Fase di Pianificazione del Progetto ..................................................................................... 44 Figura 25: Proposta di Progetto vs. Piano di Implementazione ........................................................... 45 Figura 26: Elementi di un Progetto completo ....................................................................................... 47 Guida al PMD Pro 150 Figura 27: Fase di Implementazione del Progetto ................................................................................ 51 Figura 28: Tabella dei Problemi ........................................................................................................... 53 Figura 29: Monitoraggio, Valutazione e Controllo di un Progetto ......................................................... 56 Figura 30: Il Cosa, Come, Quando e Perché del Monitoraggio ............................................................ 57 Figura 31: Esempi di indicatori di Monitoraggio ................................................................................... 57 Figura 32: Esempi di indicatori di valutazione ...................................................................................... 58 Figura 33: Esempio di un piano di Monitoraggio e Valutazione di progetto ......................................... 59 Figura 34: Compromesso tra costo e complessità dei dati del monitoraggio ....................................... 60 Figura 35: I sei elementi di un sistema di monitoraggio ....................................................................... 60 Figura 36: Mappa illustrativa del processo di richiesta di cambiamenti di progetto ............................. 64 Figura 37: Fine del Progetto ................................................................................................................. 66 Figura 38: Matrice di Transizione del Progetto ..................................................................................... 67 Figura 39: WBS del progetto Delta River (parziale sviluppo in formato grafico) .................................. 73 Figura 40: WBS del Progetto Delta River (sviluppo parziale in formato indentato) .............................. 74 Figura 41: Utilizzo di un diagramma di rete per pianificare la sequenza di attività necessarie alla costruzione di una latrina ..................................................................................................................... 77 Figura 42: Utilizzo di un Diagramma di Rete per sequenziare le attività di costruzione di una latrina . 78 Figura 43: Diagramma di Gantt per il progetto “Delta River” ................................................................ 80 Figura 44: “Fast Tracking” della pianificazione del progetto “Delta River" ........................................... 82 Figura 45: "Crashing" della pianificazione del progetto "Delta River" ................................................... 82 Figura 46: Esempio di un semplice budget basato sulle Attività .......................................................... 87 Figura 47: Budget illustrativo per un progetto di sei mesi (inclusi i costi effettivi fino al Mese 3) ......... 89 Figura 48: Esempio di bilancio per un progetto di 6 mesi (inclusi i dati dell’Earned Value) ................. 92 Figura 49: Combinazione dei Risultati in un’Analisi dell’ Earned Value ............................................... 93 Figura 50: Categorie dei beni secondo UNDP ..................................................................................... 98 Figura 51: Matrice di valutazione dei rischi ........................................................................................ 104 Figura 52: Registro dei Rischi ............................................................................................................ 107 Figura 53: Approccio Basato sui Problemi Vs Approccio Basato sulle Risorse ................................. 110 Guida al PMD Pro 151 Figura 54: Albero dei Problemi del progetto "Delta River" .................................................................. 111 Figura 55: Albero degli Obiettivi del progetto "Delta River" ................................................................ 112 Figura 56: Albero delle Alternative del progetto "Delta River" ............................................................ 113 Figura 57: Diagramma di Venn per il progetto "Delta River" .............................................................. 117 Figura 58: Matrice di Analisi degli Stakeholder .................................................................................. 118 Figura 59: Matrice RACI per il progetto "Delta River" ......................................................................... 120 Figura 60: Piano di Comunicazione ................................................................................................... 121 Figura 61: Esempio di adattamento degli strumenti di Project Management ..................................... 123 Figura 62: Diagramma a Ragnatela che mostra il rapporto tra i valori di riferimento e gli obiettivi per alcune competenze individuate dal PMD Pro ..................................................................................... 126 Guida al PMD Pro 152 ISBN: 978-­0-­9962090-­3-­8 Guida al PMD Pro 153