1 introduzione

6
1.1 DEFINIZIONE DI PROGETTO E SUE CARATTERISTICHE
1. Concetti fondamentali
Per il PMBOK:
Il progetto è una iniziativa TEMPORANEA per creare un prodotto, un servizio,
o un risultato con caratteristiche di UNICITA’
Si crea un progetto per avere un prodotto, servizio e risultato.
Quando parliamo di progetti, quali sono le variabili cui generalmente facciamo riferimento?
TEMPI – COSTI – RISORSE – REQUISITI DEL CLIENTE – FATTIBILITA’ (propedeutico all’avvio del
progetto) – RISCHIO (è la variabile molto importante in quanto progettare - dal latino – vuol dire
“guardare in avanti”).
Considerando che chiunque non potrà mai sapere cosa succederà in futuro, i progetti sono
rischiosi per definizione ed è per questo che spesso i progetti falliscono o non rispettano i tempi e i
costi.
Non abbiamo strumenti matematici per stabilire in maniera infallibile come andrà a finire un
progetto.
Gestire efficacemente un progetto sicuramente aumenta la probabilità che lo stesso abbia successo,
ma non te lo garantisce al 100%. C’è sempre una componente di rischio.
Il rischio è dunque una variabile che è insita etimologicamente nel progetto. Tuttavia nelle definizioni
date nei vari testi la variabile “rischio” non compare mai.
Archibald (1994) definisce il progetto uno sforzo complesso, di regola, di durata minore di tre anni.
Tuttavia i progetti possono durare più di tre anni. Archibald in realtà, già all’epoca, è stato
lungimirante in quanto oggi un progetto, se dura più di tre anni, rischia di non essere più competitivo
poiché la velocità con cui cambiano le richieste di mercato sono tali che le esigenze che prima hanno
dato avvio al progetto non risultano più in linea con le richieste di mercato.
Per cui oggi un progetto deve durare un anno o poco più.

Le due caratteristiche TEMPORANEITA’ ed UNICITA’ nella definizione di progetto, si ritroveranno
sempre all’interno dei progetti.
– Temporaneo non vuol dire di breve durata ma vuol dire che tutti i progetti sono uno sforzo
circoscritto con una data di inizio e di fine ben individuabile, o comunque che abbiamo un range
di intervallo temporale ben definito entro il quale il progetto ha un inizio ed una fine.
Il progetto deve rispondere alla caratteristica di “efficacia” (cioè fare le cose giuste): cioè il
progetto finisce bene quando realizza un prodotto conforme ai requisiti del cliente, in linea con
quelle specifiche dettate dal cliente.
Il progetto deve essere anche “efficiente” (cioè fare le cose nel modo giusto). Cioè devo rispettare
i tempi e i costi concordati con il committente.
Ad esempio se per prendere ad un esame 30 e lode ho impiegato un anno e mezzo sono stato
sicuramente efficace ma non sono stato efficiente in quanto il tempo è stato spropositato per
raggiungere quell’obiettivo.
Quindi un progetto finisce bene quando vado a presidiare entrambi gli obietti: Efficacia – fare le cose
giuste e realizzare un prodotto, servizio e un risultato (deliverable) conformemente ai requirements
(requisiti) del cliente. Ed Efficienza: fare le cose nel modo giusto, ovvero la modalità con la quale si
raggiunge un obiettivo conforme ai tempi ed ai costi ed a un livello qualitativo concordato dal cliente.
Ma un progetto può finire anche male in quanto è possibile che in corso d’opera ci si renda conto che
non risulta più economicamente conveniente proseguire o comunque non si può più raggiungere gli
obiettivi che mi ero prefissato, oppure perché è venuto meno quel “trigger event” (scintilla) che mi
aveva dato avvio al progetto stesso (cioè quando viene meno una richiesta di mercato, una richiesta
del cliente, un processo tecnologico, i requisiti legali, ecc.) Quindi quando viene meno la
giustificazione che mi aveva dato avvio a quel progetto non ha più senso proseguire.
Oppure quando il portfolio manager può decidere che quel progetto non dà più un contributo, come
originariamente previsto, al raggiungimento previsto, cioè al raggiungimento degli obiettivi strategici
aziendali.
Il progetto è realizzato altresì da un team di persone allocate sullo stesso progetto e allo stesso tempo
è un team temporaneo perché a fine progetto le risorse che lavorano sul progetto verranno o
7

riallocate su altri progetti o torneranno ad essere riassegnate all’organigramma aziendale che
rappresenta il corretto funzionamento della macchina organizzativa.
Nell’organizzazione aziendale si parla di Task Force: è una unità organizzativa ad hoc che viene creata
per risolvere un determinato problema. Il team di progetto è la task force perché viene creata ad hoc
per realizzare quegli obiettivi di efficacia ed efficienza che sono stati concordati con il cliente.
Non è temporaneo invece il prodotto, servizio o un risultato (deliverable) del progetto (nella nuova
versione del PMBOK si parla anche di un miglioramento di un prodotto o servizio esistente) Un
prodotto è ad es. una galleria (prodotto realizzato non può essere temporaneo) non può essere
certamente temporaneo, anzi deve essere il più duraturo possibile a meno di interventi di
manutenzione ordinaria.
8
– UNICITA’.
Per quanto i progetti possano avere degli elementi ripetitivi, ci sarà sempre qualcosa che andrà a
connotare il progetto come Unico. Diversi saranno i personaggi, i requisiti del cliente, l’ambiente
circostante ecc.
– Un’altra caratteristica del progetto (che neanche nel PMBOK si evince) è quella della
Elaborazione Progressiva (strettamente legato al concetto di Rischio): cioè quanto vado ad
intraprendere un progetto non ho mai a disposizione tutte le informazioni, che mi farebbero
comodo avere, per poter affrontare il progetto in maniera razionale ed assoluta al 100%. Quando
lavoro sui progetti si dice che io opero in condizioni di razionalità limitata. Cioè man mano che io
vado avanti con il progetto mi si rilevano informazioni che prima non avevo e quelle stime che
avevo fatto all’inizio diventano sempre più accurate ed approfondite. Se non ci fosse
l’Elaborazione Progressiva i progetti non fallirebbero, perché sarebbe sufficiente mettere le cose
in fila che automaticamente mi porterebbero ad un risultato positivo, cosa che in realtà non è
così. In definitiva nel corso del progetto devo andare a governare variabili che si relazioneranno
in maniera differente. Il progetto genera innovazione e cambiamento – è collegato al cosiddetto
“change the business”. Il processo e le procedure, che sono ripetitivi, non sono dei progetti in
quanto all’interno ci sono delle routine che non fanno cambiare il business.
DEF.: elaborazione progressiva: continuo miglioramento e approfondimento di un piano man
mano che, con l’avanzamento del progetto, diventano disponibili informazioni più specifiche e più
dettagliate e stime più accurate.

Quando facciamo le stime in fase di avvio, esse si chiamano stime grezze (si utilizza l’acronimo
ROM – Raw Order of Magnitude – Stima grezza o grossolana), legata alla pianificazione.
9
In fase iniziale di progetto, la stima può variare tra – 25% e + 75%
Altri 3 concetti importanti relativamente alla caratteristica che deve avere un “Progetto” sono:
– VINCOLI (constraints) – dettati dal cliente, dallo sponsor. Essi limitano le prestazioni del progetto
(vincolo sul badget, sulla schedulazione, ecc.);
– REQUISITI (requirements) – esplicitate dal cliente, dallo sponsor e dagli stakeholder, da
individuare al più presto per indirizzare efficacemente i progetto sin all’inizio;
– ASSUNTI (assumptions) – Ipotesi – sono molto importanti anche se si sentono parlare poco. In
quanto sono una caratteristica di tutti i progetti collegati al concetto di elaborazione progressiva
e quindi di rischio, in quanto opera in condizioni di razionalità illimitata e quindi devo fissare dei
paletti, cioè devo ipotizzare che alcuni fattori siano veri, reali pur non avendo la matematica
certezza che essi lo siano. Sulla base di tali certezze inizio a pianificare.
Altro concetto importate sono i DELIVERABLE (ovvero un output):
– Si definisce deliverable il prodotto, servizio , risultato che esce a valle del progetto.
Il progetto non deve necessariamente generare un qualcosa di fisico, ma anche un servizio o un
risultato. Le società di consulenza, ad es., generano un servizio; vengono chiamati per risolvere un
problema. Il loro deliverable è la soluzione di quel problema. Per formalizzare tale risoluzione essi lo
scrivono su un documento che chiamano “deliverable”: formalizzazione del risultato della risoluzione
del problema.
Ad esempio: una ricerca di mercato per capire se un determinato trend sul mercato è in atto o meno:
il risultato del progetto è SI o NO. Di fatto il vero deliverable è l’esito – “si o no”.
Tuttavia il deliverable è anche un prodotto tangibile.
I deliverable possono essere di due tipi – Fisici e Documentali.
Quello fisico è quello che ci chiedono di realizzare: un ponte o una macchina

Quello documentale: per realizzare una macchina o una moto c’è bisogno di un disegno tecnico che
sia approvato. Quel disegno è una deliverable documentale intermedia al progetto e propedeutico
alla realizzazione di quella finale; ma è una deliverable fondamentale.
10
Il deliverable documentali possono essere quindi intermedi e finali.
Importante: i DOCUMENTI del P.M. sono deliverable documentali. Non esistono documenti del P.M.
fisici.
Ad esempio il progetto tecnico di un edificio, e quindi la sua approvazione, è un “deliverable” di
progetto e non deliverable di Project Management.
Ad es. il Piano di Project Management è un deliverable documentale.
Il progetto ha due cicli di vita paralleli: uno Tecnico ed uno Gestionale. Quello tecnico lo segue i
project Enginneer o Specialista o qualsiasi altro; mentre quello gestionale lo segue il P.M.
Il P.M. segue il ciclo di vita gestionale del progetto e non il ciclo di vita tecnico. Esso non è un tecnico.
Può anche non capirci niente dell’area di intervento del progetto. Infatti il P.M. può andare in
qualsiasi azienda in quanto esplica le modalità gestionali che sono comuni a tutte le aziende e
descritte nel PMBOK.
Il P.M. Indirizza, coordina e gestisce il progetto.
Con la 5° edizione del PMBOK si è introdotto un altro concetto dei deliverable. Oltre a creare un
prodotto, servizio e risultato, crea un miglioramento in un prodotto.
Differenza tra PROGETTO e OPERATION.
L’Operation gioca un ruolo molto importante in due momenti:
– a valle del progetto: Ad es. un progetto è finalizzato ad aprire una nuova filiale bancaria. Quando
la filiale apre al pubblico il progetto è finito. Dopodiché in quella filiale verranno erogati dei servizi
bancari. Ogni dipendente avrà una funzione specifica. Il cliente che andrà in filiale potrà
richiedere un’apertura di conto corrente ovvero una concessione di mutuo, ecc.
Un progetto è temporaneo ed è unico – finisce quando apre una nuova filiale.

