SlideShare une entreprise Scribd logo
1  sur  118
2 integration e scope management
SCOPE MANAGEMENT
2 integration e scope management
GESTIONE DELL’INTEGRAZIONE DEL PROGETTO E SCOPE 
MANAGEMENT 
Cosa è un progetto: 
“E’ un’iniziativa temporanea intrapresa per creare un prodotto, un servizio o un risultato con 
caratteristiche di unicità” – PMBOK – 5° Ed. 
Quindi esiste un vincolo molto rigido che è il Tempo, anche se questo vincolo non è molto certo, ma 
dovrebbe essere chiaro qual è il tempo effettivo per portare a termine un progetto. Anche la 
caratteristica di Unicità, anch’esso un vincolo rigido, non è cosa semplice per un P.M. 
Ci sono dunque delle incertezze, dei parametri assolutamente rigorosi, che il P.M. deve 
assolutamente gestire in quanto a monte risultano concetti molto variabili. 
Il concetto di progetto deve essere visto quindi da un punto di vista più ampio abbracciando variabili 
più complesse e concatenanti tra di loro.
Da dove nasce un progetto? Tendenzialmente esso nasce da un bisogno, ovvero da un sogno da 
realizzare. 
Si decide quindi di mettere in atto una serie di sforzi, di impegni, ed i passaggi vertono a valutare i 
bisogni, le soluzioni, traguardando quelli che sono ad es. i mezzi di trasporto, i tempi, i costi, ecc. 
Di tali possibili soluzioni cerco di capire le effettive esigenze e individuo quella che certo più si adatta 
a risolvere il mio bisogno. Quindi si effettua un primo percorso, divergente, cercando di capire quali 
sono tutte le possibilità esistenti per raggiungere lo scopo, e poi convergente verso la soluzione. Tale 
soluzione viene definita tramite dei requisiti, delle specifiche. Cioè andiamo a descrivere quali sono 
le caratteristiche di questa cosa che andremo ad analizzare per soddisfare il nostro bisogno. Capite 
le specifiche si provvede a realizzarle e a generare una soluzione ossia la Realizzazione di quelle 
specifiche che hanno identificato la soluzione al nostro bisogno. 
Ora il problema non è ancora risolto in quanto aver realizzato delle specifiche di fatto non ancora 
abbiamo prodotto nulla. C’è bisogno che qualcuno usi la soluzione che ho messo in piedi ottenendo 
dei risultati che provocano dei benefici che infondono i bisogni da cui sono partito. 
Ad es. in un industria meccanica, ovvero all’interno della mia linea produttiva, ha bisogno di un tornio 
verticale per fare un certo pezzo. Quindi il mio BISOGNO è modellare un certo pezzo e quindi mi serve 
un componente per modellarlo. Per far ciò posso avere delle stampanti tridimensionali a laser ovvero 
dei torni verticali, orizzontali ecc. ma ad un certo punto ne scelgo uno: ad es. il tornio verticale e 
quindi descrivo la lavorazione ovvero come dovrebbe essere questo attrezzo che mi produce questa 
lavorazione – SPECIFICHE. Lo realizzo ed ottengo il pezzo richiesto ed ho fatto il progetto. Ma se 
nessuno lo usa non me ne faccio niente di tale progetto. Cioè il progetto è stato inutile. Quindi ci 
vuole qualcuno che lo piazzi nella linea produttiva, che lo attivi, che lo faccia girare, magari anche 
qualche operatore. Quindi quell’attrezzo mi genera una soluzione o risultato che farà sì che si possa 
impiantare un sistema di cambio automatico su una macchina più performante che mi fa distinguere 
dalla concorrenza: che è poi il bisogno principale da cui sono partito. 
Quindi il progetto in se non basta: c’è un mondo che gira intorno al progetto. Che è un mondo 
estremamente significativo che ne decreta il successo.
Progetti che non rispondono a dei bisogni e che non generano dei risultati, che non portano a dei 
benefici sono anche fatti molto bene, ma rischiano di essere inutili. “Non c’è niente di peggio che fare 
una cosa molto bene ma inutile”. 
Tutte le priorità per poter fare delle scelte durante il progetto nasceranno principalmente dal 
BENEFICIO. 
Capire quale mondo gira intorno al progetto, è a tutti gli effetti una ricchezza enorme per il P.M. 
proprio sul piano concreto. Anche se in realtà stiamo parlando di una fascia che di solito non è nella 
visibilità del P.M. in quanto relativamente ai benefici e/o bisogni si hanno coinvolgimenti soprattutto 
da parte della direzione, del top manager. (Program Manager) 
Come facciamo a lavorare quindi su tali concetti. Abbiamo bisogno di alcuni strumenti e di 
un’organizzazione. Abbiamo bisogno di esigere per il nostro progetto una serie di fattori. 
Un altro esempio significativo: 
Parliamo ad es. della Mission della Coca Cola: la Mission è quella cosa che dice perché una azienda 
esiste. 
Una azienda esiste, oltre che per fare soldi – ma non è detto in quanto ci sono aziende no profit – 
anche per una caratterizzazione del suo modo di essere che magari è il motivo per fare i soldi. 
Ad esempio una mission della Coca Cola è: “To Refresh the world” – rinfrescare il mondo, ecc. 
Quindi la mission è in realtà una cosa principale per la vita di un’azienda. Esso da l’imprinting 
all’attività aziendale, il suo modo di lavorare. Come fa la Coca Cola a realizzare la propria mission? 
Esso mette in atto una serie di azioni: Obiettivi di tipo strategico misurabili e temporali. 
Dunque come fa la Coca Cola a rinfrescare il mondo…?? 
Ad esempio può dire: 
– Voglio migliorare del 2% la simpatia del mio marchio nella penisola scandinava nel prossimo 
anno. 
– Incremento del 5% le vendite nel sud est asiatico nei prossimi due anni 
– Ecc.
La mission viene sostanzialmente realizzata dalla strategia. La strategia è un percorso che l’azienda si 
dà ed è fatto da una serie di passi, di scalini, di obiettivi di tipo strategico attraverso i quali realizza la 
propria mission. 
Ma come si fa ad es. ad aumentare del 2% la simpatia del mio marchio nella penisola scandinava nel 
prossimo anno: ad esempio potrei attivare un programma di sponsorizzazione per gli sport nordici. 
Oppure faccio una bella campagna pubblicitaria, ovvero faccio delle belle bottiglie a forma di pino, 
magari perché richiama le foreste di pino molto sviluppate in quella zona. 
Nel sud est asiatico come faccio ad aumentare del 5% le vendite nei prossimi due anni: posso 
ristrutturare la rete di vendita magari gestendo anche dei chioschi anziché solo dei supermercati, 
ovvero faccio una campagna pubblicitaria, o faccio una etichetta a forma di pagoda, ecc. 
Quindi per realizzare degli obiettivi strategici metto in atto quelle iniziative suddette, cercando di 
smuovere, di cambiare una situazione che ho intorno con delle iniziative mirate ad aiutarmi a 
realizzare quegli obiettivi. Ma tali iniziative allora sono dei Progetti che sono gestiti da un P.M. il quale 
identificherà una serie di requisiti (come detto prima) che poi cercherà di realizzare, concretizzare. 
Quindi il P.M. ha il compito fondamentale di identificare i requisiti che poi vanno realizzati. 
Ma tutto questo non basta. Ad es. – perché voglio fare un programma di sponsorizzazione, ovvero 
una campagna pubblicitaria o attivare una rete di vendita, ecc. 
Questi sono tutti progetti che formano un programma che necessariamente devono essere gestiti da 
un Program Manager. 
Quindi il programma ed il progetto, pur guardando nella stessa direzione, vengono visti da due punti 
diversi. Uno avrà come attenzione quella di realizzare i requisiti (project manager), l’altra avrà come 
attenzione di valorizzare il contributo che questa realizzazione di requisiti porta alla realizzazione del 
beneficio e quindi dell’obiettivo (program manager). 
Tali punti di vista sono estremamente diversi tra loro. 
Ad esempio: io sono il P.M. del progetto della bottiglia a forma di pino che magari è anche un progetto 
spettacolare, che risponde a tutti i requisiti: tempi, costi, addirittura si è trovato anche un sistema di 
stoccaggio che ottimizza gli spazi e che addirittura stà creando un vantaggio importante sia nel
magazzinaggio, che nei trasporti. Ma il Program Manager, che invece ha l’obiettivo di migliorare la 
percezione del brand (cioè del marchio), un bel giorno entra in un bar e leggendo il giornale ascolta 
due persone che parlano tra loro discutendo negativamente del fatto che molte aziende 
multinazionali raccolgono sempre le tradizione del posto per migliorare il proprio marchio. 
A questo punto il Program Manager, avendo subito avviato un sondaggio in merito, si rende conto 
della veridicità di tale affermazione, che reputa quindi negativa per il marchio. E quindi la prima casa 
che fa è quello di eliminare tale progetto anche se esso va benissimo come detto prima. In quanto 
non serve più, ovvero può essere controproducente. 
Da qui discende il fatto che il program manager pensa alla realizzazione dei benefici e non a realizzare 
i requisiti. 
A questo punto c’è un altro concetto da affrontare. 
Il Program manager gestisce tutti i progetti al fine di portare dei benefici alla propria azienda. 
Ma occorre prendere in considerazione che ad es. il progetto di sponsorizzazione, di pubblicità, di 
rete di vendita, ecc. sono iniziative legate alla strategia ed hanno inevitabilmente un costo 
preventivato per realizzarle. Ed inoltre non ci sono risorse infinite per realizzare la propria strategia. 
Ognuno di tali iniziative ha un suo significato legato a degli obiettivi strategici. Gli obiettivi strategici 
sono tutti importanti e significativi. Però esistono degli obiettivi strategici che se non raggiunti 
determinano il fallimento dell’azienda. Oppure ci sono degli obiettivi strategici che se non raggiunti 
determinano una difficoltà dell’azienda. 
Quindi pur essendo tutti importanti, ci sono quelli di maggiore importanza e quelli di minore 
importanza. 
Si può dare ad ogni iniziativa quindi un peso, un valore numerico o di giudizio, al fine di creare una 
classifica. Inoltre ogni iniziativa, progetto o programma incide sulla realizzazione dell’obiettivo 
strategico in misura diversa. Ci saranno quei progetti determinanti per ottenere il risultato; ci saranno 
progetti che aiutano e progetti che supportano. Anche in tal caso si possono fare delle classifiche a 
punteggio o a giudizio.
Indefinitiva stiamo capendo, tra tutti i progetti, requisiti, ecc. qual è il loro peso sul raggiungimento 
degli obiettivi strategici. 
Si possono avere delle iniziative più semplici, facili ed altre più difficili, più rischiose che quindi 
possono avere un peso differente per tale raggiungimento. 
Esistono quindi una serie di parametri che caratterizzano i singoli progetti e requisiti. 
In alto avrò quindi i progetti che meglio riescono a traguardare gli obiettivi strategici ed in basso quelli 
meno. Addirittura ci possono essere quei progetti o programmi che non riescono proprio a 
traguardare quanto sopra o che addirittura possono essere cancellati. 
Chi prende queste decisioni è il Portfolio Manager. 
Se non c’è un program manager ci deve pensare il P.M. a capire quali possono essere i benefici da 
portare all’azienda. Ma un Portfolio manager c’è sempre. 
Quindi la selezione dei progetti che andranno a comporre il project portfolio (portafoglio progetti) di 
un’impresa è un’importante scelta strategica. Deve necessariamente basarsi su valutazioni oggettive 
di opportunità legate a operazioni di marketing o aspettative sul ritorno degli investimenti, ma che 
tengano conto delle competenze interne e dei rischi collegati a ogni attività progettuale. 
Il concetto di Integrazione nell’ambito del Project Management non deve, infatti, riferirsi solamente 
a un’integrazione fra attività e risorse di un singolo progetto, ma a una gestione integrata e 
coordinata del project portfolio in un’ottica di Multi-Project Management. L’obiettivo è quello non 
solo di arrivare a modelli generali che sviluppano le competenze core dell’organizzazione e che 
permettano di ottenere prestazioni e un controllo dei progetti che sarebbero inaccessibili nel caso di 
una loro gestione separata. 
In questo contesto riveste un ruolo fondamentale la pianificazione e assegnazione delle attività 
programmate che deve essere attenta a bilanciare il lavoro alle dimensioni e alla rilevanza del 
progetto.
PRIMO GRUPPO DI PROCESSI: INTEGRAZIONE 
Ritorniamo alle competenze del P.M. Egli dovrà tenere bene a mente il complesso del lavoro che 
dovrà svolgere e che sinteticamente viene riportato nel cosiddetto Framework del PMBOK. Esso 
rappresenta la” cassetta degli attrezzi”, la mappa del territorio della gestione dei progetti. 
Ogni volta che occorre far partire un “progetto” occorre capire cosa c’è da fare e con chi hai a che 
fare. 
Esistono dunque degli strumenti relativi ai costi, ai tempi, alle risorse umane, ai rischi, ecc. Ci sono 
degli strumenti che si chiamano gruppi di processi che ci permettono di organizzare il progetto, di 
pianificare il futuro. All’interno dei gruppi ci sono le fasi. 
Tali processi vengono in realtà presi contemporaneamente e non in maniera isolata. Il tema 
essenziale nel progetto è dunque l’integrazione che tiene assieme tutti i processi, in quanto il 
progetto è un sistema integrato.
Lo scopo del P.M. è proprio quello di effettuare l’integrazione dei processi, cioè ha il compito di 
riunire tutte le fasi che magari vengono svolte da altre persone. Ad es. la pianificazione dei tempi 
probabilmente lo fa il plainer (o specialisti dei tempi e così via). Il P.M. dovrà integrare tutto ciò che 
gli viene dalle singole persone. 
Quindi la prima area di conoscenza del P.M., e anche del PMBOK, è l’INTEGRAZIONE. 
Cos’è l’integrazione del progetto? (vedi libro PMBOK) 
La gestione dell’integrazione di progetto include i processi e le attività necessari per identificare, 
definire, unificare e coordinare i vari processi e le attività di gestione del progetto nell’ambito dei 
gruppi di processi di Project Management. 
I processi di gestione dell’integrazione di progetto sono i seguenti: 
1.1 Sviluppare il Project Charter 
1.2 Sviluppare il piano di Project Management 
1.3 Dirigere e gestire il lavoro del progetto 
1.4 Monitorare e controllare il lavoro del progetto 
1.5 Eseguire il controllo integrato delle modifiche 
1.6 Chiudere il progetto o una fase 
Il P.M. inizialmente dovrà sviluppare il project charter, poi dovrà effettuare lo sviluppo del piano di 
project management. Dopodiché dovrà effettuare il monitoraggio e controllo, cioè capire come 
doveva andare e cosa occorre fare per farlo tornare sulla linea giusta. Alla fine dovrà effettuare il 
completamento del progetto (anche se il progetto non è finito). 
Ma un altro processo importante che si interseca è la pianificazione e l’esecuzione del progetto 
(Dirigere e gestire il lavoro del progetto), nonché la gestione delle cose che cambiano (Eseguire il 
controllo integrato delle modifiche).
Relativamente al cambiamento, quando parliamo di progetto abbiamo 2 tipi di cambiamento a cui 
facciamo fronte: 
1) Un cambiamento che dipende dal progetto – cioè noi facciamo un progetto ma sicuramente 
qualcosa cambierà oppure è già cambiato e noi dobbiamo rincorrerlo. Il progetto va di pari 
passo con il cambiamento. Tutte le volte che c’è un cambiamento nel processo interviene un 
progetto a generare questo cambiamento. 
2) Oppure il cambiamento può essere inteso come modifica: lo slittamento dei tempi è una 
modifica, oppure l’aggiunta di una risorsa in più all’interno del progetto. 
Tali modifiche sono una prassi normali nel progetto ma occorre tuttavia pensare tale cambiamento 
in maniera integrata. Cioè come va ad impattare tale cambiamento su tutti i gruppi di processo e 
quindi considerarlo nell’insieme (integrazione). 
Quindi ogni modifica deve essere valutata dal punto di vista del “sistema progetto” e deve essere 
accolta o rifiutata a seconda dei valori e dei vantaggi che porta. 
Esiste un comitato per capire l’impatto che genera tale modifica oppure può esserci un cambiamento 
che può essere gestito direttamente dal P.M. 
L’integrazione ha a che fare con il progetto. Ma il progetto è un sistema aperto. Cioè non dobbiamo 
solo preoccuparci di integrare il progetto nelle sue dimensioni interne (cioè delle 10 aree di 
conoscenza) ma dobbiamo preoccuparci cosa succede fuori inerente al progetto. Il progetto ha un 
senso rispetto alla sua strategia. Se mi affidano un progetto e non si sa perché occorre farlo 
sicuramente tale progetto non andrà a buon fine. 
Coerenza nella gestione dei dati di esecuzione del lavoro di Project Management e del flusso delle 
informazioni: 
Nell’ambito dell’integrazione quello che il P.M. deve fare è quello di individuare in che modo 
sviluppare la gestione e quindi decidere quali strumenti usare e con quali dettagli e profondità. Cioè 
in quale modo i processi di controllo vengono sviluppati. Ad es. per sviluppare il Project Charter dovrò 
avere delle informazioni a monte (Input). Tali informazioni vengono gestiti con degli strumenti per 
ottenere (in output) il risultato che volevamo (il project charter).
Durante il ciclo di vita del progetto esiste una grande quantità di dati che devono essere raccolti. 
L’analisi e la sintesi dei dati porta alla generazione delle informazioni di progetto che devono essere 
correttamente indirizzate verso gli STK interessati. Esistono molti modi di presentazione delle 
informazioni, tra queste i report rappresentano la modalità ufficiale. 
In particolare i dati sull’andamento del progetto vengono raccolti dal P.M. e dal suo team durante i 
processi di esecuzione. La loro analisi, e la trasformazione in informazioni avviene durante i processi 
di controllo. Tali informazioni vengono comunicate principalmente in tre maniere: verbalmente, 
memorizzandole opportunamente, oppure distribuendole in forma di report. 
Nei processi di esecuzione secondo il PMBOK si nota spesso l’output Work Performed Data, dati sulle 
prestazioni del lavoro, ottenuti dalle osservazioni o dalle misurazioni eseguite durante l’esecuzione 
del progetto (es. data d’inizio effettivo di un’attività, spese sostenute per l’acquisto di 
un’apparecchiatura, risultati del controllo di qualità su un deliverable, ecc.) 
Il PMBOK introduce il modello DIKW (acronimo di Data – Information – Knowledge – Wisdom), che 
è una novità introdotta dal PMBOK. E’ un modello riconosciuto che rappresenta la gestione delle 
informazioni. Esiste un percorso della conoscenza che parte dal Dato, poi ci ragiono e lo trasformo in 
Informazione che ha un significato che viene diffuso e quindi diviene Conoscenza, e nel momento in 
cui è conoscenza può diventare Sapienza. 
Il PMBOK non arriva alla sapienza però tutte le informazioni, dati, ecc. hanno questo percorso. Ad es. 
in un processo di controllo noi leggiamo dei dati: ad esempio “ho finito il 15 di giugno tale attività” – 
questo è un Dato. Trasformiamo tali dati, attraverso una fase di controllo, in Informazioni: ad esempio 
dovevo finire il 12 anziché il 15 di giugno e per cui sarei in ritardo. “sei in ritardo è un’informazione. 
Lo comunico e quindi diventa Conoscenza: tutti sanno che c’è un ritardo. Il percorso che il PMBOK 
esprime è quello di far vedere come i dati e le informazioni seguiranno sempre tali percorsi. 
I Work Performed Data sono dati grezzi che vengono utilizzati da tutti i processi di controllo. Questi, 
a loro volta, producono informazioni (Work Performance Information), ovvero le informazioni sulle 
prestazioni del lavoro. Tali informazioni sono ottenute tramite analisi, aggregazione e trasformazione 
dei dati ricevuti (ad es. stato di avanzamento della realizzazione di un deliverable o di una parte del 
progetto, stima a finire economica dell’intero progetto, nuova data di completamento stimata, …) a
differenza dei WPD i WPI sono dati contestualizzati (tengono cioè conto della tipologia di dato che 
rappresentano e dall’evoluzione nel tempo) e derivano da una vista integrata con altre aree di lavoro 
(per es., un dato sulle previsioni al completamento può integrare informazioni relative al tempo, al 
costo e all’ambito). 
Le WPI opportunamente compilate vengono raccolte nei cosiddetti Work Performance Report, 
report sulle prestazioni del lavoro, che sono spesso usati nelle riunioni e in tutte le occasioni in cui è 
necessario prendere decisioni (es. report di avanzamento del progetto, cruscotti manageriali, note 
informative, note di raccomandazione, …) 
Flusso dei dati 
Si intuisce quindi come tutti i processi di controllo avranno in input dei Dati ed in output delle 
Informazioni che saranno poi comunicate diventando Conoscenza (report).
SVILUPPARE IL PROJECT CHARTER 
Il project charter appartiene al gruppo di avvio. A cosa serve? 
E’ come una Magna Carta. Ad es. nel nostro ordinamento costituzionale abbiamo un gruppo di leggi 
fondamentali che determinano l’essere del nostro vivere civile. Ci sono delle norme che di fatto 
danno lo stile di tutto quello che succede nella nostra nazione. Nessuna norma ulteriore può essere 
contradditoria con queste leggi fondamentali della costituzione. Qualsiasi nuova legge viene 
esaminata ed essa deve essere allineata alle norme della costituzione altrimenti viene eliminata. 
Quindi nel charter noi andiamo a coagulare i tratti salienti del nostro progetto, i tratti caratteristici. 
Quelli tali per cui se devono essere revisionati o cambiati vuol dire che cambia il progetto. Nel charter 
ci sono i plinti, le colonne portanti del progetto. Il Charter è dunque un documento fondamentale da 
cui partire per lavorare: ci dice che cosa vogliamo fare. Esso quindi deve essere sufficientemente 
chiaro e allo stesso tempo ad alto livello. Non può entrare nei dettagli del progetto. Per il P.M. è uno 
strumento fondamentale in quanto rappresenta un po’ il suo mandato. Nella pratica il charter può 
chiamarsi in diversi modi: contratto, ecc. 
Nel momento in cui il charter è promulgato ecco che lì dentro c’è scritto chi deve fare il progetto e 
da lì il progetto parte. Nel charter è nominato il P.M.
Questo ci lascia pensare che non è il P.M. che fa il charter e tantomeno lo firma. Il P.M. riceve il 
charter e quindi può solo firmarlo per accettazione. 
Il charter viene fuori dallo Sponsor ma nella realtà il PMBOK cela il fatto che quella figura che poi si 
chiamerà P.M. in realtà fa anche il charter, ma l’importante è che lo faccia poi firmare allo Sponsor. 
Il P.M. in genere, si fa’ il Charter altrimenti non sa cosa fare del progetto. La presenza di alcuni vincoli 
presenti sul Charter (tempi, costi, obiettivi) in realtà agevola il P.M. Si stabiliscono quali sono i suoi 
confini operativi. 
Il PMBOK raccomanda anche la partecipazione del P.M. alla stesura del charter. 
Il charter dovrà essere firmata da una figura organizzativamente elevata che può essere lo sponsor, 
il comitato, ecc. e chiunque ha l’autorità di decidere. Ovvero proviene da chi ha un bisogno. 
Il charter ci dice anche il perché si deve fare quel progetto. Esso nasce dal capitolato del progetto 
che è sostanzialmente una base del charter che poi si va ad affinare per completare il vero e proprio 
charter. 
Un’altra fonte del charter è il Business Case, una valutazione costi/benefici: ossia la ragione del 
perché fare il progetto attraverso una equazione del tipo Benefici > Costi + Rischi 
Un B.C. deve concentrarsi sui costi/benefici e quindi andare anche a capire come mai si fa questo 
progetto ed a che cosa può portare. 
Un progetto può nascere da un bisogno in generale: da un aggiornamento normativo, da una richiesta 
di mercato, da un cambiamento organizzativo, da una richiesta di un cliente preciso, da un’evoluzione 
tecnologica, da esigenze sociali, ecc. 
Il B.C. è un impegno per il P.M. in quanto lì c’è scritto di fatto quanto beneficio deve portare rispetto 
al costo che genera il progetto e su quello il P.M. verrà sfidato. 
A monte del charter ci possono essere dei contratti accordi di varia natura formali ed informali, dei 
livelli di servizio, ecc. 
Inoltre fra gli input che ci servono per poter costruire il P.C. ci sono due variabili collettive, di gruppo 
importanti:
a) Fattore ambientali ed aziendali che potrebbero potenzialmente influire sul successo della 
creazione del P. Charter 
FATTORI AMBIENTALI 
Interni Esterni 
• Cultura aziendale 
• Struttura organizzativa 
• Infrastrutture 
• Direttive e procedure standard di P. 
Management 
• Documentazione standard di P. 
Management 
• Disponibilità di risorse umane di insieme nel 
progetto 
• Presenza di P. Management Information 
System 
• Presenza di database su precedenti progetti 
con dati relativi ai rischi, costi, tempi, ecc. 
• Condizioni di mercato 
• Standard governativi o di settore 
• Limiti di tolleranza al rischio degli 
stakeholder 
b) Asset dei processi organizzativi: posseduti dalla propria organizzazione diverranno 
fondamentali nel favorire il successo (o l’insuccesso) del progetto. Gli Asset possono riferirsi 
all’insieme di criteri, procedure, piani o direttive, sia formali che informali, presenti in 
un’organizzazione, ma soprattutto alle esperienze pregresse divenute conoscenza esplicita 
(ad es. tempificazione delle attività, schedulazione completate, dati sui rischi, dati sugli 
Earned Value, ecc.) e contenuti nel Project Knowledge Base aziendale.
ASSET DEI PROCESSI ORGANIZZATIVI SUL PROJECT MANAGEMENT 
Direttive e procedure standard Project Knowledge Base 
• Criteri di valutazione dei progetti 
• Schematizzazioni di documenti (ad es. 
WBS, PERT, Rischi) 
• Direttive e procedure di qualità 
• Procedure di assegnazione delle risorse 
• Procedure di controllo finanziario 
• Procedure di gestione delle criticità 
nell’esecuzione 
• Procedure e tecnologie per la 
comunicazione 
• Procedure di valutazione e controllo dei 
rischi 
• Procedure di monitoraggio, controllo e 
approvazione delle modifiche di 
progetto 
• Criteri di misurazione delle prestazioni 
• Direttive e procedure di chiusura del 
progetto 
• Database sulle direttive e procedure 
standard 
• Database su cicli di vita standard di 
prodotti e progetti 
• Database su tempi standard delle 
attività di progetto e schedulazione 
completate 
• Database finanziario su budget e costi in 
progetti pregressi 
• Database sui livelli qualitativi standard 
• Database delle misurazioni dei processi 
di Project Management 
• Database dei rischi di progetto 
• Database delle Lesson Learned 
Tali variabili raggruppano una serie di fattori che vanno ad influenzare la modalità con la quale noi 
scriviamo il charter. 
Il fattore ambientale ed aziendale è un fattore di tipo generale: la cultura aziendale, la normativa di 
alto livello, ecc. 
Gli Asset dei processi organizzativi sono Asset (beni, patrimoni): beni strutturati della mia azienda, 
processi procedure, data base, informazioni proprietarie, ecc.
E’ chiaro allora che nel definire l’impianto del progetto, la sua carta di identità, devo tener presente 
di questi aspetti. 
Non è la stessa cosa costruire un palazzo di 6 piani a Milano ovvero a Caserta ovvero a Roma. 
Potrei fotocopiare il progetto ma il progetto è diverso in quanto i fattori ambientali sono diversi così 
come gli Asset aziendali. 
Tra gli strumenti e tecniche c’è uno strumento che c’è sempre: l’esperienza. 
Il progetto vuol dire qualcosa di proiettare nel futuro che sicuramente noi non conosciamo. Come 
faccio a capire il futuro allora? Ci provo sulla base del passato. Allora l’esperienza è quella struttura 
che mi permette di provare ad immaginare cosa potrebbe succedere. L’esperienza viene espressa dal 
PMBOK sotto la voce “parere degli esperti” cioè è un fattore condiviso da parte di altre persone che 
mirano a dare le migliori informazioni possibili, i migliori dati possibili per poter provare a ragionare 
su cosa succederà. 
(Fare attenzione in quanto il parere degli esperti non è esplicitato in tutti i processi del PMBOK.) 
In alcuni casi nel PMBOK, per alcuni processi non esiste proprio l’utilizzo del “parere degli esperti”. 
Altro strumento che il BOK ci suggerisce per lavorare sulla costruzione del charter sono le cosiddette 
“Tecniche di facilitazione”. Nell’andare a cogliere le informazioni per un B.C. dobbiamo andare a 
stuzzicare le persone a farli esprimere: Brainstorming, la gestione dei conflitti, ecc. 
Quindi sviluppare il project charter ha come output il project charter che autorizza il P.M. ad agire. 
Il contenuto di un project charter è variabile ed il PMBOK ne elenca alcuni. (vedi di seguito). 
Questo è dunque il documento che pone le fondamenta del progetto, tale per cui se cambia qualcosa 
nel documento vuol dire che cambia il progetto. 
Questo è il primo dei grandi processi. 
Il Project Charter è un Input al processo “Definire l’Ambito del progetto”.
DI SEGUITO VIENE PROPOSTO UN TEMPLATE DI PROJECT CHARTER
1. CODICE 
Titolo 
Descrizione breve 
Programma 
Cliente Referente 
Sponsor Referente 
Senior Executive Referente 
Descrizione del progetto 
Giustificazione del progetto 
Obiettivi di progetto (SMART) 
Ambito 
Tempi 
Costi 
Qualità 
Altri 
Deliverable Requisiti (High-level) 
Milestone Data attesa
Rischi di alto livello 
Minacce 
Opportunità 
Funzioni coinvolte Tipo di partecipazione 
Budget complessivo 
Criteri di valutazione del successo del progetto 
Project Manager 
Nome Cognome 
Funzione 
Responsabilità 
Livello di autorità 
Descrizione Documento 
Il Project Charter è il documento che ufficializza un nuovo progetto. 
Viene anche detto scheda progetto e può assumere aspetti e informazioni varie. 
Una volta che un’iniziativa è stata valutata ed analizzata, l’iniziativa (l’idea) diviene 
progetto una volta che viene ufficializzata attraverso il Project Charter che rende 
pubblica, a livello aziendale, la decisione presa. In alcuni casi, il Project Charter può 
contemplare al proprio interno altre informazioni di progetto, quali un piano di massima, 
il budget assegnato, indicazioni sul Team di progetto (il così detto Core Team – team che
lavora sin da subito a stretto contatto con il project manager) e il collegamento ad altri 
documenti allegati (il riferimento ad un contratto, un business case o ad un capitolato 
tecnico). 
Note per la compilazione 
Argomento Spiegazione
2. CODICE Codice univoco alfanumerico identificativo del progetto. Tutti i 
documenti che verranno creati successivamente avranno 
questo codice. Questo può essere formulato considerando o la 
sequenza dei progetti passati oppure secondo le regole 
dell’organizzazione o della funzione che sponsorizza il 
progetto 
Titolo Titolo del progetto 
Descrizione breve Breve descrizione del progetto 
Programma Campo da compilare solo nel caso in cui il progetto faccia 
parte di un programma 
Cliente Persona/organizzazione (interno o esterno) che usufruirà del 
prodotto/servizio finale del progetto 
Sponsor Persona/organizzazione (interno o esterno) che provvederà 
alle risorse finanziarie per il progetto 
Senior Executive Persona/organizzazione che ha facoltà di ufficializzare il 
progetto 
Descrizione del 
progetto 
In questa sezione viene dato ampio spazio ad una descrizione 
del progetto. 
Possono essere allegati anche un contratto od un capitolato 
tecnico 
Giustificazione del 
progetto 
Il Project Charter da una risposta alla domanda sul perché 
l’organizzazione abbia scelto proprio quell’iniziativa e non 
un’altra, dandone ampia spiegazione attraverso un business 
case. Si ricordi che un progetto può partire per: 
- una domanda di mercato 
- un bisogno dell’organizzazione 
- una richiesta di un cliente 
- un progresso tecnologico 
- un requisito di legge 
- un bisogno sociale 
Obiettivi di 
progetto (SMART) 
Qualsiasi progetto che inizi senza obiettivi chiari ha alte 
probabilità di insuccesso. L’acronimo SMART sta per: 
- Specifico (Specified) 
- Misurabile (Misurable) 
- Raggiungibile (Achievable) 
- Realistico (Realistic) 
- Raggiungibile entro un lasso di tempo (Time-Phased) 
In questa sezione, verranno elencati chiari obiettivi di 
progetto. Si ricordi che l’obiettivo di un progetto non è solo 
relegabile al prodotto/servizio atteso, ma devono essere 
considerati anche altri obiettivi che rappresentano specifiche 
aspettative da parte di tutti stakeholder che sono coinvolti nel 
progetto. Obiettivi di budget, obiettivi temporali, obiettivi 
qualitativi sono tutti elementi importanti sui quali verranno
valutate le performance del progetto e le capacità del project 
manager. 
Naturalmente è inutile sottolineare che questi obiettivi, nel 
caso in cui il progetto fosse particolarmente complesso, a 
volte sono contrastanti tra di loro e deve essere fatta opera di 
armonizzazione considerando diversi aspetti e diversi attori, e 
relative aspettative. Si considerino, per esempio, le 
aspettative del cliente, quelle dello sponsor o quelle dei 
responsabili di funzione, aspettative molte volte in contrasto 
tra di loro 
Deliverable e 
Requisiti 
(High-level) 
Il deliverable (si ricordi che to deliver significa consegnare) 
rappresenta il prodotto/risultato verificabile che deve essere 
prodotto secondo le esigenze/requisiti/specifiche del cliente. Il 
deliverable può essere sia di natura tecnica (una galleria, un 
ponte, un miglioramento di un servizio, etc..) ma anche 
gestionale (un verbale di un meeting, il piano di Project 
Management, il piano della qualità, etc..). Questa sezione 
elenca in maniera generale i deliverable ed i relativi requisiti 
che ci si attende dal progetto 
Milestone La milestone rappresenta un evento topico del progetto ed è 
collegata ad una data ben precisa. A questo livello, la 
milestone può rappresentare la data di inizio del progetto, la 
data di fine o date imposte dal cliente o dal contratto 
Risk (high level) In questa sezione viene richiesto a chi compila il documento di 
elencare ad alto livello quelli che potrebbero essere minacce 
od opportunità collegate al progetto. Sarà compito del project 
manager, o ad un membro incaricato del team, di 
approfondire successivamente la tematica 
Funzioni coinvolte e 
tipo partecipazione 
Le informazioni contenute in questa sezione offrono sia allo 
sponsor che al project manager una visione prospettica della 
complessità del progetto. Maggiore sarà il numero di funzioni 
coinvolte e maggiore sarà la complessità del progetto in 
termini di integrazione dei singoli apporti specialistici. Ogni 
funzione aziendale ha una propria competenza tecnica ed un 
proprio linguaggio. Più il progetto sarà trasversale 
all’organizzazione e maggiore sarà l’impegno del project 
manager in termini di integrazione e comunicazione 
Budget complessivo Stima di alto livello del budget complessivo del progetto. Può 
coincidere con il prezzo spuntato sul cliente (al netto 
dell’utile) 
Criteri di 
valutazione del 
successo del 
progetto 
In questa sezione vengono descritti i criteri per poter 
valutare, secondo delle regole, il successo o l’insuccesso del 
progetto. I criteri sono collegati ad obiettivi misurabili. Se gli 
obiettivi risultano misurabili si possono definire le regole per 
una corretta misurazione impostando opportuni criteri 
Project Manager In questa sezione viene indicato: 
- il nome del project manager assegnato, nonché la 
funzione di appartenenza
- il suo livello di responsabilità (responsabilità nella 
pianificazione, esecuzione e chiusura del progetto, 
responsabilità nel raggiungimento degli obiettivi 
prefissati) 
- il suo livello di autorità (cosa può fare e cosa il project 
manager non può fare, es: acquisizione di risorse, 
gestione del budget, gestione dei fornitori, possibilità di 
erogare premi e riconoscimenti al team, etc…) 
Riferimenti 
PMBOK® Guide 
PMBOK® Guide 
Versione Inglese Italiano 
Nome del 
documento 
Project Charter Project Charter 
Processo che lo crea 4.1 Develop Project Charter 4.1 Sviluppare il Project 
Charter 
Gruppo di processi Initiating Concezione/ Avvio 
Area di Conoscenza Project Integration Management Gestione dell’Integrazione 
di Progetto 
Processi che lo 
usano in input 
4.2 Develop Project 
Management Plan 
5.1 Collect Requirements 
5.2 Define Scope 
10.1 Identify Stakeholders 
4.2 Sviluppare il piano di 
Project Management 
5.1 Raccogliere i requisiti 
5.2 Definire l’ambito 
10.1 Identificare gli 
stakeholder 
Regole Dovrebbe essere emesso da un manager esterno al progetto 
che ricopra un livello gerarchico appropriato, od emesso 
secondo le regole dell’organizzazione. Il presente 
documento fornisce al project manager l’autorità e la 
responsabilità necessaria per utilizzare le risorse 
dell’organizzazione per le attività del progetto. 
Altre Fonti 
Kerzner: 
Secondo Kerzner, il Project Charter è il documento che attribuisce la responsabilità di 
gestione del progetto al project manager; in origine, infatti, il Project Charter 
rappresentava il documento che conferiva l’autorità di governo del progetto al project 
manager ed aveva, essenzialmente, una riconosciuta validità formale esclusivamente 
all’interno dell’organizzazione. In forme rappresentative estremamente sintetiche, il 
Project Charter si può tradurre in una semplice lettera di attribuzione di incarico al project
manager, da parte dello Sponsor di progetto: si parla infatti di Legal Agreement tra il 
project manager e l’azienda che commissiona il progetto. In alcuni contesti applicativi, Il 
contenuto informativo del Project Charter viene di solito esteso a comprendere i seguenti 
elementi: 
• Obiettivi specifici di progetto 
• Descrizione delle condizioni al contorno del progetto 
• Vincoli su tempi, costi, risorse e qualità 
• Requisiti/Aspettative del committente 
• Requisiti/Aspettative del cliente 
• Valori di budget e modalità di assorbimento delle risorse finanziare nel tempo 
• WBS di progetto 
• Impegni di risorsa 
• L’organizzazione di progetto e relative interrelazioni tra le varie Unità Funzionali 
• Matrice di responsabilità 
• Politiche di progetto e metodologia di gestione e controllo adottate 
• Piano dei rischi 
• Piano di gestione dei cambiamenti 
• Descrizione delle modalità di approvazione da parte del Management per le voci 
sopra descritte 
In teoria è lo Sponsor a preparare il Project Charter apportando la propria firma: in 
realtà potrebbe anche essere il project manager a redigere il documento da presentare 
allo Sponsor per l’approvazione. 
Si ricordi che se il progetto è suddiviso in fasi, il project manager potrebbe richiedere 
un project charter all’apertura di ciascuna fase.
Project 
Charter 
Business Case 
Requirements 
Documentation 
Sebbene all’interno del Project 
Charter vengano identificati i 
principali stakeholder (tra cui il 
project manager, il project sponsor 
e il cliente), la prima azione che il 
project manager dovrà compiere 
sarà quella di individuarli tutti 
formalizzando un documento 
Requirements 
Traceability Matrix 
Stakeholder Register 
Il Business Case fornisce 
l’inquadramento generale, i 
bisogni e le necessità, i 
presupposti e gli obiettivi 
dell’iniziativa che, una volta 
ufficializzata, diventerà progetto 
Project Scope 
Statement 
Project Management Plan 
Il project charter interviene nella definizione dei requisiti di alto livello del progetto. 
Sarà poi compito del project manager e del team di progetto approfondire l’analisi dei 
requisiti in maniera più analitica. I documenti contenuti nel Proejct Management Plan, 
fomalizzano i requisiti, le relative esigenze di tracciabilità, costituendo la fonte di 
importanti informazioni per una corretta definizione dell’ambito progettuale 
NODO: PM 01 TITOLO: PROJECT CHARTER N.: ver 1.0
Mappatura template Project Charter 
Initiating Planning Executing Monitoring & Controlling Closing 
4.1 
Develop Project 
Charter 
Project 
Charter 
4.2 
Develop Project 
management Plan 
5.2 
Define Scope
Esempio 
Viene di seguito illustrato un esempio pratico di utilizzo del Project Charter, 
riprendendo lo schema proposto nel presente documento. Si tratta di un progetto di 
Information Technology riguardante l’implementazione prototipale di una struttura 
Client-Server per il monitoraggio dei progetti aziendali. Il contesto in cui si ipotizza lo 
svolgimento del progetto prevede le seguenti caratteristiche: 
• Il progetto, fortemente voluto dall’amministratore delegato, rientra nel 
programma strategico per l’implementazione di un sistema di Project 
Management, che sarà realizzato attraverso i seguenti progetti: 
o Una struttura informatizzata (il progetto di esempio) 
o Percorsi di formazione 
o Training on the job 
o Rivisitazione dei processi di Project Management aziendale 
• Si tratta di un progetto interno; 
• Non esiste un contratto per il progetto; 
• La complessità del progetto è ritenuta elevata; 
• Il richiedente interno coincide con il committente; 
• L’autore del Project Charter è il project manager
3. CODICE IT-01-2010 
Titolo Progettazione e realizzazione di una infrastruttura Client- 
Server per il monitoraggio dei progetti aziendali 
Descrizione breve Il progetto prevede l’introduzione di un servizio informatizzato 
Client-Server per migliorare sia la pianificazione che il 
monitoraggio di tutti i progetti dell’azienda. L’implementazione 
prevederà inizialmente l’inserimento nella struttura dei soli 
progetti strategici per poi allargarla anche a tutti gli altri 
Programma Il progetto si inserisce nel programma strategico XYZ 
Cliente 
Azienda ABC Referente Amministratore 
delegato 
Sponsor 
Funzione IT Referente Mario Rossi 
Senior Executive 
Funzione strategica Referente Luigi Verdi 
Descrizione del progetto 
Il progetto prevede l’introduzione di un servizio informatizzato Client-Server per 
migliorare sia la pianificazione che il monitoraggio di tutti i progetti dell’azienda. 
L’implementazione prevederà inizialmente l’inserimento nella struttura dei soli progetti 
strategici per poi allargarla anche a tutti gli altri 
Giustificazione del progetto 
L’iniziativa, fortemente voluta dall’amministratore delegato, viene giustificata in termini 
di nuove esigenze e nuovi bisogni aziendali al fine di migliorare la comunicazione, la 
pianificazione ed il monitoraggio dei progetti 
(Vedi allegato n.1 Business Case) 
Obiettivi di progetto (SMART) 
Ambito Infrastruttura Client-Server 
Elenco progetti strategici per prototipo 
Manuale utente/amministratore 
Formazione personale sull’applicazione 
Tempi Inizio progetto il …. 
Fine progetto il ….. 
Costi per il progetto sono stati stanziati € ….
Qualità Obiettivi di qualità del sistema informatico 
- Documento di sicurezza ISO … 
- Trattamento dati secondo normativa aziendale ABC 
- Comunicazione dati secondo normativa …. 
Altri Piano di Project Management 
- WBS 
- Piano di comunicazione 
- Piano di approvvigionamento 
- Piano di qualità 
- Gant 
- Stima delle risorse 
- Curva di Budget 
Deliverable Requisiti (High-level) 
Piano di Project Management secondo standard internazionale PMI 
Infrastruttura client /server standard ICT aziendale ABC 
Elenco progetti strategici secondo regole organizzative 
Formazione personale requisiti di formazione secondo procedura XYZ 
Milestone Data attesa 
Inizio progetto Entro il …… 
Approvazione PMP Entro il …. 
Collaudo struttura Non oltre il ….. 
Fine progetto Entro il ….. 
Rischi di alto livello 
Minacce Le informazioni per i progetti pilota potrebbero essere 
obsolete ed incomplete 
Il nuovo sistema potrebbe essere incompatibile con la struttura 
esistente 
I project manager coinvolti potrebbero non avere conoscenze 
di project management 
Opportunità Alcuni server potrebbero essere dismessi ed essere riutilizzati 
per l’installazione dell’applicazione 
La gestione centralizzata dei progetti consentirebbe un 
migliore monitoraggio e governance sugli stessi 
………… 
Funzioni coinvolte Tipo di partecipazione 
Funzione Strategica Sponsorizzazione del progetto
Funzione ICT 
Responsabile del delivery infrastrutturale e 
delle attività di Project Management 
Funzione Acquisti Responsabile dell’approvvigionamento 
Budget complessivo 
Il budget complessivo per il progetto è di € ….. 
Criteri di valutazione del successo del progetto 
La valutazione del progetto seguirà i seguenti criteri: 
- raggiungimento obiettivi di ambito: 40% 
- raggiungimento obiettivi di qualità: 20% 
- raggiungimento obiettivi di tempo: 20% 
- raggiungimento obiettivo di costo: 5% 
- raggiungimento obiettivi di PM: 15% 
Project Manager 
Nome Cognome Nome Project Manager assegnato: Franco Neri 
Funzione Funzione ICT 
Responsabilità responsabile della pianificazione, controllo e chiusura del 
progetto. Responsabile del raggiungimento degli obiettivi di 
Project Management, di tempo, di budget e di qualità 
Livello di autorità Il Project Manager potrà disporre del budget allocato sul 
progetto e delle risorse che ne saranno coinvolte
2 integration e scope management
(Esempio azienda SUPARTS per creare esempio di business case e project charter) 
Nel progetto di esempio il nostro cliente è la Suparts nell’ottica di chi ha un bisogno, mentre lo 
sponsor può essere il titolare dell’agenzia di viaggi, anche se potrebbe essere in realtà un 
commerciale dell’azienda Suparts che ha deciso di portare avanti un iniziativa per risolvere 
determinati problemi. 
In tali casi occorre capire bene chi è il cliente e chi è lo sponsor. 
Immaginiamo che noi siamo l’agenzia; il nostro cliente (la Suparts) ci esprime i suoi bisogni, le sue 
esigenze cioè quelle di come portare le persone sul sito (un albergo dell’alta Italia) e farle incontrare. 
Dal cliente dobbiamo sapere con precisione come ci dobbiamo comportare nel senso che per 
risolvere il litigio tra tecnici e commerciale dell’azienda, il cliente si aspetta un trattamento 
particolare. Quindi porre molta attenzione alle richieste del cliente.
Il prodotto consiste in una serie di trasporti: aerei, pullman, treni; il tutto nei tempi giusti al fine di 
farli arrivare in loco in condizioni ottimali psico-fisiche. Ci si deve preoccupare anche della loro 
sistemazione, delle esigenze alimentare. 
Le specifiche del prodotto vanno grosso modo disegnate anche se non nei particolari. 
Come agenzia di viaggi mi chiedo inizialmente se vale la pena affrontare tale progetto. La domanda 
può essere: voglio guadagnarci? La mia strategia è quella di ottenere il massimo di redditività? oppure 
quello di ottenere la giusta reddittività ma probabilmente è una conseguente dovuta al fatto che 
magari mi specializzo in tali contesti internazionali e quindi tale esperienza potrebbe fare da referente 
per il futuro? Voglio entrare in un certo mercato di organizzazione di tali eventi? 
Queste sono tutte le strategie. 
Relativamente ai costi benefici la domanda può essere: quant’è il guadagno che mi aspetto cioè quali 
sono, nell’ambito di tale progetto, i costi ed i benefici che riesco a sopportare ed a supportare. 
Questa iniziativa che sto intraprendendo come contribuisce alla mia strategia o alla mia mission? 
Vado quindi a fare un analisi costi/benefici. Può succedere che magari tali risultati incidono in 
maniera secondaria (cioè non danno molta importanza alla mia azienda) sulla mia strategia, ma se 
incide in maniera secondaria ed inoltre i costi sono anche significativi allora non mi conviene 
affrontare tale progetto. 
Nel business case occorre vedere quali sono i fattori ambientali e aziendali che possono incidere e 
che quindi devo considerare nel nostro progetto. Cioè capire come la Suparts tratta in genere i suoi 
clienti, se li tratta bene o in maniera spartana. Queste indicazioni dettate dal cliente ci servono per 
misurare il tiro del benessere che dobbiamo infondere alle persone che vanno in albergo. 
Quindi l’agenzia intelligente deve “indagare” sulle condizioni aziendali (fattori ambientali e aziendali). 
Curare le persone anche dal punto di vista alimentare, religioso in considerazione del fatto che le 
persone vengono da tutto il mondo e che quindi hanno abitudini differenti. 
All’inizio occorre concentrarsi sul Bisogno. Quando il cliente viene a parlarci, di solito non parla del 
suo bisogno bensì pensa di esprimere già la soluzione che ha in mente. Dobbiamo essere noi a 
riportarlo indietro semplicemente con la tecnica della comunicazione e cioè chiedendo 
semplicemente il perché vuole intraprendere tale obiettivo o il suo bisogno.
Gli americani hanno studiato che 5 livelli di “perché” ci portano a determinare le cause originarie. 
A questo punto volendo seguire il BOK dobbiamo prendere questa sorgente e elaborarla attraverso 
degli strumenti per elaborare il charter. Strumenti che sono: l’esperienza (da condividere). 
Impariamo dagli errori degli altri. E poi le cosiddette “tecniche di facilitazione” perché sono quelle 
che si dovrebbero mettere in atto per aiutare il cliente a parlare del suo bisogno, per aiutarlo a tirar 
fuori il meglio delle informazioni di input. 
Una tecnica può essere il Brainstorming (tempesta cerebrale). 
E’ una tecnica potente e rigorosa ma un po’ bistrattata. E’ comunque un modo per avere idee. 
Sulle idee in genere si hanno due atteggiamenti: una cosa averla e una cosa è usarle. Ma in realtà non 
facciamo mai tale distinzione. Assimiliamo sempre tali due aspetti. Abbiamo sempre la tendenza ad 
unire questi due “momenti”: cioè nel momento in cui sorge l’idea ne andiamo subito a cercare 
l’utilità. In certi momenti e soprattutto nei momenti di creatività è così importante AVERE le idee 
mentre il fatto di giudicare e usarle subito non ci aiuta ad essere creativi. 
Il brainstorming è una tecnica o una modalità di riunione che serve a separare questi due momenti. 
Pertanto la cosa non è così facile. Per avere idee non serve l’intelligenza, la cultura ed esperienza, la 
conoscenza o la logica. Ci possono essere persone stupidissime che hanno delle idee magari anche 
stupide. L’esperienza in una data materia (nel senso di rigore) in genere è un freno alla creatività. 
Il brainstorming è sostanzialmente una tecnica strutturata, un processo, per AVERE le idee. Poi 
vedremo come usarle, e se usarle. 
E’ una tecnica che è nata da oltre un secolo da un tecnico statunitense convinto della validità 
dell’approccio creativo, ispirandosi ad una tecnica Hindu. 
Esso applica tale tecnica soprattutto quando si hanno delle idee nuove che in genere vengono 
bistrattate. Per fare questo identifica 4 regole: 
a) Le idee non si valutano. Nessuno può criticare le idee degli altri, neanche mentalmente; tali 
idee non devo usarle ma solo Averle. 
b) Si va a “ruota libera”. Non ci devono essere freni, inibizioni, in quanto farebbero tutte parte 
della critica. 
c) La quantità è molto significativa: dopo le selezionerò.
d) Usare gli altri: devo usare le idee degli altri o per aggiunta o per contrasto o per miglioramenti. 
L’enfasi va messa su tutto quello che viene fuori, non aspettare che ci sia la cosa fondamentale perché 
già questo è un giudizio, rimanendo concentrati su quello che si sta facendo, senza distrarsi con 
problemi che non c’entrano niente con il progetto di base. 
Occorre prestare attenzione a tutto quello che ci sta intorno, proprio perché bisogna agganciarsi, 
ampliarsi, moltiplicare e cercando in tutti i modi di tirare fuori tante idee senza preoccuparsi della 
qualità. Questo è lo spirito del brainstorming. 
Se dobbiamo essere innovativi purtroppo occorre cambiare i paradigmi e i presupposti su cui 
ragioniamo. Fino a che rimaniamo ingabbiati nei nostri schemi mentali non saremo mai innovativi. 
Queste tecniche ci danno la libertà, in un contesto controllato, di uscire da queste gabbie e da questi 
schemi. 
Ci aiutano moltissimo le gabbie mentali perché fanno parte della nostra abitudine che è un grande 
vantaggio: questo vuol dire non pensare tutte le volte a quello che devo fare!!! Se ad es. per ogni 
passo che faccio dovessi concentrarmi su tutti i muscoli che muovo, ecc. sarebbe impossibile vivere. 
In realtà è una cosa che mi viene in automatico camminare senza pensare al resto del corpo. Quindi 
ben vengano le abitudini. 
Ma in termini di innovazione devo scardinare un po’ queste cose ed allora devo trovare un contesto 
che mi aiuta a fare questo. 
Relativamente allo Skill del P.M. e soprattutto in determinati momenti del ciclo di vita di un progetto, 
inoltre, quando assume una fondamentale importanza la ricerca della soluzione più efficace, un P.M. 
deve anche essere capace di ricorrere alla propria creatività. Deve essere in grado, cioè, di individuare 
differenti ipotesi di soluzione anche svincolandosi dalla cosiddetta “logica comune”, di per se stessa 
scontata e prevedibile, e ricorrere a quello che la moderna psicologia definisce “pensiero alterale” (o 
divergente) che consiste nel procedere alla ricerca della soluzione ottimale interconnettendo idee, 
spunti, concetti, tra loro anche molto distanti, senza lasciarsi imbrigliare in schemi mentali 
precostituiti (e, proprio per questo, condizionanti), derivanti, di solito, dal proprio bagaglio culturale.
Il pensiero operazionale, quello del fare le cose, è il ciclo “Plan-Do-Check-Act” o ruota di Deming 
(ideato da SHEWART) – visto nelle prime lezioni. Le idee le organizzo, agisco, valuto, miglioro. Però 
quando c’è innovazione o quando c’è crisi ho bisogno di uscire da questo schema. Ed allora devo 
usare la modalità del pensiero creativo che è quello di esplorare, scoprire, di sviluppare idee e 
validarle. 
In tale senso Hosborn individua che il percorso del pensiero viene sviluppato sostanzialmente in due 
fasi: 
1) Facciamo esperienza di qualcosa, percepiamo qualcosa e questa genera l’idea; per cui dal 
confrontarsi con qualcosa nascono le idee alle quali riusciamo ad attribuirle un nome, 
riusciamo ad esprimerle. 
2) Poi c’è un passaggio che passa attraverso il linguaggio che diventa giudizio, opinione, e quindi 
li integriamo dei paradigmi, dei concetti di utilità ed integriamo una valutazione. 
Dunque il brainstorming è un viaggio di scoperta senza mappe, senza orientamenti e senza punti di 
riferimento, completamento libero, anarchico, che poi però deve convergere verso una soluzione. In 
tale situazione le soluzioni sono variabili: “1 + 1 può fare anche più di 2”, perché nascono cose man 
mano che escono. Ecco perché bisogna appoggiarsi agli altri, sfruttare quello che succede, ecc.
Quando non fare il Brainstorming? 
Quando abbiamo problemi operativi: se un aereo sta precipitando non si può fare certo un 
brainstorming. Occorre subito trovare la soluzione. 
Se abbiamo un piano da seguire dobbiamo fare le cose giuste e subito. 
In tali casi occorre fare attenzione al gruppo. Ci vanno le persone giuste. I giochi hanno regole ferree. 
Ci vuole un buon facilitatore. 
Quindi il brainstorming tradizionale si può usare quando abbiamo bisogno di idee nuove, quando 
abbiamo bisogno di trovare qualcosa che pensando ad una maniera tradizionale non funzionerebbe. 
A questo punto facciamo un passo successivo, cioè individuiamo quale può essere la soluzione, 
magari in un primo passaggio dire semplicemente se quell’idea ci sembra negativa – positiva o 
interessante. In una seconda fase, quella dell’utilità, è che queste posizioni vanno giustificate. Cioè 
tutti quelli che hanno partecipato al brainstorming valutano le idee, spiegano le cose. E questo 
rappresenta un arricchimento per tutti. 
A fronte di questo poi bisogna sempre valutare un pochino quelle che sono le situazioni del contesto: 
in particolare lo sponsor. Cioè ad es. questa data soluzione è ottima però rischia di disturbare qualche 
stakeolder ed allora non è il caso di portarlo avanti. 
A questo punto una volta fatte le valutazioni si decide come lavorarci sopra e quindi si vedrà cosa 
occorrerà fare. 
Il brainstorming lo utilizziamo per arrivare a scrivere il project charter. 
A questo punto proviamo a costruire il Project charter della nostra azienda esempio (Suparts). 
Nel charter occorre essere più definiti possibili ma ad alto livello. Non si può scendere nei particolari 
ma occorre che grosso modo ci sia tutto. Inserire anche un criterio di successo del progetto e che sia 
anche misurabile. Ad es. il 10% dei clienti non si è trovato bene. Questo può rappresentare un 
elemento misurabile di successo. 
A livello di charter ci possono essere delle milestone del tipo: posso fare questa operazione ma tu 
cliente mi devi affidare l’incarico almeno tre mesi prima; oppure 20 giorni dopo l’ordine ci riuniamo 
insieme per presentare come vogliamo svolgere il progetto; oppure i dati fondamentali dei 
partecipanti li devo avere entro una certa data altrimenti non riesco a fare i biglietti.
Per quanto riguarda gli stakeolder occorre tener presente in questo caso di esempio, che sicuramente 
avrò bisogno di una interfaccia della Suparts, ho bisogno di sapere chi è il P.M. della Suparts per 
colloquiarci. 
Il charter può avere vari livelli di definizioni. Possiamo trovare charter molto definiti in quanto alla 
base c’è un contratto molto dettagliato, altri estremamente più vaghi, per cui il charter determina 
anche lo stile del P.M. ovvero il modo di operare. 
Tutti i presupposti, gli assunti e i vincoli vengono descritti nel P. charter, esso ci deve dare le linee 
guida fondamentali rispetto alla scelta della soluzione che noi adottiamo. 
Ma cosa sono gli assunti e vincoli. 
Gli assunti, tra i requisiti in input, sono quelle cose che diamo per scontato e di cui noi non possiamo 
farne a meno. Tutti i presupposti significativi gli evidenziamo, gli accettiamo e nell’accettarli li 
trasformiamo in rischi. Per es. un progetto in Giappone comporta un assunto che può essere quello 
di avere un terremoto: questo è un assunto, lo diamo per scontato. Ma tale situazione lo dobbiamo 
trasformare in rischio che poi dobbiamo gestire. 
I vincoli invece sono delle cose che tipicamente interpretiamo come delle limitazioni di libertà. 
Esistono vincoli di qualità, di tecnologia, di persone, di tempo, di costo, ecc. 
L’assenza di vincoli tuttavia non comporta una forma di libertà. Tipicamente il vincolo va interpretato 
non come un muro o una prigione bensì come una ringhiera che ci evita di finire nel baratro. Lavorare 
in assenza di vicoli all’interno di un progetto, inevitabilmente le cose si disperdono e non si arriva alla 
soluzione. I vincoli sono un punto di appoggio. I vincoli vanno imposti necessariamente. I vincoli 
stimolano anche la creatività, qualche innovazione. Ad es. la poesia rappresenta una forma di vincolo 
per eccellenza: imparare a memoria le rime, ecc. avendo anche determinate lettere per ogni riga, 
ecc. 
Quindi raggiunto il charter si passa al processo successivo, ma non necessariamente in ordine 
cronologico. 
VEDIAMO UN ESEMPIO DI BUSINESS CASE
4. CODICE INIZIATIVA 
4.1 
Titolo Iniziativa 
Descrizione Iniziativa 
Richiedente / Ideatore Iniziativa Referente 
Redattore del Business Case Referente 
Impulso scatenante * 
Domanda di mercato 
Bisogno interno dell’organizzazione 
Richiesta di cliente esterno 
Progresso tecnologico 
Requisito di legge 
Impatto ecologico 
Bisogni sociali 
* Inserire un segno di spunta per l’impulso o gli impulsi scatenanti il progetto 
Descrizione impulsi 
Descrizione opportunità 
Stima dimensioni del mercato 
Analisi dei Concorrenti 
Descrizione del risultato
Benefici attesi 
Analisi economico/finanziaria 
Allineamento Strategico 
Priorità 
* Specificare valore da 1 a 5 
Iniziativa approvata 
Iniziativa non approvata 
* Inserire il segno di spunta e firma 
Descrizione Documento 
Il business case è quel documento che tenta di rispondere alla questione se convenga o 
meno imbarcarsi in una specifica attività commerciale o di business. 
Non si tratta solo di comprendere, in termini economici, l’ammontare dell’impegno che 
un’azienda dovrebbe sostenere per sponsorizzare un’iniziativa ma capire anche il valore 
dei benefici attesi e l’arco temporale durante il quale quell’impegno economico ed umano 
potrebbe essere richiesto e, quindi, sostenuto. 
La complessità del business case è strettamente correlata agli elementi che si vogliono 
considerare ed analizzare. Tralasciando per un momento il solo parametro economico, 
comun denominatore e chiave di lettura, l’azienda deve poter valutare, e quindi 
valorizzare, l’impegno in termini di risorse umane, materiali, subforniture, forniture, 
rischi, progresso tecnologico e tanti altri elementi. Pertanto, all’aumentare dei parametri, 
la complessità ed il rischio di commettere errori di valutazione aumenta in maniera 
proporzionale. 
Il business case può fare riferimento anche a documenti nei quali si evincono le stime di 
distribuzione temporale prevista dei costi e dei ricavi.
Nell’analisi della fattibilità economica di un progetto è infatti essenziale tenere conto della 
diversa distribuzione temporale dei costi, che sono tutti concentrati nella fase di 
realizzazione del progetto, rispetto ai benefici, che saranno disponibili solo dopo il rilascio 
in produzione del prodotto o servizio. 
I costi da considerare potrebbero essere: 
• i costi di progettazione, realizzazione ed avviamento dei prodotti finali del 
progetto: costi di risorse umane e costi di apparecchiature tecnologiche; 
• i costi di esercizio dopo la partenza operativa del nuovo sistema di processi, costi 
di risorse umane, costi di manutenzione e costi di utilizzo di componenti 
infrastrutturali. 
I benefici economici da considerare sono gli eventuali maggiori ricavi e gli eventuali 
minori costi derivanti da valutazione di maggiori efficienze, nonché minori costi derivanti 
da disattivazione di sistemi e processi attuali che potranno essere dismessi in quanto 
sostituiti. 
Per tener conto della diversa distribuzione dei costi rispetto a quella dei ricavi, tutti i 
flussi dovranno essere attualizzati al fine di renderli confrontabili. L’analisi dei flussi 
finanziari attualizzati dovrà evidenziare il “punto di pareggio economico” (Break Even 
Point), cioè il momento nel tempo in cui la curva dei ricavi incrocia la curva dei costi, e 
quindi il punto in cui il valore complessivo dei ricavi stimati pareggia i costi. Di norma, il 
progetto sarà considerato “a valore aggiunto” per l’organizzazione se il punto di pareggio 
economico risulterà anteriore al tempo previsto di vita utile del prodotto. Ovviamente, 
questo tempo potrà essere molto diverso a seconda della tipologia di prodotto interessata 
e potrà andare da pochi mesi o anni (come ad esempio per una campagna promozionale 
o un nuovo prodotto), fino anche ad alcuni decenni (come per un nuovo impianto, una 
nuova sede o un’opera pubblica). 
Note per la compilazione 
Argomento Spiegazione
5. CODICE 
INIZIATIVA 
Codice univoco alfanumerico. Tutti i documenti che verranno 
creati successivamente avranno questo codice. Questo può 
essere formulato considerando o la sequenza delle iniziative 
passate oppure secondo le regole dell’organizzazione o della 
funzione che sponsorizza il progetto 
Titolo Iniziativa Inserire il titolo dell’iniziativa 
Descrizione 
Iniziativa 
Inserire una breve descrizione 
Richiedente / 
Ideatore Iniziativa 
Nome dell’ideatore dell’iniziativa o del possibile sponsor 
Redattore del 
Business Case 
Chi realmente si occuperà della redazione del presente 
documento 
Impulso scatenante Il Business Case da una risposta alla domanda sul perché 
l’organizzazione abbia scelto proprio quell’iniziativa e non 
un’altra, dandone ampia spiegazione. Si ricordi che un 
l’iniziativa può partire da: 
- una domanda di mercato 
- un bisogno dell’organizzazione 
- una richiesta di un cliente 
- un progresso tecnologico 
- un requisito di legge 
- un bisogno sociale 
Quello che deve essere chiaro è che sino a che l’iniziativa non 
attraversi un processo, più o meno standardizzato, di 
approvazione, non è lecito parlare di progetto. 
Può accadere, infatti, che un’iniziativa venga bocciata o 
momentaneamente accantonata o perché troppo rischiosa 
oppure perché non allineata ad obiettivi strategici. Il business 
case deve rappresentare l’anello di congiunzione tra il Project 
Management ed il Portfolio Management 
Descrizione impulsi Sezione dedicata a dare ampio spazio alla descrizione degli 
impulsi che hanno scatenato l’iniziativa 
Descrizione 
opportunità 
Descrivere le opportunità legate all’iniziativa 
Stima dimensioni 
del mercato 
Nel caso di progetti di marketing, potrebbe essere 
interessante stimare le dimensioni del mercato sul quale 
lanciare un nuovo prodotto oppure, per progetti interni, 
stimare il numero di utenti che verranno impattati durante, ad 
esempio, una migrazione o per l’erogazione di un nuovo 
servizio. Stimare correttamente le dimensioni del mercato 
consentirebbe di comprenderne l’attrattività e la rischiosità 
per l’azienda stessa
Analisi dei 
Concorrenti 
Analizzare possibili concorrenti già presenti sul mercato o 
possibili concorrenti che potrebbero aggredire il mercato di 
riferimento 
Descrizione del 
risultato 
Descrivere il risultato finale che si attende dall’iniziativa 
Benefici attesi Mentre per il progetto sarebbe corretto parlare di output, 
come qualcosa di tangibile e misurabile, in questa sezione 
verranno discussi i benefici attesi collegati agli output del 
progetto, i così detti outcome. Esiste però un problema 
sostanziale tra i due elementi; mentre l’output di un progetto 
è verificabile immediatamente, anche durante le diverse fasi 
di sviluppo, per l’outcome questo non è possibile, ovvero è 
complesso verificarne il raggiungimento subito dopo che il 
progetto sia stato completato. L’utilizzo, anche in questo caso, 
di opportune metriche che considerino la natura stessa 
dell’outcome è essenziale per una corretta valutazione 
Analisi economico/ 
finanziaria 
Le risorse economiche/ finanziarie di un’azienda, come per le 
risorse umane, sono risorse limitate e come tali dovrebbero 
essere impegnate /impiegate nel modo più efficiente ed 
efficace possibile. Ponderare l’iniziativa attraverso precisi 
indici finanziari è alla base di una valutazione analitica di 
costi-benefici 
Gli indici che di solito sono utilizzati per affrontare l’analisi, 
possono essere i seguenti: 
• IRR: Tasso Interno di Rendimento (o TIR o IRR, 
acronimo dall'inglese Internal Rate of Return) è un 
indice di redditività finanziaria di un investimento. 
È il tasso di ritorno effettivo che un investimento 
genera. In termini tecnici rappresenta la resa di un 
investimento. 
• NPV: indice di profittabilità di un investimento/ 
progetto attualizzato 
• Payback Period: periodo di tempo richiesto per 
recuperare il capitale investito iniziale 
Allineamento 
Strategico 
Per capire se un’iniziativa sia più o meno allineata alla 
strategia aziendale, il piano industriale, servirebbe una 
metrica. La metrica consiste nell’individuare quelli che 
vengono chiamati Business Drivers che rappresentano i 
principali fattori che guidano le scelte strategiche in fatto di 
sviluppo applicativo o di business 
Priorità In relazione alla strategia aziendale, al piano industriale ed 
all’allineamento strategico, all’iniziativa, e di conseguenza al 
futuro progetto, viene attribuito un numero che ne 
rappresenta la priorità su scala aziendale. Attribuire una 
priorità alta ad una iniziativa significa essere coerenti a 
precise scelte strategiche che conducono, di conseguenza, a
dare precedenza nell’allocare fondi e risorse a determinati 
progetti 
Iniziati approvata/ 
non approvata 
Campo utilizzato per ufficializzare l’approvazione o meno 
dell’iniziativa 
Riferimenti 
PMBOK® Guide 
PMBOK® Guide 
Versione Inglese Italiano 
Nome del 
documento 
Business Case Business Case 
Processo che lo crea 
Gruppo di processi Initiating Concezione/ Avvio 
Area di Conoscenza Project Integration Management Gestione dell’Integrazione 
di Progetto 
Processi che lo 
usano in input 
4.1 Develop Project Charter 
4.1 Sviluppare il Project 
Charter 
Regole Dovrebbe essere emesso da un manager esterno al progetto 
che ricopra un livello gerarchico appropriato, od emesso 
secondo le regole dell’organizzazione. Il presente 
documento verrà poi sottoposto al parere di un comitato 
che, secondo metriche appropriate, lo approverà o meno. Il 
comitato prende diversi nomi, come, ad esempio, Steering 
Commitee, comitato guida, oppure potrebbe coincidere con 
un PMO, Project Management Office.
2 integration e scope management
Mappatura template Business Case 
Initiating Planning Executing Monitoring & Controlling Closing 
Business 
Case 
4.1 
Develop Project 
Charter
50 
Esempio 
Viene di seguito illustrato un esempio pratico di utilizzo del business case. Si tratta di 
un progetto di Information Technology, riguardante l’implementazione prototipale di 
una struttura client-server per il monitoraggio dei progetti aziendali. Il contesto in cui si 
ipotizza lo svolgimento del progetto prevede le seguenti caratteristiche: 
• Il progetto, fortemente voluto dall’amministratore delegato, rientra nel 
programma strategico per l’implementazione di un sistema di Project 
Management, che sarà realizzato attraverso i seguenti progetti: 
o Una struttura informatizzata (il progetto di esempio) 
o Percorsi di formazione estesi sia ai project manager che ai membri di team 
di progetto 
o Training on the job 
o Rivisitazione dei processi di Project Management aziendale 
o Knowledge Management System 
• Si tratta di un progetto interno; 
• Non esiste un contratto per il progetto; 
• La complessità del Progetto è ritenuta elevata; 
• Il richiedente interno coincide con il committente; 
Nell’esempio del business case, verrà considerato il programma nel suo complesso.
51 
6. CODICE INIZIATIVA 
6.1 INI 01 2010 
Titolo Iniziativa Sistema di Project Management aziendale 
Descrizione Iniziativa Progettazione e realizzazione di un sistema aziendale di Project 
Management. 
Richiedente / 
Ideatore Iniziativa 
Amministratore Delegato Referente Mauro Martinelli 
Redattore del 
Business Case 
Funzione Strategica Referente Luigi Verdi 
Impulso scatenante * 
Domanda di mercato 
Bisogno interno dell’organizzazione * 
Richiesta di cliente esterno 
Progresso tecnologico * 
Requisito di legge 
Impatto ecologico 
Bisogni sociali 
* Inserire un segno di spunta per l’impulso o gli impulsi scatenanti il progetto 
Descrizione impulsi 
- Bisogni interni dell’organizzazione: in ottica di miglioramento della 
gestione dei progetti, la gestione stessa ha sofferto, in questi anni, in 
termini di efficienza e di efficacia. Attualmente non esistono regole e 
strumenti per una gestione centralizzata dei progetti con conseguente 
perdita di visibilità e verifica della coerenza con obiettivi strategici. Non 
esiste una uniformità nel lessico e nella metodologia di Project 
Management generalmente accettata e condivisa 
- Progresso tecnologico: le tecnologie informatiche, orientate al dominio 
informativo di Project Management, forniscono una visuale aggregata delle 
performance dei progetti ed una uniformità nella gestione dei dati 
informatici 
Descrizione opportunità 
Miglioramento delle performance dei progetti di almeno il 15% entro 1 anno 
Acquisizione di competenze e certificazioni per i project manager entro 2 anni 
Riduzione dei tempi di approvazione dei progetti di circa il 10% entro 6 mesi
52 
Stima dimensioni dell’iniziativa (mercato) 
I risultati ottenuti da primi incontri con i responsabili di funzione coinvolti nel 
progetto, sono stati i seguenti: 
- Per il lancio del prototipo informatico, si sono stimati circa 20 progetti che 
dovrebbero essere inseriti nella struttura 
- Il personale coinvolto nell’iniziativa si stima sia circa il 35% della 
popolazione 
- Tutte le funzioni aziendali saranno coinvolte nel programma 
Analisi dei Concorrenti 
Descrizione del risultato 
Sistema informatico ed informativo di Project Management 
Selezione dei processi aziendali di Project Management 
Identificazione dei ruoli e delle responsabilità di progetto 
Percorsi di formazione per la certificazione 
Formazione training on the job 
Benefici attesi 
Sono stati selezionati i seguenti progetti, facenti parte del programma in 
oggetto, con i relativi benefici attesi: 
1- Progetto di implementazione prototipale su piattaforma client-server 
2- Progetto Percorsi di formazione per la certificazione PMP® e CAPM ® 
3- Progetto di Training on the job 
4- Progetto di rivisitazione dei processi di Project Management aziendale 
I benefici attesi sono i seguenti: 
- Miglioramento della qualità di progetto 
- Acquisizione di nuove competenze tecniche 
- Acquisizione di competenze progettuali 
- Riduzione dei costi di gestione dei progetti 
- Miglioramento dei processi decisionali aziendali 
- Miglioramento nell’utilizzo delle risorse aziendali 
- Uniformità nel lessico e nella metodologia utilizzata 
- Miglioramento delle capacità di pianificazione dei progetti 
- Miglioramento della governance sui progetti 
Analisi economico/finanziaria 
Nell’analisi economico-finanziaria, sono stati valutati i seguenti parametri: 
• Indice Ricavi/Costi: … 
• IRR: …% 
• NPV: € … 
• Payback period: … mesi
Allineamento Strategico 
L’allineamento strategico è stato valutato sulla base dei seguenti Business Driver 
individuati dal Top Management (valutazione 1-5): 
53 
- Riduzione Costi: 4 
- Miglioramento nella qualità di gestione: 5 
- Miglioramento della comunicazione: 5 
- Miglioramento nelle decisioni: 2 
- Rischiosità: 4 
- Sicurezza dei dati sensibili: 3 
Priorità 4 
* Specificare valore da 1 a 5 
Iniziativa approvata * 
Iniziativa non approvata 
* Inserire il segno di spunta e firma
54 
SVILUPPARE IL PIANO DI PROJECT MANAGEMENT 
Qui stiamo parlando di pianificazione che vuol dire organizzare il futuro e stiamo nell’area di 
conoscenza “Integrazione”. 
Il piano di P. M. è il piano del progetto, che è l’insieme di tutti i piani ma integrati, armonici, sincroni. 
Esso mi permette di avere una visione globale di come dovrebbe funzionare il progetto. In effetti 
tutto lo sforzo che il P.M. fa per arrivare a costruire un piano mi porta di fatto ad avere delle 
“baseline”.
La baseline non mi dice come andranno le cose, perché le cose andranno come andranno. Non è che 
lo decide il P.M. come andranno in futuro le cose. Esso rappresenta il come dovrebbero andare le 
55 
cose per arrivare ad ottenere quello che c’è scritto nel charter. 
Esso rappresenta il mio punto di riferimento. Se le cose dovessero andare come descritto nella mia 
baseline il mio progetto sarebbe perfetto. 
Pianificare, nell’ottica del PMI, è un lavoro che tipicamente si fa in due passaggi. 
Ci sono due livelli della pianificazione: 
– una pianificazione delle regole del gioco; di cui alcune sono specifiche delle aree di conoscenza. 
Infatti ogni area di conoscenza ha come primo progetto la pianificazione. 
– una pianificazione dell’organizzazione dell’attività; ad es. sui costi occorre sapere quanto 
spendiamo e come. 
Per ogni area di conoscenza ci sono le singole linee guida. 
Lo scopo fondamentale dello sviluppare il piano di P. Management è di integrare tutte le informazioni 
organizzative che ho elaborato nei vari contesti, nelle altre aree di conoscenza. 
Ovviamente lo spirito del P.M. è quello di non aspettarsi di avere tutto pronto. Si comincia e si fa, in 
quanto il progetto non lo conoscerò mai fino in fondo. Si comincia e poi man mano si considerano le 
varie aree di conoscenza. Questo è un discorso di elaborazione progressiva. 
Si entra nel dettaglio nella prima fase lasciando a grandi linee le fasi successive per poi riprenderle in 
maniera più puntuale e precisa. La pianificazione è un lavoro progressivo, senza inventarmi nulla ma 
nel rispetto dei vincoli. 
Per fare tutto il lavoro di organizzazione generale del progetto, integrata ed in maniera armonica, 
prendo le informzioni dal Charter. Li ci sono le cose essenziali. Poi vado a prendere tutti i singoli piani 
relativi alle aree di conoscenza e li integro tra di loro affinchè ottengo un unico macro piano che è 
appunto il Piano di P. management. 
All’interno del piano ci devo mettere innanzitutto l’esperienza del P.M. ed altrui (parere degli esperti). 
Quindi chiedere alle persone più sapienti con le tipiche tecniche di facilitazione (brainstorming, 
riunioni, conflitti). Il piano di P. management è una sorta di raccoglitore di tutti i singoli piani ma
armonizzati tra di loro. Ogni singolo piano deve tener presente la presenza contemporaneità di altri 
56 
piani. 
In particolare il risultato del Piano di P. Management è la Baseline. Cioè quella situazione fattibile che 
fa riferimento ai tre pilastri del triangolo costi-tempi-ambito 
E quindi avremo una baseline dei tempi, dei costi e dell’ambito. Questi sono quelli principali anche 
se ci sono altre che fanno parte delle altre aree di conoscenza. 
Oltre alle baseline delle aree di conoscenza abbiamo anche il ciclo di vita (ciclo di Deming) che 
vogliamo utilizzare. 
Inoltre occorre scrivere anche quali aree di conoscenza andremo ad utilizzare e di queste quali 
processi utilizzeremo. 
I 47 processi non vanno sempre applicati tutti. E di quelli da applicare, alcuni andranno utilizzati con 
un certo dettaglio altri invece con una certa superficialità. 
Altro aspetto importante è che il progetto non andrà come descritto nella baseline. 
Ogni volta che in un punto del progetto mi si presenta qualcosa che non va o che cambia come mi 
devo comportare? Prima occorre decidere come ci si comporta e poi lo applichi. 
E quindi è importare incorporare nel macro piano il piano delle gestione delle modifiche. 
Altro elemento fondamentale ed importantissimo: il mio progetto cambia nel tempo in quanto ci 
sono dei ritardi, ecc. pertanto possono esistere diverse versioni del progetto. Dobbiamo fare in modo 
di utilizzare sempre l’ultima versione ed archiviare quelle precedenti. Esiste dunque il piano di 
gestione della configurazione di un progetto. 
Il mio progetto sarà rappresentato essenzialmente da due grossi raccoglitori: 
– una sezione organizzativa: piano di project management , in quanto mi dice come dovrebbero 
funzionare le cose e dove dentro ci sono tutti i piani. 
Ma il mio progetto ha tutta una serie di altre rappresentazioni che sono tipicamente 
documentali: elenco delle modifiche, elenco degli stakeolder, ecc. 
– Una sezione documentale: esistono allora i Documenti di progetto (vedi PMBOK pag. 78); 
Ma non tutti i progetti hanno tutti i documenti illustrati nel PMBOK, dipende dal tipo di progetto.
57 
A questo punto vediamo il primo piano di progetto e parliamo di SCOPE (o ambito del progetto). 
Riassumendo lo sviluppo del piano di project management prevede un’integrazione e un 
coordinamento di tutti i differenti piani relativi ai differenti aspetti di qualità, tempo e costo, nonché 
di pianificazione delle risorse. Esso definisce come eseguire, monitorare, controllare e, infine, 
chiudere il progetto. 
Una volta definito, il piano deve essere approvato e successivamente “congelato”; in tal modo 
fungerà da “Baseline” iniziale per le fasi di controllo e continuamente integrato con modifiche 
suggerite da feed-back provenienti dal monitoraggio delle attività eseguite. In generale nel piano 
dovrebbero essere descritti: 
• Il ciclo di vita del progetto e le attività ad esso associate 
• I principali input e output (deliverables) delle attività in relazione agli obiettivi di progetto, le 
modalità di esecuzione del lavoro e i luoghi in cui saranno realizzate 
• Le relazioni fra le attività di progetto 
• Le descrizioni degli strumenti e delle tecniche da utilizzare per l’esecuzione dei processi di 
progetto 
• Le modalità di monitoraggio e controllo delle attività 
• Le modalità di implementazione delle modifiche 
• Le modalità di manutenzione e utilizzo per la salvaguardia dell’integrità delle baseline di 
misurazioni delle prestazioni 
• Le necessità e modalità di comunicazione fra gli stakeholder 
Accanto al piano principale devono essere previsti i piani ausiliari fondamentali nel Project 
Management, ovvero i piani di: 
• Gestione dell’ambito di progetto 
• Gestione del reclutamento del personale 
• Gestione delle qualità e del miglioramento dei processi 
• Gestione della schedulazione 
• Gestione dei costi 
• Gestione dell’approvvigionamento
58 
• Gestione della comunicazione 
• Gestione dei rischi 
• Gestione degli stakeholder 
Presenti in questi piani vi sono anche dei componenti ausiliari, come ad esempio: 
• Elenco delle milestone 
• Calendario delle risorse 
• Baseline della qualità (la baseline dell’ambito) 
• Baseline della schedulazione 
• Baseline dei costi 
• Registro dei rischi (risk register) 
• Registro degli stakeholder (stakeholder register) 
La pianificazione del progetto prevede almeno otto step sequenziali che partendo dalla 
segmentazione della WBS, attraverso la selezione del team di progetto, l’analisi della qualità, dei 
tempi e dei costi, perviene all’identificazione e allocazione delle risorse.
Senza un piano di progetto (o piano di project management) è probabile che un progetto non riesca 
a raggiungere i suoi obiettivi. 
In un progetto di piccole dimensioni è possibile costruire rapidamente un piano che contenga tutte 
le informazioni riguardo l’ambito del lavoro da svolgere e le risorse necessarie per svolgerlo. Per 
59
progetti di grandi dimensioni, la pianificazione sarà un processo iterativo svolto in più fasi e tempi 
diversi a livelli di dettaglio crescente. 
Qualunque sia la dimensione del progetto, il piano di progetto costituirà la “rotta” che il progetto 
dovrà seguire e costituirà quindi il punto di riferimento (baseline) rispetto al quale calcolare gli 
scostamenti ed individuare gli interventi correttivi in corso d’opera per riportarlo in linea con le attese 
degli stakeholder. In assenza di un piano non è pertanto possibile questa opera di monitoraggio 
continuo e ripianificazione alla luce dell’andamento reale delle attività. 
60 
Il piano sarà quindi aggiornato durante tutto il ciclo di vita di un progetto. 
Contenuti del Piano di Project Management 
Il piano è costituito da un documento principale e da un serie di documenti allegati che emergono 
dall’attività di pianificazione (es. descrizione d’ambito, analisi requisiti, WBS, attività, Gant, budget, 
cash flow, piano della qualità, ecc.…). Conterrà quindi anche altri piani più di dettaglio. 
Il documento principale descrive la strategia di project management e costituisce anche una guida 
alla lettura dei documenti allegati da parte di chi non ha partecipato alla pianificazione del progetto. 
Il piano di progetto formalizza l’accordo tra project manager e l’organizzazione di cui fa parte riguardo 
le specifiche di realizzazione del progetto. Dovrà essere quindi approvato dal Comitato di 
Coordinamento del Progetto. 
Più specificatamente, il piano di project management deve fornire una descrizione chiara: 
• dell’ambito e delle finalità del progetto; 
• dei suoi prerequisiti (azioni preliminari che devono essere svolte per garantire il successo del 
progetto) 
• dei collegamenti e dipendenze con altri progetti; 
• degli assunti (es. risorse pre-assegnate al progetto) 
• dei ruoli e responsabilità; 
• dei punti di attenzione (criticità e rischi); 
• delle attività previste; 
• della tipologia (quantità e qualità) delle risorse necessarie allo svolgimento del lavoro; 
• dei tempi di esecuzione di ciascuna attività e della durata complessiva del progetto: 
• dei costi associati e dei ricavi attesi; 
• delle modalità di gestione dei rapporti e delle comunicazioni con gli stakeholder; 
• degli interventi a garanzia della qualità del lavoro e dei deliverables; 
• dei criteri di gestione degli approvvigionamenti e dei rapporti con i fornitori. 
Pertanto il piano di progetto contiene a sua volta: 
• Il Business Case ed il Project charter (o documento che formalizza l’avvio del progetto) 
• La strategia di project management 
• I requisiti del progetto
• Il documento di definizione d’ambito (Scope statement) contenente la descrizione dei 
61 
deliverables 
• La WBS (Work Breakdown Structure) 
• Le attività e i loro attributi/caratteristiche 
• Le risorse e le loro caratteristiche (quantità e qualità) 
• La struttura di governo del progetto 
• La OBS di progetto 
• La Matrice di assegnazione delle responsabilità 
• La schedulazione (Diagrammi reticolari e/o Gant di progetto) contenente anche le milestones 
principali 
• Il budget ed il cash flow di progetto 
• Le strategie di gestione dei rischi ed il budget di contingency 
• Il piano di gestione della qualità 
• Il piano di gestione delle comunicazioni di progetto 
• Il piano di gestione degli approvvigionamenti 
• Le baseline per la misurazione della performance 
• Le procedure per la gestione delle Issue di progetto e delle richieste di modifica 
La costruzione del piano di progetto 
La costruzione del piano richiede i seguenti passaggi principali: 
• comprendere i vincoli e i prodotti che caratterizzano il progetto; 
• descrivere i deliverables di progetto ed i loro requisiti; 
• specificare le attività necessarie a creare i deliverables; 
• definire la sequenza logica delle attività e le loro interdipendenze; 
• stimare le risorse necessarie ed i loro requisiti; 
• stimare i tempi per ciascuna attività; 
• produrre la schedulazione delle attività (reticolo e/o Gant); 
• definire le milestones ed i punti di controllo; 
• identificare le modalità per gestire rischi ed incertezze; 
• identificare le modalità di gestione della qualità; 
• identificare le modalità di gestione delle comunicazioni di progetto (canali, format, templates 
di documenti, modalità di conduzione degli stati di avanzamento lavori, calendario delle 
riunioni di lavoro, ecc.…) 
• calcolare i costi di ciascuna attività, il budget totale e quello di contingency; 
• valutare la compatibilità con il piano di fatturazione contrattualmente previsto; 
• formalizzare le modalità di gestione e le procedure di escalation a fronte di variazioni 
d’ambito; 
• formalizzare il documento di descrizione del piano; 
• ottenere l’approvazione del piano di progetto. 
Un buon modo per predisporre il piano di project management consiste nel seguire la check 
list di seguito articolata.
62 
a) Definire l’ambito e le finalità del progetto 
• Sono chiare le finalità per cui occorre predisporre il piano e le modalità per una sua 
approvazione? 
• Conoscete i processi di project management relativi alla pianificazione di progetto? 
• Sono chiari gli obiettivi che si intende raggiungere con il progetto? 
• Gli obiettivi sono definiti in modalità SMART? 
• Sono chiari i contenuti del progetto in termini di deliverables attesi? 
• Ci sono dei vincoli (ad esempio la disponibilità delle risorse, date di consegna ecc…)? 
• Esistono degli assunti o delle ipotesi di partenza in base ai quali costruire il piano? 
b) Definire i deliverables di progetto 
• Quali saranno i risultati finali ed intermedi prodotti dal progetto? 
• Cosa deve contenere e quali aree deve coprire ciascun deliverable? 
• Chi sarà responsabile dello sviluppo per ciascun deliverable? 
• Da chi o da cosa dipenderà il risultato (es. informazioni, risorse)? 
• Quali sono i requisiti richiesti dal punto di vista della qualità? 
• Quali sono le modalità per controllare la qualità di ciascun deliverable? 
• Quali sono le competenze, le risorse, le persone necessarie per sviluppare ciascun deliverable 
e svolgere i controlli di qualità? 
• Qual è l’ordine cronologico in cui i deliverables saranno prodotti? 
c) Identificare e stimare le attività 
• Predisporre la WBS di progetto coinvolgendo anche persone esperte e specialisti che 
conoscono bene i criteri di lavorazione ed i processi di costruzione di ciascun deliverable 
• Consolidare la WBS attraverso il coinvolgimento e l’approvazione dei principali stakeholder di 
progetto 
• Identificare tutte le attività necessarie allo sviluppo di ogni deliverable 
• Identificare tutte le attività necessarie al controllo di qualità di ogni deliverable 
• Concordare l’ordine in cui le attività devono essere svolte 
• Identificare le competenze necessarie a svolgere ogni attività 
• Stimare la quantità di sforzo (es. ore/uomo) ed il numero ottimale di risorse da coinvolgere 
nel progetto 
• Consolidare la durata di ciascuna attività sulla base delle ore/uomo ripartite sul numero di 
risorse effettivamente assegnate 
• Identificare e valutare le risorse non umane (es. mezzi, materiali, impianti) e i servizi di 
supporto richiesti 
• Calcolare il costo stimato per sviluppare ogni deliverable 
• Calcolare il costo complessivo per tutte le attività
63 
d) Schedulare le attività e le risorse 
• E’ stato predisposto il Gant di progetto? 
• Il progetto ha una data di inizio e di fine realistiche? 
• Sono state considerate le pause per i fine settimana, le festività, le ferie e gli altri giorni non 
lavorativi? 
• E’ stata verificata la disponibilità delle risorse nei periodi di impegno sul progetto? 
• Le risorse hanno tutte le competenze giuste o deve essere previsto un piano di formazione 
con conseguenti tempi di attesa? 
• Esistono stakeholder od eventi esterni che possono limitare l’utilizzo delle risorse? 
• Il carico di lavoro è correttamente ripartito sulle risorse? Esistono ambiti di sovrapposizione 
delle risorse su più progetti con possibilità di over head? 
• Sono previste attività da far svolgere in sub-appalto? I fornitori sono al corrente dei requisiti 
delle attività, dei deliverables e delle modalità di controllo del progetto? 
• e) Identificare i rischi e i punti di controllo 
• Sono chiari i momenti di revisione del progetto, le approvazioni necessarie ed il calendario di 
incontri con lo Sponsor ed il Comitato di Coordinamento del progetto? 
• Sono state definite le principali milestones del progetto? 
• Nel piano sono formalizzati anche i punti di controllo della qualità? 
• Sono stati identificati i rischi e le strategie di gestione per ciascun rischio? 
• Sono stati formalizzati e contrattualizzati i rapporti con eventuali fornitori e terze parti? 
• Sono state previste riserve o budget di contingency per gestire eventuali situazioni di 
emergenza? 
• Prima di partire con la realizzazione del progetto, il piano è stato presentato alle risorse in un 
kick off meeting? 
• Le risorse hanno ben compreso il livello di responsabilità e committment a loro richiesto? 
• e) Formalizzare il piano ed ottenerne l’approvazione 
• Il piano di progetto è formulato in modo tale da poter essere compreso anche da chi non ha 
partecipato alla fase di pianificazione/progettazione? In particolare può essere utilizzato da 
un altro Project Manager per condurre la fase di realizzazione senza doverlo rifare? 
• Il piano è sufficientemente dettagliato da guidare il lavoro delle risorse coinvolte nella 
realizzazione? 
• Il piano è comprensibile da parte di coloro che dovranno fornire le risorse? 
• Il piano è comprensibile da parte di coloro che dovranno assicurare le fonti di finanziamento? 
• Il piano è comprensibile da parte di coloro che dovranno svolgere l’assicurazione ed il 
controllo della qualità? 
• Il piano di project management è stato inviato preventivamente a Sponsor e Comitato di 
Coordinamento del Progetto perché ne prendano visione prima dell’incontro finalizzato 
all’approvazione o integrazione? 
Prima di andare oltre nella spiegazione delle varie fasi dell’Integrazione vediamo la gestione 
dell’ambito del progetto.
64 
GESTIONE DELL’AMBITO DI PROGETTO (SCOPE MANAGEMENT) 
A partire dal Project Charter, che come si è precedentemente visto formalizza l’inizio del progetto, vi 
è la gestione dell’ambito (Scope Management) che operativamente si traduce in una sua accurata 
descrizione. Ciascun progetto richiede un attento equilibrio fra complessità dell’ambito in cui si opera 
e livello di complessità delle metodologie e degli strumenti da utilizzare. E’ richiesta una 
formalizzazione degli obiettivi globali del progetto, che serviranno da riferimento per decisioni future. 
Successivamente vi dovrà essere una definizione di massima delle attività da eseguire e la definizione 
di quali saranno i criteri di accettazione dei risultati conseguiti. Non bisogna dimenticare infine di fare 
delle ipotesi su nuovi eventi (positivi e negativi) e su come affrontarli. 
La descrizione dell’ambito è la vera e propria definizione formale degli obiettivi di progetto, ovvero 
cosa deve essere portato a termine evidenziando i vincoli esterni ed interni che ne delimitano il 
campo d’azione. I vincoli esterni sono determinati da tutti gli aspetti precisati nel contratto, ovvero 
le specifiche tecniche e qualitative, i tempi di consegna e il prezzo stabilito o il budget allocato nel 
caso di progetti interni. I vincoli interni sono determinati primariamente dalle risorse e dalle 
competenze dell’organizzazione e dai carichi di lavoro già assegnati. Inoltre, definendo l’ambito, è 
necessario considerare tutti gli attori presenti nell’ambiente in cui si andrà ad operare e che 
necessariamente influenzeranno l’andamento del progetto. 
E’ necessario sviluppare una documentazione che chiarisca le caratteristiche e i limiti del progetto e 
dei prodotti e servizi ad esso associati, nonché dei termini di valutazione e di controllo. In generale 
gli elementi contenuti nel documento di descrizione dell’ambito sono: 
• Obiettivi del progetto 
• Requisiti e caratteristiche del prodotto o del servizio e criteri di accettazione dei risultati 
• Principali stakeholder 
• Fattori critici di successo 
• Pianificazione di massima con principali deliverables e schedulazione delle milestone 
fondamentali 
• Organizzazione iniziale e livello di partecipazione delle frazioni aziendali 
• Rischi definiti nelle fasi iniziali 
• Budget di progetto
Come detto, nella definizione degli obiettivi di progetto è necessario tener conto dei vincoli in termini 
di risorse interne possedute e disponibili, di risorse economiche e del tempo necessario al suo 
completamento. Gli obiettivi devono essere SMART (Specifici – Misurabili – Assegnabili – Realistici – 
65 
Tempificabili). 
In questa fase è necessario iniziare ad effettuare una descrizione delle specifiche di prodotto, anche 
se non nel massimo dettaglio. Le caratteristiche del prodotto dovranno essere progressivamente 
elaborate, in quanto subiranno di necessità delle variazioni si aformali che sostanziali. In questo 
momento è sufficiente chiarire i requisiti fondamentali del prodotto (o del servizio o del processo), 
assegnandone le priorità in base alle esigenze espresse dal cliente e alle aspettative degli stakeholder. 
“Le aspettative, le necessità, le esigenze degli Stakeholder devono essere analizzate e convertite in 
requisiti”. 
La preparazione di una descrizione dettagliata dell’ambito del progetto è critica per la riuscita del 
progetto stesso. Per far ciò è opportuno organizzare una riunione di avvio a cui partecipano i 
rappresentanti del cliente, i principali stakeholder, gli sponsor e il management del futuro team di 
progetto. In questo meeting si dovrebbe usualmente pervenire a decisioni fondamentali relative alle 
revisioni da apportare al progetto e all’accettazione definitiva dell’ordine, ma anche collegare le 
attività del progetto al lavoro in corso all’interno dell’organizzazione. In particolare si effettua una 
revisione del contratto e un’analisi degli aspetti relativi a: 
• Requisiti di approvazione del prodotto, sevizio processo oggetto del progetto e delle attività 
previste 
• Tempistiche di realizzazione delle attività 
• Decisioni preliminari di “Make or Buy” su elementi della fornitura 
• Definizione preliminare degli elementi di fornitura, delle possibili varianti e dei margini 
• Identificazione dell’organizzazione iniziale del progetto 
• Distribuzione delle risorse fra le differenti funzioni ed eventualmente fra differenti siti 
produttivi 
• Limite di finanziamento, stima dei costi e budget di progetto 
Fondamentali sono le decisioni relative alla pianificazione delle principali milestones di progetto e 
alla definizione dei principali deliverables:
66 
FASE PRINCIPALI DELIVERABLES 
Start-Up Contratto, Project Charter, Registro degli stakeholders 
Pianificazione Piano principale e piani ausiliari, WBS, OBS, RBS, ECC. 
Approvvigionamento Piano digestione degli approvvigionamenti 
Esecuzione Convalida dei deliverables, aggiornamento del piano principale e dei 
piani ausiliari 
Monitoraggio e Controllo Project status, registro richieste di modifica, registro delle Issue 
Chiusura Output finale, documentazione finale di progetto, indicatori di 
performance 
Altro fattore fondamentale indispensabile è la descrizione dei criteri di accettazione del prodotto 
e dei fattori critici di successo del progetto relativi all’ambito in cui sopra. 
Dopo questa breve descrizione generale veniamo alla descrizione dettaglia del Piano di Gestione del 
Ambito 
Cominciamo a fare il Piano dello Scope (dell’ambito). 
Esso deve traguardare il lavoro da fare nel progetto e quello da non fare nel progetto. L’obiettivo è 
sempre quello di completare con successo il progetto. Esso raccoglie tutto quello che riguarda e 
capire cosa c’è da fare. 
Viene struttura nell’ambito del BOK con 6 attrezzi: i 6 processi di gestione dell’ambito. Il primo è 
sempre la pianificazione. 
Cosa vuol dire pianificare la gestione dell’ambito? Cosa vuol dire ambito nel nostro progetto? quali 
sono le regole del gioco e le linee guida che ci diamo per la gestione dell’ambito? 
Quando parliamo di ambito parliamo certamente dell’ambito del progetto ma anche dell’ambito del 
prodotto. Quando parliamo di scope (di ambito), ad es. per fare un ponte, parleremo di cose che 
occorre fare per costruire il ponte (calcoli, gettate di cls, ecc.) – e questo si chiama ambito del 
prodotto – sia di gestione del progetto, cioè una pianificazione temporale, un charter, ecc. – e questo 
si chiama ambito del progetto.
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management
2 integration e scope management

