GUIDA ALLA GESTIONE DEI PROGETTI

(DISPENSE PER IL CORSO DI LAUREA IN INGEGNERIA GESTIONALE DEI PROGETTI E DELLE INFRASTRUTTURE)

2. INTRODUZIONE ALLA GESTIONE DEI PROGETTI

2.1  Introduzione al Project Management
Partiamo da alcune semplici definizioni.

Che cos’è un Progetto?

Abbiamo già visto nel Capitolo I come Archibald definisce un “progetto”, ovvero uno “sforzo complesso, di durata significativa, relativo alla realizzazione di uno specifico ed unico output, la cui realizzazione comporta la realizzazione di una pluralità di compiti - di natura diversa ma tra essi interrelati – eseguiti da soggetti diversi, con obiettivi,schedulazione temporale e budget ben definiti” (Archibald, 1985).
Abbiamo, anche, analizzato le peculiarità della produzione per commessa, in particolare quella delle imprese edili.

Il Project Management Institute , nella sua principale pubblicazione, il PMBOK 4th Edition, definisce un progetto come “a temporary endeavour undertaken to create a unique product or service”, ovvero, un progetto “è uno sforzo temporaneo intrapreso per creare un prodotto, un servizio o un risultato con caratteristiche di unicità” .

Questa semplice definizione fotografa le caratteristiche di un progetto:

1. E’ uno sforzo (un’iniziativa): è “un qualcosa” che richiede del lavoro per creare un prodotto o servizio, richiede l’impegno di risorse, costi, tempi. I progetti sono vincolati dall’utilizzo delle risorse stesse e sono soggetti a pianificazione, monitoraggio e controllo, oltre che alla loro esecuzione operativa.
2. E’ temporaneo: ovvero ha una sua collocazione nel tempo, un inizio certo e una fine, altrettanto certa, almeno si spera! E’ dunque limitato nel tempo. La fine del progetto si consegue quando tutti gli obiettivi sono stati raggiunti. Non è importante la sua durata temporale. Sono progetti quelli di una settimana, es. un progetto per realizzazione di un piccolo impianto, così come quelli pluriennali, es. la realizzazione di un complesso residenziale.
3. E’ unico: I Progetti sono unici. Le caratteristiche sono elaborate (lavorando con cura e dettaglio) progressivamente (procedendo per step). Questo ci porta a dire che non esistono due progetti uguali. Anche se ci sono elementi di ripetitività, l’oggetto o il servizio da realizzare sono fisicamente diversi, gli uni dagli altri, e richiedono una specifica pianificazione, esecuzione delle attività e monitoraggio e controllo.

Il venir meno di una sola di queste caratteristiche mina la definizione stessa di progetto.  

In sintesi

I progetti:

• hanno un inizio e una fine definite;
• Consideriamo per esempio la realizzazione di un edificio: per inizio del progetto possiamo considerare la stipula di un contratto, o la partecipazione a un bando di gara. Per fine, la consegna dell’edificio al committente;
• sono organizzati per processi;
• I processi sono molteplici. Avremo, per esempio, il processo di pianificazione di scopo e tempi e quello di pianificazione dei costi, quello di gestione dei subfornitori e delle imprese in subappalto, il processo di gestione dei rischi, e così via;
• hanno una sequenza di attività interconnesse;
• Se consideriamo, per esempio, il processo di pianificazione di scopo e tempi, questo consiste in una serie di attività, quali, per esempio, l’analisi dei requisiti o del capitolato di gara (che in seguito chiameremo, anche, definizione dello scopo), la creazione della della wbs, la stima delle risorse e la creazione della schedulazione di progetto
• un numero definito di obiettivi (scopo);
• Realizzare il progetto (l’edificio nel nostro caso) nei tempi e nei costi stabiliti e con la qualità richiesta dal committente è, in genere, il principale scopo del progetto.
• finiscono quando gli obiettivi dichiarati sono stati raggiunti (non necessariamente positivamente);      
• Es. l’edificio è stato completato e consegnato, ma non necessariamente nei tempi e costi pianificati;
• sono associati a dei rischi;
• I rischi posso essere di varia natura: gestionali (risorse, tempi, costi), ambientali, tecnici, legislativi, ecc. Per esempio nella costruzione di un edificio, i rischi possono essere connessi al mancato ottenimento di un permesso amministrativo, o alla valutazione di  impatto ambientale (specie per le infrastrutture), alla mancata consegna da parte di subfornitore dei materiali da costruzione, al fallimento di una delle imprese in subappalto;
• hanno dei vincoli da rispettare;
• Anche i vincoli possono essere di varia natura: gestionali (l’edificio non deve costare più di quanto stimato a budget), vincoli contrattuali (l’edificio deve essere completato entro una certa data), vincoli tecnici (occorre utilizzare determinate tecnologie o materiali), vincoli ambientali (occorre ridurre l’impatto ambientale), vincoli normativi (limitare la cubatura dell’edificio);
• possono coinvolgere poche o molte persone di una o più organizzazioni/funzioni;
• Per la realizzazione di un edificio, dobbiamo pensare, non solo  alla direzione di cantiere, ai tecnici, alle squadre di operai, ai subfornitori, ma anche ai progettisti, ai collaudatori, ai dipendenti delle imprese in subappalto;
• possono durare poche settimane o svariati anni;
• Per realizzare una piccola casa bastano pochi mesi, per un complesso residenziale ci possono volere anni. La durata non è un fattore vincolante per la definizione di progetto.   
• sono il mezzo con cui le strategie vengono implementate;
• le aziende che operano su commessa, come nel caso del settore Edile, perseguono i loro obiettivi strategici, realizzando i singoli progetti/commesse.

Il responsabile di un progetto è il Project Manager o Responsabile di Commessa o Capoprogetto.

Gli obiettivi di un progetto devono essere: Chiari, definiti, misurabili e raggiungibili.
Sembrano caratteristiche ovvie. Eppure gran parte dei fallimenti di progetti sono riconducibili al venire meno di una o più di queste caratteristiche.