Le Operation non hanno fine: ci sono dei servizi routinati e ripetitivi e che non hanno mai fine
non nel senso che “fai sempre la stessa cosa”, ovvero si ha un catalogo di servizi predefinito
fornito al cliente e che deve svolgere il lavoratore.
– durante il progetto: Le operation sono importanti non solo a valle del progetto ma anche durante
il progetto.
Ad es. l’amministrazione del personale che ha il compito di elaborare i cedolini paga. Cosa
importante in quanto a fine mese il lavoratore riceve la busta paga e quindi lo stipendio. Se non
ci fosse l’amministrazione del personale coinvolto direttamente sul progetto e che a fine mese
non eroga i cedolini la cosa non andrebbe bene. L’amministrazione del personale tuttavia non è
coinvolta direttamente nel progetto ma è una Operation che eroga servizi per il progetto.
Quando il progetto finisce l’amministrazione del personale rimane e continua ad erogare benefici
a servizio di altri progetti e a beneficiare le altre unità di line o di staff per assicurare il corretto
funzionamento della macchina organizzativa.
Quindi l’operation può essere anche un ufficio che produce output ripetitivi il cui obiettivo è
quello di sostenere il business dell’organizzazione.
11
I fattori critici di successo nei progetti
1) obiettivi chiari e condivisi: spesso il cliente non sa cosa vuole e all’interno del team non c’è
chiarezza e condivisione degli obiettivi. Invece nel momento in cui c’è uniformità di veduta su
ciò che si vuole fare, vuol dire già tracciare una linea ben marcata molto più semplice per il
raggiungimento di quegli obiettivi di efficacia e di efficienza del progetto.
Gli obiettivi devono essere SMART: acronimo di Specific o simple (Semplice); Materiable
(misurabile) in quanto l’obiettivo qualitativo sarà sempre oggetto ad interpretazione non
omogenea. Occorre dare una metrica di misurazione; Achievable (auspicabile – realizzabile -
raggiungibile) cioè alla portata delle risorse che ho a disposizione: ad es. risorse umane,
finanziare che ho a disposizione. Realistic: a prescindere dall’avere il budget e le risorse a
disposizione occorre verificare che si può comunque ottenere il raggiungimento
dell’obiettivo. Time: è sempre necessaria sapere il tempo occorrente per dare via il progetto.

Alcuni testi dicono che il progetto deve essere SMARTER dove la E sta per Exciting (eccitante):
ciascuna risorsa rende il meglio di se in contesti in cui è sotto pressione. Ovvero quando si è
in un uno stato di Stress.
12
Quest’ultimo si suddivide in due forme: Eustress e Distress.
L’Eustress è quello positivo mentre il Distress è quello negativo.
L’Eustress è quando stai nella giusta pressione che ti permette di dare il meglio di te.
La R sta per Record, cioè tracciare man mano lo stato di avanzamento verso il raggiungimento
degli obiettivi.
Gli obiettivi quando sono condivisi da tutte le persone sono allineate e si riescono a fare le
cose con maggiore cognizione di causa potendo dare un valore aggiunto al mio progetto. In
tal caso si evitano le asimmetrie informative (cioè chi dice una e chi dice un’altra cosa ovvero
capire cose diverse); nel caso della gestione dei tempi l’incongruenza temporale dettata dal
Team viene inglobata dal P.M. nella “contingency plan” (vedi Feeding Buffer) che il P.M. tiene
conto per se e non lo dirama ai componenti del team: è una sorta di misura di emergenza
temporale che si impone il P.M.
2) Capacità di influenza e presenza dello SPONSOR di progetto.
Lo sponsor su un progetto non è chi tira fuori i soldi o fa pubblicità promozionale, bensì è colui
che ci mette la faccia sul progetto ed è colui che sul progetto ci crede a tal punto da sponsorizzare
questa iniziativa verso il Top Management affiche avi quell’iniziativa dando dignità al progetto.
Quindi lo sponsor gioca un ruolo politico perché assicura il committente (l’impegno emotivo – il
crederci) ed allo stesso tempo assicura le risorse finanziare e cioè assicura che ci sia qualcuno che
approvi le risorse finanziare per quel progetto, oppure se ha un badget a disposizione, egli stesso
può reperire le risorse finanziare per il progetto. E’ colui che all’interno dell’azienda promuove
quell’iniziativa perché ci crede e perché è convinto che possa dare un impatto positivo all’azienda.
Avere un forte sponsor sul progetto, come fattore di successo (il che vuol dire che se c’è un
problema viene subito risolto), dà il via libera al raggiungimento degli obiettivi del progetto.

13
Lo sponsor c’è sempre a capo di un progetto.
Se non c’è uno sponsor chi sarà l’ideatore dell’iniziativa? in genere all’interno dell’azienda c’è un
Direttore Commerciale che è lo sponsor di quell’iniziativa.
3) Aspettative realistiche - pianificazione realistica – comprendere e adattarsi al naturale ciclo
della vita del progetto.
La pianificazione deve essere realistica. E’ impensabile per finire in anticipo. Questo può voler
dire che il P.M. ha potuto sbagliare qualcosa. Ci deve essere il giusto equilibrio tra le
peculiarità del progetto all’interno del contesto in cui esso e calato adattandosi al naturale
ciclo della vita.
4) Prendere in considerazione l’esperienza passata
Non rifare le stesse cose fatte ai precedenti progetti, ma l’esperienza serve per valorizzare gli
aspetti positivi e quindi cercarli di migliorarli successivamente.
5) Predisporre i sistemi di pianificazione e controllo
Questo è proprio l’attività principale del P.M. – predisporre delle Mileston più frequenti: è un
punto all’interno del progetto importante e significativo. Sono definite a contratto perché in
corrispondenza di ogni M. c’è il rilascio dei soldi (ad esempio). Quindi è fondamentale per
autofinanziare il progetto. In corrispondenza di ogni M. il P.M. va a valutare quello chè è lo
stato di salute del progetto, quindi qualche M. in più gestionale e scelta dal P.M. in aggiunta
a quelle contrattuali può essere foriera di aspetti particolarmente efficaci. Quando si
tratteranno i Costi si vedrà che in corrispondenza di una M. il P.M. applica una tecnica
dell’Earned Value finalizzata a vedere se siamo in linea con i tempi o con i costi.
6) Avere un chiaro confine di progetto (SCOPE)
Scope vuol dire ambito – perimetro; lo scope mi dice tutto ciò che fa parte del progetto e
tutto ciò che è fuori dal progetto. Se blindiamo il progetto in termini di confini e lo si condivide
con il cliente, il progetto prende una strada (probabilmente positiva) se invece non viene
definito un ambito (scope) il cliente chiederà sempre qualcosa in più da aggiungere, in quanto
nel caso di un dubbio come si farà a dimostrare che quell’attività non rientrava nel progetto.
Lo Scope è una delle attività più importanti.

Esiste il fenomeno dello SCOPE CREEP: incremento strisciante dell’ambito di progetto. E’
umano che il cliente prova ad aggiungere, nel tempo, delle attività al progetto: in tal caso il
cliente riesce a farsi fare un mega progetto (a piccoli passi) senza pagare niente.
14
7) Utilizzare un vocabolario comune
Esso è fondamentale in quanto spesso si creano incomprensioni.
8) Concedere al P.M. la necessaria autorità
Al P.M. gli vanno date le risorse, le autorità e gli strumenti necessari per farlo altrimenti non
potrà mai giocare il suo ruolo. Se il P.M. non ha le possibilità di scegliere le risorse che vuole,
o non ha un badget, esso non può svolgere il proprio ruolo.
9) Prevedere misure di emergenza (Contingency plan)
Il P.M. deve creare delle riserve: una su ogni singola attività e l’altra in generale sul progetto.
Sulla singola attività la riserva non la svelo alle mie risorse. La riserva sul progetto è
generalmente fatta sui costi e tempi. E’ come avare due salvadanai: uno sui tempi e l’altro sui
costi.
10) Identificare al più presto gli Stakeolder e pianificare una adeguata comunicazione.
E’ vitale capire al più presto chi sono gli interlocutori del mio progetto ed individuare con loro
una adeguata modalità con cui rapportarmi e comunicare con loro, in quanto solo in tal caso
tutti quelli che sono coinvolti nel progetto sono informati, allineati e che hanno condiviso la
documentazione, il progetto non avrà alcun intoppo.
Perché i progetti nascono?
– Perché ci può essere una richiesta di mercato;
– oppure delle opportunità strategiche/aziendali
– ovvero una esigenza sociale e considerazioni ambientali (introdotta nella 5° edizione del PMBOK)
– richiesta del cliente
– il progresso tecnologico
– requisiti legali (magari faccio un progetto perché me lo richiede la legge)
DEFINIZIONE DI PROJECT MANAGEMENT (Gestione progetti)
Quando diciamo progettare, per noi è sinonimo di pianificare. Progetto vuol dire non solo
pianificare ma anche eseguire (implementare).

