Il documento tratta della gestione dell'integrazione del progetto, evidenziando l'importanza dello scope management e della definizione di requisiti chiari per il successo del progetto. Viene sottolineato che i progetti devono rispondere a bisogni concreti e generare risultati significativi; altrimenti, possono risultare inutili, indipendentemente dalla loro realizzazione tecnica. L'integrazione di processi e la gestione strategica del project portfolio sono fondamentali per governare l'interazione tra vari progetti e garantire il raggiungimento degli obiettivi aziendali.

2. 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.

67. Oltre alla pianificazione poi, uno dei passaggi importanti è la raccolta dei requisiti che per il PMI viene
considerata un pezzo del progetto; poi ci sono altri 2 passaggi di pianificazione: definizione
dell’ambito – la descrizione di ciò che vogliamo fare – che in parte abbiamo già visto nel charter ma
qui andiamo più a fondo con maggior chiarezza; e l’altro passaggio è quello di spezzare il progetto in
più pezzi meglio gestibili e quindi creare la WBS che è un processo che ci fa ottenere dei blocchetti
67
del progetto più gestibili singolarmente.
Di seguito si hanno 2 processi di esecuzione e controllo: il primo è convalidare l’ambito che consiste
sostanzialmente nel prendere quello che noi abbiamo realizzato (i deliverable del nostro progetto),
che già hanno avuto il benestare della qualità cioè rispettato i parametri con cui dovevano essere
costruiti, e lo facciamo accettare a chi li deve ricevere. Convalidare l’ambito è la formalizzazione
dell’accettazione da parte di chi deve ricevere i deliverable (intermedi o finali).
Controllare l’ambito significa verificare che quello che dovevamo fare lo stiamo facendo, né di meno
e ne di più, senza cambiare le cose.

68. Per sviluppare il piano di gestione dell’ambito occorre utilizzare un piano di project management
nonché il charter che quindi sono gli input principali per la definizione del piano di gestione in
68
argomento.
Tutti i processi di pianificazione hanno inoltre come input i fattori ambientali ed aziendali nonché gli
Asset dei processi organizzativi.
Gli strumenti che andremo ad utilizzare sono: l’esperienza e le riunioni.
Il piano di gestione dell’ambito è quello che avremo come risultato che dichiarerà come l’ambito sarà
definito, controllato, quali sono le regole del gioco e che cosa intendiamo organizzare.
Quali modalità usiamo per andare a descrivere con chiarezza il lavoro da fare: ad es. possiamo
scrivere di fare delle riunioni sia con i tecnici che con lo sponsor oppure dire che adotto degli studi
che sono stati fatti da enti di settore, ecc.; oppure come andremo a strutturare la WBS (strumento
principale della gestione dell’ambito); magari è una WBS completamente nuova in quanto si sta
trattando un progetto ex novo, per cui occorrono delle strutture per capire come disegnare la WBS.
Oppure è un progetto che assomiglia a tanti altri e che quindi prenderò una WBS esistente e magari
andrò semplicemente a fare qualche modifica alla propria struttura.
Nella pianificazione della gestione dell’ambito andiamo a descrivere tutto quanto detto.
Oltre a questo però esiste la definizione dei requisiti.
Per fare questo occorre prima darci delle regole per la definizione e la raccolta dei requisiti. Prima si
deve decidere come vogliamo fare, organizziamoci e poi lo metteremo in atto. E quindi nasce da
questa pianificazione anche il piano di gestione dei requisiti. Il quale si comporta alla stessa maniera,
relativamente, dei requisiti.

69. Come facciamo a garantirci che i requisiti non cambiano o viceversa? Occorre quindi mettere in
evidenza all’interno del piano di gestione dei requisiti i tipi di controllo e i relativi livelli di controllo.
Quindi prima costituisco le regole del gioco e poi le applico. Questo è lo spirito del PMBOK: non posso
69
fare nulla se prima la cosa non è organizzata.

70. In tale ottica quindi raccogliamo i requisiti. Il processo di raccolta dei requisiti è un processo piuttosto
sofisticato in quanto stiamo andando a sottolineare, ad identificare con estrema chiarezza le
70
caratteristica della nostra soluzione.
Ma come si raccolgono i requisiti da manuale. Ci sarebbero varie modalità ma la logica tipicamente è
quella di fare riferimento agli stakeolder. Essi sono quelli che a vario titolo rientrano nel nostro
progetto. Il BOK dice che sono stakeolder anche quelli che hanno la percezione di entrare a far parte
del progetto. Di fatto gli elementi chiave per uno stakeholder sono quelli che possono portargli una
convenienza e/o lui è in grado di cambiare la vita al progetto. Essi sono uno degli elementi chiave per
la gestione dell’intero progetto; ed uno dei fattori importanti quindi è proprio quello di capire come
gestirli.
Nel ragionare sui requisiti, uno degli elementi chiave è quello di partire da loro. Per cui una buona
parte del tempo che occorre al P.M. è quello di iniziare a ragionare con gli stakeolder. Cioè la prima
cosa che il P.M. deve fare è individuare gli stakeolder e poi ragionarci. In tal caso da essi posso
raccogliere i requisiti importanti, misurabili. E’ buona norma chiedere anche a loro quali dei requisiti
dettati hanno una maggiore o minore priorità. Quindi avremo vari stakeolder che mi elencano i propri
requisiti secondo una certa priorità.
Successivamente farò un’analisi a livello di importanza e priorità. Ma posso anche aggiungerli io.
A questo punto vado a ragionare sulle priorità di questi requisiti indipendentemente da quello che
mi hanno detto gli stakeolder. Devo pensare quali sono i requisiti più importanti. Ma qual’è il modo?
Il criterio è quello di mantenere come obiettivo che rappresenta la soddisfazione del cliente ovvero
noi dobbiamo creare qualcosa che genera una soluzione, che produce un risultato che porta alla