I progetti non sono eventi continuativi: quando si entra nel campo della ripetitività cessano di essere progetti.  Infatti, la fase di progettazione di un determinato prodotto, lo sviluppo e la sua industrializzazione   sono senza dubbio dei progetti, sia se vengono gestite singolarmente come una moltitudine di progetti in serie, sia facenti parti di un unico grande progetto. Ma quando questo prodotto arriva sulla linea di produzione e questa è a ciclo continuo (ovvero non si produce per commessa, ma per lotti o in serie), allora cessa di essere di essere un progetto e si entra nel campo della produzione di massa. Diverso è se la produzione è “su commessa”. Ovvero, viene commissionato un singolo, specifico, oggetto (o pochi) da un cliente, es. una nave, degli aerei, delle auto particolari, una serie di edifici, un’autostrada, un ponte.
In questo caso la loro realizzazione riacquista la caratteristica di unicità. Dunque possono essere considerati dei progetti.

 

Che cos’è un Programma?

Per il PMBOK, un programma è “un gruppo di progetti correlati, gestiti in modo coordinato al fine di ottenere benefici e un controllo non possibili nella gestione individuale dei singoli progetti” , che possono comprendere anche attività ricorrenti

Si parla di Programma quando abbiamo una serie di progetti che per loro natura afferiscono allo stesso cliente o allo stesso prodotto, ma che vanno gestiti singolarmente, pur mantenendone un controllo e coordinamento complessivo.

Il responsabile di un Programma è il Program Manager, coadiuvato da una serie di Project Manager, responsabili dei singoli progetti del programma.

Facciamo qualche esempio:

• Un grande progetto di costruzioni, un’autostrada, per la quale ci saranno un certo numero di tronconi, finanziati con contratti differenti. Tutti i vari contratti, che identificano i singoli progetti, rientreranno nel Programma “Costruzione dell’autostrada”.
• Un programma di costruzione residenziale articolato in più lotti. Ciascun lotto è un singolo progetto. Questo è il caso di una serie di progetti, gestiti singolarmente e indipendentemente, ma che hanno lo stesso committente, la stessa area geografica, la stessa tipologia di progetto. In più per avere dei benefici in termini di costi e di utilizzo di risorse, vengo affidati allo stesso responsabile o Program Manager.
• Molte volte, le varie fasi del ciclo di vita di un  prodotto complesso vengono distinte e gestite separatamente, perché così è richiesto il più delle volte dal committente, in “n” progetti indipendenti: es. la progettazione, l’industrializzazione, la realizzazione del prodotto sono tre progetti che possono essere realizzati in serie. Anche in questo caso, per mantenere una coerenza gestionale e dare maggiore efficienza ai singoli progetti  parleremo di programma.

Si possono fare tantissimi esempi.  Non è possibile generalizzare nel Project Management. Pertanto l’organizzazione e la struttura di un Programma o di un Progetto, dipendono da molteplici fattori: l’organizzazione che li gestisce, il committente, lo sponsor, il prodotto o servizio creato, le normative, i finanziatori, le risorse disponibili, i rischi connessi.

Il responsabile di un Programma è il Program Manager, che sarà il coordinatore dei vari Project Manager responsabili dei singoli progetti.

Che cos’è il Project Management?

Vediamo, a questo punto,  di dare una definizione a quello che è l’oggetto principale di queste dispense, il Project Management:
Per il PMBOK, “è l’applicazione di conoscenze, capacità, strumenti e tecniche alle attività di progetto per soddisfarne i requisiti” .

Project Management (ISO 8402, 1990):
“Processo unico consistente in un insieme di attività coordinate con scadenze iniziali e finali, intraprese per ottenere un obiettivo conformemente a specifiche richieste, quali vincoli di
tempo, costo e risorse”.

Dunque il Project Management è tutto ciò che serve a supporto del progetto per il raggiungimento dei suoi obiettivi. Per questo sono stati definiti dei processi di project management, individuate delle metodologie e delle tecniche, che andremo ad analizzare nei vari capitoli di queste dispense.

 

Cos’è il ciclo di vita di un progetto?

Abbiamo più volte accennato al ciclo di vita di un progetto. Ogni progetto, per sua stessa definizione, è unico, e come tale va gestito, inoltre, va concepito e gestito secondo il suo particolare contesto operativo .  
Per il PMBOK, il Ciclo di vita del progetto o Project Life Cycle è una “raccolta di fasi di progetto, generalmente in sequenza, il cui nome e numero sono determinati dalle esigenze di controllo dell’organizzazione o delle organizzazioni coinvolte nel progetto”

I progetti, dunque, possono essere suddivisi in fasi per garantire un più accurato controllo. Nel loro insieme queste fasi sono conosciute con il nome di ciclo di vita del progetto.

Tenendo sempre a mente che non  esiste un modo univoco per strutturare un progetto, proviamo ad individuare le principali fasi di un progetto, che ritroviamo nella gran parte dei progetti, come suggerito dal PMBOK :

1. Avvio del progetto;
2. Organizzazione e preparazione del progetto;
3. Esecuzione del progetto;
4. Chiusura del progetto.

Facciamo qualche esempio di come si possono articolare le fasi di differenti prodotti.

Per la realizzazione di una strada:

• Gara di appalto;
• Progettazione di dettaglio e realizzazione cantiere;
• Realizzazione opera;
• Collaudo e consegna all’ente appaltante.

Per un generico Progetto Edile:

1. Fattibilità/Gara.
2. Pianificazione
3. Progettazione.
4. Costruzione.
5. Collaudo finale.

Possiamo avere, anche, più fasi, per esempio, per la immissione di un nuovo prodotto sul mercato, abbiamo:

1. Analisi del mercato
2. Definizione caratteristiche del prodotto e politiche di marketing
3. Pianificazione
4. Progettazione
5. Sviluppo e prototipazione
6. Acquisto e installazione impianti
7. Lancio in produzione
8. Realizzazione
9. Commercializzazione

Osserviamo che:

• Ciascuna di queste fasi avrà un certo numero di processi che si concluderà col completamento di un importante deliverable (obiettivo, prodotto del lavoro tangibile e verificabile) di progetto.
• La struttura in fasi consente un migliore gestione e controllo del progetto. 
• In ciascuna fase che si colloca temporalmente in serie alle altre, le risorse impiegate possono variare in maniera sostanziale. Nella figura 2.1, vediamo come il valore totale delle risorse è basso nelle fasi iniziali, di avvio, cresce con l’avanzare del progetto, per raggiungere il suo massimo nella fase realizzativa del progetto, per poi decrescere fino alla sua chiusura.
• Ogni fase è determinata dalla realizzazione di una o più deliverable.
• Alla fine di ogni fase ci sarà una verifica dei deliverables e delle performance di progetto al fine di determinare e autorizzare a procedere agli step successivi (tali momenti di verifica vengono definiti, meeting di phase review, meeting di review o chiusura delle fasi). Il meeting di phase review è un riunione, normalmente ben strutturata, alla quale prendono parte tutti i principali attori coinvolti della fase. Come vedremo meglio nel prossimo capitolo, nella riunione di phase review della fase di Pianificazione, per esempio, vengono verificati l’esistenza e la coerenza dei  principali deliverable della fase che sono la schedulazione di progetto (Gantt), il budget, la wbs e il piano dei rischi.

• Spesso le fasi del progetto prendono il nome dal principale output o deliverable : esempio fase di avvio, di gara, di pianificazione, di progettazione, di realizzazione dell’opera, fase di collaudo, fase di chiusura del cantiere, ecc.

• Una fase di progetto NON è un processo di project management (esempio, il processo di pianificazione o il processo di monitoraggio e controllo, non sono da confondere con la Fase Pianificazione, se questa è presente nel ciclo di vita del progetto).

 

• Non esiste una regola o un modo unico per definire le fasi di un progetto. Dipende molto dal settore e dall’organizzazione in cui viene gestito. Molte strutture organizzative identificano un insieme standard di cicli di vita da utilizzare per tutti i propri progetti.

• Non bisogna confondere il Ciclo di vita del Progetto con il Ciclo di vita del prodotto:

Il primo riguarda le fasi in cui è diviso il progetto (se ce ne sono).
Il secondo è il raggruppamento naturale di evoluzione del prodotto in fasi. Generalmente:

1. ideazione, concezione del prodotto;
2. sviluppo, progettazione del prodotto;
3. realizzazione del prodotto
4. messa fuori dalla produzione.

Per cui potremmo avere un progetto per ciascuna di queste fasi, o uno solo per lo sviluppo.

            Figura 2.3 -Esempio di ciclo di vita in un progetto edile

 

In ciascuna fase si possono reiterare una serie di processi tipici del project management:

 

 

 

 

 

Figura 2.4 – I processi nelle fasi

Ricapitolando:

• Le fasi del progetto costituiscono il ciclo di vita del progetto stesso.
• Ogni fase è composta da vari processi correlati (I processi creano tra loro interazioni complesse, non rappresentabili in maniera esaustiva in un documento o con dei grafici)
• In ogni fase i processi possono essere riferiti a diverse aree del project management (per esempio i processi possono interagire anche per quanto riguarda, il costo, la schedulazione di progetto e così via, come vedremo nel prossimo paragrafo).

Breve excursus sui processi di Project Management del PMBOK

Per meglio capire quanto detto nel paragrafo sul Ciclo di vita del progetto, vediamo come il PMBOK® descrive i processi di Project Management. Questi  identifica  5 Gruppi di Processi (Avvio, Pianificazione, Esecuzione, Monitoraggio e Controllo, Chiusura),  9 Aree di Conoscenza (knowledge Area, sono la Gestione dell’Integrazione, dello Scopo, dei Tempi, dei Costi, dei Rischi, della Qualità, delle Risorse Umane, delle Communicazioni, degli Acquisti) in cui sono analizzati e dettagliati 42 processi che il Project Team potrà utilizzare nel corso della gestione dell’intero progetto.

I Gruppi di Processi

I processi di gestione dei progetti possono essere raggruppati in 5 Gruppi di Processi (Process Groups):

• Processi di Avvio (Initiating): autorizzano l’avvio di un nuovo progetto o la fase di un progetto esistente
• Processi di Pianificazione (Planning): definiscono lo scopo del progetto, affina gli obiettivi  del progetto e pianificano le azioni e risorse per raggiungerli.
• Processi di Esecuzione (Executing): assicurano che vengano eseguite tutte le attività vengano eseguite per raggiungere gli obiettivi.
• Processi di Monitoraggio e Controllo (Monitoring and Controlling): verificano che gli obiettivi di progetto siano raggiunti controllando e misurando l'avanzamento ed identificando gli scostamenti rispetto al piano.
• Processi di Chiusura (Closing): formalizzano il raggiungimento o meno degli obiettivi e l'accettazione del progetto o della fase.

 

Figura 2.5 – I Gruppi di processi

• I “gruppi di processi” del PMBOK forniscono una struttura di base per la comprensione del Project Management.
• Ciascun gruppo contiene una serie di processi.

 

Esempio:  Il Gruppo di Processi  “Pianificazione” comprende i processi di:

• 4.2 Sviluppare il Project Management Plan;
• 5.1 Raccogliere I Requisiti;
• 5.2 Definire l’ambito;
• 5.3 Creare la WBS;
• 6.1 Definire le attività;
• 6.2 Sequenzializzare le attività;
• 6.2 Stimare le risorse per le attività;
• 6.3 Stimare la durata delle attività;
• 6.4 Sviluppare la schedulazione;
• 7.1 Stimare i costi;
• 7.2 Determinare il budget;
• 8.1 Pianificare la qualità;
• 9.1 Sviluppare il piano delle risorse;
• 10.2 Pianificare le comunicazioni;
• 11.1 Pianificare la gestione dei rischi;
• 11.2 Identificare i rischi;
• 11.3 Eseguire l’analisi quantitativa dei rischi;
• 11.4 Eseguire l’analisi qualitativa dei rischi;
• 11.5 Pianificare le risposte ai rischi;
• 12.1 Pianificare gli approvvigionamenti.
• Ogni singolo processo è sempre caratterizzato da (Figura 2.6):
• Input (Documenti o altre entità in ingresso al processo)
• Strumenti e Tecniche (che vengono utilizzate per trasformare gli input in output)
• Output (Documenti o altre entità in uscita dal processo, che ne costituiscono il risultato tangibile).

 