I manager gestiscono, indirizzano e coordinano. Il P. Management è una attività di indirizzo e
coordinamento del progetto. Il P.M. non può prendere decisioni. Le decisioni vengono prese da
qualcuno di più alto livello (ad es. anche lo sponsor). Quindi Project Management vuol dire gestione
di un progetto, indirizzare e coordinare un progetto andando ad applicare le conoscenze, le capacità,
gli strumenti e le tecniche.
Gestire efficacemente un progetto aumenta la probabilità di raggiungere quegli obiettivi di efficacia
e di efficienza, ma nessuno mai mi potrà assicurare al 100% che quegli obiettivi saranno raggiunti.
Gestire un progetto vuol dire che si ha una visione realistica del progetto durante tutto il ciclo di vita
dello stesso; cioè sapere sempre come si trova il progetto e allo stesso tempo permette di tracciare
un quadro direzionale di dove andrai; ti permette di responsabilizzare tutti gli attori coinvolti nel
progetto, perché si eviteranno situazioni in cui ad es. due persone stanno facendo la stessa cosa,
mentre magari la cosa importante nessuno la sta facendo.
P. Management, ossia gestire, indirizzare e coordinare, vuol dire anche DELEGARE. Il P.M. delega a
chi di competenza quello che deve fare. Il bravo P.M. frena il responsabile tecnico il quale ha la
tendenza a non delegare.
Quindi gestire un progetto vuol dire assegnare le attività a qualcuno che sa quello che deve fare,
quando deve iniziare e quando deve finire. Esso tuttavia, non è una delega “totale” bensì è una delega
controllata dove il P.M. nell’arco di un tempo dovrà monitorare come sta andando il progetto.
15
Il P. Management è quindi uno strumento di delega.
ATTIVITA’ PRINCIPALI (CORE) DEL P.M.
1) Identificare i requirement del cliente
2) Considerare le loro esigenze
3) Comunicare, collaborare e gestire efficacemente gli stakeholder
4) Bilanciare i molteplici vincoli di progetto.
Il P.M. deve sempre gestire i progetti nel rispetto del Triplice Vincolo. Questo è quello che
generalmente viene chiamato Triple Constraints (triplice vincolo).
I vincoli a cui si farà riferimento sono 3: TEMPI COSTI E QUALITA’ con l’Ambito all’interno del
triangolo.

Nel momento in cui si modifica uno dei tre termini suddetti, fermo restando la seconda, la terza viene
inevitabilmente impattata/influenzata.
I casi più realistici sono quelli che ti chiedono delle attività in più ovvero tempi più brevi ovvero costi
inferiori. Nel momento in cui chiedono tempi più brevi succede che o bisogna aumentare i costi in
quanto dovrò assumere delle persone o pagare dello straordinario, oppure se non si possono toccare
i costi dovrò intervenire nello Scope facendo qualche attività in meno. Con i costi più bassi nel corso
del progetto, o si allungano i tempi oppure riduco lo Scope.
16
Per i PMBOK il Triple Constraint è costituito da TEMPI – COSTI – AMBITO.
Se ho un progetto dettato da una scadenza normativa i tempi sono importanti.
Se ho un progetto ad es. di lancio sul mercato di un nuovo farmaco la qualità è importante.
Tuttavia ci sono altre variabili importanti soprattutto nel momento in cui ci sono delle compressioni
dei tempi e pertanto le risorse ne risentono principalmente.
Un'altra variabile è il Rischio in quanto con l’accorciamento dei tempi, i rischi in un progetto
aumentano. Infatti il disegno ideale non è un triangolo ma è una piramide avente per base il rischio,
il volume è l’ambito ed il resto dei lati sono i tempi, costi, qualità e risorse.
CONCETTO DI PROGRAMMA
Cosa è un programma?
E’ un insieme di due o più progetti che hanno un nesso causale in comune la cui gestione congiunta
permette di realizzare sinergie che altrimenti non riuscirei a realizzare qualora andassi a gestire i
singoli progetti. Andrò a realizzare dei benefici ed un livello di controllo che non avrei se andassi a

gestire i singoli progetti. L’elemento fondamentale è che ci deve essere un nesso comune: le stesse
risorse condivise, gli stessi rischi, la stessa tecnologia, lo stesso cliente, gli stessi obiettivi.
Ad es.: esiste la FAO con una costola che gestisce un programma costituito da più progetti che hanno
un nesso causale in comune che è quello di avere tanti progetti con l’obiettivo in comune di superare
il problema della fame nel mondo.
Pertanto un programma ha necessariamente dei progetti, ma un progetti non necessariamente deve
far parte di un programma.
17
Ad es.: un quotidiano che esce in edicola è un progetto o un programma?
Il numero che esce in edicola è un progetto perché è temporaneo, è unico. Mentre alla base di tutto
questo c’è un programma che permette di far uscire con cadenza giornaliera il quotidiano.
Il program management non è altro che un gradino di livello superiore che gestisce a livello alto quello
che fa il P.M.
Il master plan lo gestisce il program manager ed ha l’obiettivo del conseguimento dei benefici.
Il Program manager può ottimizzare le risorse all’interno di tutti i progetti (se le risorse sono
condivise). In tal caso ottengo un controllo e dei benefici che diversamente non potrei ottenere.
Su ogni progetto però esiste ogni singolo P.M.
Programmare per definizione, vuol dire gestire un programma. Schedulare vuol dire pianificare i
tempi. Progettare vuol dire pianificare ma anche implementare.
CONCETTO DI PORTFOLIO
L’ultimo concetto anch’esso importante è il concetto di Portfolio.
E’ un insieme di progetti, programmi, gestiti come un gruppo per facilitare la gestione efficace del
lavoro complessivo, allo scopo di raggiungere obiettivi aziendali strategici. I progetti o i programmi
del portfolio possono non essere necessariamente interdipendenti o direttamente collegati.
Esso va ad analizzare il contributo che una Deliverable di progetto lascia in eredità all’azienda in
termini di raggiungimento agli obiettivi strategici aziendali.

Il portfolio management attiva i progetti e ricerca i contributi strategici aziendali. Esso ha una visione
decisamente più ampia del P.M.
Strategia vuol dire prendere una decisione su dove vogliamo andare (Vision). Questo in genere è di
competenza del top manager o executive. Questi si servono di un portfolio manager che prendono
in pasto la strategia disegnata dal top manager e la traducono in programmi o progetti. Ecco che
quindi i programmi e i progetti non sono altro che strumenti con cui andare ad implementare la
strategia aziendale. Il Portfolio manager attiva programmi o progetti che non sono altro strumento
con cui realizzare la strategia aziendale definita a livello di Top management.
Nelle aziende un program manager può mancare ma un portfolio manager c’è sicuramente. Magari
si chiamerà in un altro modo!!
Esso abilita i progetti perché vede in ciascuno di essi un contributo al raggiungimento della strategia
aziendale. Di questo si occupa il Portfolio management.
Quindi lo Sponsor è colui che ci crede e vuole far partire il progetto ma alla fine chi decide se il
progetto parte o no è il Portfolio manager.
18
N.B.
Il P.M. ha degli obiettivi di efficacia ed efficienza nel realizzare la deliverable con plaints e
requirement aziendali nel rispetto dei tempi e costi concordati con il cliente;
Il Programma ha l’obiettivo di realizzare i benefici che altrimenti non riuscirei a conseguire qualora
non li gestissi congiuntamente;
Il portfolio management ha l’obiettivo di verificare il contributo di ogni progetto e programma al
raggiungimento degli obiettivi strategici aziendali.
Per il PMI: L’INSIEME DI PROJECT, PROGRAM E PORTFOLIO management: questo è il classico
modello di maturità di crescita della cultura del P.M.
E’ un processo a gradini per quanto riguarda la cultura del P.M.
Il portfolio management guarda più all’efficacia laddove il P.M. guarda anche all’efficienza.
Un progetto può anche terminare sia perché il cliente non vuole andare avanti, ma anche perché il
Portfolio manager può valutare che quel progetto non è più utile al raggiungimento degli obiettivi
strategici aziendali. Allo stesso tempo però potrebbe decidere di far partire una iniziativa progettuale

che ha un nesso causale con un altro progetto già in corso (per costituire così insieme un programma).
Quindi il portfolio management è anche dinamico: esso guarda sia i progetti che i programmi attuati
ma anche a quelli prospettici e futuri.
Un progetto ha sempre una fine così come un programma, un portfolio non avrà mai una fine. Se così
fosse l’azienda chiuderebbe.
Il compito di un portfolio manager è avviare i progetti o programmi ma anche di prioritizzarli per il
raggiungimento degli obiettivi strategici aziendali.
Le tecniche di applicazione della scelta della tipologia che mi porta al raggiungimento suddetto, sono
le stesse della valutazione degli investimenti finanziari.
19
CICLO DI VITA TECNICO E GESTIONALE DEL PROGETTO E DEL PRODOTTO
Per ciclo di vita del progetto (Project Life-Cycle) s’intende l’insieme delle fasi tecniche in cui un
progetto è diviso.
I cicli di vita di progetto hanno alcune caratteristiche in comune:
o I costi e l’impegno sono bassi all’inizio, hanno un picco nella fase intermedia e scendono
rapidamente;

o Il livello d’incertezza e il livello di rischio sono alti all’inizio e diminuiscono con il procedere del
20
progetto;
o La possibilità d’influenzare il prodotto finale del progetto da parte degli stakeholder è alta
all’inizio e poi decresce;
o Il costo dell’esecuzione di modifiche (Changes) è basso all’inizio e poi cresce.
Tutti i progetti hanno un ciclo di vita: uno tecnico ed uno gestionale. Quello tecnico cambia da settore
a settore perché un ciclo tecnico (ad es. informatico) può essere differente da uno farmaceutico
ovvero da una dell’edilizia.
Quando si parla di ciclo di vita del progetto ci riferiamo a quello tecnico.
Quando si parla di ciclo di vita di project management si parla di ciclo di vita gestionale.
Difatti, parallelamente (ma dialogando) c’è il ciclo di vita gestionale. E’ il ciclo di vita del P.
management che è uguale per tutti i progetti in quanto i progetti possono essere gestiti tutti allo
stesso modo: il ciclo gestionale riguarda le attività di indirizzo e coordinamento necessarie alla
corretta impostazione (avvio), pianificazione, esecuzione, controllo e chiusura del progetto (che sono
le 5 fasi principali del progetto gestionale).
Il ciclo di vita del prodotto è più ampio del ciclo di vita del progetto in quanto esso inizia con
l’ideazione del prodotto, con lo sviluppo, la messa sul mercato, di restailing. Quindi ci possono essere
più cicli di vita del progetto all’interno di un ciclo di vita del prodotto.
Un prodotto viene creato da un progetto, ma non sempre rimane nella sua versione originale. Si pensi
al modello di un’autovettura, o a un sistema informatico che subiscono nel tempo diverse modifiche
rispetto la prodotto iniziale.
Il ciclo di vita del prodotto ingloba sia il progetto di costruzione del primo prodotto, sia tutti i progetti
messi in campo per generare nuove versioni di esso.
Si può dire che il ciclo di vita del prodotto nasce prima dell’inizio del progetto con la formulazione
dell’idea e del piano di business, prosegue dopo la fine del progetto con l’esercizio e finisce con al
fase di dismissione del prodotto stesso.