71. generazione dei benefici che soddisfano il bisogno da cui eravamo partiti. Quindi l’obiettivo non è
71
quello di raccontare tutti gli stakeolder o solo uno.
La priorità del requisito quindi è capire quanto quel requisito incide sulla realizzazione di quel
beneficio. E quindi assegnerò ai singoli requisiti delle priorità in funzione del beneficio atteso. Ci
saranno quelli più importanti e quelli meno. Tra i requisiti degli stakeolder potremmo trovarne anche
alcuni che risultano controproducenti, che non ci aiutano per niente.
Una modalità per definire questa scaletta di importanza dei requisiti è la tecnica MoSCoW La tecnica
MoSCoW che permette di assegnare le priorità su requisiti o criteri di accettazione. Esso è
l’acronimo di:
• M - MUST: Describes a requirement that must be satisfied in the final solution for the solution
to be considered a success.
• S - SHOULD: Represents a high-priority item that should be included in the solution if it is
possible. This is often a critical requirement but one which can be satisfied in other ways if
strictly necessary.
• C - COULD: Describes a requirement which is considered desirable but not necessary. This will
be included if time and resources permit.
• W - WON'T: Represents a requirement that stakeholders have agreed will not be
implemented in a given release, but may be considered for the future. (note: occasionally the
word "Would" is substituted for "Won't" to give a clearer understanding of this choice)
“quello che devo assolutamente avere altrimenti non arrivo al risultato – quello che è significativo
avere, importante avere – quello che potrei avere – quello che non devo o voglio avere”.
Quindi, rispetto al punto di arrivo o beneficio che voglio inquadrare, vado a prioritizzare i requisiti
secondo le modalità di cui sopra. A questo punto i requisiti vanno gestiti – identificare, analizzare -
agire – controllare. Fino ad ora gli abbiamo identificati, ma ora andiamo ad analizzarli.
Da un lato posso avere tutti i requisiti ordinati, prioritizzati secondo le esigenze del progetto e
dall’altro secondo quelli dettati dagli stakeolder. Infatti non è detto che siano le stesse. Mi posso
trovare con uno stakeolder che ha individuato un requisito che per lui è fondamentale ma che con il
mio progetto c’entra molto poco. Oppure potrei avere individuato da parte di uno stakeolder un
requisito secondario che risulta invece determinante nel mio elenco e quindi per il mio progetto
(bisogno) che comunque deve rispecchiare il charter.

72. E’ ovvio che devo capire chi è lo stakeolder che ha espresso quel requisito perché se essi sono il
cliente o lo sponsor e mi rendo conto che secondo la mia analisi tali requisiti non risultano importanti
o necessari al mio progetto, occorre capire se loro hanno le idee poco chiare rispetto al progetto
ovvero al charter. Quindi o il charter è sbagliato o qualcuno ha cambiato idea troppo repentinamente
72
(o non ha le idee chiare).
Le aspettative non realistiche è una delle principali cause di fallimento del progetto.
Quindi il P.M., in tali situazioni, deve andare a riconciliare o confrontare la priorità di quel requisito
data dal progetto, rispetto al beneficio che è stato indicato di ottenere, con quella dello stakeolder,
attraverso dei livelli di comunicazione adeguata oppure andando dallo sponsor per rappresentargli
la problematica.
Tutto questo perché il P.M. deve sempre inquadrare il risultato nel rispetto dell’utente, cioè di chi va
ad utilizzare quel progetto.
Dopo aver effettuato tale “riconciliazione” occorre aggiungere ad ogni requisito un suo grado di
chiarezza e completezza ed un suo grado di stabilità.
Cosa vuol dire avere un requisito di importanza massima e determinante per raggiungere il mio
obiettivo ma che non è descritto in maniera chiara? Significa che devo lavorare sulle “sabbie mobili”,
cioè in un clima di incertezza. Quindi tali requisiti vanno approfonditi altrimenti avremo un progetto
instabile, ad alto rischio e con grande incertezza. Cioè il progetto si può fare ma lo sponsor deve
sapere che corriamo il rischio di dover rivedere i prezzi, di dover spendere di più. E quindi dobbiamo
fare una gestione del rischio più sofisticata.
Se uno dei requisiti fondamentali non ha dei buoni livelli di completezza, chiarezza e di stabilità
evidentemente dovremmo andare a bilanciare questo aspetto con una dimensione di rischiosità del
progetto.
Se viceversa le qualità di completezza, chiarezza e di stabilità sono lacune di un requisito poco
fondamentale, meno significativo, allora la cosa è più trascurabile. Se quel requisito lo soddisfo ok
altrimenti non fa niente. Posso anche andare avanti senza averlo definito con chiarezza.
Quindi lo sforzo maggiore per il P.M. è proprio la raccolta e l’analisi di questi requisiti che devono
sempre traguardare al beneficio. Obiettivo ultimo del nostro progetto.