Figura 2.6

 

• L’applicazione dei processi di Project Management a un progetto è  iterativa e molti processi vengono ripetuti e rivisti nel corso del progetto:
• I Processi della Pianificazione non sono in serie con i Processi di Esecuzione, in quanto la Pianificazione è un processo che si reitera nel tempo. Questo perché non si esaurisce nella prime fasi del progetto, ma viene continuamente aggiornata via via che il progetto avanza ed vengono rilevati periodicamente gli avanzamenti (per una migliore comprensione di questo processo ci riferiamo al capitolo sulla pianificazione di tempi e costi).
• I Processi di Monitoraggio e Controllo intervengono su tutto l’arco del ciclo di vita del progetto. Questi processi sono fondamentali, come vedremo in seguito, per avere una chiara visione di come procede il progetto e identificare le aree sulle quali occorre intervenire.

 

Le Knowledge area

Il PMBOK  individua, oltre ai Gruppi di Processo (Avvio, Pianificazione, Esecuzione, Monitoraggio e Controllo, Chiusura), delle cosiddette “Knowledge area” (Aree di Conoscenza)  del Project Management che, per specifici argomenti, (es. integrazione, scopo, tempo, costo, qualità, risorse umane, rischi, acquisti, comunicazione) descrivono metodi e tecniche  della gestione dei progetti in base ai processi stessi che la compongono.

Riprendendo l’esempio precedente, l’Area di Conoscenza della Gestione dei Tempi (Time Management) include  i processi che afferiscono al fattore “tempo”, ovvero:

• 6.1 Definire le attività;
• 6.2 Sequenzializzare le attività;
• 6.2 Stimare le risorse per le attività;
• 6.3 Stimare la durata delle attività;
• 6.4 Sviluppare la schedulazione;

 

Le 9 Aree di Conoscenza (knowledge area) sono:

 

Dunque i Gruppi di Processi organizzano i processi per fasi (più o meno in serie); le Aree di Conoscenza, organizzano gli stessi processi per tipologia di argomento (Tempi, Costi, Rischi….).
Il PMBOK  è più  una guida che una metodologia da seguire pedissequamente. Spetterà, poi, al Project Manager decidere se e quali processi applicare.L’intersezione delle KA con i Gruppi di processi definisce una matrice.

Figura 2.7

Ogni elemento della matrice, se presente, è definito da uno o più processi. La tabella seguente illustra la relazione tra Gruppi di Processi e Aree di Conoscenza.

2.2 Un modello semplificato di pianificazione e controllo di un progetto
I processi e le interazioni mostrate nelle paragrafo precedente, sono generalmente accettati come validi in gran parte delle organizzazioni e il più delle volte i processi presenti sono effettivamente eseguiti nei progetti.

In ogni caso, non tutti i processi individuati sono necessari a tutti i progetto, e non tutte le interrelazioni sono sempre e comunque attivabili e condivisibili.
Solo nei grandi progetti abbiamo una distinzione netta tra fasi, gruppi di processi e processi, così come descritto nel PMBOK.

In queste dispense, abbiamo voluto, nell’ambito delle metodologie generali per la gestione dei progetti, considerare un modello semplificato. Uno strumento pratico che possa essere concettualmente applicato a qualunque tipologia di “progetto”.

Ciclo di vita semplificato di gestione di un progetto

Il Ciclo di vita del modello di Gestione di un progetto, semplificato, comprende le seguenti fasi:

• L’avvio del progetto.
• La gestione della pianificazione di scopo e tempi.
• La gestione della pianificazione dei costi.
• La gestione dei rischi.
• Il monitoraggio e controllo.
• La chiusura del progetto.

Ciascuna fase sarà caratterizzata da uno o più processi.

Nel modello di studio applicheremo i processi di project management relativi a queste 6 fasi. Valuteremo la gestione di uno specifico progetto reale (se pur semplificato per esigenze didattiche) dove analizzeremo l’impatto dei processi sulle attività di progetto.

Tralasceremo, tuttavia, alcuni processi legati alla fase di esecuzione del progetto, così come quelli di gestione degli approvvigionamenti, della qualità, delle risorse umane e delle comunicazioni. Altri processi secondari di project management saranno inglobati all’interno delle 6 fasi individuate, pur senza darne una dettagliata descrizione.

La gestione dei costi di progetto è un processo generalmente incluso nella fase, più generale, di pianificazione dei progetti, ed è strettamente legato alla stima delle risorse e dei tempi.
Nel nostro modello, abbiamo ritenuto opportuno scindere questo processo, inserendolo in un’apposita fase, la Gestione dei Costi, per più di un motivo:  

• Questo processo è spesso trascurato, sia nella letteratura che nella sua applicazione, in quanto, da molti, è considerato un logica conseguenza della stima dei tempi e delle risorse.
• La gestione dei costi è un processo molto articolato e complesso, richiede definizioni e l’applicazione di criteri gestionali applicati sia a livello aziendale che a livello di progetto.
• Gli enti interni ed esterni al progetto che ne sono coinvolti sono molteplici: il finance, gli acquisti, le ditte esterne, il controllo di gestione.
• Ha una importanza nevralgica, in quanto è sui costi che maggiormente si concentra l’attenzione di tutti gli stakholder aziendali. 

Da notare che l’estensione temporale della fase di Gestione dei Costi eccede quella strettamente legata alla fasi di pianificazione stessa, per la ragione che comprende la definizione del budget e degli investimenti, prima, e la consuntivazione e analisi degli scostamenti, dopo.
Questa fase è comunque parallela a quelle della pianificazione dei tempi e delle risorse.  Nonché all’analisi dei rischi.

Nel diagramma di flusso seguente è illustrato il modello semplificato di Gestione del Progetto che andremo a descrivere:

• Per ciascun fase sono individuati i processi;
• Per ciascun processo sono individuati gli input e gli output principali, alcuni evidenziati in un riquadro. Questi ultimi saranno oggetto della nostra attenzione.

 
Nei paragrafi successivi, per ciascuna fase, analizzeremo i principali processi, in cui saranno individuati:

• Riferimento del PMBOK,
• Diagramma di flusso,
• Descrizione,
• Responsabilità,
• Input e Output,
• Tecniche (se presenti),

Inoltre approfondiremo la teoria con:

• Esercizi di riepilogo,
• Applicazione del processo a un case study.

2.3  Avvio del progetto

PMBOK 4th Ed. Reference
Knowledge Area:	Project Integration Management
Processi:	4.1

La fase di Avvio è il primo passo per la realizzazione di un progetto.

Questa fase è costituita da un unico processo:  1.0 Avvio del Progetto.

Figura 1 – Fase 1 – Avvio del Progetto

Descrizione: “Avviare un progetto” consiste nell’esecuzione di tutte le attività necessarie a lanciare ufficialmente il progetto.
In questo processo vengono formalizzate le caratteristiche del prodotto o servizio che  andranno a costituire l’oggetto del progetto stesso.

Il processo, sebbene non generalizzabile, si può schematizzare nelle seguenti attività: 

1. Acquisizione da parte della Direzione Aziendale di tutte le informazioni utili all’azienda per migliorare e/o perseguire i propri obiettivi strategici (gli Input al processo possono essere per esempio: il Capitolato di progetto, il bando di gara, il contratto, un business case, una proposta di progetto, ecc.)
2. Analisi della documentazione disponibile:
1. Output principale è la decisione da parte della direzione aziendale a procedere ad una analisi di fattibilità del progetto.
3. Realizzazione dell’analisi  di fattibilità.
1. Output principale è il documento analisi di fattibilità corredato da una stima di massima del progetto e, se disponibile, dalla progettazione preliminare.
4. Realizzazione del Project Charter
1. Input a questa attività sono i modelli di project charter, se già facenti parte della documentazione standard aziendale.
2. Output è il project charter, documento ufficiale di decisione e avvio del progetto (vedasi paragrafo successivo)
5. Individuazione e ufficializzazione del Project Manager. Questo è un passo importante, perché con la nomina del responsabile di progetto, di fatto si da il via a tutte le fasi successive, avendone individuato il “regista”.
6. Avvio ufficiale del nuovo Progetto.
1. Output formale è l’ufficializzazione dell’avvio del progetto, che è sancito dalla firma del Project Charter da parte dello Sponsor e della Direzione Aziendale.
2. La fine di questo processo coincide con quello che i project manager chiamano “T0”, ovvero il momento in cui ufficialmente il progetto ha inizio.

 

A valle di questo atto formale, il Project Manager incaricato, indirà un “kick off meeting”, che è la prima riunione ufficiale del progetto e sancisce l’inizio di tutte le attività operative (vedasi riquadro).

Il diagramma di flusso del processo 1.0 Avvio del Progetto:

 

Progetto vs. Prodotto
Abbiamo visto cos’è un Progetto. Distinguiamo il progetto dal prodotto, che è il possibile output, fisico, del primo. I “Prodotti” sono cose tangibili che vengono prodotte dal progetto. 

Per questo motivo occorre non fare confusione tra i Processi di Gestione del Progetto vs. i Progetti di Gestione del Prodotto:

• Processi di Project Management: descrivono, organizzano e completano il lavoro del progetto.
Sono generalizzabili e applicabili al più dei progetti. La Gestione del progetto, abbiamo visto, sono tutte quelle attività di project management connesse con il governo del progetto, che prescindono dal prodotto stesso. Assicura il corretto flusso di progetto durante la sua evoluzione

• Processi orientati al prodotto: specificano e creano il prodotto del progetto. Sono specifici della particolare tipologia del progetto. Questi processi sono generalmente definiti dal ciclo di vita di progetto e dipendono dall’area di applicazione.

I processi di Project Management e i processi orientati al prodotto si sovrappongono ed interagiscono durante il progetto.

 

Chi: In genere è la Direzione Aziendale a gestire questo processo, servendosi del supporto di esperti interni e/o esterni all’azienda.
Nella fase di Avvio, non sono ancora stati individuati il Responsabile di Commessa (il Project Manager) e il team di progetto. Pur tuttavia, il supporto di coloro i quali saranno chiamati a gestire il progetto è di fondamentale importanza per una corretta e attendibile definizione degli output di questo processo.

Input: Input a questo processo sono tutte le informazioni utili alla direzione aziendale e/o al futuro Responsabile di commessa (Project Manager) per iniziare a definire scopo, attività, tempi e costi preliminari di progetto.
Gli input posso variare a seconda del tipo di progetto e/o del settore in cui si sta lavorando:

• Piano strategico aziendale;
• Capitolato di progetto;
• Bando di gara;
• Contratto;
• Proposta di progetto interno;
• Altri documenti informali (es. relazione di ricerca, piano di marketing, studio di settore, analisi della concorrenza,…)  

Output: I principali output di questo processo sono:

• Il Project Chapter;
• L’Individuazione del Project Manager;
• La documentazione preliminare di progetto;
• La formalizzazione e autorizzazione del lancio del progetto.

Gli output sono tutti preliminari e saranno oggetto di dettagliata ed esaustiva integrazione e revisione in fase di Pianificazione.
Ciò che è determinante al fine di una ottimale formalizzazione del progetto è la corretta individuazione dei requisiti generali del prodotto o servizio che si andrà a realizzare,  delle richieste e delle specifiche del committente.

Questo è particolarmente vero quando si sta partecipando ad una gara di appalto. La non corretta comprensione dei requisiti o errori di valutazione possono compromettere il risultato di progetto in termini di tempi, costi e qualità.

Molto spesso questa fase viene ingiustamente sottovalutata o ridotta ai minimi termini, ridimensionando l’impegno e le risorse impegnate, con gravi rischi per il progetto. Una non corretta stima iniziale del progetto, talvolta, conduce alla sua chiusura o a un grave ritardo o perdita economica.

 

2.3.1 Il Project Charter
Il principale output del processo di Avvio è il Project Charter, che, sebbene il più delle volte è realizzato solo parzialmente o superficialmente, è il documento che sancisce l’inizio ufficiale di un progetto. In taluni settori, come spesso accade nell’edile, può essere sostituito da altri documenti ufficiali richiesti dal committente, per esempio la Documentazione di Gara.