Durante la fase di esercizio, che tipicamente comprende assistenza, supporto e manutenzione del
prodotto realizzato, possono avere inizio nuovi progetti di aggiornamento, allo scopo di soddisfare
nuove esigenze.
21
Il PMBOK dedica 3 pagine al ciclo di vita del progetto. Esso dice semplicemente:
– Il ciclo di vita del progetto (tecnico) può essere gestito da vie metodologie che variano da settore
a settore. Per gestirlo in maniera più semplice si può scomporre il ciclo di vita del progetto in fasi
in quanto le fasi mi riducono la complessità del progetto. Il PMBOK rappresenta il ciclo di vita del
progetto (tecnico) con un diagramma
Rappresentante una curva ascendente e poi discendente. Questo ci serve quando si va a parlare
con il top management che non conosce i dettagli tecnici del progetto.
All’interno di tale grafico c’è una fase di avvio, una di preparazione, una durante il lavoro ed una
rappresenta la chiusura. Il maggior livello di costi e di impegno delle risorse umane si hanno in
corrispondenza della fase esecutiva del progetto tecnico. Nel grafico sono rappresentati l’effort
(il livello di impegno) delle risorse umane ed i costi che tendenzialmente vengono sostenuti
durante un progetto. Questo grafico può essere utile, oltre che per dialogare con i top
management, perché permette di avere anche un raffronto di progetti che se anche sono non
simili, i top management riescono a comprendere.
Il ciclo di vita tecnico del progetto può essere scomposto in fasi.

La scomposizione in fasi, correlate tra di loro, permettono di gestire meglio la complessità del
progetto. Ogni fase termina con il rilascio di una deliverable che diventa elemento di input per la
fase successiva. Generalmente ad ogni fase ci può essere anche la decisione “go o no go”, cioè
posso decidere se interrompere i progetti o no.
La scomposizione in fasi è una modalità con la quale io posso ridurre la complessità tecnica del
progetto in una ambiente più circoscritto dove riesco avere un miglior controllo gestionale ed
attenzione sui risultati intermedi su quella fase.
Il PMBOK descrive due tipi di relazione tra le fasi: sequenziale e di sovrapposizione ma occorre
aggiungere anche parallela.
Sequenziale: l’output di una fase rappresenta l’input per la fase successiva;
Sovrapposizione: una fase inizia poco prima che finisca l’altra.
Parallelo: alcune fasi possono viaggiare in parallelo.
Non esiste un modello di ciclo di vita unico per tutti i progetti.
Secondo il PMBOK i cicli di vita tecnici possono essere ordinati lungo un continuum al cui estremo
sx ci sono gli approcci predittivi (plan driven) ed all’opposto ci sono quelli adattivi (change
driven) o agili.
Quelli predittivi sono quelli classici. In quelli incrementali ed iterativi (situazioni intermedie) si
creano delle iterazioni e ad ogni iterazione può cambiare l’ambito. Il coinvolgimento del cliente,
in quelli classici è all’inizio, mentre in quelli incrementali ed iterativi risulta periodico o addirittura
continuo in quelli agili in quanto cambiando l’ambito il cliente è sempre presente.
22

I cicli di vita predittivi si riferiscono a quei progetti in cui la definizione dell’ambito, dei tempi e dei
costi può (e deve) essere eseguita in maniera completa e al più presto possibile. Dovendo realizzare
un prodotto sufficientemente chiaro, questi progetti procedono attraverso una sequenzialità ben
definita di fasi. In ognuna di tali fasi le attività di progetto sono altrettanto ben definite come anche
le competenze necessarie.
In tali progetti le richieste di cambiamento devono essere gestite, e i cambiamenti approvati hanno
bisogno di un’attenta ripianificazione e riapprovazione formale.
23
I progetti di costruzione e di impiantistica usano spesso cicli di vita predittivi.
Il ciclo di vita iterativo o incrementale prevede la ripetizione di alcune attività (iterazioni) man mano
che il team di progetto migliora la conoscenza del prodotto che è chiamato a realizzare. Ogni
iterazione prevede il ripetersi di tutti i processi di Project Management, fornisce feedback ed
esperienza per l’iterazione successiva, realizza nuovi deliverable o migliora quelli precedentemente
realizzati.
E’ preferibile adottare un ciclo di vita iterativo per progetti molto complessi e rischiosi, o nel caso in
cui è necessario prevedere cambi di obiettivi o di ambito durante l’evoluzione del progetto.
I progetti dell’Information Technology usano spesso cicli di vita iterativi o incrementali.

Il ciclo di vita adattivo si rifà a progetti in cui il cambiamento è la regola (vengono detti anche Change
Driven o Agile Methods). Pur essendo un ciclo iterativo, la differenza risiede nel fatto che le iterazioni
sono molto rapide e pianificate nel tempo.
L’ambito di tali progetti viene scomposto in porzioni estremamente piccole e assegnate a ciascuna
iterazione. Ogni iterazione si avvia con la definizione delle priorità e termina con il controllo stretto
da parte del cliente dei deliverable realizzati. Lo sponsor e il cliente sono impegnati in modo
continuativo sul progetto e sono chiamati a fornire il loro feedback e chiarire continuamente i loro
bisogni.
I metodi adattivi sono spesso preferiti quando si opera in ambienti in rapida evoluzione e quando
requisiti e ambito sono difficilmente definiti da subito. Per tale motivo sono utilizzati per progetti
nell’ambito della ricerca e sviluppo (R&D Project) o per sviluppo di nuovi prodotti che hanno bisogno
di un Time to Market particolarmente veloce e sfidante.
24
1.2 GLI STAKEOLDER DI PROGETTO
E’ un concetto nuovo e nasce nel 1984 nel mondo aziendale.
Essi sono tutti coloro che hanno un interesse, da non confondere con gli azionisti americani
(Stakeolder).
Il P.M. vive in un clima di costante incertezza.
L’oggetto della fornitura ad esempio, raramente mantiene invariata, fino alla consegna definitiva, la
sua connotazione iniziale.
Il processo di fabbricazione, quasi sempre innovativo e, pertanto, difficilmente rappresentabile
mediante un modello operativo già collaudato nel passato.
Lo scenario entro il quale si sviluppa il progetto, in termini di condizioni socio-economico-finanziarie,
di competitività del mercato, di adeguatezza delle risorse disponibili, sempre più turbolento e quindi
sempre più di difficile governo.
L’insorgere, durante il previsto iter realizzativo, di “disturbi”, varianti, criticità impreviste, certamente
non facilita il compito di chi ha la responsabilità della conduzione del progetto.

Progetto che comunque deve concludersi entro i limiti di tempo ben definiti, a costi contenuti e con
caratteristiche qualitative che rispettino le condizioni contrattuali.
E tutto questo con una disponibilità di risorse che si rivela quasi sempre limitata, per non dire
addirittura scarsa.
Per sottolineare con maggior precisione le cause che determinano il continuo stress al quale è
normalmente sottoposto il P.M. durante tutto l’arco di tempo necessario a completare la fornitura,
si individuano tutti i suoi naturali interlocutori, analizzando, per ciascuno di essi, i probabili motivi di
conflitto.
Gli enti, sia interni che esterni all’azienda, con i quali il P.M. si deve quotidianamente confrontare,
sono molto numerosi e di natura eterogenea.
A cominciare con i rapporti con il Committente, con il quale il P.M. deve riuscire ad accordarsi circa
le caratteristiche qualitative della fornitura (oltre che sul prezzo di vendita e sui tempi di consegna
del prodotto finale). E non si pensi che tale accordo, una volta raggiunto in sede di contrattazione
iniziale, mantenga inalterati i propri termini di riferimento fino alla conclusione del progetto!! nella
realtà operativa non sono certamente rari i casi nei quali, quando si è già dato inizio ai lavori e ci si
trova, magari, anche in fase di avanzata realizzazione, vengono richieste delle modifiche al prodotto
finale che possono a volte incidere anche in modo sostanziale sui costi previsti e sui tempi di consegna
concordati. Il P.M. dovrà allora rinegoziare le condizioni contrattuali, cercando di impegnare il cliente
a riconoscere, anche in via ufficiale, le varianti all’oggetto della fornitura e a farsi carico, per questo,
del maggior onere economico che ne consegue.
Un altro tipo di negoziazione, sia pure sorretto da un ben diverso potere contrattuale, deve essere
condotto con i fornitori esterni e con tutti gli enti ai quali sono state eventualmente applicate
porzioni di fornitura. Rispetto al rapporto appena descritto, il P.M. scambia, in questo caso, il proprio
ruolo per diventare a sua volta cliente, e pretendere la totale adempienza a quanto pattuito.
Dei rapporti del P.M. con i responsabili dei diversi enti aziendali interni coinvolti nel ciclo realizzativo,
occorre sottolineare il probabile insorgere di contrasti derivanti, da un lato, dalla diversa mentalità e
formazione professionale che contraddistingue il manager funzionale e il P.M. e, dall’altro, dalle
differenti finalità organizzative normalmente perseguite dalle due figure professionali.
25

Relativamente al Team di progetto esistono delle difficoltà che il P.M. incontra nel reclutare, avviare
e infine gestire il proprio gruppo di progetto. La diversa estrazione aziendale e i differenti skill
professionali dei suoi componenti ne rendono estremamente difficile il reale amalgama. A seconda
del rispettivo settore aziendale di provenienza, e in dipendenza della preparazione tecnico-professionale
individuale, ciascun membro del gruppo sarà latore di particolari abitudini lavorative,
riconoscerà scale di valori differenti, sarà portato ad assegnare priorità secondo criteri diversi e, a
volte, addirittura contrastanti. Risulta quindi evidente come per il P.M. sia tutt’altro che agevole
ottenere la piena collaborazione di tutti i componenti del gruppo. E in mancanza di questa è
puramente velleitario pensare di raggiungere livelli di efficienza e di efficacia anche soltanto
lontanamente accettabili.
Anche i rapporti con il Top Management presentano diverse problematiche, legate, soprattutto alla
latitanza che spesso caratterizza il vertice aziendale a proposito del quale è responsabile, e molto
spesso è per di più costretto a operare senza il riconoscimento formale della propria autorità da parte
dell’azienda.
Tutti gli elementi elencati, ma non esaustivi, vengono chiamati Stakeholder, cioè tutti coloro che
hanno un interesse (positivo o negativo) sul progetto. E’ un concetto molto più ampio del semplice
cliente (che è anch’esso uno stakeolder per eccellenza). Ma il concetto va ad allargare di molto il
raggio di azione andando a focalizzarsi proprio su tutti coloro che hanno un interesse (anche a livello
concettuale).
Difatti non tutti hanno lo stesso interesse sul progetto, ed inoltre c’è anche chi ha un interesse
negativo ovvero che può remare contro la buona riuscita del progetto.
Il P.M. deve gestire le esigenze contrastanti degli STK, ed una delle attività più importanti consiste
nell’identificarli al più presto (è la prima cosa che deve fare dopo la propria nomina), in quanto così
ha la possibilità di intervenire con un maggior ventaglio di soluzioni, ma soprattutto di impattare
meno sui costi del progetto perché man mano che si va avanti se uno STK forte mi appare e mi impatta
sul progetto, i costi della modifica in corso d’opera sono decisamente maggiori rispetto a quelli di
averli identificati prima.
26

