Intgegration e Scope Management (5th PMBOK)
“Il Progetto è un’iniziativa temporanea intrapresa per creare un prodotto, un servizio o un risultato con caratteristiche di unicità” – PMBOK – 5° Ed.
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”.
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.