Ciò che vogliamo sottolineare, in questo paragrafo, è la necessità di strutturare un documento formale, che contenga tutte le informazioni disponibili, allo stato attuale del progetto, che consenta di assegnare in modo chiaro e definito il Responsabile di Progetto/commessa, e definire gli obiettivi strategici aziendali relativamente al progetto.

Descrizione:  Per il PMBOK “sviluppare il Project Charter è il processo di sviluppo di un documento che autorizza formalmente un progetto o una fase e che documenta i requisiti iniziali che soddisfano le esigenze e le aspettative” .

Il Project Charter è, dunque, il documento iniziale di una progetto che:

• Definisce quali obiettivi devono essere raggiunti.
• Identifica i principali sponsor o committenti del progetto.
• Individua il project manager.
• Dà una sintetica evidenza dei principali output/deliverable, tempi e costi del progetto.
• Dà una breve descrizione del progetto, sottolinea le principale assunzioni e vincoli.
• E’ un contratto tra la Direzione Aziendale e i principali stakeholder e il team di progetto che ne sommarizza le aspettative.
• E’ un documento vivo, che può essere cambiato durante il progetto, ma solo se variano le definizioni e i confini in termini di scopo e obiettivi del progetto. In genere non viene modificato nel corso del progetto e, in ogni caso, eventuali modifiche devono essere accettate dalla Direzione Aziendale e dal Project Sponsor.
• Include i risultati attesi del progetto, ma non come saranno raggiunti (proprio della pianificazione).
• Include, perchè il progetto è importante e le principali risorse finanziarie

• E’ la base sulla quale verrà realizzato il Project Plan. Questo documento garantisce che il progetto sia riconosciuto dall’azienda.
• Il Project Charter è un documento sintetico, a volte di sole 2 pagine.

 

Anche per il Project charter non esiste una regola fissa. Dipende dal tipo di progetto, dall’organizzazione, dal management, dai vari stakeholder.
In alcune organizzazioni e alcuni progetti non è detto che sia necessario, ed è sostituito da altri documenti formali. Per esempio nel caso di una gara di appalto.

A valle della approvazione del Project Charter, il progetto può partire con la fase di pianificazione. 

Chi:  Il Project Charter viene emesso dal Project Sponsor, di concerto con la Direzione Aziendale. E’ buona norma che il Project Manager, in questa fase, sia già individuato e contribuisca fattivamente alla sua realizzazione.
Se il progetto è un progetto esterno (esempio costruzione di un edificio) allora è il Project Manager che realizza il documento e lo sottopone per approvazione alla Direzione Aziendale.
Il Project charter deve essere firmato dallo sponsor e dai principali stakeholder del progetto per accettazione.

Input: tutti i documenti a disposizione dell’azienda al fine di inquadrare il progetto sono input.
E’ molto importante che l’azienda si doti di un modello di project charter in modo tale che tutti i progetti possano essere avviati con analoga documentazione e informazione.

Output: Il project charter. E’ un documento cartaceo o elettronico.

Di seguito è inserito un esempio di un project Charter.

Kick off meeting

Abbiamo accennato al kick off meeting come ultimo step del processo di Avvio.
Non in tutti i progetti questo meeting ha luogo nelle primissima fase del progetto. Talvolta si decide di porlo in una fase più avanzata della pianificazione o comunque prima dell’inizio della Fase di Esecuzione del Progetto. Anche in questo caso è fortemente dipendente dal tipo di progetto e  dal settore.

E' una riunione organizzata e gestita dal Project Manager, a cui partecipano i responsabili delle varie aree aziendali coinvolte nel progetto,  allo scopo di allineare tutti i principali attori, sugli obiettivi,  procedure, piani e per far partire il processo di costruzione del team di progetto.

Tipicamente, è una sorta di workshop, più che un meeting formale, che può durare anche più di un giorno e includere diverse attività, come la condivisione del project Charter o del business plan, un primo brainstorming sui vincoli e della struttura organizzativa di progetto…etc.

 

PROJECT CHARTER - Esempio

 

Progetto:	Codice progetto:
Data:	Revisione:
Cliente:	Sponsor:

OBIETTIVI
Descrive gli obiettivi del progetto e  le ragioni per i quali si è deciso di lanciare il progetto. Devono essere chiari, definiti, misurabili e raggiungibili, al fine di consentire al Project Manager e al team di individuare se e quando il risultato di progetto è stato raggiunto.
PRINCIPALI DELIVERABLE
Fornisce una lista di “alto livello” di quello che deve essere fatto per raggiungere gli obiettivi di progetto.  Ciascun deliverable dovrebbe essere sufficientemente dettagliato così che il team di progetto abbia una chiara comprensione di ciò che dovrà essere pianificato, e  in seguito, realizzato.
DEFINIZIONE DELLO SCOPO
Definisce lo “scopo” del progetto (vedasi paragrafo sullo scopo). Definisce “cosa deve essere fatto” “In Scopo”  definiamo  tutto ciò che il progetto deve includere per raggiungere gli obiettivi (cosa include). “Fuori  Scopo” è  tutto ciò che non è parte del progetto e non dovrà essere realizzato dal team di progetto (cosa non include).
4.     MILESTONE
Identifica le milestone del progetto, includendo le date di pagamento del cliente.
5.     ASSUNZIONI, VINCOLI & DIPENDENZE
Identifica i  vincoli e le ipotesi (“assumption”, fattori potenziali di rischio che hanno impatto sul progetto e potrebbero rendere difficile la sua realizzazione) che stanno alla base della definizione dello “scopo” del progetto e per la successiva fase di pianificazione.  L’obiettivo di questo paragrafo è la definizione dei confine dei tre principali vincoli del project management (scopo, tempi e costi) che dovranno essere gestiti. Inoltre, individua la dipendenza da risorse particolari coinvolte nel progetto o risorse economiche e/o finanziarie.
6.            TEMPISTICA PRELIMINARE
Descrive a grandi linee le principali date di inizio, esecuzione e la fine attesa del progetto. Non è ancora la schedulazione del progetto, che prenderà corpo nella pianificazione.
7.            PRINCIPALI RISORSE & LIMITI DI COSTO PRELIMINARE
Si effettua una stima di massima delle risorse umane ed economiche del progetto. E’ particolarmente importante quando occorre definire un’offerta economica da presentare a un committente o per partecipare ad una gara. In questa fase, in genere,  non siamo in grado di definire un budget, se pur preliminare, ma si individuano i limiti di costo e le principali voci di spesa.
8.            DOCUMENTI DI RIFERIMENTO & ALLEGATI
Deve essere allegato ogni documento utile per la definizione dello scopo, deliverable – es. Capitolato di gara, RFQ, RFP, offerte dei fornitori, Gantt preliminare, etc.
9.            STRUTTURA ORGANIZZATIVA DI PROGETTO
Identifica: Project Manager (Capo Commessa) Team di progetto Le principali risorse assegnate Le dipendenze gerarchico/funzionali con gli altri stakeholder. In questa fase siamo piuttosto ad una individuazione di risorse “desiderate” che dovranno essere definite nella fase di pianificazione.
Funzione		Nome	Ruolo
9.  AUTORIZZAZIONE
Approvato da:	Responsabile Aziendale / Sponsor / Amministratore			Date
Approvato da:	Project Manager			Date

 
A valle di ogni capitolo di teoria di Project Management, andremo ad applicare la metodologia individuata con pratici esempi che si riferisco ad un progetto reale, che per uso didattico sarà comunque semplificato.