In genere l’influenza degli STK è altissimo all’inizio del progetto e tende a decrescere man mano che
ci avviciniamo alla fine del progetto.
Invece il costo delle modifiche, se non individuo subito gli stakeholder, all’inizio del progetto è basso
ma man mano che si va avanti con il progetto esso tende ad aumentare moltissimo.
Una volta che il P.M. ha identificato gli STK, li va a classificare mettendoli in ordine di importanza,
perché il P.M. non può investire tutto il suo tempo allo stesso modo con tutti gli STK ma applica delle
logiche di differenze tra gli STK al fine di dare importanza agli STK più impattanti. E nei confronti di
ciascuno il P.M. applica logiche di comunicazione differente.
Si fa presente che la gestione degli STK ha anche un costo che il P.M. dovrà assorbire dal budget
assegnatoli.
27

28
In genere i passi che il P.M. deve fare è:
1) Identificare gli STK;
2) Classificare gli STK;
3) Raccogliere i requisiti (soprattutto degli STK);
4) Definire lo Scope ed effettuare la WBS
5) Definire le WP
6) Identificare le attività
7) Costruire il reticolo
8) Assegnazione delle attività
9) Calcolo durata del progetto
10) Definire la Baseline dei tempi (Gant) e dei costi ed infine….
11) Costruire il team Project
A questo punto, insieme al team costituito, il P.M. concorda con esso il bagaglio precedentemente
costituito e, nel caso, controlla se tutto è stato fatto bene oppure no. Il team può anche indicare al

P.M. nuovi STK. Comunque la procedura è di tipo interattiva, fino a quando una volta definita la WBS
finale il P.M. lo pubblica e quindi lo rende definitiva.
Tra i vari STK che deve individuare i P.M. c’è il Project Management Office (PMO). Esso è una unità
organizzativa all’interno dell’azienda messa a disposizione del P.M.
Pur essendo una unità organizzativa in realtà è un Operation, cioè non muore con il progetto ma vive
con l’azienda perché eroga i suoi servizi non solo per il P.M. ma per tutti progetti aziendali. Esso non
ha alcuna responsabilità sul progetto.
29
Il PMO non è una persona ma una unità organizzativa.
Per una azienda avere un PMO all’interno vuol dire avere una cultura di progetto all’interno del
contesto aziendale.
Esso è di supporto al P.M. cioè il P.M. si avvale di loro ma non riporta le risultanze del progetto al
PMO. Un membro del PMO può anche fare il P.M.
Dunque il P.M. è al centro di una fitta serie relazionale. Si dice che in fase di esecuzione il P.M.
dovrebbe passare circa l’80% del suo tempo a gestire le relazioni.
Il P.M. non potrà mai entrare in merito al livello qualitativo del progetto: quello è compito del
responsabile tecnico. Tuttavia il P.M. deve sapere che esiste un tempo per finire il progetto che deve
necessariamente rispettare.
Il P.M. non è mai il capo gerarchico della risorsa (team di progetto). Il capo è il Manager funzionale e
è a lui che dovrà fare riferimento per la ricerca del personale formate il Team di progetto. Cioè il
Team è prestato al P.M.
Il P.M. non può né punire e ne premiare la singola persona del Team di Progetto. Semmai si può dire
che il P.M. è il capo funzionale. Ma il capo gerarchico è il Manager Funzionale.

30
COMPETENZE DEL P.M.
Il P.M. deve avere 4 caratteristiche principali, 2 hard skill e 2 soft skill
1) Caratteristiche gestionali – deve capire la qualità – customer satisfaction – aspetti
contrattuali – legali (hard skill)
2) Caratteristiche tecniche - deve conoscere il linguaggio tecnico di P.M. – avere esperienze in
campo – conoscere i sistemi informatici di P.M. (hard skill)
3) Caratteristiche personali – problem solving (soft skill)
4) Caratteristiche relazionali – negoziazione – gestire conflitti – motivare (soft skill)
Queste sono tutte competenze che il P.M. deve avere. La parte più importante per un bravo P.M.
sono le soft skill (capacità interpersonali). In quanto la parte tecnica e gestionale lo sanno fare
tutti.
LEADERSHIP: la leadership è la capacità di completare il lavoro attraverso l’impegno di altre
persone.
Rispetto e fiducia sono le parole chiave per una corretta leadership, non paura e sottomissione.

La leadership ha il suo momento cruciale nella fase iniziale del progetto, ovvero quando si deve
infondere motivazione e ispirazione da parte dei componenti del team per ottenere prestazioni
di alto livello.
31
La leadership comporta tre passi fondamentali:
o Stabilire la direzione: sviluppando un approccio orientato agli obiettivi e alle strategie;
o Allineare le persone sugli obiettivi: comunicando alle persone gli obiettivi allertandole su
difficoltà e insidie;
o Motivare e ispirare: aiutando le persone a superare gli ostacoli e le difficoltà
Inoltre il P.M. deve determinare lo stile di leadership più appropriato per i bisogni del progetto.
Essi si distinguono:
o Directin Style: stile direttivo ovvero dirigere le persone in modo diretto e continuo
nell’espletamento delle attività di progetto;
o Facilitating Style: stile agevolatore ovvero coordinare le persone cercando di semplificare
le loro incombenze lavorative;
o Coaching Style: stile addestratore ovvero seguire le persone e istruire su come operare e
migliorarsi;
o Supporting Style: stile supportativo ovvero fornire assistenza e supporto continuo;
La prevalenza assoluta di uno dei precedenti stili sugli altri è sconsigliata perché poco efficace. Il buon
P.M. sa coniugare un giusto equilibrio di stili nell’applicazione della leadership nei confronti del team.
Nel corso del progetto i leader del gruppo di progetto sono responsabili delle seguenti attività:
stabilire e mantenere la “Vision”, le strategie e le comunicazioni, promuovere la fiducia e il team
building, influenzare, consigliare e monitorare le prestazioni del gruppo e del progetto.
TEAM BUILDING: Significa aiutare un gruppo di persone, unite da uno scopo comune, a lavorare
meglio insieme. Nell’ambito del progetto, il team, diretto dal P.M. che funge d leader, opera
nell’organizzazione rimanendo in stretto rapporto con molti stakeholder. Una buona leadership
e l’esecuzione di buone attività di team building sono funzionali al lavoro di squadra e al successo.

Anche se il team building è essenziale all’inizio del progetto, in realtà si tratta di un processo
continuativo in quanto le modifiche ambientali sono inevitabili.
32
(vedi anche capitolo “Gestione delle risorse umane”).
MOTIVAZIONE: esso è una delle armi più efficaci per ottenere il massimo dell’impegno da parte
dei componenti del team. E’ fondamentale per il P.M. motivare continuamente le persone
durante l’intero ciclo di vita del progetto. (vedi capitolo sulla “Gestione delle Risorse Umane”).
COMUNICAZIONE EFFICACE: il P.M. deve essere un efficace comunicatore con le persone del
team e con gli stakeholder.
I concetti fondamentali per una buona comunicazione del progetto sono:
o Il P.M. deve identificare i corretti canali di comunicazione (vedi capitolo sul “Project
Communication Management), stabilendo al più presto le informazioni che devono
transitare;
o È fondamentale che il P.M. conosca e applichi gli opportuni stili di comunicazione;
o È compito del P.M. e del suo team di Project Management identificare le informazioni
che devono circolare fra le persone coinvolte nel progetto;
o Una parte fondamentale della comunicazione è la capacità d’ascolto: “Chi non sa
ascoltare, non sa comunicare”;
o Una buona comunicazione da parte del P.M. aiuta a raggiungere un livello di fiducia e di
rispetto fra tutte le persone coinvolte;
o Il P.M. deve liberarsi e liberare i membri del team da qualsiasi blocco di comunicazione,
ovvero da qualsiasi entità fisica e psicologica che ostacoli o interrompa lo scambio di
informazioni.
CAPACITA’ DI INFLUENZARE: Ha capacità di influenzare colui che riesce a stimolare gli altri verso
una collaborazione orientata al raggiungimento di obiettivi comuni.

Per il P.M. è fondamentale riuscire a influenzare positivamente tutti gli STK che possono
contribuire al successo del progetto, in particolare gli executive, i functional manager, ma anche
il cliente e i fornitori.
33
Nei confronti dei membri del team di progetto, il P.M. può influenzare le persone tramite:
o Il buon esempio;
o La dimostrazione di portare sempre a termine gli impegni presi;
o L’uso di uno stile interpersonale flessibile e adeguato al contesto.
E’ molto importante che il P.M. mostri chiarezza e decisione nel processo decisionale e che applichi
il proprio potere con integrità, correttezza, rispetto ed equità con un approccio orientato a stabilire
relazioni e collaborazioni di lungo termine.
CAPACITA’ DECISIONALE: E’ una delle principali caratteristiche del P.M. efficace.
Prendere decisioni si esplica i 6 passi:
o Definire il problema su cui deve essere presa la decisione in modo chiaro e completo;
o Identificare le possibili soluzioni tramite un approccio collegiale e senza prendere decisioni
affrettate;
o Dall’idea all’azione, ovvero scegliere la migliore fra le soluzioni possibili, usando criteri
valutativi oggettivi;
o Pianificare l’azione risolutiva, tramite un approccio di gruppo orientato a far funzionare la
soluzione;
o Valutare a posteriori la soluzione adottata e registrando quanto è stato appreso (lesson
Learned)
o Valutare i risultati e rivalutare il processo decisionale in un’ottica di miglioramento continuo.
Nell’ambito delle Capacità Decisionali sono stati catalogati alcuni stili di leadership:
o Stile autocratico, che consiste nel prendere decisioni senza ascoltare il parere degli altri;
o Stile consultativo, che consiste nel prendere decisioni autonomamente ma dopo aver
consultato gli altri in cerca di idee e opinioni;
o Stile del consenso, che consiste nel prendere decisioni basate sul consenso del team;