73. Anche l’identificazione dei requisiti è un processo progressivo, che si andrà ad affinare man mano
73
che andremo avanti con il progetto.
Una volta identificati i requisiti ed analizzati, ora tocca agire.
Agire vuol dire prendere le conseguenze di queste analisi che abbiamo fatto. E quindi agire con gli
stakeolder per ragionare sulle cose, comunicare, spiegare, ecc.
Agire nei confronti dei requisiti per individuare gli indici di rischiosità generali del progetto, se vale la
pena partire.
Ultima cosa è controllare i requisiti. Esso vuol dire rifare tutto in quanto i requisiti non sono stabili;
gli stakeolder cambiano idee continuamente. E quindi rivedere i mie elenchi, le mie priorità e
riverificare, in base ai nuovi dettami degli stakeolder se mi cambia la classifica finale dei requisiti, ecc.
Quindi controllare vuol dire riprendere tutto: identificare, analizzare, agire, ecc.
Fino alla fine del progetto non si ha mai niente di sicuro.
Tutto questo è presente nel PMBOK (pag. 110 e seguenti di cui non si trascrivono qui gli strumenti e
tecniche).
Gli strumenti e le tecniche utilizzate per raccogliere i requisiti sfociano poi ad una documentazione
dei requisiti. Cioè il requisito con tutta la storia che gli abbiamo messo dietro.
Oltre a questo occorre inoltre costruire una matrice di tracciabilità dei requisiti che non è altro
quell’allineamento, quell’identificazione tra il punto di arrivo del progetto, ovvero gli obiettivi indicati
nel charter, e il requisito. Cioè da dove arriva il requisito, in che cosa consiste e cosa mi aiuta a
realizzare. Tale matrice crea un contesto di significato di requisito. Ogni volta che ci sarà un
cambiamento o una differenza di un generico requisito si potrà capire istantaneamente, grazie alla
suddetta matrice, che impatto può avere tale differenza perché vado a vedere su che area del
beneficio mi impatta. Capendo anche da dove mi è arrivato il cambiamento posso capire quali sono
le fonti.
Comunque i requisiti finali vanno concordati e condivisi con lo sponsor ed a volte anche con il
cliente.
(segue esercizio Moon Landing sull’utilità del lavoro di gruppo e sul giudizio degli esperti)

74. Questo esercizio ci fa fare delle riflessioni. Cioè considerando che abbiamo affrontato una
problematica di cui non si conosce niente, l’ignoranza del gruppo è meglio dell’ignoranza del singolo.
Quindi è meglio confrontarsi, stare insieme. Questo vale anche per la raccolta dei requisiti o altre
74
decisioni.
Questa rappresenta una dinamica che nel progetto capita spesso e quindi fare attenzione, quando
del progetto non si conosce niente, a camminare da soli: meglio in gruppo.
Individuato i requisiti facciamo un passo in avanti.

75. 75
DEFINIRE L’AMBITO
Vuol dire chiarirci in maniera più definita possibile che cosa dobbiamo andare a fare. Cosa fa parte
del progetto e cosa non fa parte del progetto. Quindi descrizione dettagliata del progetto (cioè come
realizzarlo) e del prodotto (risultato, soluzione). Sostanzialmente definire l’ambito è quell’attrezzo
che ci permette di andare a identificare un documento che in qualche modo chiarirà cosa dobbiamo
fare. Questo documento si chiama descrizione dell’ambito (Scope Statement) che è il frutto del
definire l’ambito. Questo è di nuovo un raffinamento a partire dal charter di alcuni aspetti legati a
cosa fare e focalizza nella maniera più chiara possibile il progetto ed il prodotto.
Più dettagliata (più chiara possibile) vuol dire che il processo che ci porterà alla definizione dello scope
statement è sostanzialmente iterativo. Man mano che procedo con il parlare con altri stakeholder
ovvero trovare altri requisiti, ecc. arrivo ad avere sempre un maggior dettaglio. E questa procedura
iterativa va anche formalizzata, scritta.