Nella seguente sezione, sotto il cappello “Case study”, viene affrontato il caso di una impresa di costruzioni analizzando, attraverso un esempio di progetto completo, tutti gli aspetti che tale impresa deve affrontare per pianificare, eseguire e controllare un proprio progetto.

Il progetto scelto è quello per la realizzazione di un complesso di edifici universitari.
Ipotizzeremo di essere il Project Manager dell’azienda 321Progetti, al quale verrà affidato il progetto.

Requisiti di progetto forniti dal committente:

• Progetto: Realizzazione di edifici per la nuova Facoltà di Ingegneria.
• Ente committente: Università di Napoli
• Lavori da completarsi entro 2 anni dalla data di inizio.
• Assegnazione lavori: gara pubblica.
• Documenti forniti: Capitolato di gara

Sulla base delle informazioni ricevute la 321Progetti realizza il Project Charter:

PROJECT CHARTER
 

Progetto:  Nuova Facoltà di Ingegneria	Codice progetto: NFI10
Data: 10 Gennaio 2010	Revisione: 0
Cliente: Università di Napoli	Sponsor: Amministratore Delegato 321Progetti

1.            OBIETTIVI
Il progetto è perfettamente allineato alla mission della 321Progetti: Il progetto consiste nella realizzazione di un complesso Universitario, costituito da tre edifici principali. Obiettivi principali: Pieno rispetto degli impegni iniziali presi sulle aree di intervento con modalità e tempi concordati pienamente rispettati. Consegna al committente degli edifici entro due  anni dal T0, secondo quanto illustrato nel capitolato di progetto. Definizione della progettazione esecutiva del progetto entro tre mesi dall’aggiudicazione del progetto. Il progetto dovrà dimostrare la fattibilità tecnica del complesso secondo le richieste del committente. Il progetto dovrà evidenziare un margine economico del progetto pari ad almeno il 20% del ricavo complessivo. Piena trasparenza e visibilità dei costi sostenuti e degli investimenti effettuati.
2.            PRINCIPALI DELIVERABLE
I principali deliverable richiesti dal progetto sono: DELIVERABLE NOTE PROJECT MANAGEMENT   Pianificazione   PROGETTAZIONE   Progettazione di base   Progettazione di dettaglio   ATTIVITA' GENERALI DI CANTIERE   IMPIANTI DI CANTIERE   OPERE GENERALI   COSTRUZIONE FABBRICATI (AULE, DIPARTIMENTI, RETTORATO)   Strutture fabbricato   Opere edilizie fabbricato   Opere impiantistiche   CHIUSURA CANTIERE   SMONTAGGIO CANTIERE   CHIUSURA AMMINISTRATIVA
3.            DEFINIZIONE DELLO SCOPO
In “Scopo” Consideriamo “in scopo” la realizzazione nei tempi e nei costi preventivati di tutti i deliverable elencati nella sezione “deliverable”, così come richiesto dal committente. Fuori “Scopo” è tutto ciò non espressamente richiesto dal cliente
4.           MILESTONE
Di seguito le principali milestone di progetto identificate: NUOVA FACOLTA' INGEGNERIA   Pianificazione Milestone progetto PROGETTAZIONE   Progettazione di base Milestone progetto Progettazione esecutiva Milestone pagamento ATTIVITA' GENERALI DI CANTIERE   IMPIANTI CANTIERE Milestone progetto OPERE GENERALI Milestone progetto REALIZZAZIONE FABBRICATI   FABBRICATO AULE Milestone pagamento FABBRICATO DIPARTIMENTI Milestone pagamento FABBRICATO RETTORATO Milestone pagamento CHIUSURA CANTIERE Milestone progetto CONSEGNA AL COMMITTENTE Milestone pagamento
5.           ASSUNZIONI, VINCOLI & DIPENDENZE
Assunzioni: Il capitolato di progetto non evidenzia rischi legati alla progettazione e realizzazione tecnica degli edifici. Le risorse ingegneristiche sono tutte interne all’azienda.  Tutte le autorizzazioni saranno disponibili prima della data di T0 Vincoli: Parte delle realizzazioni edili e di cantiere dovranno essere affidate a ditte esterne. Disponibilità delle squadre operai impegnati su altri progetti. Disponibilità delle attrezzature. Dipendenze: Dare evidenza del cash flow di progetto al fine di evidenziare la fattibilità finanziaria. Dipendenza da risorse particolari coinvolte nel progetto.
6.            TEMPISTICA PRELIMINARE
7.            PRINCIPALI RISORSE & LIMITI DI COSTO PRELIMINARE
Stima di massima delle risorse umane ed economiche del progetto. Si individuano i limiti di costo e le principali voci di spesa. Il progetto dovrà evidenziare un margine economico del progetto pari ad almeno il 20% del ricavo complessivo.
8.            DOCUMENTI DI RIFERIMENTO & ALLEGATI
Capitolato di progetto, RFP consulenze esterne; RFQ  dei fornitori esterni, Gantt preliminare.
9.            STRUTTURA ORGANIZZATIVA DI PROGETTO
Project Manager (Capo Commessa)del progetto è nominato l’ing. Mario Rossi Il Team di PM  sarò costituito da 4 risorse. Le dipendenze gerarchico/funzionali con gli altri stakeholder saranno definite dall’OBS di progetto. Le ditte esterne in appalto saranno coordinate dal Responsabile di Cantiere, che risponderà gerarchicamente al Capo Commessa Le principali risorse assegnate:
Funzione		Nome	Ruolo
Direzione Tecnica			Direttore tecnico
Direzione Amministrativa			Responsabile Amministrativo
Direzione Qualità e Sicurezza			Responsabile Qualità
Direzione Acquisti			Responsabile Acquisti
9.  AUTORIZZAZIONE
Approvato da:	Responsabile Amministratore			Date
Approvato da:	Project Manager			Date

 2.4  Realizzazione del Project Management Plan 