o Stile casuale, decisamente sconsigliato, che consiste nel prendere decisioni in modo casuale;
o Stile della condivisione, che prevede il lasciare completa autonomia decisionale agli altri,
34
ovvero condividere il comando con il team.
Un buon P.M. sa coniugare un giusto equilibrio di stili nell’applicazione della Capacità di Influenzare.
CONSAPEVOLEZZA POLITICA E CULTURALE: La conoscenza e la consapevolezza delle politiche del
paese in cui opera, delle differenti culture delle persone che partecipano, nonché delle politiche
aziendali dell’organizzazione operante, possono pesantemente influire sul raggiungimento del
successo del progetto. Il P.M. deve essere fortemente coinvolto in tali aspetti: in particolare va
sottolineata l’importanza della cura delle differenze culturali qualora il progetto si esegua in ambienti
di lavoro e di progetto internazionali.
Un approccio positivo e costruttivo consiglia il P.M. di favorire attività orientate ad approfondire la
reciproca conoscenza tra i componenti del team. Il tutto in un’ottica di reciproco rispetto, di
ottimizzazione comunicativa e di crescita morale.
NEGOZIAZIONE: Negoziare significa attivare una strategia che preveda il confronto fra parti aventi
interessi diversi al fine di raggiungere un accordo.
La negoziazione è parte integrante dell’operato del P.M. ed è fondamentale per ottenere successo e
raggiungimento di obiettivi.
Alcuni consigli importanti per una valida negoziazione sono:
o Ascoltare ed esprimersi con estrema chiarezza;
o Considerare separatamente i bisogni dai desideri: i primi si devono ottenere, i secondi è
auspicabile ottenerli;
o Essere realistici nella trattazione negoziale;
o Mostrare il valore di quanto concesso durante la negoziazione
Una delle armi più utili è quella di tentare una negoziazione Win-Win, in cui al raggiungimento
dell’accordo, entrambe le parti abbiano la sensazione di aver ottenuto il massimo e quindi “di aver
vinto”. (per approfondimenti vedi cap. “Gestione dell’approvvigionamento”).

CREAZIONE DI FIDUCIA: il P.M. deve saper costruire rapporti di fiducia sia con le persone del team
sia con gli altri STK di progetto.
Attivare rapporti di fiducia significa collaborare, cooperare, condividere le informazioni, rendere
efficace la risoluzione dei problemi. Occorre in definitiva che il P.M. debba:
o Attivare una comunicazione aperta e diretta, soprattutto durante la risoluzione dei problemi;
35
o Mantenere gli STK informati;
o Cercare di capire al meglio le problematiche del team tramite colloqui aperti e diretti;
o Esprimere in maniera esplicita e diretta i propri bisogni e le proprie aspettative;
o Condividere le informazioni a disposizione
o Dimostrare ricettività all’innovazione;
o Guardare oltre i propri interessi;
o Dimostrare un vero interesse alle esigenze degli altri.
GESTIONE DEI CONFLITTI: il temine viene definito come “comportamento di un individuo, di un
gruppo o di un’organizzazione che impedisce o limita un’altra parte nel raggiungimento dei suo
desiderati obiettivi”.
Il conflitto è connaturato con la natura umana. Nel team di progetto è in genere in qualsiasi gruppo
di persone i conflitti esistono ed è sbagliato pensare di riuscire ad evitarli.
Durante il progetto i conflitti si possono verificare tra tutti gli STK: le persone del team, il P.M., il
management, i fornitori, i responsabili di funzione, ecc., e possono impattare diversi livelli
dell’organizzazione e riguardare qualsiasi argomento.
Una situazione conflittuale deve essere gestita in maniera costruttiva: da essa possono nascere spunti
di riflessione orientati al miglioramento. Spesso accade infatti, che, dopo aver risolto correttamente
un conflitto interno, il team risulta essere più forte.
Il P.M. è il maggior artefice della gestione dei conflitti fra le persone coinvolte nel progetto e deve
usare un approccio positivo alla loro risoluzione.
Il proliferare dei conflitti in un team è sintomo negativo che spesso dipende da una difettosa
assegnazione dei ruoli e da obiettivi non ben definiti o in contrasto tra di loro.

I conflitti nel progetto devono essere risolti al più presto possibile affrontandoli con coraggio. Conflitti
repressi, prima o poi riemergeranno e potrebbero farlo con maggiore forza e con poco tempo a
disposizione per risolverli.
36
I tipi di conflitto in ordine di frequenza sono i seguenti:

37
Il PMBOK definisce 6 modalità di risoluzione dei conflitti:

AFFIANCAMENTO – COACHING: il Coaching è la capacità di addestrare le persone, premettendo loro
di crescere e migliorare.
Lo sviluppo delle persone del team di progetto è un argomento molto importante (vedi Cap. Risorse
Umane), tanto che il Coaching è considerata una delle competenze necessarie a qualsiasi P.M.
38
Il PMBOK dà molta enfasi a tali capacità interpersonali (soft skill).
Queste sono tutte capacità importanti ma quella principe è la Comunicazione Efficace soprattutto
con il cliente. Cioè saper capire il cliente che in effetti a volte non sa spiegare di cosa ha bisogno.
Pertanto la capacità di comunicare, avere un vocabolario comune, sono elementi fondamentali per il
buon esito relazionale e quindi del progetto.

39
TEAM DI PROGETTO (o Project Office)
Esso è costituito dal P.M. il quale può farsi supportare da un team di P. Management che lo
coadiuva per quanto concerne il ciclo di vita gestionale. Poi ci sono gli specialisti e la mano
d’opera, che sono coloro che si occupano del ciclo di vita tecnico del progetto, poi ci possono
essere delle operation a supporto e su richiesta.
Il P.M. ha un ruolo di indirizzo e di coordinamento; nella fase di esecuzione gestisce le relazioni;
man mano che il progetto diventa complesso e lungo ed inoltre quando gli STK in gioco sono
numericamente rilevanti, il P.M. non ce la fa da solo a fare tutto quello che dovrebbe fare. Si fa
coadiuvare dal team di P. Management che rappresenta il braccio destro del P.M. ed è composto
da un assistente del P.M. (CAPM), da una segreteria di progetto, da un risk manager ecc.
Anche quando i fornitori sono molti, il P.M. può chiedere ad un membro del team di interfacciarsi
con i fornitori ed essere il referente dello stesso.
Il project team o Project Office non ha niente a che vedere con il PMO.

40
SPONSOR D PROGETTO
Chi è lo sponsor? Tipicamente è un senior manager.
Nel caso di un gruppo di senior manager che beneficiano del progetto è importante che il gruppo sia
d’accordo nel nominare un singolo rappresentante in modo da evitare divergenze.
Il ruolo dello sponsor è diverso da quello del P.M. in quanto esso è focalizzato allo sviluppo del
business dell’impresa e non all’efficace ed efficiente completamento del progetto.
Lo sponsor non ha frequenti contatti con il P.M., eccetto nel caso che il progetto esca dai piani previsti
o gli obiettivi di business non siano raggiunti.
Gli sponsor di progetto devono essere informati in modo sintetico, chiaro ed esauriente sullo
svolgimento del progetto stesso. In particolare le informazioni devono essere relative a:
raggiungimento di obiettivi intermedi; criticità che il P.M. non può gestire autonomamente; stato di
avanzamento periodico; clima all’interno del team.
Lo sponsor è quello che ci crede al progetto ed è colui che promuove fortemente, presso il top
management, l’avvio di quel progetto affinché convinca il Portfolio Management ad avviare il
progetto: quest’ultimo ha l’autorità formale di avviare il progetto.
Esso gioca un ruolo politico ed allo stesso tempo finanziario; non si sostituisce al P.M. che non ha
potere decisionale. Tale potere rimane in capo allo Sponsor ed è questo che firma i documenti e non
il P.M.
Lo sponsor prende delle decisioni anche in merito all’utilizzo o meno di alcuni membri del team.
Il P.M. può suggerire di fare qualcosa. Dove c’è qualche problema di natura politica finanziaria il P.M.
chiede allo Sponsor cosa deve fare. Se al P.M. non gli vogliono dare ad es. delle risorse che lui ha
chiesto esso si deve rivolgere allo sponsor. Se quelle skill non ci sono, il P.M. prima di iniziare va dallo
sponsor per fare tali approvvigionamenti (vedi cap. Procurement)
Tuttavia il potere finale di decidere è il top manager.
Lo sponsor non può mai essere il P.M. e viceversa.
Laddove lo sponsor si rende conto che, durante il progetto, lo stesso progetto possa avere impatti su
altre unità organizzative o altri processi, organizza ed istituzionalizza il comitato guida (Steering
Committee) composta da tutti i responsabili di alto livello che sono i responsabili dei processi ed unità

organizzative potenzialmente impattate dal progetto, ed eventuali membri di società esterne incaricate
della realizzazione del progetto o di fasi dello stesso.
Lo Steering Committee esercita il controllo strategico sul progetto tramite riunioni periodiche nelle quali le
persone responsabili della realizzazione del progetto ragguagliano il comitato sullo stato avanzamento lavori,
sulle eventuali criticità emerse e sulle eventuali azioni da intraprendere.
Quindi in tali casi lo sponsor non si assume la personale responsabilità ma crea un comitato, di cui lui
presiede, che si riunisce periodicamente o in via straordinaria. Pertanto le decisioni vengono prese in
maniera collegiale per evitare che la sua scelta (anche intermedie) possa generare impatti non noti
ai responsabili delle singole unità organizzative.
41
PMO – Project Management Office
Quando il numero di progetti gestiti da un’organizzazione è elevato, ovvero l’azienda è di grandi-medie
dimensioni e operante in situazioni multi progetto, è giustificabile la presenza di una funzione
aziendale, in genere denominata PMO.
Esso è un centro di competenza sul project management ed è un Operation: vive con l’azienda e non
con il progetto. Quando il progetto finisce, finisce il project team o project office ma non il PMO.
Il vantaggio principale di un PMO è quello di avere una chiave di lettura univoca dei progetti da parte
del top management perché quando si gestiscono tutti i progetti l’alta direzione non sa come il
project manager ha definito le stime. Laddove c’è un centro di competenza che da indirizzo e le linee
guide ben definite si ha una metrica di valutazione univoca di come è stato gestito il progetto.
I progetti, con il PMO, saranno gestiti in maniera uniforme e questo permette di avere una chiave di
lettura univoca, chi ha lavorato bene o male, a parità di condizioni.
Le competenze principali di un PMO:
1) Gestire il sistema di reporting verso il top management
2) Definire la metodologia di project management a livello aziendale
3) Definire il sistema di project management: nel sistema ci sono procedure, processi, linee
guida, il software di project management
4) Definire dei template di project management
5) Fanno formazione ai project management

