Summary

This document appears to be a textbook or study guide on project management. It includes a table of contents and an introduction to project management.

Full Transcript

## Gruppo A. Conoscenze di contesto ### **N.** | **Codice** | **Elementi di conoscenza del gruppo** ------- | -------- | -------- 1 | A.01 | “Conoscenze di contesto” 2 | A.02 | Progetto 3 | A.03 | Project management 4 | A.04 | Strutture organizzative e progetti 5 | A.05 | Program e portfolio manage...

## Gruppo A. Conoscenze di contesto ### **N.** | **Codice** | **Elementi di conoscenza del gruppo** ------- | -------- | -------- 1 | A.01 | “Conoscenze di contesto” 2 | A.02 | Progetto 3 | A.03 | Project management 4 | A.04 | Strutture organizzative e progetti 5 | A.05 | Program e portfolio management 6 | A.06 | Governance dei progetti 7 | A.06.01 | Processi di project management - Avvio (start-up) 8 | A.06.02 | - Pianificazione 9 | A.06.03 | - Esecuzione 10 | A.06.04 | - Controllo 11 | A.06.05 | - Chiusura (close-out) 13 | A.07 | Contesto e gestione stakeholder 14 | A.08 | Fasi del progetto (ciclo di vita) 15 | A.09 | Criteri di successo del progetto 16 | A.10 | Strategie di progetto, requisiti e obiettivi 17 | A.11 | Responsabile di progetto (Project Manager) 18 | A.12 | Modelli di maturità nel project management 19 | A.13 | Criteri di valutazione del progetto ## Gruppo B. Conoscenze tecniche e metodologiche ### **N.** | **Codice** | **Elementi di conoscenza del gruppo** ------- | -------- | -------- 1 | B.01 | “Conoscenze tecniche e metodologiche" 2 | B.02 | Gestione dell'integrazione di progetto 3 | B.03 | Gestione dell'ambito e dei deliverable di progetto 4 | B.04 | Gestione dei tempi di progetto 5 | B.05 | Gestione delle risorse di progetto 6 | B.06 | Gestione contrattualistica e acquisti di progetto 7 | B.07 | Gestione dei rischi di progetto 8 | B.08 | Gestione dei costi di progetto 9 | B.09 | Gestione della configurazione e delle modifiche di progetto 10 | B.10 | Gestione dell'avanzamento di progetto 11 | B.11 | Gestione delle informazioni e della documentazione di progetto 12 | B.12 | Gestione della qualità di progetto | | Normative e Standard ## Gruppo C. Conoscenze comportamentali ### **N.** | **Codice** | **Elementi di conoscenza del gruppo** ------- | -------- | -------- 1 | C.01 | “Conoscenze comportamentali" 2 | C.02 | Comunicazione 3 | C.03 | Leadership 4 | C.04 | Motivazione ed orientamento al risultato 5 | C.05 | Team working/team building 6 | C.06 | Negoziazione 7 | C.07 | Conflitti e crisi 8 | C.08 | Problemsolving | | Etica **[*]** Presidente dell'Istituto Italiano di Project Management ([email protected]). ## Gruppo A. Conoscenze di contesto ### PROGETTO **Codice elemento:** A.01 **Definizione** Un progetto è un'impresa complessa, unica e di durata determinata, volta al raggiungimento di un obiettivo prefissato mediante un processo continuo di pianificazione, esecuzione e controllo di risorse differenziate e con vincoli interdipendenti di costi-tempi-qualità. **Descrizione** Un progetto è costituito da un insieme di processi comprendenti attività coordinate e controllate - ciascuna con data di inizio e fine - la cui realizzazioneconsente di conseguire gli obiettivi del progetto stesso, rilasciando i deliverable richiesti nel rispetto di vincoli interdipendenti di costi, tempi e qualità. Le caratteristiche essenziali di un progetto sono, dunque, il suo essere “unico” e “temporaneo”. La caratteristica di unicità (e, quindi, di irripetibilità) di ciascun progetto dipende da diversi fattori, nonostante il progetto in questione possa rifarsi a schemi o modelli derivanti da progetti simili già realizzati in passato. Infatti le condizioni di partenza del progetto, in termini di caratteristiche della fornitura, di condizioni economico-finanziarie al contorno, di competitività del mercato e di adeguatezza delle risorse umane, si presentano sempre diverse; anche durante la fase esecutiva vengono a crearsi situazioni e ambienti di lavoro che ricalcano solo in parte quelli determinatisi, nel passato, per progetti analoghi Inoltre un progetto ha la caratteristica di essere temporaneo, cioè di avere un inizio e una fine definiti e, quindi, di prevedere la propria conclusione entro una durata determinata. Ogni progetto crea dei deliverable unici, in termini di prodotti, servizi o risultati [vedi elemento B.02]. Altra connotazione, oggi sempre più riscontrabile nei progetti, è quella della complessità: i progetti sono, infatti, sempre più interdisciplinari e alla fase realizzativa partecipano di norma numerosi attori (interni ed esterni all'organizzazione), di differente cultura ed estrazione tecnica, ciascuno dei quali opera svolgendo molteplici attività tra loro correlate da stretti vincoli di interdipendenza di natura logica, fisica e temporale. Proprio per ovviare alla complessità crescente dei progetti e alla conseguente difficoltà di definire piani a lungo termine che siano realistici, oggi si adotta per la gestione dei progetti un approccio basato su una elaborazione progressiva, gestendo la pianificazione ed il controllo del progetto attraverso successivi stadi e proseguendo in maniera incrementale. Un ulteriore elemento che caratterizza il contesto progettuale è rappresentato dalla necessità di operare una pianificazione e un controllo accurati, non soltanto finalizzati alla ottimizzazione della logica operativa (e alla contemporanea minimizzazione dei costi), ma che tengano anche conto, in termini sia quantitativi che qualitativi, della reale disponibilità delle risorse occorrenti nell'arco di tempo durante il quale è previsto il loro impiego. La definizione di progetto si completa con la precisazione delle tre variabili principali tempi, costi, qualità, rispetto alle quali saranno esercitate le attività di gestione lungo l'intero ciclo di vita del progetto (ossia la sua suddivisione in fasi successive dall'inizio alla fine [A.08]) fino al raggiungimento dei risultati finali e degli obiettivi prefissati. Questa triade di tempi, costi e qualità viene solitamente definita “triplo vincolo” e nell'esplicitare il significato di questo triplice concetto non si può non far costante riferimento all'ambito del progetto[B.02], considerando l'impegno a consegnare il risultato del progetto, oltre che nei tempi e costi previsti, anche nei contenuti e in una forma che risponda a quanto atteso dal committente e in linea con i requisiti (vincolo della qualità). In funzione della sua complessità ed estensione, un progetto può essere suddiviso in sotto-progetti, fasi e sotto-fasi, aventi opportune relazioni di continuità e interdipendenza fra loro. Esistono diverse tipologie di progetti (impiantistici, software, sviluppo di nuovi prodotti, di riorganizzazione ecc.). Occorre inoltre distinguere tra: - progetti per terzi o esterni: realizzati per fornire un prodotto/servizio a un cliente/committente; - progetti interni: realizzati da un'organizzazione per soddisfare una propria esigenza promossa in genere da uno sponsor interno. **Principali elementi correlati** - Tutti ### PROJECT MANAGEMENT **Codice elemento:** A.02 **Definizione** Il project management è l'applicazione di conoscenze, capacità professionali e personali, metodi, tecniche e strumenti alle attività di gestione di un progetto, al fine di soddisfarne i requisiti. **Descrizione** Il project management è l'applicazione di conoscenze, capacità professionali e personali, metodi, tecniche e strumenti alle attività di gestione di un progetto, al fine di soddisfarne i requisiti. **Principali elementi correlati** - Tutti ### PROCESSI DI PROJECT MANAGEMENT **Codice elemento:** A.06 **Definizione** I Processi di Project Management sono quei processi che, ripetutamente attivati per tutta la durata del progetto (dall'avvio alla conclusione), forniscono al Responsabile di Progetto il necessario supporto per svolgere al meglio la propria attività di conduzione del progetto. **Descrizione** Un processo è un insieme di attività correlate volte a ottenere una determinata serie di prodotti, risultati o servizi. Un processo trasforma un insieme di input aggiungendo valore agli stessi, utilizzando tecniche e strumenti nell'ottica di conseguire un determinato risultato che sia congruente con gli altri processi. L'insieme dei processi di project management, con le loro attività interne e con i relativi input e output, strumenti e tecniche, consente di avviare, pianificare, eseguire, controllare e chiudere qualsiasi tipo di progetto. Il Responsabile di Progetto deve stabilire quali sono i processi e gli eventuali adattamenti (tailoring) che è conveniente utilizzare per ciascun progetto. I processi si dividono in due macrocategorie: - processi direttamente collegati alla realizzazione del prodotto o servizio generato dal progetto (processi orientati al prodotto); - processi relativi alla gestione del progetto (processi di project management), che si possono suddividere nei seguenti gruppi di processi: - avvio [A.06.01] per la definizione e l'autorizzazione formale del progetto; - pianificazione[A.06.02] per l'elaborazione del piano e della baseline di progetto; - esecuzione[A.06.03] per la conduzione delle attività di realizza-zione del contenuto (deliverable) del progetto; - controllo [A.06.04] per la verifica dell'aderenza a quanto previsto dal piano nonché per il monitoraggio delle prestazioni rispetto al piano; - chiusura [A.06.05] per la conclusione formale delle attività di progetto. I gruppi di processi a loro volta si scompongono in processi elementari riferibili alle aree di conoscenza tecniche e metodologiche [da B.01 a B.11]. I processi di project management vanno eseguiti secondo una determinata sequenza in quanto molti di essi producono come output dei risultati intermedi (deliverable) [B.02]utilizzati da processi successivi. Tuttavia la natura iterativa della gestione dei progetti comporta la necessità di ripetere alcuni processi (per esempio la pianificazione) per definire più accuratamente attività, costi, risorse e tempi, man mano che il team di progetto acquisisce una migliore conoscenza del prodotto da realizzare e dei rischi relativi. Pertanto, nel corso della vita di un progetto, alcuni gruppi di processi possono essere ripetuti più di una volta. Quando il progetto è suddiviso in Fasi (stage), i processi di project management devono generalmente essere ripetuti per ciascuna fase [A.08]. Ciascun progetto o fase inizia con il processo di avvio e termina con il processo di chiusura, iterando al suo interno i processi di pianificazione e quelli di esecuzione, supervisionati dai processi di controllo. Uno degli aspetti che devono essere maggiormente tenuti in considerazione nella gestione dei progetti è l'approccio sistemico al problema, considerando il progetto come l'insieme di interazioni tra diverse variabili tecniche e organizzative. L'integrazione di tali componenti variabili costituisce uno dei compiti principali del Responsabile di Progetto [B.01]. **Principali elementi correlati** - A.01 progetto - A.02 project management - B.01 gestione integrazione del progetto - A.08 fasi del progetto - B.02 gestione dell'ambito e dei deliverable del progetto ## Gruppo A. Conoscenze di contesto ### PROCESSI DI PROJECT MANAGEMENT - ### AVVIO **Codice sotto elemento:** A.06.01 **Definizione** Il processo di Avvio supporta la definizione e l'approvazione formale del progetto o di una sua specifica fase. **Descrizione** Il processo di Avvio prende il via dal recepimento di un documento sottoscritto dallo sponsor/committente a cui si dà generalmente il nome di “mandato di progetto”. Durante il processo di avvio è bene organizzare una riunione che sancisca la partenza formale (start-up) del progetto o, nel caso tale riunione si realizzi a fine avvio, dia il via al successivo processo di pianificazione. A tale riunione si dà solitamente il nome di Kick-Off Meeting (KOM) e ad essa vengono invitati a partecipare tutti gli attori coinvolti nella definizione del progetto e nella redazione/approvazione di un documento fondamentale per l'avvio di un progetto: la Scheda Progetto (Project Charter). La Scheda Progetto sancisce, quindi, la conclusione del processo di avvio e in essa vengono descritti: - gli obiettivi del progetto e la loro giustificazione; - i requisiti che soddisfano le esigenze e le aspettative degli stakeholder; - i deliverable (risultati) che il progetto dovrà produrre; - le milestone, come risultati intermedi o principali scadenze temporali da rispettare; - i presupposti (assunti) e i vincoli contrattuali; - il budget; - il Responsabile di Progetto assegnato, il suo livello di autorità e il proprio team; - i criteri di successo del progetto; - l'individuazione degli stakeholder. La Scheda Progetto conferisce al Responsabile di Progetto l'autorità per richiedere all'organizzazione le risorse necessarie a svolgere le attività pianificate. Per documentare le caratteristiche del progetto (o della fase) appena avviato, i processi di avvio devono essere utilizzati per formulare, in base alla Scheda Progetto e alle altre informazioni disponibili, una prima definizione dell'ambito del progetto. Tale definizione iniziale dell'ambito progettuale deve contenere: - obiettivi del prodotto o servizio (tecnici, economici o di altro genere); - caratteristiche del prodotto/servizio e i relativi criteri di accettazione; - limiti del progetto (lo spazio di opportunità entro il quale il progetto si muove); - requisiti e deliverable del progetto (ad esempio prodotti da consegnare); - vincoli (ad esempio di natura finanziaria) e presupposti; - eventuali standard e norme da rispettare; - organizzazione iniziale del progetto (i partecipanti principali); - identificazione degli stakeholder; - aree di rischio più evidenti; - milestone e scadenze; - WBS (Work Breakdown Structure) di massima [B.02]; - stime di massima (valutazioni non approfondite di costi, tempi e altre variabili misurabili). La corretta gestione del processo di Avvio da parte del Responsabile di Progetto costituisce il presupposto per il successo del progetto. Si ricorda che, nel caso in cui un processo fosse suddiviso in più fasi, i processi di avvio sono più di uno e precisamente uno per ogni inizio di fase. **Principali elementi correlati** - A.07 contesto e gestione stakeholder - A.08 fasi del progetto - A.09 criteri di successo - A.02 gestione ambito del progetto e deliverable - A.11 responsabile di progetto ## Gruppo A. Conoscenze di contesto ### PROCESSI DI PROJECT MANAGEMENT - ### PIANIFICAZIONE **Codice sotto elemento:** A.06.02 **Definizione** Il processo di Pianificazione costituisce l'insieme dei processi utilizzati per sviluppare il Piano di Progetto, nel quale si definiscono le attività e i valori delle variabili (tempi, costi, qualità ecc.) necessari al raggiungimento degli obiettivi stabiliti. **Descrizione** Scopo principale della Pianificazione è identificare e definire l'ambito, il costo, la tempistica delle attività, le quantità di risorse necessarie, i rischi, la qualità e tutte le altre variabili di progetto. Questi elementi di pianificazione dovrebbero servire per stabilire delle baseline da utilizzare quale riferimento di confronto nel corso dell'esecuzione del progetto, oltre che per misurare e controllare le prestazioni del progetto stesso. Alcuni autori differenziano il processo di pianificazione vero e proprio (inteso come stima e definizione delle varie informazioni) da quello di “programmazione” (schedulazione). Oggi il termine Pianificazione (Planning) è più generalmente utilizzato per comprendere tutte le attività, sia di stima che di schedulazione, che portano ad elaborare e approvare il Piano di Progetto (Project Plan). È importante coinvolgere durante il processo di pianificazione tutti gli stakeholder del progetto [A.06] ed in particolare coloro che ne sono esperti e/o che dovranno realizzare le attività. Le domande principali a cui un buon processo di pianificazione deve dare risposta, e i relativi output documentali, sono di seguito elencate: **Domanda** | **Output** ------- | -------- Cosa fare? | Creare la WBS e definire le attività Chi Fa? | OBS (Organizzazione e stakeholder) Chi fa Cosa? | Matrice delle responsabilità Come fare? | Reticolo logico delle attività e stima della loro durata Con che cosa? | Stima risorse necessarie (piano risorse) Quando fare? | Diagramma di Gantt (piano tempi) Con quali costi? | Stima dei costi e budget di progetto (piano costi) A queste domande se ne dovrebbero aggiungere altre e precisamente: **Domanda** | **Output** ------- | -------- Con quali rischi? | Registro dei rischi (piano rischi) Con quale qualità? | Piano della qualità Come comunicare? | Piano della comunicazione Con quali forniture? | Piano degli acquisti Un piano di progetto è quindi costituito da diversi sotto-piani, ognuno dei quali riferito appunto alle diverse variabili di progetto. Soltanto l'attività di Integrazione [B.01], svolta principalmente dal Responsabile di Progetto, fa sì che i diversi sotto-piani di progetto siano coerenti e congruenti fra loro, evitando, ad esempio, che un piano dei tempi non sia realistico in quanto non supportato da un adeguato piano delle risorse in termini di rapporto necessità-disponibilità. I processi di pianificazione del progetto richiedono lo svolgimento dei seguenti passi: - identificare tutte le componenti di pianificazione del progetto, con riferimento alle domande di cui sopra; - programmare nel tempo (schedulare) le attività, le risorse, i costi, ecc.; - affinare gli elementi di pianificazione attraverso cicli di feedback, per ottimizzare al meglio le variabili di progetto e soprattutto la triade tempi-costi-qualità; - formalizzare e approvare il piano di progettoe salvarlo come “baseline”, da utilizzare come riferimento di confronto nel corso dell'Esecuzione del progetto, oltre che per misurare e controllare le prestazioni del progetto (processo di Controllo) e rendicontarne poi i successivi stati di avanzamento. È bene specificare che un piano di progetto è e resta una previsione (stima) rispetto ad eventi che avverranno in futuro. Un piano, quindi, non è per sua natura né esatto né sbagliato a priori. Compito del Responsabile di Progetto e del suo team è invece quello di sviluppare un piano che sia il più possibile “realistico", seppur basato necessariamente su dei presupposti di stima. **Principali elementi correlati** - Tutti gli elementi del gruppo B ## Gruppo A. Conoscenze di contesto ### PROCESSI DI PROJECT MANAGEMENT - ### ESECUZIONE **Codice sotto elemento:** A,06,03 **Definizione** Il processo di Esecuzione riguarda l'insieme di attività coordinate che consentono di assicurare la realizzazione di quanto pianificato, fornendo i prodotti/servizi (deliverable) richiesti, utilizzando le risorse previste e distribuendo le opportune informazioni agli stakeholder. **Descrizione** Il processo di Esecuzione comprende l'insieme delle attività tese ad acquisire e coordinare le risorse di progetto e a dirigere lo stesso portandolo a completamento con la realizzazione dei prodotti richiesti e rispondenti al livello qualitativo atteso. In particolare il processo di esecuzione comprende i seguenti processi ed attività: - dirigere i lavori del progetto; - gestire i bisogni e le attese degli stakeholder; - sviluppare il team di progetto, favorendo le prestazioni e le interazioni tra i membri del team; - sviluppare le azioni di risposta ai rischi; - eseguire l'assicurazione di qualità; - selezionare i fornitori; - distribuire le informazioni. Nel corso dell'esecuzione del progetto occorre verificare la rispondenza (conformità) ai requisiti iniziali, nonché i passi previsti per soddisfarli. I processi relativi all'esecuzione del progetto hanno luogo normalmente dopo i processi di avvio e di pianificazione, ripetendosi anche in presenza di richieste di modifica [B.08 e C.03], di rischi non precedentemente analizzati e di azioni correttive. L'esecuzione di un progetto ha luogo a partire dall'acquisizione delle risorse, umane e materiali. Per l'acquisizione delle risorse di progetto può essere necessario coinvolgere fornitori esterni e prevedere contratti anche attraverso il processo di approvvigionamento [B.05]. Al processo di esecuzione corrispondono i costi più rilevanti del progetto, perché è questo il processo che sottende alla produzione dei deliverable, cioè dei prodotti o servizi che sono il risultato delle attività di progetto. Di norma, il processo di Esecuzione è quello che impiega il maggior numero di risorse messe a piano per il progetto. Tutti i processi e i prodotti del progetto sono sottoposti alla assicurazione di qualità al fine di verificare che vengano seguiti i metodi ed i requisiti di documentazione necessari per stabilire i livelli di prestazioni predefiniti e che vengano adottati, ove necessario, gli opportuni interventi di miglioramento dei processi (es. azioni preventive). Ciò comporta, di conseguenza, la necessità di considerare le attività da rieseguire a seguito di una opportuna attività di ri-pianificazione comprendente la gestione delle richieste di modifica o varianti di progetto. Nel corso dei processi di Esecuzione si devono anche considerare: - lo sviluppo dei team di progetto; - la formazione, ove richiesta, dei componenti del team; - la distribuzione dei dati riguardanti l'avanzamento lavori e di tutte le altre informazioni da rendere note ai diversi stakeholder, secondo quanto previsto dal piano di gestione della comunicazione [C.01]. **Principali elementi correlati** - B.02 gestione ambito e deliverabledel progetto - B.08 gestione configurazione e modifiche - B.10 gestione informazioni e documentazione di progetto - B.11 gestione qualità di progetto - C.01 comunicazione ## Gruppo A. Conoscenze di contesto ### PROCESSI DI PROJECT MANAGEMENT - ### CONTROLLO **Codice sotto-elemento:** A.06.04 **Definizione** Il processo di Controllo comprende il monitoraggio, la misurazione e la verifica delle prestazioni del progetto rispetto ai piani, al fine di identificarne tempestivamente gli scostamenti e di attuare, ove necessario e possibile, adeguate misure correttive. **Descrizione** L'azione di controllo di un progetto si articola in una serie di passi successivi che, nell'ordine, consistono sostanzialmente in: - rilevazione dei dati effettivi di avanzamento (monitoraggio); - confronto tra i valori rilevati e quelli pianificati (baseline) alla data di avanzamento; - evidenziazione degli eventuali scostamenti e delle performance di progetto; - individuazione delle cause che hanno comportato gli scostamenti; - ridefinizione, se necessaria, delle stime a finire; - ri-pianificazione del progetto con riferimento ai tempi, ai costi, alle risorse e all'aderenza dei deliverable ai requisiti attesi. Il controllo di progetto non deve essere inteso, quindi, come un intervento di natura meramente contabile o ispettiva, teso a individuare il “colpevole” di ritardi nelle consegne o di costi che hanno superato i valori di budget; esso deve essere inteso, piuttosto, come un'azione collaborativa rivolta alla ricerca di quanto si potrà fare nel periodo di tempo che ancora rimane prima della definitiva conclusione dell'iter realizzativo, al fine di far rientrare il progetto entro gli standard qualitativi e i limiti temporali ed economici prefissati. Si tratta, quindi, di un'attività orientata alla cooperazione e volta a responsabilizzare il comportamento dei componenti del team di progetto sul miglioramento dei risultati delle prestazioni future. I processi di controllo riguardano in particolare: - il controllo dell'ambito; - il controllo delle risorse e la gestione del team; - il controllo del programma dei tempi; - il controllo dei costi; - il controllo dei rischi; - il controllo di qualità dei deliverable e dei processi; - il controllo delle forniture; - il controllo delle comunicazioni verso gli stakeholder. È bene sottolineare che una eventuale ridefinizione del piano del progetto non comporta necessariamente anche la ridefinizione della baseline di progetto. Inoltre, alcuni studiosi distinguono tra i termini "monitoraggio” e “controllo”, intendendo per monitoraggio la semplice rilevazione “contabile” dei dati di avanzamento, e per controllo l'analisi critica degli scostamenti, l'elaborazione delle proiezioni a finire e l'attivazione delle azioni correttive, secondo il ciclo PDCA (Plan, Do, Check, Act) di Deming, composto dai seguenti 4 passi iterativi: - Plan, ossia il momento della pianificazione dell'intervento o dell'azione da compiere; - Do, ossia la messa a punto di quanto pianificato, anche nella forma di un intervento pilota, atto a testarne l'efficacia prima di un'applicazione diffusa; - Check, ossia la verifica di quanto implementato ai fini della valutazione della bontà dell'intervento correttivo con l'eventuale affinamento dell'intervento stesso; - Act, ossia l'entrata in produzione dell'intervento correttivo, l'individuazione delle successive azioni di miglioramento e la predisposizione per l'avvio di un successivo ciclo. Una delle tecniche più utilizzate per il controllo di progetto è l'Earned Value [B.09]. **Principali elementi correlati** - A.06.02 pianificazione - A.08 fasi di progetto - Tutti gli elementi del gruppoB ## Gruppo A. Conoscenze di contesto ### PROCESSI DI PROJECT MANAGEMENT - ### CHIUSURA **Codice sotto-elemento:** Α.06.05 **Definizione** Il processo di Chiusura consente di concludere ordinatamente e compiutamente le attività di un progetto (o di una sua fase) e di consegnare tutti i prodotti, i servizi e i risultati previsti, includendo l'accettazione formale da parte del cliente. **Descrizione** Un progetto può dirsi effettivamente chiuso solo quando: - tutti i prodotti, i servizi e i risultati previsti sono stati realizzati e formalmente accettati dal cliente; - sono state trasferite ad altri le attività di gestione dei prodotti o servizi realizzati dal progetto (chiusura amministrativa); - sono stati assolti gli obblighi contrattuali e i relativi adempimenti amministrativi (chiusura del contratto). Al compimento dell'iter realizzativo i principali stakeholder di progetto procedono, in sede congiunta, all'esame approfondito dei risultati conseguiti, allo scopo di formulare le considerazioni conclusive circa il reale andamento del progetto, con l'intento di evidenziare i punti di forza e di debolezza che ne hanno caratterizzato la gestione. L'esame viene condotto nel corso di una riunione di fine progetto (close-out meeting), indetta e presieduta dal Responsabile di Progetto, alla quale partecipano attivamente tutte le strutture (interne ed esterne) che sono state coinvolte nel ciclo realizzativo. Nel corso di tale riunione viene svolta una sessione di analisi critica delle modalità con le quali si è realmente svolto l'iter realizzativo del progetto, con particolare riferimento alle cause che ne hanno determinato il successo o l'insuccesso, in modo da dedurre, redigere ed archiviare le lezioni apprese (lessonslearned). È necessario tenere presente che sia la chiusura amministrativa che la eventuale chiusura del contratto fanno parte dei processi di chiusura del progetto. I passi per una corretta chiusura del progetto comprendono quindi: - l'archiviazione dei dati del progetto (con particolare attenzione alle lezioni apprese); - il "rilascio" delle risorse umane e materiali utilizzate, che vengono rese disponibili per essere assegnate ad altri progetti; - la chiusura amministrativa, che riguarda il trasferimento dei prodotti e servizi realizzati ai reparti di produzione e alle funzioni operative; - la chiusura del contratto, che prevede: - l'ufficializzazione dell'accettazione da parte del cliente dei prodotti e dei servizi contrattualizzati e consegnati; - l'archiviazione dei documenti formali previsti dal contratto; - il controllo delle fatture, con la verifica degli avvenuti incassi/pagamenti; - la chiusura delle dispute o dei reclami (claim), mediante formalizzazione del consenso del cliente. L'archiviazione dei dati relativi ai progetti terminati dovrebbe permetter, dopo un congruo periodo di tempo, di consolidare quello che alcuni organismi definiscono database storico dei progetti. Tale banca dati è un asset organizzativo di inestimabile valore in quanto permette di trasferire nel tempo, a colleghi di lavoro appartenenti a generazioni differenti, un importante patrimonio di conoscenze (knowledge base) e di esperienze che spesso viene vanificato o perduto a causa, appunto, del ricambio generazionale. Tali database storici permettono, specie ai giovani Responsabili di Progetto, di definire un piano di progetto in tempi più rapidi e in modo più esaustivo. **Principali elementi correlati** - B.05 gestione contrattualistica e acquisti di progetto - B.08 gestione configurazione e modifiche ## Gruppo A. Conoscenze di contesto ### CONTESTO E STAKEHOLDER DI PROGETTO **Codice elemento:** A.07 **Definizione** Il Contesto è l'ambiente socio-economico e territoriale nel quale il progetto si svolge e che, con i suoi tratti distintivi, è in grado di influenzare fortemente il progetto stesso. Gli Stakeholder sono persone, organizzazioni o gruppi i cui interessi possono essere influenzati positivamente o negativamente dal progetto. **Descrizione** L'analisi del Contesto di riferimento è un processo conoscitivo che il Responsabile di Progetto deve eseguire nel momento in cui si accinge a realizzare un progetto, con uno sforzo di lettura e ricostruzione delle forze in gioco, degli interessi, delle possibili influenze organizzative, delle inevitabili relazioni tra il progetto in esame e le altre iniziative in corso. Dal contesto si deducono il modo di concepire il progetto, le possibili modalità di gestione e, in particolare, il risultato finale che il progetto è in grado di produrre. L'analisi del contesto consiste nel comprendere le principali variabili in gioco, sia esterne sia interne, al fine di individuare le forze, i rischi e le tendenze che sono in grado di influenzare le attività o i risultati del progetto. È possibile scomporre l'analisi del contesto in: - analisi del contesto esterno, costituito dall'insieme di variabili che si riferiscono ad aspetti demografici, sociali, economici, politici, del lavoro, territoriali, ambientali, culturali e infrastrutturali, che condizionano e influenzano le scelte e i comportamenti delle persone e delle organizzazioni; - analisi del contesto interno, costituito da tutti quegli elementi che compongono la struttura interna della stessa organizzazione: la sua cultura, gli attori chiamati in causa dal progetto, i rapporti di influenza, il modo di organizzare il lavoro (processi e procedure) e le strutture organizzative. Uno strumento di supporto all'analisi del contesto (interno ed esterno) entro cui si colloca il progetto è l'analisi SWOT che consente di ottenere una visione integrata di: punti di forza interni (Strenght), punti di debolezza interni (Weakness), opportunità esterne (Opportunities), rischi/minacce esterne (Threats). L'identificazione e la gestione di tutti gli Stakeholder (parti interessate o coinvolte) di un progetto costituisce il presupposto indispensabile per la buona riuscita del progetto stesso, in quanto gli stakeholder possono operare a favore o contro il progetto. I principali stakeholder sono: - lo Sponsor; - il Responsabile di Progetto (project manager); - il Team di project management; - Membridel PMO – Project Management Office; - gli utenti del prodotto, servizio o risultato finale del progetto; - i fornitori; - enti governativi centrali e/o locali, competenti per verifiche di conformità alle normative o per il rilascio di specifiche autorizzazioni; - altri gruppi di interesse economico e sociale. Oltre al Responsabile di Progetto hanno un ruolo fondamentale per la buona riuscita del progetto, lo Sponsor e il Team di project management. Per Sponsor si intende la persona che si assume l'impegno globale del Progetto nei confronti del Top management. Egli autorizza il progetto, prende decisioni di alto livello, e si impegna a sostenere il Responsabile di Progetto per la risoluzione di tutte le problematiche che vanno oltre il mandato e l'autorità di quest'ultimo; di norma lo Sponsor è la figura in cui può identificarsi il committente e/o finanziatore del progetto. Per Team di project management (a volte definito solo, anche se erroneamente, Team di progetto) si intende un gruppo ristretto di persone che supportano il Responsabile di Progetto nelle sue attività di pianificazione, direzione, gestione e controllo di progetto. Spesso, in progetti di piccole dimensioni, il Responsabile di Progetto opera senza un vero e proprio Team di project management assegnato. Tra gli stakeholder di progetto vanno compresi anche tutti coloro che, se non adeguatamente coinvolti/convinti a collaborare, possono determinare il fallimento del progetto stesso. È compito del Responsabile di Progetto gestire le informazioni e un adeguato livello di coinvolgimento verso tutti gli stakeholder [B.10]. **Principali elementi correlati** - A.09 strategie di progetto, requisiti e obiettivi - B.07 gestione rischi e opportunità di progetto - B.01 gestione ambito del progetto e deliverable - B.10 gestione delle informazioni e documentazione di progetto ## Gruppo A. Conoscenze di contesto ### FASI DEL PROGETTO E CICLO DI VITA **Codice elemento:** A.08 **Definizione** Per Fasi di progetto si intendono periodi e/o “parti di progetto" (stadi) chiaramente definiti in cui il progetto può essere scomposto al fine di agevolare il controllo e il raggiungimento dei risultati intermedi e globali. L'insieme delle fasi e delle attività di un progetto che vanno dal suo inizio alla sua fine ne costituiscono il Ciclo di vita. **Descrizione** I progetti nei quali sia necessario definire dei momenti di controllo intermedi possono essere suddivisi in Fasi, o stadi (stage). Le fasi di un progetto sono quindicostituite da un insieme di attività raggruppate e messe in sequenza in maniera logica allo scopo di assicurare il raggiungimento dei risultati intermedi e globali del progetto. Per consentire una chiara definizione delle fasi e, quindi, un efficace controllo del progetto, ogni fase deve concludersi con il completamento di uno 0 più parti di lavoro deliverable[B.02]. Il riesame dei deliverable di una fase del progetto, condotto eventualmente insieme a sponsor e/o cliente, scandisce l'evoluzione del progetto determinando il elementi di carattere tecnico-funzionale, che in modo più analitico concorrono alla definizione dell'ambito [B.02] ed alla qualità di progetto [B.11].I requisiti costituiscono condizioni o capacità che devono essere soddisfatte o possedute da un prodotto/servizio affinché esso sia conforme a quanto richiesto da un contratto, da uno standard, da una specifica di prodotto o da altri documenti formali. I requisiti devono essere quantificati, documentati, compresi e approvati dalle sponsor, dal cliente, da altri stakeholder. **Principali elementi correlati** - A.07 contesto e gestione stakeholder - A.08 criteri di successo del progetto - A.13 criteri di valutazione del progetto - B.02 gestione ambito e deliverabledel progetto - B.06 gestione rischi e opportunità di progetto - B.11 gestione della qualità di progetto ## Gruppo A. Conoscenze di contesto ### IL RESPONSABILE DI PROGETTO ### (PROJECT MANAGER)

Use Quizgecko on...
Browser
Browser