Insegnamento di Gestione e Organizzazione dei Progetti A.A. 2008/9 Lezione 5: ciclo di vita di un progetto strutture organizzative il Project Charter

Transcript

1 Insegnamento di Gestione e Organizzazione dei Progetti A.A. 2008/9 Lezione 5: ciclo di vita di un progetto strutture organizzative il Project Charter Prof.ssa R. Folgieri folgieri@dico.unimi.it folgieri@mtcube.com Prof. R. Folgieri, Ing. PhD Gestione e Organizzazione dei Progetti 1 Ciclo di P.M. (Project Management) Nello schema sono rappresentate le varie fasi del ciclo di PM, precedute dall AVVIO DEL PROGETTO, che abbiamo identificato con la fase 0 (e il relativo dicumento di valutazione) di studio di fattibilità. Vi sono, comunque, varie rappresentazioni del ciclo di vita di un progetto, utili a seconda del tipo di progetto o aderenti allo standard del committente Prof. R. Folgieri, Ing. PhD Gestione e Organizzazione dei Progetti 2 1

2 Altre rappresentazioni del ciclo di vita: Difesa USA - Il sistema di acquisizione del Ministero della Difesa Americana, prevede fasi e deliverable di ciasuna milestone, secondo lo schema seguente: Milestone 0 Faseability Study approval Milestone II Technical Project approval Milestone IV Main Modification approval Milestone I Demonstration approval Milestone III Production approval Prof. R. Folgieri, Ing. PhD Gestione e Organizzazione dei Progetti 3 Altre rappresentazioni del ciclo di vita: Morris - La rappresentazione di morris (nello schema seguente) viene utilizzata per progetti di costruzioni Completamento (%) Feasibility Studio di fattibilità Progetto strategico Approvazione decisione di procedere Planning & Design Progetto di base Costi e tempi Termini contrattuali Condizioni Planning dettagliato Definizione pricipali contratti Production Manufacturing Consegne Opere civili Istallazioni Test Completamento sostanziale, realizzazione Turnover & startup Test finali Manutenzione operatività Stage 1 Stage 2 Stage 3 Stage 4 Prof. R. Folgieri, Ing. PhD Gestione e Organizzazione dei Progetti 4 2

3 Altre rappresentazioni del ciclo di vita: Murphy - Utilizzata per i progetti di prodotti farmaceutici test clinici test stabilità origine screening medicinale migliori lavoro preclinico per richiesta pratica IND IND ph I ph II ph III pratica NDA attività di controllo metabolismo tossicologia Processo di autorizzazione scoperta screening sviluppo preclinico (oltre 10 anni) registrazione lavoro approvazione IND Investigation New Drug application NDA New Drug Application Prof. R. Folgieri, Ing. PhD Gestione e Organizzazione dei Progetti 5 Altre rappresentazioni del ciclo di vita: PLM Product Lifecicle Management Obiettivo: ottimizzare (minor tempo, minori costi, maggiore qualità, minori rischi) lo sviluppo, la modifica e il ritiro dei prodotti o servizi dal mercato. Strategia che permette all impresa di innovare il prodotto durante tutto il cilco di vita (fino all obsolescenza), creando archivio di capitale intellettuale riutilizzabile (basato su accesso condiviso a fonte comune da cui attingere informazioni e processi relativi al prodotto). Molto utile in progetti di innovazione- Composto da vari moduli, organizzati nelle categorie: Document Management: gestione della documentazione tecnica (CAD/CAM/CAE) e di progetto. Product Structure Management: gestione della configurazione di prodotto (Struttura). Configuration management: gestione di varianti e lotti di produzione. Change management: gestione cambiamenti di entità che descrivono il prodotto. Workflow management: gestione del flusso aziendale dei dati. Catalog Library: gestioni dei componenti normalizzati e delle parti standard (viti bulloni, resistenze...). Supply Chain Management: gestione scambio dati con i fornitori. La scelta dei moduli da prevedere dipende dal grado di integrazione voluto per il processo produttivo. Prof. R. Folgieri, Ing. PhD Gestione e Organizzazione dei Progetti 6 3