76. Quali sono le fonti (input) di questo lavoro: sono certamente il nostro piano di gestione dell’ambito
76
(ovvero il Project Management Plan), il charter, il lavoro sui requisiti.
Nella definizione dello scope statement non compaiono i “fattori ambientali ed aziendali”. Infatti
il BOK mette in evidenzia che avendo già fatto il piano di project management, lì ho già detto come
devo fare le cose, ho recepito nel dire come devo fare le cose (fattori ambientali di contorno del
progetto) e quindi non devo rimetterlo all’interno della definizione dell’ambito e quindi dello scope
statement (descrizione dell’ambito). Mentre invece ritornano gli Asset dei processi organizzativi. Se
lo scope statement è un documento con template aziendale esso è un Asset dei miei processi
organizzativi che devo utilizzare.
Le tecniche e gli strumenti che metto in atto per usare queste fonti e generare lo scope statement:
l’esperienza (parere degli esperti), l’analisi del prodotto che può essere sommaria, sofisticata,
tecnica, approfondita. Inoltre si possono valutare delle alternative, indirizzare diversamente certe
tecniche, certe modalità o attitudini costruttive. O addirittura utilizzare dei workshop guidati (riunioni
ben focalizzate tra i principali stakeolder per definire i requisiti del prodotto.
Il tutto per sfociare in un risultato che è appunto la descrizione dell’ambito del progetto (scope
statement). Quindi il cosa c’è da fare (quali sono i confini del progetto), i principali deliverable, assunti
e vincoli del progetto derivati dal charter e magari sofisticati e più orientati al cosa fare.
Il tema dell’ambito è sempre “il cosa fare”.
In questa fase stiamo focalizzando con maggior dettaglio ciò che abbiamo già visto in precedenza:
stiamo sofisticando quella che è la definizione della soluzione che andiamo a generare.
Ma tutto questo in effetti lo abbiamo già visto nel charter. In effetti si, ma in questo processo
parliamo di un livello di dettaglio molto più sofisticato con voci anche diverse.
Il charter riguarda il progetto nella sua globalità. Lo scope statement riguarda invece lo scope, cioè ci
concentriamo su una parte del progetto (o prodotto) che è “il cosa fare”. E quindi ci saranno alcune
voci che abbiamo già messo nel charter ma dettagliate rispetto all’ambito. In definitiva lo scope
statement non è altro che un approfondimento di una parte del charter.
Anche in tale processo ci possono essere delle iterazioni dovute alla presenza ad es. di stakeolder che
magari non avevo preso prima in considerazione o magari dovrò adeguare il piano dei tempi o altro.

77. Da tale processo iterativo esce fuori un qualcosa che potrebbe stare in piedi e cioè la Baseline dello
77
scopo (o ambito).
Arriviamo così ad un livello ulteriore di dettaglio, perché in pratica attraverso lo scope statement ho
descritto il progetto in toto definendo anche i propri confini. Però adesso abbiamo il problema di
andarlo a gestire perché il progetto è molto ampio da svolgerlo. Ad esempi dovendo fare una casa e
quindi lo scope statement va a vedere il disegno globale della casa, cioè il mio punto di arrivo. Però a
questo punto bisogna cominciare a costruire la casa e quindi a dividere in pezzi questo lavoro a partire
dalla parte burocratica fino alla costruzione del basamento, dei singoli piani e del tetto e fino alle
parti architettoniche, alle parti impiantistiche.
Cioè devo scomporre il modellino che ho in una serie di pezzettini di lavoro. La procedura di
scomposizione del lavoro da fare ha come frutto, come risultato la WBS.
Quindi davanti alla domanda “cosa fare” che messa di fronte al totale (scope statement) diventa un
pochino disorientante, scomposta in pezzettini diventa molto più semplice, più gestibile, affrontabile.
CREARE LA WBS
Il PMBOK ci dice appunto che uno degli attrezzi da usare per la scomposizione è appunto il processo
di creazione della WBS.

78. La WBS è una struttura di scomposizione molto semplice – un albero rovesciato con radici in alto e
foglie in basso, che seguono le tipiche regole degli albero. Ogni suo elemento viene scomposto in una
78
serie di sotto elementi che lo rappresentano.
Esso viene suddiviso in una serie di argomenti.

79. 79
La WBS ha sostanzialmente due regole importanti:
– Trattandosi di una scomposizione devo avere almeno due elementi di livello inferiore che
raggruppano l’elemento di livello superiore.
– La completezza. Quando andiamo a scomporre, nell’andare a descrivere con maggior dettaglio,
con maggior fattori quello che vogliamo realizzare a livello superiore è importante che non
dimentichiamo niente. Quindi vale la regola del 100%. Alla cima della WBS c’è il mio modellino
della casa (lo scope statement)
Quindi la WBS assume un importanza anche comunicativa estremamente significativa. Quello che c’è
nella WBS è nel progetto, quello che non c’è non si deve fare. Quindi comunicativamente la WBS è
molto chiara.
Dopodiché ci sono degli elementi che ci aiutano a strutturare il nostro progetto in maniera più
efficace.
Lo scope statement è preciso nella sua definizione ma non ci permette di gestirlo: ha bisogno di
essere spezzato.
Le logiche di scomposizione dello scope statement ne sono diverse. Per es. una delle più diffuse è
quello di scomporre secondo la logica del ciclo di vita. Oppure potrei scomporre secondo blocchi di
prodotto.
Ad es. la casa la posso scomporre: i permessi, il disegno, il terreno, la costruzione, ecc. oppure potrei
dire: interrato, piano terra, primo piano, secondo piano, giardino.
Oppure potrei dividerlo per sotto progetti (ad esempio una serie di villette a schiera).
Nella WBS non si mette in evidenza il fattore tempo né il fattore costo.

80. Un’altra cosa importante per la WBS è capire fino a quando devo andare avanti nella scomposizione.
80
Poter arrivare a scomporre fino a dei dettagli direi quasi infiniti.
Ci sono per questo due criteri da tener presente: uno soggettivo e l’altro oggettivo.
Il primo (soggettivo) mi dice che mi fermo nella scomposizione quando quella cosa ha una sufficiente
chiarezza per me che la sto considerando o gestendo. Ad es. effettuare lo scavo per la fondazione per
me è già chiaro, non devo andare oltre a capire con che cosa devo scavare o altre modalità. Ma per
qualcun altro c’è bisogno di scendere a particolari ancora più raffinati perché magari vuole capire
ancora meglio come bisogna fare lo scavo.
L’altro criterio (oggettivo) è che il blocco d lavoro che ho scomposto, oltre ad essere sufficientemente
chiaro per me, deve anche avere qualcuno di riferimento, farsene carico. E questo qualcuno deve
essere una figura univoca. Devo avere sostanzialmente un responsabile ovvero un referente che sia
in grado di rispondere e che abbia una capacità di dirmi come vanno le cose.
Dunque questo livello di scomposizione mi porta ad una foglia del mio albero che assume il nome di
pacchetto di lavoro (Work Package): entità del lavoro globale, che ho da fare che ritengo gestibile,
chiara ed attribuibile ad una responsabilità univoca.
L’ultima indicazione è sulla modalità con la quale noi andiamo ad esprimere il lavoro da fare.

81. La domanda è sempre “cosa fare”: abbiamo lo scope statement (dichiarazione, istruzione
81
dell’ambito), ovvero il disegno globale del nostro progetto.
Se penso a “cosa fare” faccio riferimento tipicamente all’esecuzione: cioè effettuare lo scavo, gettare
la soletta, posizionare i ferri di armatura ed i casseri, ecc. parlare in termini (con il verbo all’infinito)
si ha l’immagine di una cosa in corso.
Quindi nell’ambito della formazione della WBS risulta più opportuno descrivere il lavoro non tanto
con l’azione che si fa per compiere quel lavoro ma con il risultato del lavoro. Quindi è diverso dire
“effettuare lo scavo per le fondazioni” o semplicemente “fondazioni”. In tale ultimo caso non si ha in
mente una cosa in corso bensì una cosa finita, e questo modo di descrivere mi è più chiaro.
Quindi esprimiamo la scomposizione non con l’azione ma con il risultato ovvero con il deliverable,
cioè con un risultato finale di quell’azione.
(segue esercizio sulla WBS)
La WBS è un deliverable che va approvata.
La WBS deriva da tutto quello che si è raccolto fino ad esso.
Quindi l’input della WBS è sicuramente il piano di gestione dell’ambito, la descrizione dell’ambito del
progetto (lo scope statement), la documentazione dei requisiti, i fattori ambientali aziendali e gli
Asset dei processi organizzativi.
Per Asset si intendono i beni aziendali, il patrimonio le attività, ecc.
Tra gli strumenti e tecniche che andiamo ad utilizzare ci sono prevalentemente la scomposizione
nonché il parere degli esperti.
Il risultato del processo di creazione della WBS è la baseline dell’ambito che comprende la WBS. La
Baseline dell’ambito è fatta di scope statement, quindi il totale di quello che dobbiamo realizzare, la
wbs scomposta opportunamente, nonché il dizionario della WBS che è una specie di allegato che noi
abbiamo per ogni casella della wbs che approfondisce l’argomento, quel deliverable.

82. 82

83. 83

84. 84

85. 85
TEMPLATE DI WBS E DIZIONARIO WBS

86. 86

87. 87

88. 88

89. 89

90. 90

91. 91

92. 92

93. 93

94. 94
CONVALIDARE L’AMBITO
In cosa consiste convalidare l’ambito.
Semplicemente dire: prendiamo i vari deliverable che abbiamo prodotto, ad es. tutti i pacchetti di
lavoro della wbs. Posto che abbiano superato il vaglio della qualità, cioè che quindi ci sia stata
un’ispezione che garantisce che quello che dovevamo fare con le caratteristiche che avevamo
identificato è stato realizzato, a questo punto dobbiamo ottenere l’accettazione di chi di dovere: il
cliente, lo sponsor, ma anche il responsabile del pacchetto di lavoro.
Convalidare l’ambito è lo strumento che il BOK ci offre per gestire questa serie di passaggi. Gli
strumenti per convalidare l’ambito sono il nostro progetto così come dovrebbe essere che sta nel
project management plan, i requisiti, i deliverable verificati e i dati sullo stato di avanzamento
(prestazioni) del lavoro che sono semplicemente dati della realtà, su come sta andando il nostro
lavoro.

95. 95
Gli strumenti e tecniche che utilizziamo sono:
– l’ispezione
– tecniche decisionali di gruppo
il risultato finale sarà o il deliverable accettato o rifiutato. In tale ultimo caso andiamo a generare
delle richieste di modifiche cioè delle evidenze del fatto che certe cose andrebbero cambiate. Le
richieste di modifica non sono le modifiche ma sono semplicemente delle proposte.
Trasformiamo quindi i dati in input in informazioni sullo stato di avanzamento del progetto. Per
ultimo adiamo ad aggiornare la configurazione del nostro progetto attraverso l’aggiornamento dei
documenti di progetto.
L’ultimo processo legato allo scope (ambito) è il controllo dell’ambito.
L’ultimo processo legato allo scope (ambito) è il controllo dell’ambito
CONTROLLARE L’AMBITO

96. 96
E’ un processo di controllo.
Controllare vuol dire sostanzialmente sempre tenere sempre presente come sarebbero dovute
andare le cose e confrontarle come vanno realmente.
Inoltre evidenziare anche se come avevamo pensato di fare è efficace, cioè ci porta ad ottenere i
risultati che il progetto si aspetta.
Controllare l’ambito nello specifico vuol dire: il “cosa fare” continua a servirci, ci serve ancora? Ed
inoltre: le cose stanno ancora così? – magari cambiando l’ambito ci si rende conto che il nostro
progetto non serve più.
Controllare l’ambito dunque rappresenta il monitoraggio dello stato dell’ambito del progetto e delle
specifiche di prodotto e di gestione delle modifiche alla baseline dell’ambito.
Il fatto che le cose da fare esplodano in maniera non controllata, cioè che ci tocchi fare delle cose che
magari all’inizio non erano previste e che in qualche maniera non vengono autorizzate ma vengono
semplicemente accavallate si chiama tecnicamente Scope Creep. Questo è uno dei problemi più
grandi che sorge nel progetto perché di fatto sposta tutte le conseguenze.
Se questo cambiamento dell’ambito non è controllato ci troveremo a non rispettare mai i parametri
del progetto.
Ogni modifica va interpretata rispetto al sistema” progetto” soprattutto quello dello scope perché le
modifiche dell’ambito rischiano molto spesso di andare ad intaccare le fondamenta del progetto: il
charter direttamente. Tutto quello che noi abbiamo impostato sul progetto nasce dallo scope, dalle
cose che dobbiamo fare.
Se cambia questo le conseguenze sono devastanti. I cambiamenti dello scope hanno ripercussioni
molto più ampie rispetto ad es. al cambiamento dei tempi di 2 giorni che magari risulta confinato alla
problematica dei tempi.
Controllare l’ambito, dunque, è l’attrezzo che il BOK ci fornisce per evitare tali situazioni.
L’inputo del processo “controllare l’ambito” è sicuramente il piano di project management, la
documentazione dei requisiti, la matrice di tracciabilità dei requisiti che allinea il requisito al beneficio
che devo andare a realizzare, i dati sullo stato di avanzamento dei lavori (come le cose stanno

97. andando realmente chiaramente per la quota legata all’ambito: e nell’integrazione che poi andremo
97
a mettere assieme tutti i pezzi) e gli Asset dei processi organizzativi.
Tra gli strumenti e tecniche che andiamo ad utilizzare per controllare l’ambito troviamo l’analisi dello
scostamento: confrontiamo il come sta andando con il come dovrebbe andare, il tutto attraverso la
baseline scope.
L’output di tale processo sono:
Informazioni sullo stato di avanzamento dei lavori: se prima erano semplicemente dei dati ora
attraverso le tecniche di scostamento possiamo vedere se tali dati che si trasformano in informazioni
ci portano ad avere delle conseguenze devastanti per il nostro progetto.
Naturalmente, come tutti i processi di controllo, inneschiamo la richiesta di modifica. Ci accorgiamo,
confrontando le cose che c’è qualcosa da cambiare, per migliorarlo, per adattarlo quindi
conseguentemente ad una richiesta di modifica, e poi andiamo ad aggiornare la raffigurazione del
nostro progetto nella forma organizzativa di piani e documentali.
Tutti i processi di controllo provvedono a fare queste cose.
Attraverso questo processo di controllo dello scope non ci limitiamo ad aggiornare la
rappresentazione del nostro progetto ma andiamo anche ad aggiornare il patrimonio della nostra
azienda e cioè aggiornamento degli Asset dei processi organizzativi: questi diventano le lesson
learned (le lezioni apprese, i miei errori che diventano le esperienze degli altri).

98. 98
ESEMPIO DI TEMPLATE GESTIONE DELL’AMBITO

99. 99

100. 100

101. 101

102. 102

103. 103

104. 104

105. 105

106. 106
TORNIAMO ORA ALL’INTEGRAZIONE
Vediamo come dirigere e gestire il lavoro del progetto.
Abbiamo visto prima il piano di project management, che quindi assorbe ora il Piano di gestione
dell’ambito (plan scope management) compreso la richiesta dei requisiti, la definizione dello scope e
la WBS.
Lo scope è uno di quelli che concorrono a creare l’organizzazione generale del progetto.
L’integrazione quindi guarda a tutto il percorso del progetto nella maniera più ampia e sistemica
possibile.

107. Parallelamente abbiamo le baseline che consolidano il piano di project management ed inoltre i dati
107
sullo stato di avanzamento del lavoro.
Il processo successivo, ma non in maniera cronologica del progetto, è quello di guardare l’andamento
del progetto in termini generali e cioè governare l’esecuzione del progetto durante la sua parte
realizzativa.
Gestire il lavoro di progetto significa semplicemente mettersi a servizio del progetto. Il P.M. di fatto
si deve preoccupare di far si che chi lavora sia nelle migliori condizioni di poter fare quello che gli è
stato richiesto di fare e quindi avvisarlo di quello che deve fare, garantirsi che la risorsa sia disponibile
e che abbia gli strumenti o le opportunità per muoversi. Naturalmente il suo compito è gestire anche
tutto quello che capita indipendentemente dal fatto che sia tutto organizzato, pianificato, ecc.
Quindi direzione ed esecuzione del lavoro, implementazione delle modifiche, per raggiungere gli
obiettivi del progetto.
Le fonti di tutto questo sono: principalmente il progetto che mi dice il lavoro da fare e quindi il piano
di project management, ma il lavoro da fare mi nasce anche dalle richieste di modifiche approvate.
Oltreché ai fattori ambientali ed aziendali ed agli Asset organizzativi dei processi.
Gli strumenti e tecniche per approfittare di queste fonti e sviluppare il lavoro che sia efficace per il
progetto sono: il parere degli esperti (esperienza), sistema informativo di project management
nonché le riunioni con il P.M. ed invitando gli stakeolder ed il gruppo di progetto, cioè persone che
hanno un ruolo efficace, che possono servire a qualcosa.

108. Le riunioni, tra gli strumenti e tecniche, sono uno dei mali del secolo perché sono tendenzialmente
sistemi costosi che servono per prendere delle decisioni e spesso vengono anche gestite malissimo.
La riunione dovrebbe essere un momento di confronto per trovare delle soluzioni: il problema lo
posso spiegare con una e-mail. Il BOK sulla gestione del meeting prova ad evidenziare alcune aspetti
108
di buon senso, alcuni obiettivi: scambio di informazioni, generazione di idee e presa di decisione.
Lo scambio di informazioni è una forma di riunione che in genere non è poi così necessaria, dipende
dai contesti. Sarebbe buona norma comunque non mescolare i tre obiettivi suddetti. La riunione
dovrebbe avere possibilmente un obiettivo. Tipicamente il lavoro sulla riunione viene strutturato con
un 50-60% prima della riunione: preparazione dell’agenda, diffusione della documentazione,
acquisizione del know-out della riunione. I partecipanti dovrebbero preoccuparsi di capire
esattamente tutta la documentazione che esplicita il problema prima di andare alla riunione in modo
di arrivarci già preparati e dare delle soluzioni. Un 10-15% dell’effort, dell’impegno, del costo
dovrebbe essere durante la riunione ed il rimanente, circa 25-30%, dovrebbe essere dopo la
riunione. Questo è grosso modo il peso da dare alle singole fasi della riunione.
Prepararsi per una riunione è un lavoraccio ed esso dovrebbe essere un momento estremamente
attivo in cui vengono fuori le cose e da lì vengono fuori una serie di conseguenze che di solito
dovrebbe essere anche in qualche modo strutturato, documentato, con risultati tangibili. Il verbale
della riunione dovrebbe contenere: il punto fondamentale dell’agenda, cosa abbiamo deciso e chi se
ne occupa, ed entro quando.
Usando dunque questi strumenti e tecniche generiamo l’output del dirigere e gestire il lavoro di
progetto che sono le cose che faccio, un deliverable. Quindi la generazione dei deliverable, non da
parte del P.M. in senso stretto ma da parte di tutto il team.
In tale fase evidenziamo una serie di situazioni e quindi dei dati sullo stato di avanzamento del lavoro,
ed evidenziamo una serie di necessità di cambiamento: nel momento ci accorgiamo che alcune cose
possono essere fatte in maniera diversa e quindi attiviamo le richieste di modifiche sempre nella
formula delle azioni correttive, preventive, e correzione dei difetti ed eventualmente degli
aggiornamenti.

109. Di seguito provvediamo ad aggiornare la raffigurazione del nostro progetto nella forma del piano e
109
dei documenti.
MONITORARE E CONTROLLARE IL LAVORO DEL PROGETTO (Monitor and Control Project Work)
Questo è un’altra fase, un ulteriore strumento che il BOK ci mette a disposizione, che corrisponde a
quello che abbiamo già visto nel controllare l’ambito, nel controllare i tempi, ecc.
Qui il punto di partenza, il tema che stiamo considerando, è l’integrazione: il tutto.
Il controllo è visto nell’insieme: ad es. un ritardo viene visto come conseguenza globale, sui costi, sui
rischi, sulle risorse, sul beneficio, ecc.
Monitorare è un’attività passiva: io leggo la situazione.

110. 110
Controllare è un attività attiva: vado a cercare, innesco un processo di ricerca della situazione.
Questo processo si occupa anche di raffrontare la mia baseline (cioè come dovrebbero andare le
cose) con la realtà non più su un singolo aspetto bensì sull’insieme del progetto. Naturalmente
raccogli le conseguenze, gli output di tutti i processi di monitoraggio e controllo che ci sono stati e
che fanno riferimento alle altre aree di conoscenza.
Tale processo non si limita altresì a controllare tutte queste cose, attivamente o passivamente, ma ci
ragiona su e fa delle valutazioni.
INPUT: Le fonti di tale processo sono: il piano di project management - una serie di previsioni sui
tempi, sui costi - le modifiche validate, nonché le informazioni sullo stato di avanzamento dei lavori
e non i dati che invece abbiamo visto precedentemente ad esempio nell’ambito. Infatti i dati sullo
stato di avanzamento provengono già dai singoli processi di controllo delle singole aree di
conoscenza. Ad es. i dati sullo stato di avanzamento del tempo vengono presi inconsiderazione
quando si farà la gestione dei tempi, ecc. e li ha già ragionati, trasformati.
Altro input sono i fattori ambientali ed aziendali nonché gli Asset dei processi organizzativi.
Gli strumenti e tecniche sono: i parere degli esperti (l’esperienza) soprattutto quanto si parla di
aspetti integrativi. Poi occorre analizzare la differenza tra realtà e piano con le tecniche analitiche:
analisi della regressione, metodi di raggruppamento, analisi delle cause. Elaborare sulle cause
richiede meno fatica ed è più efficace che lavorare sugli effetti. L’80% degli effetti nascono da un 20%
di cause e quindi lavoro sul 20% in quanto è più perseguibile.
Altri metodi importanti sono le analisi delle tendenze: il P.M. non si può limitare a dire come vanno
le cose. Ha senso parlare di come andranno le cose rispetto a come vanno.

111. Anche in tale processo ci sono come tecniche di utilizzo i sistemi informativi di P.M. nonché a finire
111
le famose riunioni.
Come output del monitorare e controllare il lavoro del progetto cosa abbiamo?
Sarà sostanzialmente il fatto che guardando come vanno le cose probabilmente alcune di queste le
devo cambiare. E di nuovo si propongono delle modifiche e comunicare a chi di dovere cosa fare.
(Richieste di modifica)
Altro output che diamo facendo un passaggio in più, cioè il passaggio dal dato all’informazione, alla
conoscenza si ottiene il report sullo stato di avanzamento del lavoro. Tale report dovrebbe essere
abbastanza standard che va concordato con gli stakeolder che va a comunicare nei loro confronti la
situazione del progetto non limitata a come stanno andando le cose ma anche quali saranno le
conseguenze.
Inoltre andiamo ad aggiornare il nostro progetto nella forma del piano e nella forma dei documenti.
E cioè aggiornare la configurazione del nostro progetto.

112. 112
ESEGUIRE IL CONTROLLO INTEGRATO DELLE MODIFICHE (Perform Integrated Change Control)
Fa parte del gruppo di processi di monitoraggio e controllo, quindi siamo sempre nel discorso del
controllare, ma dobbiamo controllare qualcosa in maniera globale, integrata. Infatti dentro questo
processo abbiamo la possibilità di recepire le varie richieste di modifiche che nascono dappertutto.
Il BOK sottolinea che quando mi accorgo che c’è qualcosa da fare di diverso, non lo faccio mai.
L‘impatto di una richiesta di modifica, ovvero il suo costo, è vero fino a che non viene approvato.
Bisogna prendere la richiesta di modifica, valutarla nella globalità del progetto, ragionare sui
costi/benefici, sulle alternative, sulla possibilità di fruizione e poi decidere se accettare questa
richiesta di modifica oppure no. In alcuni casi il fatto di non accettare una richiesta di modifica può
indicare di bloccare o chiudere il progetto. Vuol dire che ho fatto le mie valutazioni e ho visto che non
vale la pena andare a vanti se devo fare quello.
Il potere decisionale viene sempre dallo sponsor e non dal P.M. Quest’ultimo semmai crea il terreno
allo sponsor per poter decidere consapevolmente, ma il titolare del beneficio è lo sponsor ovvero il
program manager, il capo, ecc.

113. Eseguire il controllo integrato delle modifiche vuol dire avere questo processo che mi permette, dalla
richiesta di modifiche, valutare se vale la pena incorporarlo nel progetto e quindi realizzarlo oppure
113
no.
Per fare tutto questo ho bisogno di creare una struttura organizzativa. Intanto il percepire le
modifiche, raccogliere le richieste di modifica e analizzarle è un compito del P.M. in quanto
quest’ultimo è la figura più preparata a comprendere tutte le sfaccettature del progetto e quindi a
comprendere tutte le conseguenze dell’accettare o rifiutare una modifica rispetto al progetto. Ma se
lui non è in grado, quanto meno deve sapere da chi andare a raccogliere queste informazioni: essere
capace di farsi aiutare.
Ma in definita è lui che ha la visione globale del progetto.
Le modifiche, nell’ottica del BOK, devono rientrare, in quanto richieste, in un registro, o forma scritta.
Anche le richieste di modifica rifiutate vengono registrate nel registro delle modifiche.
Chi deve decidere se accettare o meno una richiesta di modifica? Il P.M. ha l’incarico di documentarla,
di capire come va a finire e quali sono le conseguenze, dopodiché sulla base dei costi/benefici
qualcuno deve decidere se vale la pena o no. Il BOK è più specifico. Esso istituisce un comitato CCB
(Centre Control board) comitato di gestione ed approvazione delle modifiche.

114. Esso potrebbe essere lo stesso P.M., quando l’entità della modifica è piccolina e gli effetti di tale
modifica stanno all’interno delle tolleranze, delle possibilità di movimento, dell’autorità che lui ha.
Può essere lo Sponsor quando la modifica ha delle conseguenze su aspetti più ampi del progetto; può
essere un comitato più articolato. Il CCB è un nome generico che il BOK utilizza per rappresentare
114
una entità che ha autorità a fare questo.
Il CCB:
Una conseguenza della gestione delle modifiche è ovviamente l’aggiornamento del piano di
configurazione del nostro progetto ovvero il piano di project management, nonché l’aggiornamento
dei documenti di progetto.
Quindi eseguire il controllo integrato delle modifiche è un processo annegato all’interno
dell’integrazione ed è un processo fondamentale che ha un impatto molto vasto per l’intero
progetto.

115. Quali sono gli input al processo “controllo integrato delle modifiche”: sicuramente il progetto ovvero
il piano di project management, il report sullo stato di avanzamento del lavoro nonché le richieste di
modifica; dopodiché abbiamo i soliti fattori ambientali ed aziendali e gli Asset dei processi
115
organizzativi.
Gli strumenti e tecniche che metto in atto sono: l’esperienza, le riunioni nonché gli strumenti di
controllo delle modifiche: situazioni per capire come vanno le cose, per cercare di articolare
diversamente la nostra struttura.
Il risultato di tale processo (output) è:
– le richieste di modifiche approvate dal CCB; nonché il registro delle modifiche; aggiorniamo il
nostro progetto (piano di project management) ed infine aggiornamento dei documenti di
progetto.
il processo del controllo integrato delle modifiche lo applichiamo quando serve, ovvero quando ci
sono delle modifiche da fare (quasi sempre).

116. 116
CHIUDERE IL PROGETTO O UNA FASE (Close Project or Fase)
La conclusione riguarderà ciò che deve essere chiuso. Nel gruppo di processi dobbiamo chiudere gli
approvvigionamenti e quindi il progetto o la fase. Anche i progetti interrotti devono avere una
chiusura.
Esso è un processo di completamento di tutte le attività appartenenti ai gruppi di processi di project
management (vedi integrazione) al fine di completare a livello formale il progetto o una fase.

117. 117
Chiudere un progetto, o una fase, significa 3 cose:
– chiudere tutto, chiudere un contratto con i fornitori, professionisti, esperti, ecc. abbiamo pagato
tutto;
– l’archiviazione di quello che abbiamo fatto consistente di restituire all’azienda quel patrimonio
cha abbiamo in qualche maniera elaborato nel nostro progetto. Archiviamo il progetto e le lesson
learned nonché le e-mail, gli appunti, e quindi anche la documentazione non ufficiale. Queste
ultime cose potrebbero essere molto utili al P.M. per rintracciare tutte le soluzioni (non applicate
dal P.M.) ovvero se occorre aiutarsi per risolvere determinati problemi giudiziari.
– Trasferire i prodotti, servizi o risultati del progetto alla fase successiva o alla produzione e/o alle
attività operative.
Gli elementi in input per tale processo sono:
– Il piano di project management, il progetto così com’è in quanto il progetto è finito e per cui non
c’è più differenza tra il piano e la realtà.
– I risultati che ho prodotto: i deliverable accettati in quel momento o alla fine.
– Gli Asset dei processi organizzativi
Gli strumenti e tecniche da usare sono:
– Il parere degli esperti: per a chiusura amministrativa che assicurano che la chiusura del progetto
o di una fase sia eseguita secondo gli standard adeguati
– Le tecniche analitiche
– Le riunioni

118. 118
L’output di tale processo è:
– Transizione del prodotto, servizio o risultato finale: accompagniamo il progetto nelle mani di
qualcuno che ne dovrebbe decretare il successo. Da qui in poi nasce il successo del progetto.
– Aggiornamento degli Asset: archiviazione, lesson learned, file di progetto, documenti di chiusura
del progetto o di una fase, dati storici.