Contenu connexe

Tendances

Agile Project Management
Agile Project ManagementAgile Project Management
Agile Project ManagementGiulio Roggero
 
Pm first presentation
Pm first presentationPm first presentation
Pm first presentationcarlobisio
 
Business & consulting toolkits free sample in powerpoint
Business & consulting toolkits   free sample in powerpointBusiness & consulting toolkits   free sample in powerpoint
Business & consulting toolkits free sample in powerpointDonald Gest
 
Service Integration and Management / MultiSourcing Services Integrationn
Service Integration and Management / MultiSourcing Services IntegrationnService Integration and Management / MultiSourcing Services Integrationn
Service Integration and Management / MultiSourcing Services IntegrationnBoonNam Goh
 
ScrumOps - Featuring Dave West & Jayne Groll
ScrumOps - Featuring Dave West & Jayne GrollScrumOps - Featuring Dave West & Jayne Groll
ScrumOps - Featuring Dave West & Jayne GrollTaylor Puleri
 
PMBOK GUIDE 7th Summary
PMBOK GUIDE 7th Summary PMBOK GUIDE 7th Summary
PMBOK GUIDE 7th Summary Amr Miqdadi
 
Leadership and Managerial Skills Toolkit - Framework, Best Practices and Temp...
Leadership and Managerial Skills Toolkit - Framework, Best Practices and Temp...Leadership and Managerial Skills Toolkit - Framework, Best Practices and Temp...
Leadership and Managerial Skills Toolkit - Framework, Best Practices and Temp...Aurelien Domont, MBA
 