4 Altre rappresentazioni del ciclo di vita: a spirale - Utilizzata per i progetti di sviluppo software Immagine tratta da wikipedia Prof. R. Folgieri, Ing. PhD Gestione e Organizzazione dei Progetti 7 Altre rappresentazioni del ciclo di vita: a cascata Per lo sviluppo del software (c è anche la metodologia waterfall) - il primo modello di ciclo di vita del software. il processo di sviluppo è diviso in fasi sequenziali output di ogni fase usato come input dalla fase successiva ogni fase del processo viene documentata. Fasi del modello a cascata tradizionale: studio di fattibilità. Scopo: determinare se avviare lo sviluppo del sistema analisi dei requisiti. Scopo: determinare cosa farà il sistema progetto. Scopo: determinare come il sistema farà quanto stabilito, la sua suddivisione in moduli e le relazioni fra questi codifica, o sviluppo. Scopo: creazione dei moduli con un linguaggio di programmazione collaudo. Scopo: verificare la correttezza dell'implementazione dei singoli moduli integrazione (o test di integrazione). Scopo: verificare la correttezza del funzionamento complessivo del sistema manutenzione. Scopo: dopo la consegna o delivery del prodotto, attività volte a migliorare, estendere e correggere il sistema nel tempo. Svantaggi: difficile stimare le risorse e i costi in maniera accurata prima del completamento della prima fase di analisi; specifica dei requisiti: documento scritto che vincola il prodotto da sviluppare e non sempre soddisfa le esigenze del cliente che spesso appaiono chiare dopo il primo rilascio del software l utente spesso non conosce tutti i requisiti dell applicazione il modello obbliga a usare standard di documentazione tali da rischiare la burocratizzazione Prof. R. Folgieri, Ing. PhD Gestione e Organizzazione dei Progetti 8 4

5 Altre rappresentazioni del ciclo di vita: a cascata Fonte: Prof. R. Folgieri, Ing. PhD Gestione e Organizzazione dei Progetti 9 Altre rappresentazioni del ciclo di vita: evolutivo Sviluppo ICT. Supera il modello a cascata. Si basa sulla prototipizzazione (realizzazione rapida di una versione semplificata del sistema informativo), per la sperimentazione di funzionalità. La verifica del prototipo può portare a una modifica dei requisiti e una eventuale revisione del progetto. La prima versione va dunque considerata throw-away ("cestinabile") valida finché non fornisce un feed-back sufficiente. La seconda versione può essere sviluppata seguendo il modello cascata. Poche fasi che si ripetono: Realizzazione di un prototipo Consegna del prototipo all utente Raccolta delle valutazioni dell utente Modifica del progetto in funzione delle valutazioni Soluzione parziale ai problemi del modello a cascata (elimina gli errori nei requisiti ma non riduce la distanza temporale per il completamento del ciclo di sviluppo). Le fasi possono essere anche concorrenti (si riducono i tempi, ma aumentano i rischi) Si è evoluto nel modello incrementale. Svantaggio maggiore: rischio di indisciplina. Necessari standard di processo. Prof. R. Folgieri, Ing. PhD Gestione e Organizzazione dei Progetti 10 5

