Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

2 integration e scope management

2 375 vues

Publié le

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.

Publié dans : Ingénierie

2 integration e scope management

  1. 1. SCOPE MANAGEMENT
  2. 2. 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.
  3. 3. 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.
  4. 4. 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.
  5. 5. 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
  6. 6. 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.
  7. 7. 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.
  8. 8. 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.
  9. 9. 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).
  10. 10. 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).
  11. 11. 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
  12. 12. 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).
  13. 13. 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.
  14. 14. 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:
  15. 15. 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.
  16. 16. 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.
  17. 17. 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”.
  18. 18. DI SEGUITO VIENE PROPOSTO UN TEMPLATE DI PROJECT CHARTER
  19. 19. 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
  20. 20. 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
  21. 21. 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
  22. 22. 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
  23. 23. 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
  24. 24. - 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
  25. 25. 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.
  26. 26. 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
  27. 27. 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
  28. 28. 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
  29. 29. 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 € ….
  30. 30. 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
  31. 31. 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
  32. 32. (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.
  33. 33. 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.
  34. 34. 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ò.
  35. 35. 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.
  36. 36. 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.
  37. 37. 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.
  38. 38. 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
  39. 39. 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
  40. 40. 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.
  41. 41. 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
  42. 42. 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
  43. 43. 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
  44. 44. 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.
  45. 45. Mappatura template Business Case Initiating Planning Executing Monitoring & Controlling Closing Business Case 4.1 Develop Project Charter
  46. 46. 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.
  47. 47. 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
  48. 48. 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
  49. 49. 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
  50. 50. 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”.
  51. 51. 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
  52. 52. 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.
  53. 53. 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
  54. 54. 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.
  55. 55. 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
  56. 56. 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
  57. 57. • 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.
  58. 58. 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à
  59. 59. 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.
  60. 60. 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
  61. 61. 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:
  62. 62. 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.

×