Outcomes vs Outputs: How Outcome Driven Development Planning Changes Everything
Outcomes vs Outputs: How Outcome Driven Development Planning Changes EverythingOutcomes vs Outputs: How Outcome Driven Development Planning Changes Everything
Outcomes vs Outputs: How Outcome Driven Development Planning Changes EverythingChris Reynolds
 
Project Governance Framework PowerPoint Presentation Slides
Project Governance Framework PowerPoint Presentation SlidesProject Governance Framework PowerPoint Presentation Slides
Project Governance Framework PowerPoint Presentation SlidesSlideTeam
 
PPM and PMO In The Current Market
PPM and PMO In The Current MarketPPM and PMO In The Current Market
PPM and PMO In The Current Marketerwin_dunnink
 
Il ruolo del Project Manager
Il ruolo del Project ManagerIl ruolo del Project Manager
Il ruolo del Project ManagerEmanuele Rizzo
 
PMP Chap 3 - Project Management Processes
PMP Chap 3 - Project Management ProcessesPMP Chap 3 - Project Management Processes
PMP Chap 3 - Project Management ProcessesAnand Bobade
 
Project management - kickoff - opensource erp
Project management - kickoff - opensource erpProject management - kickoff - opensource erp
Project management - kickoff - opensource erpThanh Nguyen
 