6 Altre rappresentazioni del ciclo di vita: incrementale Per sviluppo ICT. Prevede le fasi: analisi dei requisiti progetto codifica test (o collaudo) Si ottiene la prima versione funzionante del prodotto software; si procede poi con la seconda iterazione, che prevede le fasi: analisi dei requisiti progetto codifica test (o collaudo) e si ottiene la seconda versione del prodotto, anch'essa funzionante. Si procede allora fino all'ennesima iterazione, finchè non si arriva ad un progetto solido. Consigliabile quando si ha una visione sufficientemente chiara dell'intero progetto sin dall inizio, perché occorre fare in modo che la realizzazione della generica versione k risulti utile per la realizzazione della versione k+1. Prof. R. Folgieri, Ing. PhD Gestione e Organizzazione dei Progetti 11 Altre rappresentazioni del ciclo di vita: a fontana Modello per ICT, altamente iterativo, particolarmente adatto per metodologie orientate agli oggetti e per grandi progetti cui partecipano molte persone, utile specialmente se il progetto riguarda prodotti mission critical che non possono fallire Si basa sul concetto che anche se alcune attività non possano iniziare prima di altre, (es. codifica e progettazione) sussiste forte sovrapposizione tra le attività durante il ciclo di sviluppo. Si chiama modello a fontana perché nel disegno sono presenti degli zampilli, anche a livelli inferiori, che indicano i casi in cui, per conoscenze sopraggiunte in corso di progetto, occorre ripianificare e quindi risalire la fontana. Permette lo sviluppo di componenti software maggiormente autonome, all interno di un infrastruttura unificante (integrazione). Si potrebbe dire che tende alla costruzione di un repository in cui immagazzinare componenti riutilizzabili (considerevole risparmio di tempo dovuto al parallelismo). Prof. R. Folgieri, Ing. PhD Gestione e Organizzazione dei Progetti 12 6

7 Altre rappresentazioni del ciclo di vita: a fontana Fonte: Prof. R. Folgieri, Ing. PhD Gestione e Organizzazione dei Progetti 13 Altre rappresentazioni del ciclo di vita: iterativo - Un altro esempio di rappresentazione per ICT è il modello iterativo. - Nella categoria dei modelli iterativi rientrano tutti i processi di sviluppo che permettono di ritornare ad una fase del procedimento già affrontata in precedenza. In ogni fase si tende a partire con una prima bozza della soluzione che seguirà successivamente raffinata al prossimo passaggio. - Vi sono tante altre rappresentazioni. - Non le elencheremo tutte. Abbiamo visto le principali. - Ciascuna dipende dalle caratteristiche del progetto Prof. R. Folgieri, Ing. PhD Gestione e Organizzazione dei Progetti 14 7

8 Ciclo di P.M. (Project Management) Se facciamo riferimento al modello generico che abbiamo utilizzato per introdurre il ciclo di P.M.(o project life cycle), ci accorgiamo che: le fasi (cui attribuire i gruppi di processi PMI) generalizzano tutti i modelli le 4 fasi e i gruppi o i singoli processi, ricorrono, in modi diversi o in diversa successione, in tutti i modelli. 4 fasi: stabilire obiettivi qualitativi e quantitativi pianificare e programmare costi e tempi mettere in atto il piano di lavoro valutare i risultati Prof. R. Folgieri, Ing. PhD Gestione e Organizzazione dei Progetti 15 FASE 1 Il progetto è approvato. Occorre specificare in dettaglio. A volte (è il caso dei progetti europei o dei progetti commissionati) si è indotti a pensare che fase 0 e fase 1 siano unificate. In realtà c è sempre una fase di analisi e di produzionedi specifiche di dettaglio. In questa fase tutti i capitoli della fase 0 vengono ripresi, dettagliati in sottocapitoli, e dettagliati. I documenti che vengono prodotti sono quelli che guideranno tutte le fasi del progetto: Project Charter: riporta i termini dell autorizzazione formale del progetto Descrizione dell ambito del progetto: collegato al precedente, stabilisce quale lavoro occorre eseguire e quali deliverable produrre Piano di Project Management: tipico di questa fase, stabilisce come deve essere eseguito il lavoro Il progetto è corredato poi di molti documenti a corollario (qualità, rapporti di stato d avanzamento, specifiche tecniche, documenti di exploitation), tutti conservati nel repository di progeto (es. wiki) Il piano di progetto, in tutte le sue parti, vive ed è aggiornato per tutta la durata del progetto. Prof. R. Folgieri, Ing. PhD Gestione e Organizzazione dei Progetti 16 8