PMBOK 4th Ed. Reference
Knowledge Area:	Project Integration Management
Processi:	4.2

Poniamo la nostra attenzione, ora, su un processo molto importante: la Realizzazione del Project Management Plan o Piano di Project Management. Questo processo consente di individuare, definire preparare tutti i piani del progetto.

Realizzare il Piano di Project Management
Facciamo subito una premessa: il Piano di Project Management non è un output dei processi di avvio.  Il Project Management Plan (Piano di Project Management) è sviluppato durante tutta la  fase della pianificazione. E la sua chiusura e approvazione deve coincidere con la fine della fase stessa.
Un progetto, infatti, non può passare alla fase di esecuzione se prima non c’è la formale approvazione del Piano di Project Management.
Tuttavia, fin dalla fase di avvio si incominciano ad individuare e definire i principali componenti del Piano di Project Management, in particolare i piani ausiliari e  il Project Charter.

Descrizione
Il Piano di Project Management è il documento che consolida tutti i piani e le procedure utilizzati dal project manager.

Figura 2.8 – Il piano di project management

Il Piano di Project Management lo possiamo immaginare come un raccoglitore nel quale andranno a confluire tutti i piani di gestione ausiliari e le baseline di progetto.

I piani ausiliari del Piano di Project Management sono i piani che descrivono come verrà gestito il progetto  nelle singole aree di conoscenza, ed identificano l’organizzazione, le metodologie, le procedure, gli strumenti e le tecniche da utilizzare per gestire i vari ambiti (costi, tempi, qualità, rischi, risorse umane, ecc…) e comprendono (a titolo indicativo):

• Il Piano di gestione dello scopo del progetto
• Il Piano di gestione della schedulazione
• Il Piano di gestione dei costi
• Il Piano di gestione della qualità
• Il Piano di miglioramento dei processi
• Il Piano di gestione del personale
• Il Piano di gestione della comunicazione
• Il Piano di gestione dei rischi
• Il Piano di gestione dell’approvvigionamento.

La presenza o meno dei piani ausiliari  è principalmente legata alla complessità del progetto, all’organizzazione che lo gestisce e alle leggi che possono imporre la realizzazione di determinati piani (esempio il piano di gestione della qualità o della sicurezza).
Su un progetto di piccole-medie dimensioni non sarà necessario definire tutti i piani ausiliari.

La pianificazione del progetto è, anch’essa, inserita nel Piano di Project Management e rappresenta, però, solo una delle componenti del piano. All’interno del Piano di Project Management sono presenti, infatti, oltre ai piani ausiliari, anche altri elementi, quali gli output della pianificazione (schedulazione, Gantt, budget, scopo, ecc…). Le “baseline” (il riferimento) delle prestazioni che andranno misurate sono la base rispetto alla quale verificare l’andamento del progetto:

• La baseline dello scopo di progetto,  comprende  la work breakdown structure (WBS), la lista delle attività e i work package, contenente le indicazioni per l’interpretazione dei vari elementi della WBS.
• La baseline di costo riporta l’andamento del budget previsto nel tempo.
• La baseline della schedulazione comprende la pianificazione temporale delle attività previste e viene utilizzata per verificare il rispetto dei tempi.

Una baseline non dovrebbe essere mai  modificata, a meno che non intervengano richieste da parte del committente, dal top management o eventi esterni che non erano stati presi in considerazione durante la pianificazione (Esempio una nuova legge o regolamento).
La modifica di una baseline è una questione delicata e di non poco conto. Questo perché le “baseline” sono il riferimento rispetto al quale il PM deve valutare l’avanzamento del progetto, e, in caso di scostamento, attuare gli opportuni  interventi correttivi atti a riportare il progetto in linea con essa.
Il Project manager viene giudicato  principalmente sul rispetto delle “baseline”, vale a dire sulla sua capacità di portare a termine il progetto così come era stato pianificato inizialmente.

Il Piano di Project Management è concordato con tutti coloro che sono coinvolti nel progetto (Direzione Aziendale, Struttura Operativa Aziendale, Clienti, Fornitori, Team di Progetto, ecc.),  e formalmente approvato per la propria parte di competenza da ciascun stakeholder. Il piano è poi rivisto nel suo insieme e firmato dallo sponsor, dalla direzione aziendale e dal Project Manager. Diventa, così, il documento formale di riferimento utilizzato durante il progetto.

Per concludere, il Piano di Project Management è creato per rispondere a  domande del tipo:

• Come pianificherò, gestirò e controllerò il progetto?
• Quali saranno le procedure, le tecniche e le metodologie che utilizzerò?
• Come misurerò il raggiungimento degli obiettivi?
• Come saranno stimate le risorse e come confronto gli scostamenti tra risultati attesi ed ottenuti?
• Come gestirò le azioni correttive e le modifiche alla pianificazione?
•  
•  
•