The Strategic Business Plan
The Strategic Business PlanThe Strategic Business Plan
The Strategic Business PlanEarl Stevens
 
Chapter 3 Lecture Slides
Chapter 3 Lecture SlidesChapter 3 Lecture Slides
Chapter 3 Lecture Slidesdotesch
 
Agile Mindset For Executives
Agile Mindset For ExecutivesAgile Mindset For Executives
Agile Mindset For ExecutivesMichael Tarnowski
 
Pmbok 4th edition chapter 3 - Project Management Processes for a Project
Pmbok 4th edition   chapter 3 - Project Management Processes for a Project Pmbok 4th edition   chapter 3 - Project Management Processes for a Project
Pmbok 4th edition chapter 3 - Project Management Processes for a Project Ahmad Maharma, PMP,RMP
 
An Agile Approach to Starting an Agile Transformation Office (COE)
An Agile Approach to Starting an Agile Transformation Office (COE)An Agile Approach to Starting an Agile Transformation Office (COE)
An Agile Approach to Starting an Agile Transformation Office (COE)Dan Craig
 

Tendances (20)

Agile Project Management
Agile Project ManagementAgile Project Management
Agile Project Management
 
Pm first presentation
Pm first presentationPm first presentation
Pm first presentation
 
Business & consulting toolkits free sample in powerpoint
Business & consulting toolkits   free sample in powerpointBusiness & consulting toolkits   free sample in powerpoint
Business & consulting toolkits free sample in powerpoint
 
Il Piano di Project Management in 20 mosse
Il Piano di Project Management in 20 mosseIl Piano di Project Management in 20 mosse
Il Piano di Project Management in 20 mosse
 
Service Integration and Management / MultiSourcing Services Integrationn
Service Integration and Management / MultiSourcing Services IntegrationnService Integration and Management / MultiSourcing Services Integrationn
Service Integration and Management / MultiSourcing Services Integrationn
 
ScrumOps - Featuring Dave West & Jayne Groll
ScrumOps - Featuring Dave West & Jayne GrollScrumOps - Featuring Dave West & Jayne Groll
ScrumOps - Featuring Dave West & Jayne Groll
 
PMBOK GUIDE 7th Summary
PMBOK GUIDE 7th Summary PMBOK GUIDE 7th Summary
PMBOK GUIDE 7th Summary
 
Leadership and Managerial Skills Toolkit - Framework, Best Practices and Temp...
Leadership and Managerial Skills Toolkit - Framework, Best Practices and Temp...Leadership and Managerial Skills Toolkit - Framework, Best Practices and Temp...
Leadership and Managerial Skills Toolkit - Framework, Best Practices and Temp...
 