9 Struttura organizzativa e progetto Un progetto è spesso parte di strutture organizztive pi ampie (il progetto è circoscritto nel tempo, ricordate? A volte può rappresentare un organizzazione (ad es. in caso di startup) In termini di prestazioni, un progetto dipende fortemente dalla sua struttura organizzativa Possiamo distinguere (PMI): Organizzazioni orentate ai progetti: le operazioni sono costituite principalmente da progetti, ovvero: il loro obiettivo è gestire/lavorare a progetti (es. società di consulenza) hanno adottato un modus operandi che segue la gestione per progetti Le organizzazioni che non sono invece orientate a progetti (ad es. molte aziende di produzione, manifatturiere, artigiane), sono solitamente poco efficaci. In questo caso vengono create sotto-organizzazioni Projectoriented. Prof. R. Folgieri, Ing. PhD Gestione e Organizzazione dei Progetti 17 Strutture organizzative In alcuni casi nell ambito di un progetto alcuni stakeholder (e spesso proprio il Project Manager) operano come amministratori delegati e si ha una struttura gerarchica che accentra poteri e responsabilità nella figura del Project Manager. Dunque vi è necessità di: dare ai Project Manager elevata libertà d azione. Si hanno quindi vincoli di strutture estremamente verticali, con forte connotazione gerarchica Seguire una politica di controllo e valutazione delle prestazioni molto stringenge e dunque predisporre procedure operative puntuali e strumenti efficaci Problema in questo caso: trovare un corretto bilanciamento tra potere e responsabilità per garantire che non si traduca tutto in puro decisionismo, ma che le scelte siano pesate. Prof. R. Folgieri, Ing. PhD Gestione e Organizzazione dei Progetti 18 9

10 Organizzazioni funzionali e project-oriented Nel caso delle organizzazioni Funzionali si ha una connotazione gerarchica, ma che coinvolge più livelli (è più complessa). vi è una precisa definizione del line management (gerarchia) lo staff è raggruppato per specializzazione In questo caso i progetti sono gestiti in fasi separate e la comunicazione segue il flusso gerarchico della struttura Nelle organizzazioni Project Oriented, invece, il personale è ridistribuito sulla base dei progetti e risponde al Project Manager del progetto che raggruppa lo staff. Le divisioni sono di solito di servizio ed il referente resta il Project Manager, che ha grande autonomia Entrambi gli approcci, se seguiti pienamente, presentano problemi. Esistono matrici (dette, rispettivamente, deboli, bilanciate e forti) che combinano caratteristiche dei due approcci per il miglio vantaggio di progetto. Prof. R. Folgieri, Ing. PhD Gestione e Organizzazione dei Progetti 19 PM nell organizzazione funzionale Da PMBOK - PMI Un progetto coinvolge staff di diverse funzioni per le rispettive attività Comunicazioni e decisioni seguono il line management (la gerarchia) Prof. R. Folgieri, Ing. PhD Gestione e Organizzazione dei Progetti 20 10

11 PM nell organizzazione Project-Oriented Da PMBOK - PMI ogni progetto ha il proprio staff Il project manager gode di maggiore autonomia e decide i ruoli nel progetto Prof. R. Folgieri, Ing. PhD Gestione e Organizzazione dei Progetti 21 Weak-matrix (matrice debole) Seguono molto il profilo funzionale Il project manager è più un coordinatore (facilitator) Da PMBOK - PMI Prof. R. Folgieri, Ing. PhD Gestione e Organizzazione dei Progetti 22 11

12 Strong-matrix (matrice forte) Da PMBOK - PMI Seguono molto il profilo delle organizzazioni project-oriented Project manager, a tempo pieno, con considerevole livello di autorità Prof. R. Folgieri, Ing. PhD Gestione e Organizzazione dei Progetti 23 Balanced-matrix (matrice equilibrata) Da PMBOK - PMI Il project manager non ha autorità assoluta sul progetto e sul suo finanziamento Prof. R. Folgieri, Ing. PhD Gestione e Organizzazione dei Progetti 24 12

13 Composite-matrix (matrice composita) Da PMBOK - PMI un organizzazione funzionale può creare un gruppo per progetto importante: avrà molte caratteristiche di un gruppo di progetto di un organizzazione project-oriented. personale di diversi reparti funzionali, dedicato a tempo pieno al progetto, svilupperà procedure proprie, potrà operare anche al di fuori della struttura gerarchica standard Prof. R. Folgieri, Ing. PhD Gestione e Organizzazione dei Progetti 25 Strutture organizzative e progetti Da PMBOK - PMI Prof. R. Folgieri, Ing. PhD Gestione e Organizzazione dei Progetti 26 13

14 PMO e Project Manager Molte strutture (soprattutto nelle strutture a matrice e in quelle orientate ai progetti) sentono il bisogno di un PMO PMO: Project Management Office (meglio Program Management Office) Visione strategica dei progetti Coordinamento di più progetti correlati (es. risorse condivise) Individuazione metodologie, standard e migliori pratiche di PM Predisposizione modulistica e documentazione Gestione dei rischi (condivisi e specifici) Gestione centrale degli strumenti di project management Coordinamento della comunicazione Monitoraggio tempi e budget (generalmente a livello aziendale) Coordinamento degli standard di qualità Prof. R. Folgieri, Ing. PhD Gestione e Organizzazione dei Progetti 27 PMO vs Project Manager Integrazione PMO e Project Manager Obiettivi ed esigenze diversi, comunque allineati alla strategia comune PM responsabile di speifici deliverable nell ambito del progetto; PMO ha specifici incarichi secondo la visione aziendale e gestisce modifiche di grande portata (programma) PM controlla le risorse del progetto; PMO ottimizza l uso delle risorse condivise PM gestise ambito, scheduling, costo e qualità dei prodotti dei Work Package; PMO gestisce rischio e opportunità complessivi e interdipendenza tra i progetti PM risponde dei progressi del progetto; PMO relazione complessivamente Prof. R. Folgieri, Ing. PhD Gestione e Organizzazione dei Progetti 28 14

15 PMO e struttura organizzativa Può essere adottato in qualsiasi struttura organizzativa A volte si limita a fornire suggerimneti su regole e procedure, altre autorizza (in questo caso generalmente delega la propria autorità ai PM) Il gruppo di progetto fa riferimento sempre al PM, a volte al PMO quando si tratta di risorse condivise (in questi casi c è preventivo accordo tra PMO e PM) Nelle strutture fortemente gerarchiche e nell organizzazione projectoriented, il PMO è una casella tra i PM e la direzione generale Nelle organizzazioni a matrice forte e nelle composite, il PMO è il manager dei PM Nelle strutture a matrice debole e a matrice equilibrata il PMO non riporta al direttore generale Se il PMO è presente, gestisce il sistema di Project Management. Il piano di Project Management descrive come sarà utilizzato questo sistema. Prof. R. Folgieri, Ing. PhD Gestione e Organizzazione dei Progetti 29 Definizione dei ruoli in un progetto ovvero persone giuste al posto giusto Il PM definisce i ruoli all interno di un progetto. E una delle prime fasi/scelte da affrontare Occorrono tatto e diplomazia, ma interessi del progetto due differenti approcci: il primo, orientato alle persone: richiede più tempo perché le persone si adeguino naturalmente al progetto e si orientino verso i ruoli più congegnali, ma rafforza l impegno e la lealtà di gruppo; il secondo, l approccio alla mansione: pone le esigenze del progetto prima di quelle delle persone e risulta più efficace quando le scadenze sono a breve termine. Spesso con questo approccio ci si deve preparare ad affrontare più momenti di crisi, poiché solitamente le richieste temporali sono molto vincolanti e le persone incontrano difficoltà, rendendo difficile lo sviluppo di lealtà di gruppo e impegno. sebbene migliore, non sempre è possibile scegliere il primo approccio cercate sempre di selezionare le persone giuste, tenendo presente che a ciascun membro del team tende in modo naturale ad assumere specifici atteggiamenti Ci sono sempre comportamenti come quelli descritti nella prossima slide Prof. R. Folgieri, Ing. PhD Gestione e Organizzazione dei Progetti 30 15

16 Definizione dei ruoli il coordinatore: persona che funge da coordinatore ed assume il compito di chiarire gli obiettivi al gruppo e favorire il processo di decision-making collegiale. Spesso però non porta a termine la discussione, delegando gli altri il docente: è la persona che seguirà più da vicino il processo di cambiamento, cercando di agevolarlo (mediante azioni di formazione). In generale, comunque, è anche colui che si aspetta la modifica immediata dei comportamenti da parte degli altri; l attuatore: trasforma le idee in azioni pratiche (o a volte definisce un vero e proprio piano di dettaglio). Può capitare che si senta poi così coinvolto da risultare inflessibile e poco tollerante sui risultati prodotti da altri; il tecnicone: in genere si identifica con il tecnico vero e proprio, il problem solver tecnologico, per esempio. In genere è creativo ma ha difficoltà a seguire strettamente il piano; il mediatore: è colui che comprende tutti gli altri e come interagire immediatamente. In genere, però, tende a perdere interesse nel progetto una volta che viene terminata la fase di pianificazione; chi si sente parte del team : generalmente queste persone incoraggiano e appoggiano gli altri e sono piuttosto diplomatiche, anche se a volte tendono ad evitare conflitti a discapito del progetto; il controllore: chi controlla e valuta tutte le fasi e le attività del progetto. Potrebbe però non essere in grado di stimolare gli altri ed essere visto dal gruppo in modo negativo; l ansioso: è la persona che cerca di fare in modo che il progetto sia completato nei tempi giusti ma tende a fare tutto autonomamente ed in modo eccessivamente apprensivo. Prof. R. Folgieri, Ing. PhD Gestione e Organizzazione dei Progetti 31 Definizione dei ruoli Per stabilire bene il ruolo che una persona (voi compresi) può avere in un team di progetto, sia per carattere, sia per capacità, ponetevi (e ponete, se è il caso) alcune domande fondamentali e le cui risposte vi forniranno l orientamento corretto: Quali skill ha la persona? Ha conoscenze specifiche? Qual è la sua ultima esperienza di progetto? Cosa ne ha appreso? Si dedicherà a tempo pieno al progetto? Chi valuterà l operato della persona? Come potrà comunicare se c è un problema o informarvi in caso di successo? Chi si occuperà delle esigenze dei componenti del gruppo di progetto? Qual è la situazione operativa ottimale per ciascuna persona? Prof. R. Folgieri, Ing. PhD Gestione e Organizzazione dei Progetti 32 16

17 Il Project Charter (1) Autorizza formalmente il progetto È pubblicato da un iniziatore o sponsor del progetto (esterni al progetto) È prodotto tenenedo in considerazione: Richieste di mercato Necessità commerciali Richieste di un cliente Miglioramento tecnologico Requisito legale Esigenza sociale Definisce come rispondere e quali progetti autorizzare ed avviare formalmente. I metodi di selezione dei progetti comportano la misura del valore o del grado di interesse per lo sponsor Prende spunto dallo studio di fattibilità (a volte analisi più semplici) Prof. R. Folgieri, Ing. PhD Gestione e Organizzazione dei Progetti 33 Il Project Charter (2) Deve fornire le informazioni: Requisiti che soddisfano le esigenze, le necessità e le aspettitative Necessità commerciali, descrizione del progetto ad alto livello o requisiti del prodotto Obiettivo e giustificazione del progetto Project manager assegnato e livello di autorità Scheduling delle milestone di riepilogo Influenza degli stakeholder Organizzazioni funzionali e loro partecipazione Assunti organizzativi, ambientali ed esterni Vincoli organizzativi, ambientali ed esterni Business Case che giustifica il progetto (compreso il rendimento dell investimento) Budet riepilogativo Spesso si ricorre al parere di esperti Prof. R. Folgieri, Ing. PhD Gestione e Organizzazione dei Progetti 34 17