6) Creano una cultura di “progetto” all’interno dell’azienda: se un P.M. ha un dubbio, può
42
rivolgersi al PMO per risolvere il problema
7) Concentrare la conoscenza di metodologie, strumenti e procedure di Project Management a
livello aziendale, allo scopo di condividerla con gli altri interpreti aziendali, fungendo quindi
da centro di competenza nel Project Management;
8) Supportare i P.M. e i team di P.M. fornendo assistenza e addestramento, fungendo da guida
e maestro e fornendo una formazione adeguata;
9) Verificare la corretta attuazione delle regole gestionali stabilite per i progetti, garantendo al
top management la massima uniformità nella gestione dei progetti stessi in termini di
metodologia, strumenti e procedure di project management.
10) Supportare il top management nei processi decisionali di gestione dei progetti e di portfolio,
fornendo informazioni sui progetti omogenei o comparabili tra di loro;
11) Coordinare la comunicazione inter progettuale, favorendo il confronto e il miglioramento.
Il PMBOK 5° edizione fa una distinzione in tre tipologie di strutture possibili di PMO:
1) Supportive (di supporto): è quello basic per l’azienda e funge da archivio di progetto, fornisce
template, formazione, gestisce le lesson learned; mette cioè in condizioni il P.M. di lavorare
in modo efficace gestendo il sistema di gestione.
2) Controlling (di controllo): esso ha anche una componente di audit, cioè va a vedere se le
documentazioni vengono utilizzate in modo corretto;
3) Directive (di direzione): può esercitare il controllo sui progetti gestendo direttamente i
progetti stessi. In questo caso il PMO gioca il ruolo di Project manager
In ogni caso il PMO integra i dati ed informazioni provenienti dai progetti strategici aziendali ed è
quindi l’anello di congiunzione tra i progetti, programmi e portfolio di una organizzazione ed i sistemi
di misurazione aziendale.
PROGRAMME BOARD
Nella maggior parte delle organizzazioni di grande dimensione che operano per progetti esiste un
comitato di coordinamento, il Programme Board, che si incontra periodicamente per sovrintendere
l’esecuzione dell’intero portfolio dei progetti. Il compito del P.B. è revisionare, approvare e assegnare
le priorità ai vari progetti o alle proposte di progetto e di autorizzare l’allocazione delle risorse
secondo criteri prefissati. Infine questo comitato deve gestire le eccezioni che possono verificarsi nei

progetti (non recuperabili da parte del P.M.) e dare avvio ad azioni correttive. In alcune realtà il
comitato di progetto coincide con lo Steering Committee.
E’ necessario che il P.B. sia periodicamente informato sullo stato di avanzamento del progetto
attraverso report sintetici e incontri con il P.M.
43
PROJECT MANAGEMENT ED ORGANIZZAZONE
Modelli organizzativi aziendali in termini di project management.
Cosa dice il PMBOK: le configurazioni organizzative aziendali possono essere diverse in quanto
ognuno può farsi una organizzazione strutturata a suo piacimento. Ma tutte le configurazioni
organizzative possono essere ordinate lungo un “continuum” in cui ad un estremo abbiamo
organizzazioni orientati per progetti e all’altro quelle non project based.
1) Organizzazione orientata per progetti: Quelle orientate ai progetti sono quelle che vivono di
progetti in cui gli stessi sono centri di ricavo: lavorano cioè su commessa o consulenza in
quanto i progetti diventano la fonte di finanziamento principale per l’azienda: più progetti si
fanno e più ricavi ottiene l’azienda. Queste aziende vogliono che il proprio dipendente non
stia in ufficio ma che stia presso il cliente in quanto in tal caso esso rappresenta parte di un
centro di ricavo; se stai in ufficio sei un centro di costo.
Ma ci sono anche delle aziende che pur non lavorando per progetti, hanno una cultura di project
management: sono quelle aziende dove comunque esiste un PMO e in cui comunque si è raggiunto
il massimo livello di maturità in project management.
2) Organizzazione Funzionale: c’è l’azienda verticistica, gerarchica, dove non esiste il P.M. esiste
solo il capo, azienda verticistica. Qui i progetti ci sono ma non esiste il P.M. Le risorse sono
impegnate solo part-time in quanto gli stessi dovranno anche svolgere le proprie attività di
competenza.
Nel mezzo di tali estremi (1 e 2) ci sono una varietà enorme di strutture, ed il PMBOK ne individua 3.
a) Organizzazione a matrice debole: più vicina a quella funzionale dove cambia per il fatto
che le risorse sono assegnate a tempo pieno al progetto ma non esiste il P.M.: esiste

semmai un coordinatore del progetto con limitata autorità, più che un responsabile di
progetto.
b) Organizzazione a matrice bilanciata o equilibrata: è una via intermedia dove inizia ad
esistere il P.M. ed inizia ad avere una autorità. Le risorse sono assegnate a tempo pieno
sul progetto e lavorano esclusivamente sul progetto.
c) Organizzazione a matrice forte: è quella più vicina a quella progettuale. Tutte le risorse
sono assegnate a tempo pieno al progetto ed esiste una specifica funzione di project
management ed il P.M. riveste una notevole autorità. Questo tipo di organizzazione è
quella preferita dal PMBOK in quanto è meglio visualizzabile da molte aziende. La
cultura di progetto è elevatissima.
44
Quali sono le influenze delle strutture organizzative sul progetto?

45
Criteri per la scelta della struttura organizzativa:
Il progetto ha una Governane che è assicurata essenzialmente dallo sponsor e dal portfolio manager
che l’ha attivata. Ovviamente il governo di questo progetto rientra sotto un cappello di governance
organizzativa che è garantita dal top manager. La governance del progetto ovviamente deve essere
allineata alla struttura organizzativa aziendale e questo incide ovviamente sul ciclo di vita tecnico del
progetto.
PROCESSI DI PROJECT MANAGEMENT
Il Project Management si esplicita attraverso i processi sequenziali.
Un processo è un insieme di attività sequenziali propedeutiche in cui l’output di una attività
rappresenta l’input per l’attività successiva e sono correlate tra di loro per raggiungere un risultato.
I processi nel progetto sono condotti dal team di progetto e si distinguono in due tipologie:

a) Processi di Project Management: sono generalizzabili e applicabili al più dei progetti e
riguardano concezione, pianificazione, esecuzione, monitoraggio/controllo e chiusura del
progetto;
b) Processi orientati al prodotto: specificano e creano il prodotto del progetto. Sono specifici
46
della particolare tipologia del progetto.
I processi delle due tipologie si sovrappongono e interagiscono continuamente durante l’evoluzione
del progetto.
Competenza del P.M. è stabilire quali di questi processi devo applicare sui miei progetti.
Il PMBOK è pieno di processi. La competenza del P.M. è calare il modello sulla realtà aziendale e poi
sul singolo progetto.
Il processo è costituito da un input – strumenti e tecniche – output.
Per arrivare al frame work del PMBOK si parte da un modello manageriale chiamato ciclo “Plan-Do-
Check-Act” o ruota di Deming (ideato da SHEWART): è un modello studiato per il miglioramento continuo
della qualità in un'ottica a lungo raggio. Serve per promuovere una cultura della qualità che è tesa al
miglioramento continuo dei processi e all'utilizzo ottimale delle risorse. Questo strumento parte dall'assunto
che per il raggiungimento del massimo della qualità sia necessaria la costante interazione tra ricerca,
progettazione, test, produzione e vendita. Per migliorare la qualità e soddisfare il cliente, le quattro fasi
devono ruotare costantemente, tenendo come criterio principale la qualità.

47
La sequenza logica dei quattro punti ripetuti per un miglioramento continuo è la seguente:
• P - Plan. Pianificazione.
• D - Do. Esecuzione del programma, dapprima in contesti circoscritti.
• C - Check. Test e controllo, studio e raccolta dei risultati e dei riscontri.
• A - Act. Azione per rendere definitivo e/o migliorare il processo (estendere quanto testato
dapprima in contesti circoscritti all'intera organizzazione).
Questo modello che si applica a livello aziendale dice: “prima di agire occorre pensare”
Occorre cioè prima pianificare, poi ad implementare quanto pianificato (cioè ad eseguire), poi c’è un
momento di controllo per verificare se quanto eseguito corrisponde a quanto pianificato. Qualora ci
fossero delle discrepanze faccio delle azioni per provare a riallineare e probabilmente a ripianificare.
Questo si chiama ruota in quanto rappresenta un circolo iterativo che si svolge nel tempo e al termine
di ogni giro fuoriesce quello che in gergo della qualità totale, viene chiamato progetto migliorato
continuamente.
Applicando tale modello aziendale al mondo dei progetti abbiamo:

In tal caso abbiamo sia la famosa ruota suddetta (al centro) nonché altri processi aggiunti (in totale
5) che sono:
48
1) Initiating (avvio): processi per autorizzare e per avviare correttamente il progetto;
2) Planning (pianificazione): processi per definire gli obiettivi e selezionare le migliori azioni
per raggiungere gli obiettivi predefiniti;
3) Executing (esecuzione): processi per coordinare le persone e altre risorse per seguire il
piano;
4) Monitoring e controlling (monitoraggio e controllo): processi che aiutano a raggiungere gli
obiettivi tramite monitoraggio del progetto e misurazione degli avanzamenti;
5) Closing (chiusura): processi per la formalizzazione dell’accettazione e della conclusione del
progetto o di una sua fase.