Outcomes vs Outputs: How Outcome Driven Development Planning Changes Everything
Outcomes vs Outputs: How Outcome Driven Development Planning Changes EverythingOutcomes vs Outputs: How Outcome Driven Development Planning Changes Everything
Outcomes vs Outputs: How Outcome Driven Development Planning Changes Everything
 
Project Governance Framework PowerPoint Presentation Slides
Project Governance Framework PowerPoint Presentation SlidesProject Governance Framework PowerPoint Presentation Slides
Project Governance Framework PowerPoint Presentation Slides
 
PPM and PMO In The Current Market
PPM and PMO In The Current MarketPPM and PMO In The Current Market
PPM and PMO In The Current Market
 
The Modern PMO
The Modern PMOThe Modern PMO
The Modern PMO
 
Il ruolo del Project Manager
Il ruolo del Project ManagerIl ruolo del Project Manager
Il ruolo del Project Manager
 
PMP Chap 3 - Project Management Processes
PMP Chap 3 - Project Management ProcessesPMP Chap 3 - Project Management Processes
PMP Chap 3 - Project Management Processes
 
Project management - kickoff - opensource erp
Project management - kickoff - opensource erpProject management - kickoff - opensource erp
Project management - kickoff - opensource erp
 
The Strategic Business Plan
The Strategic Business PlanThe Strategic Business Plan
The Strategic Business Plan
 
Chapter 3 Lecture Slides
Chapter 3 Lecture SlidesChapter 3 Lecture Slides
Chapter 3 Lecture Slides
 
Agile Mindset For Executives
Agile Mindset For ExecutivesAgile Mindset For Executives
Agile Mindset For Executives
 
Pmbok 4th edition chapter 3 - Project Management Processes for a Project
Pmbok 4th edition   chapter 3 - Project Management Processes for a Project Pmbok 4th edition   chapter 3 - Project Management Processes for a Project
Pmbok 4th edition chapter 3 - Project Management Processes for a Project
 
An Agile Approach to Starting an Agile Transformation Office (COE)
An Agile Approach to Starting an Agile Transformation Office (COE)An Agile Approach to Starting an Agile Transformation Office (COE)
An Agile Approach to Starting an Agile Transformation Office (COE)
 

Similaire à 2 integration e scope management

L’idea di impresa: strumenti per creare e rimodellare il valore
L’idea di impresa: strumenti per creare e rimodellare il valoreL’idea di impresa: strumenti per creare e rimodellare il valore
L’idea di impresa: strumenti per creare e rimodellare il valoreKilowatt
 
La mappa strategica: la creazione delle strategie di crescita e il loro monit...
La mappa strategica: la creazione delle strategie di crescita e il loro monit...La mappa strategica: la creazione delle strategie di crescita e il loro monit...
La mappa strategica: la creazione delle strategie di crescita e il loro monit...CentoCinquanta srl
 
Business Conversation su Web Marketing e SEO.pdf
Business Conversation su Web Marketing e SEO.pdfBusiness Conversation su Web Marketing e SEO.pdf
Business Conversation su Web Marketing e SEO.pdfLuca Calderan
 
Dal Design Thinking allo Sprint di Google
Dal Design Thinking allo Sprint di GoogleDal Design Thinking allo Sprint di Google
Dal Design Thinking allo Sprint di GoogleAIMB2B
 
Lean canvas vs business model canvas
Lean canvas vs business model canvasLean canvas vs business model canvas
Lean canvas vs business model canvasT3basilicata
 
8 richmond-report-purchase
8 richmond-report-purchase8 richmond-report-purchase
8 richmond-report-purchasePaola Signorino
 
Project management: un must per imprese e professionisti
Project management: un must per imprese e professionistiProject management: un must per imprese e professionisti
Project management: un must per imprese e professionistiMarco Turolla
 
Project management
Project managementProject management
Project managementmobi-TECH
 
Workshop di Business Design sul Business Model Canvas: dall'idea all'impresa
Workshop di Business Design sul Business Model Canvas: dall'idea all'impresaWorkshop di Business Design sul Business Model Canvas: dall'idea all'impresa
Workshop di Business Design sul Business Model Canvas: dall'idea all'impresaGino Tocchetti
 
David Bramini | Gestione strategica del Portfolio Progetti. Orientare l exec...
David Bramini  | Gestione strategica del Portfolio Progetti. Orientare l exec...David Bramini  | Gestione strategica del Portfolio Progetti. Orientare l exec...
David Bramini | Gestione strategica del Portfolio Progetti. Orientare l exec...PMexpo
 
Agile@scale: Portfolio level
Agile@scale: Portfolio levelAgile@scale: Portfolio level
Agile@scale: Portfolio levelFelice Pescatore
 
Luca Graziosi Presentazione Servizi
Luca Graziosi Presentazione ServiziLuca Graziosi Presentazione Servizi
Luca Graziosi Presentazione ServiziLG Food Service LTD
 
II coopup 2017 Business Model Canvas
II coopup 2017 Business Model CanvasII coopup 2017 Business Model Canvas
II coopup 2017 Business Model CanvasKilowatt
 
Workshop: il controllo direzionale oggi
Workshop: il controllo direzionale oggiWorkshop: il controllo direzionale oggi
Workshop: il controllo direzionale oggiSedoc Digital Group
 
Mobile App Development - Strategie di web marketing e comunicazione - Parte 1
Mobile App Development - Strategie di web marketing e comunicazione - Parte 1Mobile App Development - Strategie di web marketing e comunicazione - Parte 1
Mobile App Development - Strategie di web marketing e comunicazione - Parte 1Paolo Bolpet
 
CoopUPBologna 2018: MVP, testing e validazione
CoopUPBologna 2018: MVP, testing e validazioneCoopUPBologna 2018: MVP, testing e validazione
CoopUPBologna 2018: MVP, testing e validazioneKilowatt
 
Stefano Supino, Università di Cassino e del Lazio Meridionale: pillole di lea...
Stefano Supino, Università di Cassino e del Lazio Meridionale: pillole di lea...Stefano Supino, Università di Cassino e del Lazio Meridionale: pillole di lea...
Stefano Supino, Università di Cassino e del Lazio Meridionale: pillole di lea...ASVI Social Change
 

Similaire à 2 integration e scope management (20)

L’idea di impresa: strumenti per creare e rimodellare il valore
L’idea di impresa: strumenti per creare e rimodellare il valoreL’idea di impresa: strumenti per creare e rimodellare il valore
L’idea di impresa: strumenti per creare e rimodellare il valore
 
Articolo ad net-16_maggio_s&op
Articolo ad net-16_maggio_s&opArticolo ad net-16_maggio_s&op
Articolo ad net-16_maggio_s&op
 
La mappa strategica: la creazione delle strategie di crescita e il loro monit...
La mappa strategica: la creazione delle strategie di crescita e il loro monit...La mappa strategica: la creazione delle strategie di crescita e il loro monit...
La mappa strategica: la creazione delle strategie di crescita e il loro monit...
 
Business Conversation su Web Marketing e SEO.pdf
Business Conversation su Web Marketing e SEO.pdfBusiness Conversation su Web Marketing e SEO.pdf
Business Conversation su Web Marketing e SEO.pdf
 
Dal Design Thinking allo Sprint di Google
Dal Design Thinking allo Sprint di GoogleDal Design Thinking allo Sprint di Google
Dal Design Thinking allo Sprint di Google
 
Elexperience
ElexperienceElexperience
Elexperience
 
Lean canvas vs business model canvas
Lean canvas vs business model canvasLean canvas vs business model canvas
Lean canvas vs business model canvas
 
8 richmond-report-purchase
8 richmond-report-purchase8 richmond-report-purchase
8 richmond-report-purchase
 
Project management: un must per imprese e professionisti
Project management: un must per imprese e professionistiProject management: un must per imprese e professionisti
Project management: un must per imprese e professionisti
 
Project management
Project managementProject management
Project management
 
Workshop di Business Design sul Business Model Canvas: dall'idea all'impresa
Workshop di Business Design sul Business Model Canvas: dall'idea all'impresaWorkshop di Business Design sul Business Model Canvas: dall'idea all'impresa
Workshop di Business Design sul Business Model Canvas: dall'idea all'impresa
 
David Bramini | Gestione strategica del Portfolio Progetti. Orientare l exec...
David Bramini  | Gestione strategica del Portfolio Progetti. Orientare l exec...David Bramini  | Gestione strategica del Portfolio Progetti. Orientare l exec...
David Bramini | Gestione strategica del Portfolio Progetti. Orientare l exec...
 
Agile@scale: Portfolio level
Agile@scale: Portfolio levelAgile@scale: Portfolio level
Agile@scale: Portfolio level
 
Luca Graziosi Presentazione Servizi
Luca Graziosi Presentazione ServiziLuca Graziosi Presentazione Servizi
Luca Graziosi Presentazione Servizi
 
II coopup 2017 Business Model Canvas
II coopup 2017 Business Model CanvasII coopup 2017 Business Model Canvas
II coopup 2017 Business Model Canvas
 
1 introduzione
1 introduzione1 introduzione
1 introduzione
 
Workshop: il controllo direzionale oggi
Workshop: il controllo direzionale oggiWorkshop: il controllo direzionale oggi
Workshop: il controllo direzionale oggi
 
Mobile App Development - Strategie di web marketing e comunicazione - Parte 1
Mobile App Development - Strategie di web marketing e comunicazione - Parte 1Mobile App Development - Strategie di web marketing e comunicazione - Parte 1
Mobile App Development - Strategie di web marketing e comunicazione - Parte 1
 
CoopUPBologna 2018: MVP, testing e validazione
CoopUPBologna 2018: MVP, testing e validazioneCoopUPBologna 2018: MVP, testing e validazione
CoopUPBologna 2018: MVP, testing e validazione
 
Stefano Supino, Università di Cassino e del Lazio Meridionale: pillole di lea...
Stefano Supino, Università di Cassino e del Lazio Meridionale: pillole di lea...Stefano Supino, Università di Cassino e del Lazio Meridionale: pillole di lea...
Stefano Supino, Università di Cassino e del Lazio Meridionale: pillole di lea...
 

Plus de gianni raducci

Ricardovargaspmbokflow5edcolorit 140726203841-phpapp02
Ricardovargaspmbokflow5edcolorit 140726203841-phpapp02Ricardovargaspmbokflow5edcolorit 140726203841-phpapp02
Ricardovargaspmbokflow5edcolorit 140726203841-phpapp02gianni raducci
 
11 professional e social responsibility
11 professional e social responsibility11 professional e social responsibility
11 professional e social responsibilitygianni raducci
 
10 stakeholder management
10 stakeholder management10 stakeholder management
10 stakeholder managementgianni raducci
 
9 procurement management
9 procurement management9 procurement management
9 procurement managementgianni raducci
 
7 communication management
7 communication management7 communication management
7 communication managementgianni raducci
 

Plus de gianni raducci (10)

Ricardovargaspmbokflow5edcolorit 140726203841-phpapp02
Ricardovargaspmbokflow5edcolorit 140726203841-phpapp02Ricardovargaspmbokflow5edcolorit 140726203841-phpapp02
Ricardovargaspmbokflow5edcolorit 140726203841-phpapp02
 
11 professional e social responsibility
11 professional e social responsibility11 professional e social responsibility
11 professional e social responsibility
 
10 stakeholder management
10 stakeholder management10 stakeholder management
10 stakeholder management
 
9 procurement management
9 procurement management9 procurement management
9 procurement management
 
8 risk management
8 risk management8 risk management
8 risk management
 
7 communication management
7 communication management7 communication management
7 communication management
 
6 human resources
6 human resources6 human resources
6 human resources
 
5 quality management
5 quality management5 quality management
5 quality management
 
4 cost management
4 cost management4 cost management
4 cost management
 
3 time management
3 time management3 time management
3 time management
 

2 integration e scope management

  • 4. GESTIONE DELL’INTEGRAZIONE DEL PROGETTO E SCOPE MANAGEMENT Cosa è un progetto: “E’ un’iniziativa temporanea intrapresa per creare un prodotto, un servizio o un risultato con caratteristiche di unicità” – PMBOK – 5° Ed. Quindi esiste un vincolo molto rigido che è il Tempo, anche se questo vincolo non è molto certo, ma dovrebbe essere chiaro qual è il tempo effettivo per portare a termine un progetto. Anche la caratteristica di Unicità, anch’esso un vincolo rigido, non è cosa semplice per un P.M. Ci sono dunque delle incertezze, dei parametri assolutamente rigorosi, che il P.M. deve assolutamente gestire in quanto a monte risultano concetti molto variabili. Il concetto di progetto deve essere visto quindi da un punto di vista più ampio abbracciando variabili più complesse e concatenanti tra di loro.
  • 5. Da dove nasce un progetto? Tendenzialmente esso nasce da un bisogno, ovvero da un sogno da realizzare. Si decide quindi di mettere in atto una serie di sforzi, di impegni, ed i passaggi vertono a valutare i bisogni, le soluzioni, traguardando quelli che sono ad es. i mezzi di trasporto, i tempi, i costi, ecc. Di tali possibili soluzioni cerco di capire le effettive esigenze e individuo quella che certo più si adatta a risolvere il mio bisogno. Quindi si effettua un primo percorso, divergente, cercando di capire quali sono tutte le possibilità esistenti per raggiungere lo scopo, e poi convergente verso la soluzione. Tale soluzione viene definita tramite dei requisiti, delle specifiche. Cioè andiamo a descrivere quali sono le caratteristiche di questa cosa che andremo ad analizzare per soddisfare il nostro bisogno. Capite le specifiche si provvede a realizzarle e a generare una soluzione ossia la Realizzazione di quelle specifiche che hanno identificato la soluzione al nostro bisogno. Ora il problema non è ancora risolto in quanto aver realizzato delle specifiche di fatto non ancora abbiamo prodotto nulla. C’è bisogno che qualcuno usi la soluzione che ho messo in piedi ottenendo dei risultati che provocano dei benefici che infondono i bisogni da cui sono partito. Ad es. in un industria meccanica, ovvero all’interno della mia linea produttiva, ha bisogno di un tornio verticale per fare un certo pezzo. Quindi il mio BISOGNO è modellare un certo pezzo e quindi mi serve un componente per modellarlo. Per far ciò posso avere delle stampanti tridimensionali a laser ovvero dei torni verticali, orizzontali ecc. ma ad un certo punto ne scelgo uno: ad es. il tornio verticale e quindi descrivo la lavorazione ovvero come dovrebbe essere questo attrezzo che mi produce questa lavorazione – SPECIFICHE. Lo realizzo ed ottengo il pezzo richiesto ed ho fatto il progetto. Ma se nessuno lo usa non me ne faccio niente di tale progetto. Cioè il progetto è stato inutile. Quindi ci vuole qualcuno che lo piazzi nella linea produttiva, che lo attivi, che lo faccia girare, magari anche qualche operatore. Quindi quell’attrezzo mi genera una soluzione o risultato che farà sì che si possa impiantare un sistema di cambio automatico su una macchina più performante che mi fa distinguere dalla concorrenza: che è poi il bisogno principale da cui sono partito. Quindi il progetto in se non basta: c’è un mondo che gira intorno al progetto. Che è un mondo estremamente significativo che ne decreta il successo.
  • 6. Progetti che non rispondono a dei bisogni e che non generano dei risultati, che non portano a dei benefici sono anche fatti molto bene, ma rischiano di essere inutili. “Non c’è niente di peggio che fare una cosa molto bene ma inutile”. Tutte le priorità per poter fare delle scelte durante il progetto nasceranno principalmente dal BENEFICIO. Capire quale mondo gira intorno al progetto, è a tutti gli effetti una ricchezza enorme per il P.M. proprio sul piano concreto. Anche se in realtà stiamo parlando di una fascia che di solito non è nella visibilità del P.M. in quanto relativamente ai benefici e/o bisogni si hanno coinvolgimenti soprattutto da parte della direzione, del top manager. (Program Manager) Come facciamo a lavorare quindi su tali concetti. Abbiamo bisogno di alcuni strumenti e di un’organizzazione. Abbiamo bisogno di esigere per il nostro progetto una serie di fattori. Un altro esempio significativo: Parliamo ad es. della Mission della Coca Cola: la Mission è quella cosa che dice perché una azienda esiste. Una azienda esiste, oltre che per fare soldi – ma non è detto in quanto ci sono aziende no profit – anche per una caratterizzazione del suo modo di essere che magari è il motivo per fare i soldi. Ad esempio una mission della Coca Cola è: “To Refresh the world” – rinfrescare il mondo, ecc. Quindi la mission è in realtà una cosa principale per la vita di un’azienda. Esso da l’imprinting all’attività aziendale, il suo modo di lavorare. Come fa la Coca Cola a realizzare la propria mission? Esso mette in atto una serie di azioni: Obiettivi di tipo strategico misurabili e temporali. Dunque come fa la Coca Cola a rinfrescare il mondo…?? Ad esempio può dire: – Voglio migliorare del 2% la simpatia del mio marchio nella penisola scandinava nel prossimo anno. – Incremento del 5% le vendite nel sud est asiatico nei prossimi due anni – Ecc.
  • 7. La mission viene sostanzialmente realizzata dalla strategia. La strategia è un percorso che l’azienda si dà ed è fatto da una serie di passi, di scalini, di obiettivi di tipo strategico attraverso i quali realizza la propria mission. Ma come si fa ad es. ad aumentare del 2% la simpatia del mio marchio nella penisola scandinava nel prossimo anno: ad esempio potrei attivare un programma di sponsorizzazione per gli sport nordici. Oppure faccio una bella campagna pubblicitaria, ovvero faccio delle belle bottiglie a forma di pino, magari perché richiama le foreste di pino molto sviluppate in quella zona. Nel sud est asiatico come faccio ad aumentare del 5% le vendite nei prossimi due anni: posso ristrutturare la rete di vendita magari gestendo anche dei chioschi anziché solo dei supermercati, ovvero faccio una campagna pubblicitaria, o faccio una etichetta a forma di pagoda, ecc. Quindi per realizzare degli obiettivi strategici metto in atto quelle iniziative suddette, cercando di smuovere, di cambiare una situazione che ho intorno con delle iniziative mirate ad aiutarmi a realizzare quegli obiettivi. Ma tali iniziative allora sono dei Progetti che sono gestiti da un P.M. il quale identificherà una serie di requisiti (come detto prima) che poi cercherà di realizzare, concretizzare. Quindi il P.M. ha il compito fondamentale di identificare i requisiti che poi vanno realizzati. Ma tutto questo non basta. Ad es. – perché voglio fare un programma di sponsorizzazione, ovvero una campagna pubblicitaria o attivare una rete di vendita, ecc. Questi sono tutti progetti che formano un programma che necessariamente devono essere gestiti da un Program Manager. Quindi il programma ed il progetto, pur guardando nella stessa direzione, vengono visti da due punti diversi. Uno avrà come attenzione quella di realizzare i requisiti (project manager), l’altra avrà come attenzione di valorizzare il contributo che questa realizzazione di requisiti porta alla realizzazione del beneficio e quindi dell’obiettivo (program manager). Tali punti di vista sono estremamente diversi tra loro. Ad esempio: io sono il P.M. del progetto della bottiglia a forma di pino che magari è anche un progetto spettacolare, che risponde a tutti i requisiti: tempi, costi, addirittura si è trovato anche un sistema di stoccaggio che ottimizza gli spazi e che addirittura stà creando un vantaggio importante sia nel
  • 8. magazzinaggio, che nei trasporti. Ma il Program Manager, che invece ha l’obiettivo di migliorare la percezione del brand (cioè del marchio), un bel giorno entra in un bar e leggendo il giornale ascolta due persone che parlano tra loro discutendo negativamente del fatto che molte aziende multinazionali raccolgono sempre le tradizione del posto per migliorare il proprio marchio. A questo punto il Program Manager, avendo subito avviato un sondaggio in merito, si rende conto della veridicità di tale affermazione, che reputa quindi negativa per il marchio. E quindi la prima casa che fa è quello di eliminare tale progetto anche se esso va benissimo come detto prima. In quanto non serve più, ovvero può essere controproducente. Da qui discende il fatto che il program manager pensa alla realizzazione dei benefici e non a realizzare i requisiti. A questo punto c’è un altro concetto da affrontare. Il Program manager gestisce tutti i progetti al fine di portare dei benefici alla propria azienda. Ma occorre prendere in considerazione che ad es. il progetto di sponsorizzazione, di pubblicità, di rete di vendita, ecc. sono iniziative legate alla strategia ed hanno inevitabilmente un costo preventivato per realizzarle. Ed inoltre non ci sono risorse infinite per realizzare la propria strategia. Ognuno di tali iniziative ha un suo significato legato a degli obiettivi strategici. Gli obiettivi strategici sono tutti importanti e significativi. Però esistono degli obiettivi strategici che se non raggiunti determinano il fallimento dell’azienda. Oppure ci sono degli obiettivi strategici che se non raggiunti determinano una difficoltà dell’azienda. Quindi pur essendo tutti importanti, ci sono quelli di maggiore importanza e quelli di minore importanza. Si può dare ad ogni iniziativa quindi un peso, un valore numerico o di giudizio, al fine di creare una classifica. Inoltre ogni iniziativa, progetto o programma incide sulla realizzazione dell’obiettivo strategico in misura diversa. Ci saranno quei progetti determinanti per ottenere il risultato; ci saranno progetti che aiutano e progetti che supportano. Anche in tal caso si possono fare delle classifiche a punteggio o a giudizio.
  • 9. Indefinitiva stiamo capendo, tra tutti i progetti, requisiti, ecc. qual è il loro peso sul raggiungimento degli obiettivi strategici. Si possono avere delle iniziative più semplici, facili ed altre più difficili, più rischiose che quindi possono avere un peso differente per tale raggiungimento. Esistono quindi una serie di parametri che caratterizzano i singoli progetti e requisiti. In alto avrò quindi i progetti che meglio riescono a traguardare gli obiettivi strategici ed in basso quelli meno. Addirittura ci possono essere quei progetti o programmi che non riescono proprio a traguardare quanto sopra o che addirittura possono essere cancellati. Chi prende queste decisioni è il Portfolio Manager. Se non c’è un program manager ci deve pensare il P.M. a capire quali possono essere i benefici da portare all’azienda. Ma un Portfolio manager c’è sempre. Quindi la selezione dei progetti che andranno a comporre il project portfolio (portafoglio progetti) di un’impresa è un’importante scelta strategica. Deve necessariamente basarsi su valutazioni oggettive di opportunità legate a operazioni di marketing o aspettative sul ritorno degli investimenti, ma che tengano conto delle competenze interne e dei rischi collegati a ogni attività progettuale. Il concetto di Integrazione nell’ambito del Project Management non deve, infatti, riferirsi solamente a un’integrazione fra attività e risorse di un singolo progetto, ma a una gestione integrata e coordinata del project portfolio in un’ottica di Multi-Project Management. L’obiettivo è quello non solo di arrivare a modelli generali che sviluppano le competenze core dell’organizzazione e che permettano di ottenere prestazioni e un controllo dei progetti che sarebbero inaccessibili nel caso di una loro gestione separata. In questo contesto riveste un ruolo fondamentale la pianificazione e assegnazione delle attività programmate che deve essere attenta a bilanciare il lavoro alle dimensioni e alla rilevanza del progetto.
  • 10. PRIMO GRUPPO DI PROCESSI: INTEGRAZIONE Ritorniamo alle competenze del P.M. Egli dovrà tenere bene a mente il complesso del lavoro che dovrà svolgere e che sinteticamente viene riportato nel cosiddetto Framework del PMBOK. Esso rappresenta la” cassetta degli attrezzi”, la mappa del territorio della gestione dei progetti. Ogni volta che occorre far partire un “progetto” occorre capire cosa c’è da fare e con chi hai a che fare. Esistono dunque degli strumenti relativi ai costi, ai tempi, alle risorse umane, ai rischi, ecc. Ci sono degli strumenti che si chiamano gruppi di processi che ci permettono di organizzare il progetto, di pianificare il futuro. All’interno dei gruppi ci sono le fasi. Tali processi vengono in realtà presi contemporaneamente e non in maniera isolata. Il tema essenziale nel progetto è dunque l’integrazione che tiene assieme tutti i processi, in quanto il progetto è un sistema integrato.
  • 11. Lo scopo del P.M. è proprio quello di effettuare l’integrazione dei processi, cioè ha il compito di riunire tutte le fasi che magari vengono svolte da altre persone. Ad es. la pianificazione dei tempi probabilmente lo fa il plainer (o specialisti dei tempi e così via). Il P.M. dovrà integrare tutto ciò che gli viene dalle singole persone. Quindi la prima area di conoscenza del P.M., e anche del PMBOK, è l’INTEGRAZIONE. Cos’è l’integrazione del progetto? (vedi libro PMBOK) La gestione dell’integrazione di progetto include i processi e le attività necessari per identificare, definire, unificare e coordinare i vari processi e le attività di gestione del progetto nell’ambito dei gruppi di processi di Project Management. I processi di gestione dell’integrazione di progetto sono i seguenti: 1.1 Sviluppare il Project Charter 1.2 Sviluppare il piano di Project Management 1.3 Dirigere e gestire il lavoro del progetto 1.4 Monitorare e controllare il lavoro del progetto 1.5 Eseguire il controllo integrato delle modifiche 1.6 Chiudere il progetto o una fase Il P.M. inizialmente dovrà sviluppare il project charter, poi dovrà effettuare lo sviluppo del piano di project management. Dopodiché dovrà effettuare il monitoraggio e controllo, cioè capire come doveva andare e cosa occorre fare per farlo tornare sulla linea giusta. Alla fine dovrà effettuare il completamento del progetto (anche se il progetto non è finito). Ma un altro processo importante che si interseca è la pianificazione e l’esecuzione del progetto (Dirigere e gestire il lavoro del progetto), nonché la gestione delle cose che cambiano (Eseguire il controllo integrato delle modifiche).
  • 12. Relativamente al cambiamento, quando parliamo di progetto abbiamo 2 tipi di cambiamento a cui facciamo fronte: 1) Un cambiamento che dipende dal progetto – cioè noi facciamo un progetto ma sicuramente qualcosa cambierà oppure è già cambiato e noi dobbiamo rincorrerlo. Il progetto va di pari passo con il cambiamento. Tutte le volte che c’è un cambiamento nel processo interviene un progetto a generare questo cambiamento. 2) Oppure il cambiamento può essere inteso come modifica: lo slittamento dei tempi è una modifica, oppure l’aggiunta di una risorsa in più all’interno del progetto. Tali modifiche sono una prassi normali nel progetto ma occorre tuttavia pensare tale cambiamento in maniera integrata. Cioè come va ad impattare tale cambiamento su tutti i gruppi di processo e quindi considerarlo nell’insieme (integrazione). Quindi ogni modifica deve essere valutata dal punto di vista del “sistema progetto” e deve essere accolta o rifiutata a seconda dei valori e dei vantaggi che porta. Esiste un comitato per capire l’impatto che genera tale modifica oppure può esserci un cambiamento che può essere gestito direttamente dal P.M. L’integrazione ha a che fare con il progetto. Ma il progetto è un sistema aperto. Cioè non dobbiamo solo preoccuparci di integrare il progetto nelle sue dimensioni interne (cioè delle 10 aree di conoscenza) ma dobbiamo preoccuparci cosa succede fuori inerente al progetto. Il progetto ha un senso rispetto alla sua strategia. Se mi affidano un progetto e non si sa perché occorre farlo sicuramente tale progetto non andrà a buon fine. Coerenza nella gestione dei dati di esecuzione del lavoro di Project Management e del flusso delle informazioni: Nell’ambito dell’integrazione quello che il P.M. deve fare è quello di individuare in che modo sviluppare la gestione e quindi decidere quali strumenti usare e con quali dettagli e profondità. Cioè in quale modo i processi di controllo vengono sviluppati. Ad es. per sviluppare il Project Charter dovrò avere delle informazioni a monte (Input). Tali informazioni vengono gestiti con degli strumenti per ottenere (in output) il risultato che volevamo (il project charter).
  • 13. Durante il ciclo di vita del progetto esiste una grande quantità di dati che devono essere raccolti. L’analisi e la sintesi dei dati porta alla generazione delle informazioni di progetto che devono essere correttamente indirizzate verso gli STK interessati. Esistono molti modi di presentazione delle informazioni, tra queste i report rappresentano la modalità ufficiale. In particolare i dati sull’andamento del progetto vengono raccolti dal P.M. e dal suo team durante i processi di esecuzione. La loro analisi, e la trasformazione in informazioni avviene durante i processi di controllo. Tali informazioni vengono comunicate principalmente in tre maniere: verbalmente, memorizzandole opportunamente, oppure distribuendole in forma di report. Nei processi di esecuzione secondo il PMBOK si nota spesso l’output Work Performed Data, dati sulle prestazioni del lavoro, ottenuti dalle osservazioni o dalle misurazioni eseguite durante l’esecuzione del progetto (es. data d’inizio effettivo di un’attività, spese sostenute per l’acquisto di un’apparecchiatura, risultati del controllo di qualità su un deliverable, ecc.) Il PMBOK introduce il modello DIKW (acronimo di Data – Information – Knowledge – Wisdom), che è una novità introdotta dal PMBOK. E’ un modello riconosciuto che rappresenta la gestione delle informazioni. Esiste un percorso della conoscenza che parte dal Dato, poi ci ragiono e lo trasformo in Informazione che ha un significato che viene diffuso e quindi diviene Conoscenza, e nel momento in cui è conoscenza può diventare Sapienza. Il PMBOK non arriva alla sapienza però tutte le informazioni, dati, ecc. hanno questo percorso. Ad es. in un processo di controllo noi leggiamo dei dati: ad esempio “ho finito il 15 di giugno tale attività” – questo è un Dato. Trasformiamo tali dati, attraverso una fase di controllo, in Informazioni: ad esempio dovevo finire il 12 anziché il 15 di giugno e per cui sarei in ritardo. “sei in ritardo è un’informazione. Lo comunico e quindi diventa Conoscenza: tutti sanno che c’è un ritardo. Il percorso che il PMBOK esprime è quello di far vedere come i dati e le informazioni seguiranno sempre tali percorsi. I Work Performed Data sono dati grezzi che vengono utilizzati da tutti i processi di controllo. Questi, a loro volta, producono informazioni (Work Performance Information), ovvero le informazioni sulle prestazioni del lavoro. Tali informazioni sono ottenute tramite analisi, aggregazione e trasformazione dei dati ricevuti (ad es. stato di avanzamento della realizzazione di un deliverable o di una parte del progetto, stima a finire economica dell’intero progetto, nuova data di completamento stimata, …) a
  • 14. differenza dei WPD i WPI sono dati contestualizzati (tengono cioè conto della tipologia di dato che rappresentano e dall’evoluzione nel tempo) e derivano da una vista integrata con altre aree di lavoro (per es., un dato sulle previsioni al completamento può integrare informazioni relative al tempo, al costo e all’ambito). Le WPI opportunamente compilate vengono raccolte nei cosiddetti Work Performance Report, report sulle prestazioni del lavoro, che sono spesso usati nelle riunioni e in tutte le occasioni in cui è necessario prendere decisioni (es. report di avanzamento del progetto, cruscotti manageriali, note informative, note di raccomandazione, …) Flusso dei dati Si intuisce quindi come tutti i processi di controllo avranno in input dei Dati ed in output delle Informazioni che saranno poi comunicate diventando Conoscenza (report).
  • 15. SVILUPPARE IL PROJECT CHARTER Il project charter appartiene al gruppo di avvio. A cosa serve? E’ come una Magna Carta. Ad es. nel nostro ordinamento costituzionale abbiamo un gruppo di leggi fondamentali che determinano l’essere del nostro vivere civile. Ci sono delle norme che di fatto danno lo stile di tutto quello che succede nella nostra nazione. Nessuna norma ulteriore può essere contradditoria con queste leggi fondamentali della costituzione. Qualsiasi nuova legge viene esaminata ed essa deve essere allineata alle norme della costituzione altrimenti viene eliminata. Quindi nel charter noi andiamo a coagulare i tratti salienti del nostro progetto, i tratti caratteristici. Quelli tali per cui se devono essere revisionati o cambiati vuol dire che cambia il progetto. Nel charter ci sono i plinti, le colonne portanti del progetto. Il Charter è dunque un documento fondamentale da cui partire per lavorare: ci dice che cosa vogliamo fare. Esso quindi deve essere sufficientemente chiaro e allo stesso tempo ad alto livello. Non può entrare nei dettagli del progetto. Per il P.M. è uno strumento fondamentale in quanto rappresenta un po’ il suo mandato. Nella pratica il charter può chiamarsi in diversi modi: contratto, ecc. Nel momento in cui il charter è promulgato ecco che lì dentro c’è scritto chi deve fare il progetto e da lì il progetto parte. Nel charter è nominato il P.M.
  • 16. Questo ci lascia pensare che non è il P.M. che fa il charter e tantomeno lo firma. Il P.M. riceve il charter e quindi può solo firmarlo per accettazione. Il charter viene fuori dallo Sponsor ma nella realtà il PMBOK cela il fatto che quella figura che poi si chiamerà P.M. in realtà fa anche il charter, ma l’importante è che lo faccia poi firmare allo Sponsor. Il P.M. in genere, si fa’ il Charter altrimenti non sa cosa fare del progetto. La presenza di alcuni vincoli presenti sul Charter (tempi, costi, obiettivi) in realtà agevola il P.M. Si stabiliscono quali sono i suoi confini operativi. Il PMBOK raccomanda anche la partecipazione del P.M. alla stesura del charter. Il charter dovrà essere firmata da una figura organizzativamente elevata che può essere lo sponsor, il comitato, ecc. e chiunque ha l’autorità di decidere. Ovvero proviene da chi ha un bisogno. Il charter ci dice anche il perché si deve fare quel progetto. Esso nasce dal capitolato del progetto che è sostanzialmente una base del charter che poi si va ad affinare per completare il vero e proprio charter. Un’altra fonte del charter è il Business Case, una valutazione costi/benefici: ossia la ragione del perché fare il progetto attraverso una equazione del tipo Benefici > Costi + Rischi Un B.C. deve concentrarsi sui costi/benefici e quindi andare anche a capire come mai si fa questo progetto ed a che cosa può portare. Un progetto può nascere da un bisogno in generale: da un aggiornamento normativo, da una richiesta di mercato, da un cambiamento organizzativo, da una richiesta di un cliente preciso, da un’evoluzione tecnologica, da esigenze sociali, ecc. Il B.C. è un impegno per il P.M. in quanto lì c’è scritto di fatto quanto beneficio deve portare rispetto al costo che genera il progetto e su quello il P.M. verrà sfidato. A monte del charter ci possono essere dei contratti accordi di varia natura formali ed informali, dei livelli di servizio, ecc. Inoltre fra gli input che ci servono per poter costruire il P.C. ci sono due variabili collettive, di gruppo importanti:
  • 17. a) Fattore ambientali ed aziendali che potrebbero potenzialmente influire sul successo della creazione del P. Charter FATTORI AMBIENTALI Interni Esterni • Cultura aziendale • Struttura organizzativa • Infrastrutture • Direttive e procedure standard di P. Management • Documentazione standard di P. Management • Disponibilità di risorse umane di insieme nel progetto • Presenza di P. Management Information System • Presenza di database su precedenti progetti con dati relativi ai rischi, costi, tempi, ecc. • Condizioni di mercato • Standard governativi o di settore • Limiti di tolleranza al rischio degli stakeholder b) Asset dei processi organizzativi: posseduti dalla propria organizzazione diverranno fondamentali nel favorire il successo (o l’insuccesso) del progetto. Gli Asset possono riferirsi all’insieme di criteri, procedure, piani o direttive, sia formali che informali, presenti in un’organizzazione, ma soprattutto alle esperienze pregresse divenute conoscenza esplicita (ad es. tempificazione delle attività, schedulazione completate, dati sui rischi, dati sugli Earned Value, ecc.) e contenuti nel Project Knowledge Base aziendale.
  • 18. ASSET DEI PROCESSI ORGANIZZATIVI SUL PROJECT MANAGEMENT Direttive e procedure standard Project Knowledge Base • Criteri di valutazione dei progetti • Schematizzazioni di documenti (ad es. WBS, PERT, Rischi) • Direttive e procedure di qualità • Procedure di assegnazione delle risorse • Procedure di controllo finanziario • Procedure di gestione delle criticità nell’esecuzione • Procedure e tecnologie per la comunicazione • Procedure di valutazione e controllo dei rischi • Procedure di monitoraggio, controllo e approvazione delle modifiche di progetto • Criteri di misurazione delle prestazioni • Direttive e procedure di chiusura del progetto • Database sulle direttive e procedure standard • Database su cicli di vita standard di prodotti e progetti • Database su tempi standard delle attività di progetto e schedulazione completate • Database finanziario su budget e costi in progetti pregressi • Database sui livelli qualitativi standard • Database delle misurazioni dei processi di Project Management • Database dei rischi di progetto • Database delle Lesson Learned Tali variabili raggruppano una serie di fattori che vanno ad influenzare la modalità con la quale noi scriviamo il charter. Il fattore ambientale ed aziendale è un fattore di tipo generale: la cultura aziendale, la normativa di alto livello, ecc. Gli Asset dei processi organizzativi sono Asset (beni, patrimoni): beni strutturati della mia azienda, processi procedure, data base, informazioni proprietarie, ecc.
  • 19. E’ chiaro allora che nel definire l’impianto del progetto, la sua carta di identità, devo tener presente di questi aspetti. Non è la stessa cosa costruire un palazzo di 6 piani a Milano ovvero a Caserta ovvero a Roma. Potrei fotocopiare il progetto ma il progetto è diverso in quanto i fattori ambientali sono diversi così come gli Asset aziendali. Tra gli strumenti e tecniche c’è uno strumento che c’è sempre: l’esperienza. Il progetto vuol dire qualcosa di proiettare nel futuro che sicuramente noi non conosciamo. Come faccio a capire il futuro allora? Ci provo sulla base del passato. Allora l’esperienza è quella struttura che mi permette di provare ad immaginare cosa potrebbe succedere. L’esperienza viene espressa dal PMBOK sotto la voce “parere degli esperti” cioè è un fattore condiviso da parte di altre persone che mirano a dare le migliori informazioni possibili, i migliori dati possibili per poter provare a ragionare su cosa succederà. (Fare attenzione in quanto il parere degli esperti non è esplicitato in tutti i processi del PMBOK.) In alcuni casi nel PMBOK, per alcuni processi non esiste proprio l’utilizzo del “parere degli esperti”. Altro strumento che il BOK ci suggerisce per lavorare sulla costruzione del charter sono le cosiddette “Tecniche di facilitazione”. Nell’andare a cogliere le informazioni per un B.C. dobbiamo andare a stuzzicare le persone a farli esprimere: Brainstorming, la gestione dei conflitti, ecc. Quindi sviluppare il project charter ha come output il project charter che autorizza il P.M. ad agire. Il contenuto di un project charter è variabile ed il PMBOK ne elenca alcuni. (vedi di seguito). Questo è dunque il documento che pone le fondamenta del progetto, tale per cui se cambia qualcosa nel documento vuol dire che cambia il progetto. Questo è il primo dei grandi processi. Il Project Charter è un Input al processo “Definire l’Ambito del progetto”.
  • 20. DI SEGUITO VIENE PROPOSTO UN TEMPLATE DI PROJECT CHARTER
  • 21. 1. CODICE Titolo Descrizione breve Programma Cliente Referente Sponsor Referente Senior Executive Referente Descrizione del progetto Giustificazione del progetto Obiettivi di progetto (SMART) Ambito Tempi Costi Qualità Altri Deliverable Requisiti (High-level) Milestone Data attesa
  • 22. Rischi di alto livello Minacce Opportunità Funzioni coinvolte Tipo di partecipazione Budget complessivo Criteri di valutazione del successo del progetto Project Manager Nome Cognome Funzione Responsabilità Livello di autorità Descrizione Documento Il Project Charter è il documento che ufficializza un nuovo progetto. Viene anche detto scheda progetto e può assumere aspetti e informazioni varie. Una volta che un’iniziativa è stata valutata ed analizzata, l’iniziativa (l’idea) diviene progetto una volta che viene ufficializzata attraverso il Project Charter che rende pubblica, a livello aziendale, la decisione presa. In alcuni casi, il Project Charter può contemplare al proprio interno altre informazioni di progetto, quali un piano di massima, il budget assegnato, indicazioni sul Team di progetto (il così detto Core Team – team che
  • 23. lavora sin da subito a stretto contatto con il project manager) e il collegamento ad altri documenti allegati (il riferimento ad un contratto, un business case o ad un capitolato tecnico). Note per la compilazione Argomento Spiegazione
  • 24. 2. CODICE Codice univoco alfanumerico identificativo del progetto. Tutti i documenti che verranno creati successivamente avranno questo codice. Questo può essere formulato considerando o la sequenza dei progetti passati oppure secondo le regole dell’organizzazione o della funzione che sponsorizza il progetto Titolo Titolo del progetto Descrizione breve Breve descrizione del progetto Programma Campo da compilare solo nel caso in cui il progetto faccia parte di un programma Cliente Persona/organizzazione (interno o esterno) che usufruirà del prodotto/servizio finale del progetto Sponsor Persona/organizzazione (interno o esterno) che provvederà alle risorse finanziarie per il progetto Senior Executive Persona/organizzazione che ha facoltà di ufficializzare il progetto Descrizione del progetto In questa sezione viene dato ampio spazio ad una descrizione del progetto. Possono essere allegati anche un contratto od un capitolato tecnico Giustificazione del progetto Il Project Charter da una risposta alla domanda sul perché l’organizzazione abbia scelto proprio quell’iniziativa e non un’altra, dandone ampia spiegazione attraverso un business case. Si ricordi che un progetto può partire per: - una domanda di mercato - un bisogno dell’organizzazione - una richiesta di un cliente - un progresso tecnologico - un requisito di legge - un bisogno sociale Obiettivi di progetto (SMART) Qualsiasi progetto che inizi senza obiettivi chiari ha alte probabilità di insuccesso. L’acronimo SMART sta per: - Specifico (Specified) - Misurabile (Misurable) - Raggiungibile (Achievable) - Realistico (Realistic) - Raggiungibile entro un lasso di tempo (Time-Phased) In questa sezione, verranno elencati chiari obiettivi di progetto. Si ricordi che l’obiettivo di un progetto non è solo relegabile al prodotto/servizio atteso, ma devono essere considerati anche altri obiettivi che rappresentano specifiche aspettative da parte di tutti stakeholder che sono coinvolti nel progetto. Obiettivi di budget, obiettivi temporali, obiettivi qualitativi sono tutti elementi importanti sui quali verranno
  • 25. valutate le performance del progetto e le capacità del project manager. Naturalmente è inutile sottolineare che questi obiettivi, nel caso in cui il progetto fosse particolarmente complesso, a volte sono contrastanti tra di loro e deve essere fatta opera di armonizzazione considerando diversi aspetti e diversi attori, e relative aspettative. Si considerino, per esempio, le aspettative del cliente, quelle dello sponsor o quelle dei responsabili di funzione, aspettative molte volte in contrasto tra di loro Deliverable e Requisiti (High-level) Il deliverable (si ricordi che to deliver significa consegnare) rappresenta il prodotto/risultato verificabile che deve essere prodotto secondo le esigenze/requisiti/specifiche del cliente. Il deliverable può essere sia di natura tecnica (una galleria, un ponte, un miglioramento di un servizio, etc..) ma anche gestionale (un verbale di un meeting, il piano di Project Management, il piano della qualità, etc..). Questa sezione elenca in maniera generale i deliverable ed i relativi requisiti che ci si attende dal progetto Milestone La milestone rappresenta un evento topico del progetto ed è collegata ad una data ben precisa. A questo livello, la milestone può rappresentare la data di inizio del progetto, la data di fine o date imposte dal cliente o dal contratto Risk (high level) In questa sezione viene richiesto a chi compila il documento di elencare ad alto livello quelli che potrebbero essere minacce od opportunità collegate al progetto. Sarà compito del project manager, o ad un membro incaricato del team, di approfondire successivamente la tematica Funzioni coinvolte e tipo partecipazione Le informazioni contenute in questa sezione offrono sia allo sponsor che al project manager una visione prospettica della complessità del progetto. Maggiore sarà il numero di funzioni coinvolte e maggiore sarà la complessità del progetto in termini di integrazione dei singoli apporti specialistici. Ogni funzione aziendale ha una propria competenza tecnica ed un proprio linguaggio. Più il progetto sarà trasversale all’organizzazione e maggiore sarà l’impegno del project manager in termini di integrazione e comunicazione Budget complessivo Stima di alto livello del budget complessivo del progetto. Può coincidere con il prezzo spuntato sul cliente (al netto dell’utile) Criteri di valutazione del successo del progetto In questa sezione vengono descritti i criteri per poter valutare, secondo delle regole, il successo o l’insuccesso del progetto. I criteri sono collegati ad obiettivi misurabili. Se gli obiettivi risultano misurabili si possono definire le regole per una corretta misurazione impostando opportuni criteri Project Manager In questa sezione viene indicato: - il nome del project manager assegnato, nonché la funzione di appartenenza
  • 26. - il suo livello di responsabilità (responsabilità nella pianificazione, esecuzione e chiusura del progetto, responsabilità nel raggiungimento degli obiettivi prefissati) - il suo livello di autorità (cosa può fare e cosa il project manager non può fare, es: acquisizione di risorse, gestione del budget, gestione dei fornitori, possibilità di erogare premi e riconoscimenti al team, etc…) Riferimenti PMBOK® Guide PMBOK® Guide Versione Inglese Italiano Nome del documento Project Charter Project Charter Processo che lo crea 4.1 Develop Project Charter 4.1 Sviluppare il Project Charter Gruppo di processi Initiating Concezione/ Avvio Area di Conoscenza Project Integration Management Gestione dell’Integrazione di Progetto Processi che lo usano in input 4.2 Develop Project Management Plan 5.1 Collect Requirements 5.2 Define Scope 10.1 Identify Stakeholders 4.2 Sviluppare il piano di Project Management 5.1 Raccogliere i requisiti 5.2 Definire l’ambito 10.1 Identificare gli stakeholder Regole Dovrebbe essere emesso da un manager esterno al progetto che ricopra un livello gerarchico appropriato, od emesso secondo le regole dell’organizzazione. Il presente documento fornisce al project manager l’autorità e la responsabilità necessaria per utilizzare le risorse dell’organizzazione per le attività del progetto. Altre Fonti Kerzner: Secondo Kerzner, il Project Charter è il documento che attribuisce la responsabilità di gestione del progetto al project manager; in origine, infatti, il Project Charter rappresentava il documento che conferiva l’autorità di governo del progetto al project manager ed aveva, essenzialmente, una riconosciuta validità formale esclusivamente all’interno dell’organizzazione. In forme rappresentative estremamente sintetiche, il Project Charter si può tradurre in una semplice lettera di attribuzione di incarico al project
  • 27. manager, da parte dello Sponsor di progetto: si parla infatti di Legal Agreement tra il project manager e l’azienda che commissiona il progetto. In alcuni contesti applicativi, Il contenuto informativo del Project Charter viene di solito esteso a comprendere i seguenti elementi: • Obiettivi specifici di progetto • Descrizione delle condizioni al contorno del progetto • Vincoli su tempi, costi, risorse e qualità • Requisiti/Aspettative del committente • Requisiti/Aspettative del cliente • Valori di budget e modalità di assorbimento delle risorse finanziare nel tempo • WBS di progetto • Impegni di risorsa • L’organizzazione di progetto e relative interrelazioni tra le varie Unità Funzionali • Matrice di responsabilità • Politiche di progetto e metodologia di gestione e controllo adottate • Piano dei rischi • Piano di gestione dei cambiamenti • Descrizione delle modalità di approvazione da parte del Management per le voci sopra descritte In teoria è lo Sponsor a preparare il Project Charter apportando la propria firma: in realtà potrebbe anche essere il project manager a redigere il documento da presentare allo Sponsor per l’approvazione. Si ricordi che se il progetto è suddiviso in fasi, il project manager potrebbe richiedere un project charter all’apertura di ciascuna fase.
  • 28. Project Charter Business Case Requirements Documentation Sebbene all’interno del Project Charter vengano identificati i principali stakeholder (tra cui il project manager, il project sponsor e il cliente), la prima azione che il project manager dovrà compiere sarà quella di individuarli tutti formalizzando un documento Requirements Traceability Matrix Stakeholder Register Il Business Case fornisce l’inquadramento generale, i bisogni e le necessità, i presupposti e gli obiettivi dell’iniziativa che, una volta ufficializzata, diventerà progetto Project Scope Statement Project Management Plan Il project charter interviene nella definizione dei requisiti di alto livello del progetto. Sarà poi compito del project manager e del team di progetto approfondire l’analisi dei requisiti in maniera più analitica. I documenti contenuti nel Proejct Management Plan, fomalizzano i requisiti, le relative esigenze di tracciabilità, costituendo la fonte di importanti informazioni per una corretta definizione dell’ambito progettuale NODO: PM 01 TITOLO: PROJECT CHARTER N.: ver 1.0
  • 29. Mappatura template Project Charter Initiating Planning Executing Monitoring & Controlling Closing 4.1 Develop Project Charter Project Charter 4.2 Develop Project management Plan 5.2 Define Scope
  • 30. Esempio Viene di seguito illustrato un esempio pratico di utilizzo del Project Charter, riprendendo lo schema proposto nel presente documento. Si tratta di un progetto di Information Technology riguardante l’implementazione prototipale di una struttura Client-Server per il monitoraggio dei progetti aziendali. Il contesto in cui si ipotizza lo svolgimento del progetto prevede le seguenti caratteristiche: • Il progetto, fortemente voluto dall’amministratore delegato, rientra nel programma strategico per l’implementazione di un sistema di Project Management, che sarà realizzato attraverso i seguenti progetti: o Una struttura informatizzata (il progetto di esempio) o Percorsi di formazione o Training on the job o Rivisitazione dei processi di Project Management aziendale • Si tratta di un progetto interno; • Non esiste un contratto per il progetto; • La complessità del progetto è ritenuta elevata; • Il richiedente interno coincide con il committente; • L’autore del Project Charter è il project manager
  • 31. 3. CODICE IT-01-2010 Titolo Progettazione e realizzazione di una infrastruttura Client- Server per il monitoraggio dei progetti aziendali Descrizione breve Il progetto prevede l’introduzione di un servizio informatizzato Client-Server per migliorare sia la pianificazione che il monitoraggio di tutti i progetti dell’azienda. L’implementazione prevederà inizialmente l’inserimento nella struttura dei soli progetti strategici per poi allargarla anche a tutti gli altri Programma Il progetto si inserisce nel programma strategico XYZ Cliente Azienda ABC Referente Amministratore delegato Sponsor Funzione IT Referente Mario Rossi Senior Executive Funzione strategica Referente Luigi Verdi Descrizione del progetto Il progetto prevede l’introduzione di un servizio informatizzato Client-Server per migliorare sia la pianificazione che il monitoraggio di tutti i progetti dell’azienda. L’implementazione prevederà inizialmente l’inserimento nella struttura dei soli progetti strategici per poi allargarla anche a tutti gli altri Giustificazione del progetto L’iniziativa, fortemente voluta dall’amministratore delegato, viene giustificata in termini di nuove esigenze e nuovi bisogni aziendali al fine di migliorare la comunicazione, la pianificazione ed il monitoraggio dei progetti (Vedi allegato n.1 Business Case) Obiettivi di progetto (SMART) Ambito Infrastruttura Client-Server Elenco progetti strategici per prototipo Manuale utente/amministratore Formazione personale sull’applicazione Tempi Inizio progetto il …. Fine progetto il ….. Costi per il progetto sono stati stanziati € ….
  • 32. Qualità Obiettivi di qualità del sistema informatico - Documento di sicurezza ISO … - Trattamento dati secondo normativa aziendale ABC - Comunicazione dati secondo normativa …. Altri Piano di Project Management - WBS - Piano di comunicazione - Piano di approvvigionamento - Piano di qualità - Gant - Stima delle risorse - Curva di Budget Deliverable Requisiti (High-level) Piano di Project Management secondo standard internazionale PMI Infrastruttura client /server standard ICT aziendale ABC Elenco progetti strategici secondo regole organizzative Formazione personale requisiti di formazione secondo procedura XYZ Milestone Data attesa Inizio progetto Entro il …… Approvazione PMP Entro il …. Collaudo struttura Non oltre il ….. Fine progetto Entro il ….. Rischi di alto livello Minacce Le informazioni per i progetti pilota potrebbero essere obsolete ed incomplete Il nuovo sistema potrebbe essere incompatibile con la struttura esistente I project manager coinvolti potrebbero non avere conoscenze di project management Opportunità Alcuni server potrebbero essere dismessi ed essere riutilizzati per l’installazione dell’applicazione La gestione centralizzata dei progetti consentirebbe un migliore monitoraggio e governance sugli stessi ………… Funzioni coinvolte Tipo di partecipazione Funzione Strategica Sponsorizzazione del progetto
  • 33. Funzione ICT Responsabile del delivery infrastrutturale e delle attività di Project Management Funzione Acquisti Responsabile dell’approvvigionamento Budget complessivo Il budget complessivo per il progetto è di € ….. Criteri di valutazione del successo del progetto La valutazione del progetto seguirà i seguenti criteri: - raggiungimento obiettivi di ambito: 40% - raggiungimento obiettivi di qualità: 20% - raggiungimento obiettivi di tempo: 20% - raggiungimento obiettivo di costo: 5% - raggiungimento obiettivi di PM: 15% Project Manager Nome Cognome Nome Project Manager assegnato: Franco Neri Funzione Funzione ICT Responsabilità responsabile della pianificazione, controllo e chiusura del progetto. Responsabile del raggiungimento degli obiettivi di Project Management, di tempo, di budget e di qualità Livello di autorità Il Project Manager potrà disporre del budget allocato sul progetto e delle risorse che ne saranno coinvolte
  • 35. (Esempio azienda SUPARTS per creare esempio di business case e project charter) Nel progetto di esempio il nostro cliente è la Suparts nell’ottica di chi ha un bisogno, mentre lo sponsor può essere il titolare dell’agenzia di viaggi, anche se potrebbe essere in realtà un commerciale dell’azienda Suparts che ha deciso di portare avanti un iniziativa per risolvere determinati problemi. In tali casi occorre capire bene chi è il cliente e chi è lo sponsor. Immaginiamo che noi siamo l’agenzia; il nostro cliente (la Suparts) ci esprime i suoi bisogni, le sue esigenze cioè quelle di come portare le persone sul sito (un albergo dell’alta Italia) e farle incontrare. Dal cliente dobbiamo sapere con precisione come ci dobbiamo comportare nel senso che per risolvere il litigio tra tecnici e commerciale dell’azienda, il cliente si aspetta un trattamento particolare. Quindi porre molta attenzione alle richieste del cliente.
  • 36. Il prodotto consiste in una serie di trasporti: aerei, pullman, treni; il tutto nei tempi giusti al fine di farli arrivare in loco in condizioni ottimali psico-fisiche. Ci si deve preoccupare anche della loro sistemazione, delle esigenze alimentare. Le specifiche del prodotto vanno grosso modo disegnate anche se non nei particolari. Come agenzia di viaggi mi chiedo inizialmente se vale la pena affrontare tale progetto. La domanda può essere: voglio guadagnarci? La mia strategia è quella di ottenere il massimo di redditività? oppure quello di ottenere la giusta reddittività ma probabilmente è una conseguente dovuta al fatto che magari mi specializzo in tali contesti internazionali e quindi tale esperienza potrebbe fare da referente per il futuro? Voglio entrare in un certo mercato di organizzazione di tali eventi? Queste sono tutte le strategie. Relativamente ai costi benefici la domanda può essere: quant’è il guadagno che mi aspetto cioè quali sono, nell’ambito di tale progetto, i costi ed i benefici che riesco a sopportare ed a supportare. Questa iniziativa che sto intraprendendo come contribuisce alla mia strategia o alla mia mission? Vado quindi a fare un analisi costi/benefici. Può succedere che magari tali risultati incidono in maniera secondaria (cioè non danno molta importanza alla mia azienda) sulla mia strategia, ma se incide in maniera secondaria ed inoltre i costi sono anche significativi allora non mi conviene affrontare tale progetto. Nel business case occorre vedere quali sono i fattori ambientali e aziendali che possono incidere e che quindi devo considerare nel nostro progetto. Cioè capire come la Suparts tratta in genere i suoi clienti, se li tratta bene o in maniera spartana. Queste indicazioni dettate dal cliente ci servono per misurare il tiro del benessere che dobbiamo infondere alle persone che vanno in albergo. Quindi l’agenzia intelligente deve “indagare” sulle condizioni aziendali (fattori ambientali e aziendali). Curare le persone anche dal punto di vista alimentare, religioso in considerazione del fatto che le persone vengono da tutto il mondo e che quindi hanno abitudini differenti. All’inizio occorre concentrarsi sul Bisogno. Quando il cliente viene a parlarci, di solito non parla del suo bisogno bensì pensa di esprimere già la soluzione che ha in mente. Dobbiamo essere noi a riportarlo indietro semplicemente con la tecnica della comunicazione e cioè chiedendo semplicemente il perché vuole intraprendere tale obiettivo o il suo bisogno.
  • 37. Gli americani hanno studiato che 5 livelli di “perché” ci portano a determinare le cause originarie. A questo punto volendo seguire il BOK dobbiamo prendere questa sorgente e elaborarla attraverso degli strumenti per elaborare il charter. Strumenti che sono: l’esperienza (da condividere). Impariamo dagli errori degli altri. E poi le cosiddette “tecniche di facilitazione” perché sono quelle che si dovrebbero mettere in atto per aiutare il cliente a parlare del suo bisogno, per aiutarlo a tirar fuori il meglio delle informazioni di input. Una tecnica può essere il Brainstorming (tempesta cerebrale). E’ una tecnica potente e rigorosa ma un po’ bistrattata. E’ comunque un modo per avere idee. Sulle idee in genere si hanno due atteggiamenti: una cosa averla e una cosa è usarle. Ma in realtà non facciamo mai tale distinzione. Assimiliamo sempre tali due aspetti. Abbiamo sempre la tendenza ad unire questi due “momenti”: cioè nel momento in cui sorge l’idea ne andiamo subito a cercare l’utilità. In certi momenti e soprattutto nei momenti di creatività è così importante AVERE le idee mentre il fatto di giudicare e usarle subito non ci aiuta ad essere creativi. Il brainstorming è una tecnica o una modalità di riunione che serve a separare questi due momenti. Pertanto la cosa non è così facile. Per avere idee non serve l’intelligenza, la cultura ed esperienza, la conoscenza o la logica. Ci possono essere persone stupidissime che hanno delle idee magari anche stupide. L’esperienza in una data materia (nel senso di rigore) in genere è un freno alla creatività. Il brainstorming è sostanzialmente una tecnica strutturata, un processo, per AVERE le idee. Poi vedremo come usarle, e se usarle. E’ una tecnica che è nata da oltre un secolo da un tecnico statunitense convinto della validità dell’approccio creativo, ispirandosi ad una tecnica Hindu. Esso applica tale tecnica soprattutto quando si hanno delle idee nuove che in genere vengono bistrattate. Per fare questo identifica 4 regole: a) Le idee non si valutano. Nessuno può criticare le idee degli altri, neanche mentalmente; tali idee non devo usarle ma solo Averle. b) Si va a “ruota libera”. Non ci devono essere freni, inibizioni, in quanto farebbero tutte parte della critica. c) La quantità è molto significativa: dopo le selezionerò.
  • 38. d) Usare gli altri: devo usare le idee degli altri o per aggiunta o per contrasto o per miglioramenti. L’enfasi va messa su tutto quello che viene fuori, non aspettare che ci sia la cosa fondamentale perché già questo è un giudizio, rimanendo concentrati su quello che si sta facendo, senza distrarsi con problemi che non c’entrano niente con il progetto di base. Occorre prestare attenzione a tutto quello che ci sta intorno, proprio perché bisogna agganciarsi, ampliarsi, moltiplicare e cercando in tutti i modi di tirare fuori tante idee senza preoccuparsi della qualità. Questo è lo spirito del brainstorming. Se dobbiamo essere innovativi purtroppo occorre cambiare i paradigmi e i presupposti su cui ragioniamo. Fino a che rimaniamo ingabbiati nei nostri schemi mentali non saremo mai innovativi. Queste tecniche ci danno la libertà, in un contesto controllato, di uscire da queste gabbie e da questi schemi. Ci aiutano moltissimo le gabbie mentali perché fanno parte della nostra abitudine che è un grande vantaggio: questo vuol dire non pensare tutte le volte a quello che devo fare!!! Se ad es. per ogni passo che faccio dovessi concentrarmi su tutti i muscoli che muovo, ecc. sarebbe impossibile vivere. In realtà è una cosa che mi viene in automatico camminare senza pensare al resto del corpo. Quindi ben vengano le abitudini. Ma in termini di innovazione devo scardinare un po’ queste cose ed allora devo trovare un contesto che mi aiuta a fare questo. Relativamente allo Skill del P.M. e soprattutto in determinati momenti del ciclo di vita di un progetto, inoltre, quando assume una fondamentale importanza la ricerca della soluzione più efficace, un P.M. deve anche essere capace di ricorrere alla propria creatività. Deve essere in grado, cioè, di individuare differenti ipotesi di soluzione anche svincolandosi dalla cosiddetta “logica comune”, di per se stessa scontata e prevedibile, e ricorrere a quello che la moderna psicologia definisce “pensiero alterale” (o divergente) che consiste nel procedere alla ricerca della soluzione ottimale interconnettendo idee, spunti, concetti, tra loro anche molto distanti, senza lasciarsi imbrigliare in schemi mentali precostituiti (e, proprio per questo, condizionanti), derivanti, di solito, dal proprio bagaglio culturale.
  • 39. Il pensiero operazionale, quello del fare le cose, è il ciclo “Plan-Do-Check-Act” o ruota di Deming (ideato da SHEWART) – visto nelle prime lezioni. Le idee le organizzo, agisco, valuto, miglioro. Però quando c’è innovazione o quando c’è crisi ho bisogno di uscire da questo schema. Ed allora devo usare la modalità del pensiero creativo che è quello di esplorare, scoprire, di sviluppare idee e validarle. In tale senso Hosborn individua che il percorso del pensiero viene sviluppato sostanzialmente in due fasi: 1) Facciamo esperienza di qualcosa, percepiamo qualcosa e questa genera l’idea; per cui dal confrontarsi con qualcosa nascono le idee alle quali riusciamo ad attribuirle un nome, riusciamo ad esprimerle. 2) Poi c’è un passaggio che passa attraverso il linguaggio che diventa giudizio, opinione, e quindi li integriamo dei paradigmi, dei concetti di utilità ed integriamo una valutazione. Dunque il brainstorming è un viaggio di scoperta senza mappe, senza orientamenti e senza punti di riferimento, completamento libero, anarchico, che poi però deve convergere verso una soluzione. In tale situazione le soluzioni sono variabili: “1 + 1 può fare anche più di 2”, perché nascono cose man mano che escono. Ecco perché bisogna appoggiarsi agli altri, sfruttare quello che succede, ecc.
  • 40. Quando non fare il Brainstorming? Quando abbiamo problemi operativi: se un aereo sta precipitando non si può fare certo un brainstorming. Occorre subito trovare la soluzione. Se abbiamo un piano da seguire dobbiamo fare le cose giuste e subito. In tali casi occorre fare attenzione al gruppo. Ci vanno le persone giuste. I giochi hanno regole ferree. Ci vuole un buon facilitatore. Quindi il brainstorming tradizionale si può usare quando abbiamo bisogno di idee nuove, quando abbiamo bisogno di trovare qualcosa che pensando ad una maniera tradizionale non funzionerebbe. A questo punto facciamo un passo successivo, cioè individuiamo quale può essere la soluzione, magari in un primo passaggio dire semplicemente se quell’idea ci sembra negativa – positiva o interessante. In una seconda fase, quella dell’utilità, è che queste posizioni vanno giustificate. Cioè tutti quelli che hanno partecipato al brainstorming valutano le idee, spiegano le cose. E questo rappresenta un arricchimento per tutti. A fronte di questo poi bisogna sempre valutare un pochino quelle che sono le situazioni del contesto: in particolare lo sponsor. Cioè ad es. questa data soluzione è ottima però rischia di disturbare qualche stakeolder ed allora non è il caso di portarlo avanti. A questo punto una volta fatte le valutazioni si decide come lavorarci sopra e quindi si vedrà cosa occorrerà fare. Il brainstorming lo utilizziamo per arrivare a scrivere il project charter. A questo punto proviamo a costruire il Project charter della nostra azienda esempio (Suparts). Nel charter occorre essere più definiti possibili ma ad alto livello. Non si può scendere nei particolari ma occorre che grosso modo ci sia tutto. Inserire anche un criterio di successo del progetto e che sia anche misurabile. Ad es. il 10% dei clienti non si è trovato bene. Questo può rappresentare un elemento misurabile di successo. A livello di charter ci possono essere delle milestone del tipo: posso fare questa operazione ma tu cliente mi devi affidare l’incarico almeno tre mesi prima; oppure 20 giorni dopo l’ordine ci riuniamo insieme per presentare come vogliamo svolgere il progetto; oppure i dati fondamentali dei partecipanti li devo avere entro una certa data altrimenti non riesco a fare i biglietti.
  • 41. Per quanto riguarda gli stakeolder occorre tener presente in questo caso di esempio, che sicuramente avrò bisogno di una interfaccia della Suparts, ho bisogno di sapere chi è il P.M. della Suparts per colloquiarci. Il charter può avere vari livelli di definizioni. Possiamo trovare charter molto definiti in quanto alla base c’è un contratto molto dettagliato, altri estremamente più vaghi, per cui il charter determina anche lo stile del P.M. ovvero il modo di operare. Tutti i presupposti, gli assunti e i vincoli vengono descritti nel P. charter, esso ci deve dare le linee guida fondamentali rispetto alla scelta della soluzione che noi adottiamo. Ma cosa sono gli assunti e vincoli. Gli assunti, tra i requisiti in input, sono quelle cose che diamo per scontato e di cui noi non possiamo farne a meno. Tutti i presupposti significativi gli evidenziamo, gli accettiamo e nell’accettarli li trasformiamo in rischi. Per es. un progetto in Giappone comporta un assunto che può essere quello di avere un terremoto: questo è un assunto, lo diamo per scontato. Ma tale situazione lo dobbiamo trasformare in rischio che poi dobbiamo gestire. I vincoli invece sono delle cose che tipicamente interpretiamo come delle limitazioni di libertà. Esistono vincoli di qualità, di tecnologia, di persone, di tempo, di costo, ecc. L’assenza di vincoli tuttavia non comporta una forma di libertà. Tipicamente il vincolo va interpretato non come un muro o una prigione bensì come una ringhiera che ci evita di finire nel baratro. Lavorare in assenza di vicoli all’interno di un progetto, inevitabilmente le cose si disperdono e non si arriva alla soluzione. I vincoli sono un punto di appoggio. I vincoli vanno imposti necessariamente. I vincoli stimolano anche la creatività, qualche innovazione. Ad es. la poesia rappresenta una forma di vincolo per eccellenza: imparare a memoria le rime, ecc. avendo anche determinate lettere per ogni riga, ecc. Quindi raggiunto il charter si passa al processo successivo, ma non necessariamente in ordine cronologico. VEDIAMO UN ESEMPIO DI BUSINESS CASE
  • 42. 4. CODICE INIZIATIVA 4.1 Titolo Iniziativa Descrizione Iniziativa Richiedente / Ideatore Iniziativa Referente Redattore del Business Case Referente Impulso scatenante * Domanda di mercato Bisogno interno dell’organizzazione Richiesta di cliente esterno Progresso tecnologico Requisito di legge Impatto ecologico Bisogni sociali * Inserire un segno di spunta per l’impulso o gli impulsi scatenanti il progetto Descrizione impulsi Descrizione opportunità Stima dimensioni del mercato Analisi dei Concorrenti Descrizione del risultato
  • 43. Benefici attesi Analisi economico/finanziaria Allineamento Strategico Priorità * Specificare valore da 1 a 5 Iniziativa approvata Iniziativa non approvata * Inserire il segno di spunta e firma Descrizione Documento Il business case è quel documento che tenta di rispondere alla questione se convenga o meno imbarcarsi in una specifica attività commerciale o di business. Non si tratta solo di comprendere, in termini economici, l’ammontare dell’impegno che un’azienda dovrebbe sostenere per sponsorizzare un’iniziativa ma capire anche il valore dei benefici attesi e l’arco temporale durante il quale quell’impegno economico ed umano potrebbe essere richiesto e, quindi, sostenuto. La complessità del business case è strettamente correlata agli elementi che si vogliono considerare ed analizzare. Tralasciando per un momento il solo parametro economico, comun denominatore e chiave di lettura, l’azienda deve poter valutare, e quindi valorizzare, l’impegno in termini di risorse umane, materiali, subforniture, forniture, rischi, progresso tecnologico e tanti altri elementi. Pertanto, all’aumentare dei parametri, la complessità ed il rischio di commettere errori di valutazione aumenta in maniera proporzionale. Il business case può fare riferimento anche a documenti nei quali si evincono le stime di distribuzione temporale prevista dei costi e dei ricavi.
  • 44. Nell’analisi della fattibilità economica di un progetto è infatti essenziale tenere conto della diversa distribuzione temporale dei costi, che sono tutti concentrati nella fase di realizzazione del progetto, rispetto ai benefici, che saranno disponibili solo dopo il rilascio in produzione del prodotto o servizio. I costi da considerare potrebbero essere: • i costi di progettazione, realizzazione ed avviamento dei prodotti finali del progetto: costi di risorse umane e costi di apparecchiature tecnologiche; • i costi di esercizio dopo la partenza operativa del nuovo sistema di processi, costi di risorse umane, costi di manutenzione e costi di utilizzo di componenti infrastrutturali. I benefici economici da considerare sono gli eventuali maggiori ricavi e gli eventuali minori costi derivanti da valutazione di maggiori efficienze, nonché minori costi derivanti da disattivazione di sistemi e processi attuali che potranno essere dismessi in quanto sostituiti. Per tener conto della diversa distribuzione dei costi rispetto a quella dei ricavi, tutti i flussi dovranno essere attualizzati al fine di renderli confrontabili. L’analisi dei flussi finanziari attualizzati dovrà evidenziare il “punto di pareggio economico” (Break Even Point), cioè il momento nel tempo in cui la curva dei ricavi incrocia la curva dei costi, e quindi il punto in cui il valore complessivo dei ricavi stimati pareggia i costi. Di norma, il progetto sarà considerato “a valore aggiunto” per l’organizzazione se il punto di pareggio economico risulterà anteriore al tempo previsto di vita utile del prodotto. Ovviamente, questo tempo potrà essere molto diverso a seconda della tipologia di prodotto interessata e potrà andare da pochi mesi o anni (come ad esempio per una campagna promozionale o un nuovo prodotto), fino anche ad alcuni decenni (come per un nuovo impianto, una nuova sede o un’opera pubblica). Note per la compilazione Argomento Spiegazione
  • 45. 5. CODICE INIZIATIVA Codice univoco alfanumerico. Tutti i documenti che verranno creati successivamente avranno questo codice. Questo può essere formulato considerando o la sequenza delle iniziative passate oppure secondo le regole dell’organizzazione o della funzione che sponsorizza il progetto Titolo Iniziativa Inserire il titolo dell’iniziativa Descrizione Iniziativa Inserire una breve descrizione Richiedente / Ideatore Iniziativa Nome dell’ideatore dell’iniziativa o del possibile sponsor Redattore del Business Case Chi realmente si occuperà della redazione del presente documento Impulso scatenante Il Business Case da una risposta alla domanda sul perché l’organizzazione abbia scelto proprio quell’iniziativa e non un’altra, dandone ampia spiegazione. Si ricordi che un l’iniziativa può partire da: - una domanda di mercato - un bisogno dell’organizzazione - una richiesta di un cliente - un progresso tecnologico - un requisito di legge - un bisogno sociale Quello che deve essere chiaro è che sino a che l’iniziativa non attraversi un processo, più o meno standardizzato, di approvazione, non è lecito parlare di progetto. Può accadere, infatti, che un’iniziativa venga bocciata o momentaneamente accantonata o perché troppo rischiosa oppure perché non allineata ad obiettivi strategici. Il business case deve rappresentare l’anello di congiunzione tra il Project Management ed il Portfolio Management Descrizione impulsi Sezione dedicata a dare ampio spazio alla descrizione degli impulsi che hanno scatenato l’iniziativa Descrizione opportunità Descrivere le opportunità legate all’iniziativa Stima dimensioni del mercato Nel caso di progetti di marketing, potrebbe essere interessante stimare le dimensioni del mercato sul quale lanciare un nuovo prodotto oppure, per progetti interni, stimare il numero di utenti che verranno impattati durante, ad esempio, una migrazione o per l’erogazione di un nuovo servizio. Stimare correttamente le dimensioni del mercato consentirebbe di comprenderne l’attrattività e la rischiosità per l’azienda stessa
  • 46. Analisi dei Concorrenti Analizzare possibili concorrenti già presenti sul mercato o possibili concorrenti che potrebbero aggredire il mercato di riferimento Descrizione del risultato Descrivere il risultato finale che si attende dall’iniziativa Benefici attesi Mentre per il progetto sarebbe corretto parlare di output, come qualcosa di tangibile e misurabile, in questa sezione verranno discussi i benefici attesi collegati agli output del progetto, i così detti outcome. Esiste però un problema sostanziale tra i due elementi; mentre l’output di un progetto è verificabile immediatamente, anche durante le diverse fasi di sviluppo, per l’outcome questo non è possibile, ovvero è complesso verificarne il raggiungimento subito dopo che il progetto sia stato completato. L’utilizzo, anche in questo caso, di opportune metriche che considerino la natura stessa dell’outcome è essenziale per una corretta valutazione Analisi economico/ finanziaria Le risorse economiche/ finanziarie di un’azienda, come per le risorse umane, sono risorse limitate e come tali dovrebbero essere impegnate /impiegate nel modo più efficiente ed efficace possibile. Ponderare l’iniziativa attraverso precisi indici finanziari è alla base di una valutazione analitica di costi-benefici Gli indici che di solito sono utilizzati per affrontare l’analisi, possono essere i seguenti: • IRR: Tasso Interno di Rendimento (o TIR o IRR, acronimo dall'inglese Internal Rate of Return) è un indice di redditività finanziaria di un investimento. È il tasso di ritorno effettivo che un investimento genera. In termini tecnici rappresenta la resa di un investimento. • NPV: indice di profittabilità di un investimento/ progetto attualizzato • Payback Period: periodo di tempo richiesto per recuperare il capitale investito iniziale Allineamento Strategico Per capire se un’iniziativa sia più o meno allineata alla strategia aziendale, il piano industriale, servirebbe una metrica. La metrica consiste nell’individuare quelli che vengono chiamati Business Drivers che rappresentano i principali fattori che guidano le scelte strategiche in fatto di sviluppo applicativo o di business Priorità In relazione alla strategia aziendale, al piano industriale ed all’allineamento strategico, all’iniziativa, e di conseguenza al futuro progetto, viene attribuito un numero che ne rappresenta la priorità su scala aziendale. Attribuire una priorità alta ad una iniziativa significa essere coerenti a precise scelte strategiche che conducono, di conseguenza, a
  • 47. dare precedenza nell’allocare fondi e risorse a determinati progetti Iniziati approvata/ non approvata Campo utilizzato per ufficializzare l’approvazione o meno dell’iniziativa Riferimenti PMBOK® Guide PMBOK® Guide Versione Inglese Italiano Nome del documento Business Case Business Case Processo che lo crea Gruppo di processi Initiating Concezione/ Avvio Area di Conoscenza Project Integration Management Gestione dell’Integrazione di Progetto Processi che lo usano in input 4.1 Develop Project Charter 4.1 Sviluppare il Project Charter Regole Dovrebbe essere emesso da un manager esterno al progetto che ricopra un livello gerarchico appropriato, od emesso secondo le regole dell’organizzazione. Il presente documento verrà poi sottoposto al parere di un comitato che, secondo metriche appropriate, lo approverà o meno. Il comitato prende diversi nomi, come, ad esempio, Steering Commitee, comitato guida, oppure potrebbe coincidere con un PMO, Project Management Office.
  • 49. Mappatura template Business Case Initiating Planning Executing Monitoring & Controlling Closing Business Case 4.1 Develop Project Charter
  • 50. 50 Esempio Viene di seguito illustrato un esempio pratico di utilizzo del business case. Si tratta di un progetto di Information Technology, riguardante l’implementazione prototipale di una struttura client-server per il monitoraggio dei progetti aziendali. Il contesto in cui si ipotizza lo svolgimento del progetto prevede le seguenti caratteristiche: • Il progetto, fortemente voluto dall’amministratore delegato, rientra nel programma strategico per l’implementazione di un sistema di Project Management, che sarà realizzato attraverso i seguenti progetti: o Una struttura informatizzata (il progetto di esempio) o Percorsi di formazione estesi sia ai project manager che ai membri di team di progetto o Training on the job o Rivisitazione dei processi di Project Management aziendale o Knowledge Management System • Si tratta di un progetto interno; • Non esiste un contratto per il progetto; • La complessità del Progetto è ritenuta elevata; • Il richiedente interno coincide con il committente; Nell’esempio del business case, verrà considerato il programma nel suo complesso.
  • 51. 51 6. CODICE INIZIATIVA 6.1 INI 01 2010 Titolo Iniziativa Sistema di Project Management aziendale Descrizione Iniziativa Progettazione e realizzazione di un sistema aziendale di Project Management. Richiedente / Ideatore Iniziativa Amministratore Delegato Referente Mauro Martinelli Redattore del Business Case Funzione Strategica Referente Luigi Verdi Impulso scatenante * Domanda di mercato Bisogno interno dell’organizzazione * Richiesta di cliente esterno Progresso tecnologico * Requisito di legge Impatto ecologico Bisogni sociali * Inserire un segno di spunta per l’impulso o gli impulsi scatenanti il progetto Descrizione impulsi - Bisogni interni dell’organizzazione: in ottica di miglioramento della gestione dei progetti, la gestione stessa ha sofferto, in questi anni, in termini di efficienza e di efficacia. Attualmente non esistono regole e strumenti per una gestione centralizzata dei progetti con conseguente perdita di visibilità e verifica della coerenza con obiettivi strategici. Non esiste una uniformità nel lessico e nella metodologia di Project Management generalmente accettata e condivisa - Progresso tecnologico: le tecnologie informatiche, orientate al dominio informativo di Project Management, forniscono una visuale aggregata delle performance dei progetti ed una uniformità nella gestione dei dati informatici Descrizione opportunità Miglioramento delle performance dei progetti di almeno il 15% entro 1 anno Acquisizione di competenze e certificazioni per i project manager entro 2 anni Riduzione dei tempi di approvazione dei progetti di circa il 10% entro 6 mesi
  • 52. 52 Stima dimensioni dell’iniziativa (mercato) I risultati ottenuti da primi incontri con i responsabili di funzione coinvolti nel progetto, sono stati i seguenti: - Per il lancio del prototipo informatico, si sono stimati circa 20 progetti che dovrebbero essere inseriti nella struttura - Il personale coinvolto nell’iniziativa si stima sia circa il 35% della popolazione - Tutte le funzioni aziendali saranno coinvolte nel programma Analisi dei Concorrenti Descrizione del risultato Sistema informatico ed informativo di Project Management Selezione dei processi aziendali di Project Management Identificazione dei ruoli e delle responsabilità di progetto Percorsi di formazione per la certificazione Formazione training on the job Benefici attesi Sono stati selezionati i seguenti progetti, facenti parte del programma in oggetto, con i relativi benefici attesi: 1- Progetto di implementazione prototipale su piattaforma client-server 2- Progetto Percorsi di formazione per la certificazione PMP® e CAPM ® 3- Progetto di Training on the job 4- Progetto di rivisitazione dei processi di Project Management aziendale I benefici attesi sono i seguenti: - Miglioramento della qualità di progetto - Acquisizione di nuove competenze tecniche - Acquisizione di competenze progettuali - Riduzione dei costi di gestione dei progetti - Miglioramento dei processi decisionali aziendali - Miglioramento nell’utilizzo delle risorse aziendali - Uniformità nel lessico e nella metodologia utilizzata - Miglioramento delle capacità di pianificazione dei progetti - Miglioramento della governance sui progetti Analisi economico/finanziaria Nell’analisi economico-finanziaria, sono stati valutati i seguenti parametri: • Indice Ricavi/Costi: … • IRR: …% • NPV: € … • Payback period: … mesi
  • 53. Allineamento Strategico L’allineamento strategico è stato valutato sulla base dei seguenti Business Driver individuati dal Top Management (valutazione 1-5): 53 - Riduzione Costi: 4 - Miglioramento nella qualità di gestione: 5 - Miglioramento della comunicazione: 5 - Miglioramento nelle decisioni: 2 - Rischiosità: 4 - Sicurezza dei dati sensibili: 3 Priorità 4 * Specificare valore da 1 a 5 Iniziativa approvata * Iniziativa non approvata * Inserire il segno di spunta e firma
  • 54. 54 SVILUPPARE IL PIANO DI PROJECT MANAGEMENT Qui stiamo parlando di pianificazione che vuol dire organizzare il futuro e stiamo nell’area di conoscenza “Integrazione”. Il piano di P. M. è il piano del progetto, che è l’insieme di tutti i piani ma integrati, armonici, sincroni. Esso mi permette di avere una visione globale di come dovrebbe funzionare il progetto. In effetti tutto lo sforzo che il P.M. fa per arrivare a costruire un piano mi porta di fatto ad avere delle “baseline”.
  • 55. La baseline non mi dice come andranno le cose, perché le cose andranno come andranno. Non è che lo decide il P.M. come andranno in futuro le cose. Esso rappresenta il come dovrebbero andare le 55 cose per arrivare ad ottenere quello che c’è scritto nel charter. Esso rappresenta il mio punto di riferimento. Se le cose dovessero andare come descritto nella mia baseline il mio progetto sarebbe perfetto. Pianificare, nell’ottica del PMI, è un lavoro che tipicamente si fa in due passaggi. Ci sono due livelli della pianificazione: – una pianificazione delle regole del gioco; di cui alcune sono specifiche delle aree di conoscenza. Infatti ogni area di conoscenza ha come primo progetto la pianificazione. – una pianificazione dell’organizzazione dell’attività; ad es. sui costi occorre sapere quanto spendiamo e come. Per ogni area di conoscenza ci sono le singole linee guida. Lo scopo fondamentale dello sviluppare il piano di P. Management è di integrare tutte le informazioni organizzative che ho elaborato nei vari contesti, nelle altre aree di conoscenza. Ovviamente lo spirito del P.M. è quello di non aspettarsi di avere tutto pronto. Si comincia e si fa, in quanto il progetto non lo conoscerò mai fino in fondo. Si comincia e poi man mano si considerano le varie aree di conoscenza. Questo è un discorso di elaborazione progressiva. Si entra nel dettaglio nella prima fase lasciando a grandi linee le fasi successive per poi riprenderle in maniera più puntuale e precisa. La pianificazione è un lavoro progressivo, senza inventarmi nulla ma nel rispetto dei vincoli. Per fare tutto il lavoro di organizzazione generale del progetto, integrata ed in maniera armonica, prendo le informzioni dal Charter. Li ci sono le cose essenziali. Poi vado a prendere tutti i singoli piani relativi alle aree di conoscenza e li integro tra di loro affinchè ottengo un unico macro piano che è appunto il Piano di P. management. All’interno del piano ci devo mettere innanzitutto l’esperienza del P.M. ed altrui (parere degli esperti). Quindi chiedere alle persone più sapienti con le tipiche tecniche di facilitazione (brainstorming, riunioni, conflitti). Il piano di P. management è una sorta di raccoglitore di tutti i singoli piani ma
  • 56. armonizzati tra di loro. Ogni singolo piano deve tener presente la presenza contemporaneità di altri 56 piani. In particolare il risultato del Piano di P. Management è la Baseline. Cioè quella situazione fattibile che fa riferimento ai tre pilastri del triangolo costi-tempi-ambito E quindi avremo una baseline dei tempi, dei costi e dell’ambito. Questi sono quelli principali anche se ci sono altre che fanno parte delle altre aree di conoscenza. Oltre alle baseline delle aree di conoscenza abbiamo anche il ciclo di vita (ciclo di Deming) che vogliamo utilizzare. Inoltre occorre scrivere anche quali aree di conoscenza andremo ad utilizzare e di queste quali processi utilizzeremo. I 47 processi non vanno sempre applicati tutti. E di quelli da applicare, alcuni andranno utilizzati con un certo dettaglio altri invece con una certa superficialità. Altro aspetto importante è che il progetto non andrà come descritto nella baseline. Ogni volta che in un punto del progetto mi si presenta qualcosa che non va o che cambia come mi devo comportare? Prima occorre decidere come ci si comporta e poi lo applichi. E quindi è importare incorporare nel macro piano il piano delle gestione delle modifiche. Altro elemento fondamentale ed importantissimo: il mio progetto cambia nel tempo in quanto ci sono dei ritardi, ecc. pertanto possono esistere diverse versioni del progetto. Dobbiamo fare in modo di utilizzare sempre l’ultima versione ed archiviare quelle precedenti. Esiste dunque il piano di gestione della configurazione di un progetto. Il mio progetto sarà rappresentato essenzialmente da due grossi raccoglitori: – una sezione organizzativa: piano di project management , in quanto mi dice come dovrebbero funzionare le cose e dove dentro ci sono tutti i piani. Ma il mio progetto ha tutta una serie di altre rappresentazioni che sono tipicamente documentali: elenco delle modifiche, elenco degli stakeolder, ecc. – Una sezione documentale: esistono allora i Documenti di progetto (vedi PMBOK pag. 78); Ma non tutti i progetti hanno tutti i documenti illustrati nel PMBOK, dipende dal tipo di progetto.
  • 57. 57 A questo punto vediamo il primo piano di progetto e parliamo di SCOPE (o ambito del progetto). Riassumendo lo sviluppo del piano di project management prevede un’integrazione e un coordinamento di tutti i differenti piani relativi ai differenti aspetti di qualità, tempo e costo, nonché di pianificazione delle risorse. Esso definisce come eseguire, monitorare, controllare e, infine, chiudere il progetto. Una volta definito, il piano deve essere approvato e successivamente “congelato”; in tal modo fungerà da “Baseline” iniziale per le fasi di controllo e continuamente integrato con modifiche suggerite da feed-back provenienti dal monitoraggio delle attività eseguite. In generale nel piano dovrebbero essere descritti: • Il ciclo di vita del progetto e le attività ad esso associate • I principali input e output (deliverables) delle attività in relazione agli obiettivi di progetto, le modalità di esecuzione del lavoro e i luoghi in cui saranno realizzate • Le relazioni fra le attività di progetto • Le descrizioni degli strumenti e delle tecniche da utilizzare per l’esecuzione dei processi di progetto • Le modalità di monitoraggio e controllo delle attività • Le modalità di implementazione delle modifiche • Le modalità di manutenzione e utilizzo per la salvaguardia dell’integrità delle baseline di misurazioni delle prestazioni • Le necessità e modalità di comunicazione fra gli stakeholder Accanto al piano principale devono essere previsti i piani ausiliari fondamentali nel Project Management, ovvero i piani di: • Gestione dell’ambito di progetto • Gestione del reclutamento del personale • Gestione delle qualità e del miglioramento dei processi • Gestione della schedulazione • Gestione dei costi • Gestione dell’approvvigionamento
  • 58. 58 • Gestione della comunicazione • Gestione dei rischi • Gestione degli stakeholder Presenti in questi piani vi sono anche dei componenti ausiliari, come ad esempio: • Elenco delle milestone • Calendario delle risorse • Baseline della qualità (la baseline dell’ambito) • Baseline della schedulazione • Baseline dei costi • Registro dei rischi (risk register) • Registro degli stakeholder (stakeholder register) La pianificazione del progetto prevede almeno otto step sequenziali che partendo dalla segmentazione della WBS, attraverso la selezione del team di progetto, l’analisi della qualità, dei tempi e dei costi, perviene all’identificazione e allocazione delle risorse.
  • 59. Senza un piano di progetto (o piano di project management) è probabile che un progetto non riesca a raggiungere i suoi obiettivi. In un progetto di piccole dimensioni è possibile costruire rapidamente un piano che contenga tutte le informazioni riguardo l’ambito del lavoro da svolgere e le risorse necessarie per svolgerlo. Per 59
  • 60. progetti di grandi dimensioni, la pianificazione sarà un processo iterativo svolto in più fasi e tempi diversi a livelli di dettaglio crescente. Qualunque sia la dimensione del progetto, il piano di progetto costituirà la “rotta” che il progetto dovrà seguire e costituirà quindi il punto di riferimento (baseline) rispetto al quale calcolare gli scostamenti ed individuare gli interventi correttivi in corso d’opera per riportarlo in linea con le attese degli stakeholder. In assenza di un piano non è pertanto possibile questa opera di monitoraggio continuo e ripianificazione alla luce dell’andamento reale delle attività. 60 Il piano sarà quindi aggiornato durante tutto il ciclo di vita di un progetto. Contenuti del Piano di Project Management Il piano è costituito da un documento principale e da un serie di documenti allegati che emergono dall’attività di pianificazione (es. descrizione d’ambito, analisi requisiti, WBS, attività, Gant, budget, cash flow, piano della qualità, ecc.…). Conterrà quindi anche altri piani più di dettaglio. Il documento principale descrive la strategia di project management e costituisce anche una guida alla lettura dei documenti allegati da parte di chi non ha partecipato alla pianificazione del progetto. Il piano di progetto formalizza l’accordo tra project manager e l’organizzazione di cui fa parte riguardo le specifiche di realizzazione del progetto. Dovrà essere quindi approvato dal Comitato di Coordinamento del Progetto. Più specificatamente, il piano di project management deve fornire una descrizione chiara: • dell’ambito e delle finalità del progetto; • dei suoi prerequisiti (azioni preliminari che devono essere svolte per garantire il successo del progetto) • dei collegamenti e dipendenze con altri progetti; • degli assunti (es. risorse pre-assegnate al progetto) • dei ruoli e responsabilità; • dei punti di attenzione (criticità e rischi); • delle attività previste; • della tipologia (quantità e qualità) delle risorse necessarie allo svolgimento del lavoro; • dei tempi di esecuzione di ciascuna attività e della durata complessiva del progetto: • dei costi associati e dei ricavi attesi; • delle modalità di gestione dei rapporti e delle comunicazioni con gli stakeholder; • degli interventi a garanzia della qualità del lavoro e dei deliverables; • dei criteri di gestione degli approvvigionamenti e dei rapporti con i fornitori. Pertanto il piano di progetto contiene a sua volta: • Il Business Case ed il Project charter (o documento che formalizza l’avvio del progetto) • La strategia di project management • I requisiti del progetto
  • 61. • Il documento di definizione d’ambito (Scope statement) contenente la descrizione dei 61 deliverables • La WBS (Work Breakdown Structure) • Le attività e i loro attributi/caratteristiche • Le risorse e le loro caratteristiche (quantità e qualità) • La struttura di governo del progetto • La OBS di progetto • La Matrice di assegnazione delle responsabilità • La schedulazione (Diagrammi reticolari e/o Gant di progetto) contenente anche le milestones principali • Il budget ed il cash flow di progetto • Le strategie di gestione dei rischi ed il budget di contingency • Il piano di gestione della qualità • Il piano di gestione delle comunicazioni di progetto • Il piano di gestione degli approvvigionamenti • Le baseline per la misurazione della performance • Le procedure per la gestione delle Issue di progetto e delle richieste di modifica La costruzione del piano di progetto La costruzione del piano richiede i seguenti passaggi principali: • comprendere i vincoli e i prodotti che caratterizzano il progetto; • descrivere i deliverables di progetto ed i loro requisiti; • specificare le attività necessarie a creare i deliverables; • definire la sequenza logica delle attività e le loro interdipendenze; • stimare le risorse necessarie ed i loro requisiti; • stimare i tempi per ciascuna attività; • produrre la schedulazione delle attività (reticolo e/o Gant); • definire le milestones ed i punti di controllo; • identificare le modalità per gestire rischi ed incertezze; • identificare le modalità di gestione della qualità; • identificare le modalità di gestione delle comunicazioni di progetto (canali, format, templates di documenti, modalità di conduzione degli stati di avanzamento lavori, calendario delle riunioni di lavoro, ecc.…) • calcolare i costi di ciascuna attività, il budget totale e quello di contingency; • valutare la compatibilità con il piano di fatturazione contrattualmente previsto; • formalizzare le modalità di gestione e le procedure di escalation a fronte di variazioni d’ambito; • formalizzare il documento di descrizione del piano; • ottenere l’approvazione del piano di progetto. Un buon modo per predisporre il piano di project management consiste nel seguire la check list di seguito articolata.
  • 62. 62 a) Definire l’ambito e le finalità del progetto • Sono chiare le finalità per cui occorre predisporre il piano e le modalità per una sua approvazione? • Conoscete i processi di project management relativi alla pianificazione di progetto? • Sono chiari gli obiettivi che si intende raggiungere con il progetto? • Gli obiettivi sono definiti in modalità SMART? • Sono chiari i contenuti del progetto in termini di deliverables attesi? • Ci sono dei vincoli (ad esempio la disponibilità delle risorse, date di consegna ecc…)? • Esistono degli assunti o delle ipotesi di partenza in base ai quali costruire il piano? b) Definire i deliverables di progetto • Quali saranno i risultati finali ed intermedi prodotti dal progetto? • Cosa deve contenere e quali aree deve coprire ciascun deliverable? • Chi sarà responsabile dello sviluppo per ciascun deliverable? • Da chi o da cosa dipenderà il risultato (es. informazioni, risorse)? • Quali sono i requisiti richiesti dal punto di vista della qualità? • Quali sono le modalità per controllare la qualità di ciascun deliverable? • Quali sono le competenze, le risorse, le persone necessarie per sviluppare ciascun deliverable e svolgere i controlli di qualità? • Qual è l’ordine cronologico in cui i deliverables saranno prodotti? c) Identificare e stimare le attività • Predisporre la WBS di progetto coinvolgendo anche persone esperte e specialisti che conoscono bene i criteri di lavorazione ed i processi di costruzione di ciascun deliverable • Consolidare la WBS attraverso il coinvolgimento e l’approvazione dei principali stakeholder di progetto • Identificare tutte le attività necessarie allo sviluppo di ogni deliverable • Identificare tutte le attività necessarie al controllo di qualità di ogni deliverable • Concordare l’ordine in cui le attività devono essere svolte • Identificare le competenze necessarie a svolgere ogni attività • Stimare la quantità di sforzo (es. ore/uomo) ed il numero ottimale di risorse da coinvolgere nel progetto • Consolidare la durata di ciascuna attività sulla base delle ore/uomo ripartite sul numero di risorse effettivamente assegnate • Identificare e valutare le risorse non umane (es. mezzi, materiali, impianti) e i servizi di supporto richiesti • Calcolare il costo stimato per sviluppare ogni deliverable • Calcolare il costo complessivo per tutte le attività
  • 63. 63 d) Schedulare le attività e le risorse • E’ stato predisposto il Gant di progetto? • Il progetto ha una data di inizio e di fine realistiche? • Sono state considerate le pause per i fine settimana, le festività, le ferie e gli altri giorni non lavorativi? • E’ stata verificata la disponibilità delle risorse nei periodi di impegno sul progetto? • Le risorse hanno tutte le competenze giuste o deve essere previsto un piano di formazione con conseguenti tempi di attesa? • Esistono stakeholder od eventi esterni che possono limitare l’utilizzo delle risorse? • Il carico di lavoro è correttamente ripartito sulle risorse? Esistono ambiti di sovrapposizione delle risorse su più progetti con possibilità di over head? • Sono previste attività da far svolgere in sub-appalto? I fornitori sono al corrente dei requisiti delle attività, dei deliverables e delle modalità di controllo del progetto? • e) Identificare i rischi e i punti di controllo • Sono chiari i momenti di revisione del progetto, le approvazioni necessarie ed il calendario di incontri con lo Sponsor ed il Comitato di Coordinamento del progetto? • Sono state definite le principali milestones del progetto? • Nel piano sono formalizzati anche i punti di controllo della qualità? • Sono stati identificati i rischi e le strategie di gestione per ciascun rischio? • Sono stati formalizzati e contrattualizzati i rapporti con eventuali fornitori e terze parti? • Sono state previste riserve o budget di contingency per gestire eventuali situazioni di emergenza? • Prima di partire con la realizzazione del progetto, il piano è stato presentato alle risorse in un kick off meeting? • Le risorse hanno ben compreso il livello di responsabilità e committment a loro richiesto? • e) Formalizzare il piano ed ottenerne l’approvazione • Il piano di progetto è formulato in modo tale da poter essere compreso anche da chi non ha partecipato alla fase di pianificazione/progettazione? In particolare può essere utilizzato da un altro Project Manager per condurre la fase di realizzazione senza doverlo rifare? • Il piano è sufficientemente dettagliato da guidare il lavoro delle risorse coinvolte nella realizzazione? • Il piano è comprensibile da parte di coloro che dovranno fornire le risorse? • Il piano è comprensibile da parte di coloro che dovranno assicurare le fonti di finanziamento? • Il piano è comprensibile da parte di coloro che dovranno svolgere l’assicurazione ed il controllo della qualità? • Il piano di project management è stato inviato preventivamente a Sponsor e Comitato di Coordinamento del Progetto perché ne prendano visione prima dell’incontro finalizzato all’approvazione o integrazione? Prima di andare oltre nella spiegazione delle varie fasi dell’Integrazione vediamo la gestione dell’ambito del progetto.
  • 64. 64 GESTIONE DELL’AMBITO DI PROGETTO (SCOPE MANAGEMENT) A partire dal Project Charter, che come si è precedentemente visto formalizza l’inizio del progetto, vi è la gestione dell’ambito (Scope Management) che operativamente si traduce in una sua accurata descrizione. Ciascun progetto richiede un attento equilibrio fra complessità dell’ambito in cui si opera e livello di complessità delle metodologie e degli strumenti da utilizzare. E’ richiesta una formalizzazione degli obiettivi globali del progetto, che serviranno da riferimento per decisioni future. Successivamente vi dovrà essere una definizione di massima delle attività da eseguire e la definizione di quali saranno i criteri di accettazione dei risultati conseguiti. Non bisogna dimenticare infine di fare delle ipotesi su nuovi eventi (positivi e negativi) e su come affrontarli. La descrizione dell’ambito è la vera e propria definizione formale degli obiettivi di progetto, ovvero cosa deve essere portato a termine evidenziando i vincoli esterni ed interni che ne delimitano il campo d’azione. I vincoli esterni sono determinati da tutti gli aspetti precisati nel contratto, ovvero le specifiche tecniche e qualitative, i tempi di consegna e il prezzo stabilito o il budget allocato nel caso di progetti interni. I vincoli interni sono determinati primariamente dalle risorse e dalle competenze dell’organizzazione e dai carichi di lavoro già assegnati. Inoltre, definendo l’ambito, è necessario considerare tutti gli attori presenti nell’ambiente in cui si andrà ad operare e che necessariamente influenzeranno l’andamento del progetto. E’ necessario sviluppare una documentazione che chiarisca le caratteristiche e i limiti del progetto e dei prodotti e servizi ad esso associati, nonché dei termini di valutazione e di controllo. In generale gli elementi contenuti nel documento di descrizione dell’ambito sono: • Obiettivi del progetto • Requisiti e caratteristiche del prodotto o del servizio e criteri di accettazione dei risultati • Principali stakeholder • Fattori critici di successo • Pianificazione di massima con principali deliverables e schedulazione delle milestone fondamentali • Organizzazione iniziale e livello di partecipazione delle frazioni aziendali • Rischi definiti nelle fasi iniziali • Budget di progetto
  • 65. Come detto, nella definizione degli obiettivi di progetto è necessario tener conto dei vincoli in termini di risorse interne possedute e disponibili, di risorse economiche e del tempo necessario al suo completamento. Gli obiettivi devono essere SMART (Specifici – Misurabili – Assegnabili – Realistici – 65 Tempificabili). In questa fase è necessario iniziare ad effettuare una descrizione delle specifiche di prodotto, anche se non nel massimo dettaglio. Le caratteristiche del prodotto dovranno essere progressivamente elaborate, in quanto subiranno di necessità delle variazioni si aformali che sostanziali. In questo momento è sufficiente chiarire i requisiti fondamentali del prodotto (o del servizio o del processo), assegnandone le priorità in base alle esigenze espresse dal cliente e alle aspettative degli stakeholder. “Le aspettative, le necessità, le esigenze degli Stakeholder devono essere analizzate e convertite in requisiti”. La preparazione di una descrizione dettagliata dell’ambito del progetto è critica per la riuscita del progetto stesso. Per far ciò è opportuno organizzare una riunione di avvio a cui partecipano i rappresentanti del cliente, i principali stakeholder, gli sponsor e il management del futuro team di progetto. In questo meeting si dovrebbe usualmente pervenire a decisioni fondamentali relative alle revisioni da apportare al progetto e all’accettazione definitiva dell’ordine, ma anche collegare le attività del progetto al lavoro in corso all’interno dell’organizzazione. In particolare si effettua una revisione del contratto e un’analisi degli aspetti relativi a: • Requisiti di approvazione del prodotto, sevizio processo oggetto del progetto e delle attività previste • Tempistiche di realizzazione delle attività • Decisioni preliminari di “Make or Buy” su elementi della fornitura • Definizione preliminare degli elementi di fornitura, delle possibili varianti e dei margini • Identificazione dell’organizzazione iniziale del progetto • Distribuzione delle risorse fra le differenti funzioni ed eventualmente fra differenti siti produttivi • Limite di finanziamento, stima dei costi e budget di progetto Fondamentali sono le decisioni relative alla pianificazione delle principali milestones di progetto e alla definizione dei principali deliverables:
  • 66. 66 FASE PRINCIPALI DELIVERABLES Start-Up Contratto, Project Charter, Registro degli stakeholders Pianificazione Piano principale e piani ausiliari, WBS, OBS, RBS, ECC. Approvvigionamento Piano digestione degli approvvigionamenti Esecuzione Convalida dei deliverables, aggiornamento del piano principale e dei piani ausiliari Monitoraggio e Controllo Project status, registro richieste di modifica, registro delle Issue Chiusura Output finale, documentazione finale di progetto, indicatori di performance Altro fattore fondamentale indispensabile è la descrizione dei criteri di accettazione del prodotto e dei fattori critici di successo del progetto relativi all’ambito in cui sopra. Dopo questa breve descrizione generale veniamo alla descrizione dettaglia del Piano di Gestione del Ambito Cominciamo a fare il Piano dello Scope (dell’ambito). Esso deve traguardare il lavoro da fare nel progetto e quello da non fare nel progetto. L’obiettivo è sempre quello di completare con successo il progetto. Esso raccoglie tutto quello che riguarda e capire cosa c’è da fare. Viene struttura nell’ambito del BOK con 6 attrezzi: i 6 processi di gestione dell’ambito. Il primo è sempre la pianificazione. Cosa vuol dire pianificare la gestione dell’ambito? Cosa vuol dire ambito nel nostro progetto? quali sono le regole del gioco e le linee guida che ci diamo per la gestione dell’ambito? Quando parliamo di ambito parliamo certamente dell’ambito del progetto ma anche dell’ambito del prodotto. Quando parliamo di scope (di ambito), ad es. per fare un ponte, parleremo di cose che occorre fare per costruire il ponte (calcoli, gettate di cls, ecc.) – e questo si chiama ambito del prodotto – sia di gestione del progetto, cioè una pianificazione temporale, un charter, ecc. – e questo si chiama ambito del progetto.