Pianificazione, esecuzione, monitoraggio e controllo si ripropongono durante tutta la vita del
progetto, fino al suo completamento. Le loro interrelazioni mostrano come, a fronte di una
pianificazione iniziale, è necessario tenere sotto controllo strettamente il progetto prevedendo una
serie di attività gestionali che includono verifica e analisi degli scostamenti, nuove stime a finire,
ripianificazione e gestione dei cambiamenti, il tutto gestito seguendo regole ben definite, trasparenti
e chiare a tutti gli STK di progetto.
49
A differenza della semplice ruota di Deming c’è l’aggiunta dei processi di inizio e chiusura.
I processi di project management secondo la metodologia del PMBOK, possono essere raggruppati
nei suddetti 5 gruppi di processi.
Questi processi si possono vedere anche da un altro punto di vista, che è quella chiamata “delle aree
di conoscenza”.

50
La metodologia prevede 10 aree di conoscenza:
Tra le 10 aree di conoscenza vi è una (Integration) che è l’area di conoscenza che rappresenta “la
colla” che tiene unite e assicura coerenza a tutte le altre aree di conoscenza.
Nelle vecchie versioni del PMBOK le aree di conoscenza erano 9 in quanto non c’era il Project
Stakeolder Management. (l’area di conoscenza Stakeolder era inserita nell’are di conoscenza delle
Communication nella 4° edizione del Pmbok).
Il project management si esplicita per processi e secondo la metodologia del PMBOK i processi ne
sono 47. Ciascun processo può essere raggruppato o per i 5 gruppi di processo o per le 10 aree di
conoscenza.
Nel frame work riportato all’inizio di tale capitolo si evidenziano quindi: le 10 aree di conoscenza, i 5
gruppi di processi e di 47 processi segnati a colori evidenziando la loro appartenenza al relativo
gruppo di processo.

Di seguito si evidenzia un grafico in cui si evince come i gruppi di processi sono sovrapposti tra di loro
e non sono sequenziali. Tra l’altro dal grafico si evince come il maggior numero di interazione tra
processi lo si ha relativamente al gruppo di processi di pianificazione e di esecuzione.
51
GRUPPO DI PROCESSO DI AVVIO
Quando nasce un progetto?
Un progetto nasce quando una volta definiti gli obiettivi sottesi al progetto si svolgono due attività
propedeutiche alla decisione “go o no go” del progetto, e cioè:
a) Studio di fattibilità che mi dà l’ok tecnico al progetto;

52
b) Il business case, che mi dà l’ok commerciale al progetto
Le attività dello studio di fattibilità e del Business Case sono “out of scope”, cioè non rientrano nella
sfera gestionale del progetto
Il progetto nasce esclusivamente con l’approvazione e la sottoscrizione da parte dello sponsor e del
cliente, del Project Charter.
Spesso al posto del Business Case si fa l’analisi costi/benefici (benefit cost analysis): i benefici vanno
al numeratore ed i costi vanno al denominatore.
Una volta verificato quanto sopra, si decide di avviare il progetto che ufficialmente nasce con la
redazione di un documento che si chiama “Project Charter” che è il primo deliverable documentale
del ciclo di vita gestionale di project management del progetto. Il P.C. risponde a due obiettivi
principali
a) Con la sua redazione il progetto nasce ufficialmente;
b) Nel P. Charter viene riportato il nome del P.M.;
Il P.C. viene fatto dallo Sponsor di progetto e lo sottoscrive lui insieme al cliente.
Il ciclo di vita gestionale genera dei deliverable utili al ciclo di vita tecnico ma sono tutti deliverable
documentali ed il P.C. è il primo deliverable documentale.
Una volta che viene designato il P.M. esso va subito nell’area di conoscenza degli STK per identificarli
e classificarli.
E’ da notare altresì che solo la fase di Initiating e close sono costituiti da singoli processi.
GRUPPO DI PROCESSI DI PIANIFICAZIONE
Pianificare ha la sua importanza in quanto esso vuol dire prevenire. Esso è importante in quanto se
pianifico riesco a prevenire criticità che, se qualora le cogliessi in corso d’opera, avrei un costo della
modifica più alta.
Pianificare mi permette di controllare; mi permette di delegare e farlo seguire a qualcuno.
Tra i 5 gruppi di processi, quelli che coinvolgono maggiormente il P.M. è proprio il processo di
pianificazione (che ne sono 24 – quelli verdi nel frame work) ed il monitoraggio e controllo.

Tutti i 24 processi che coinvolgono direttamente il P.M. vanno a confluire all’interno dello “Sviluppo
del Piano di Gestione Progetti – Develop Project Management Plan” facente parte dell’area di
conoscenza “Integration”, che si definisce come il “piano dei piani”.
Quando definisco tutti i sotto piani faccio confluire tutto nel piano di project management. La
versione 1.0 (definitiva) di tutti i piani prendono il nome di “Baseline”.
La baseline è la versione ufficiale del piano di ciascuna area di conoscenza. Esso mi serve per
confrontare in fase di monitoraggio con quanto eseguito.
Quindi avrò una baseline dell’ambito, che è la versione ufficiale dell’ambito (scope), delle risorse, dei
costi, dei tempi. Il tutto va a confluire nel piano di project management che è quindi un documento
iterativo e formale, cioè come eseguire, monitorare, controllare e chiudere il progetto. Viene messo
in evidenza “chi fa cosa” – “quando” – e quanto costa.
Le suddette baseline vanno condivisi con tutti gli STK (cliente, sponsor, top manager, team di
progetto, ecc.) e per questo che le baseline facilitano la comunicazione con gli STK. Nel momento in
cui tutti hanno accettato le baseline, nessun può eccepire e dire: “…ma forse non lo sapevo”…!!!
Quindi il Project Management Plan fornisce una Baseline di riferimento per le misurazioni degli
53
avanzamenti e per il controllo del progetto.

54
GRUPPO DI PROCESSI DI ESECUZIONE
In tale fase il P.M. controlla e gestisce relazioni e da qui che parte il fatto che almeno il 75%-80% del
tempo lo passa a gestire le relazioni.
Questo gruppo di processi è la più importante in quanto viene coinvolto tutto il team. Il P.M. si limita
a motivare, valutare le prestazioni e a gestire le richieste di cambiamento, cioè in questa fase il cliente
può richiedere un’attività aggiuntiva e quindi il P.M., con il suo team, valuta, in termini di impatto,
quali sono i possibili scenari che sottopone alla scelta del cliente che poi può approvarla o meno

insieme allo sponsor, e quindi si può creare, ad es., una nuova baseline dell’ambito (scope). Quindi i
change Request (richieste di cambiamento) avvengono nella fase di esecuzione.
55
I processi riguardanti l’esecuzione ne sono 8
GRUPPO DI PROCESSI DI MONITORAGGIO E CONTROLLO
Il P.M. verifica che quanto eseguito sia in linea con le Baseline riportate nel Project Management Plan
per verificare se tutto è va bene o no.
I processi riguardanti il monitoraggio e controllo sono 11.
In particolare il processo “eseguire il controllo integrato delle modifiche” (integration
management) è un processo molto importante per il P.M. attraverso il quale una volta effettuato

la richiesta di cambiamenti da parte del cliente fa quell’analisi di impatto su tutte le variabili di
progetto.
56
Monitoraggio e controllo non sono identici.
Monitorare vuol dire attività di rilevazione dei dati ad oggi e comparazione con quanto pianificato;
quindi è un’attività statica – rilevo e comparo.
Il controllo ha una dimensione proattiva che il monitoraggio non ha. Cioè una volta rilevati i risultati
come mi devo comportare?
GRUPPO DI PROCESSI DI CHIUSURA
I processi sono solo due:
1) Chiudere gli approvvigionamenti (Procurement management): vuol dire aver pagato i
fornitori, aver gestito anche amministrativamente le fatture, e ovviamente quando il progetto
finisce faccio una valutazione su ogni Mileston, se il progetto andava bene o male, e quindi
analogamente a fine progetto per capire se sono stato efficiente.
Per capire so sono stato invece efficace è fondamentale che il cliente mi firmi che gli ho
rilasciato il progetto conforme ai requisiti aziendali; se invece il cliente non firma tale
documento, il progetto non finisce. Nel momento in cui il cliente mi firma ufficialmente che
ho rilasciato la deliverable conforme ai requisiti da lui esplicitati in fase di pianificazione, in tal
caso ho realizzato l’obiettivo di efficacia.
Fatto questo faccio una riunione di fine progetto in cui condivido i risultati finali con le mie
risorse (team). Tutta la documentazione di progetto va a finire in un database aziendale
(archiviata) e compilo le lesson learned (cosa ho imparato dai progetti sia positivamente che
negativamente?). Formalizzarle ed archiviare questo documento permette di condividere con
chi domani, trovandosi nella stessa situazione, potrà verificare come sono state gestite
determinate situazioni.
2) Chiudere il progetto o una fase, e per fase si intende il ciclo di vita tecnico (integration
management)
Tutte le informazioni relative ai progetti conclusi devono essere archiviate per poter essere utilizzate
in futuro. Tutto ciò può essere fatto solo dopo aver definito e formalizzato nel knowledge base

aziendale (il data base aziendale per la gestione della conoscenza) tutti i codici indispensabili per le
future ricerche delle informazioni relative allo storico dei progetti.
La documentazione di chiusura del contratto comprende innanzitutto la documentazione di
contratto, ovvero il contratto stesso, il capitolato e gli allegati, nonché l’accettazione formale del
cliente. Dopodiché è necessario considerare e archiviare:
• I documenti che descriveranno il prodotto e il progetto (piani, specifiche, documentazioni
57
tecnica prodotta, rilasciata e allegata, ecc.)
• I documenti relativi alle modifiche richieste dal cliente e approvate
• I documenti di misurazione delle performance, ovvero tutti i report prodotti per registrare e
analizzare le performance di progetto, nonché i criteri definiti inizialmente per misurarle
• I report di performance dei fornitori e la documentazione prodotta a seguito di qualsiasi
ispezione effettuata presso i fornitori, o ricevuta dal cliente prevista nei contratti
• I vari report sullo stato di progetto e sule problematiche incontrate che verranno inseriti
nell’apposito registro (Issue log – registro delle questioni)
• La documentazione finanziaria (fatture dei fornitori, fatture emesse verso il cliente, ricevute
di pagamento, ecc.)
• I registri di progetto sui rischi e le lesson learned
La documentazione di progetto, il registro dei rischi e delle risposte che il project Manager ha
adottato, le lesson learned e ogni informazione rilevante rappresenteranno il “business case” del
progetto e serviranno da caposaldo per il successo di tutti i progetti futuri.

1 introduzione

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à 1 introduzione

Similaire à 1 introduzione (20)

Dernier

Dernier (6)

1 introduzione