PROJECT MANAGEMENT TOOLS& TECHNIQUES. MASSIMILIANO SPINETTI Diesys Informatica Srl

Transcript

1 PROJECT MANAGEMENT TOOLS& TECHNIQUES MASSIMILIANO SPINETTI Diesys Informatica Srl

2 Scenario e obiettivi del corso Il corso si propone di esplorare e approfondire i principalitemiinerenti il projectmanagement, al fine di consolidarne ed espanderne le conoscenze già oggi presenti all interno del dipartimento IT. Maggioreenfasi sarà data a temi quali la raccoltadei requisiti, la pianificazione, l analisi e la chiusura di progetto. La struttura del corso (contenuti e moduli) sono studiati per perseguire i seguenti primari obiettivi: Accrescimento delle competenze tecniche chiave Ottimizzazione interazione con stakeholders Accrescimento dell attenzione su fattori critici Accrescimento propensione al raggiungimento obiettivi 2

3 Agenda Apertura Presentazione del percorso Introduzione Project Management, perché? Progetto e Project Management Concetti base Principi di Comunicazione Raccolta dei requisiti Il processo di raccolta dei requisiti Analisi degli stakeholders Prioritizzazione dei requisiti 3

4 Agenda Pianificazione WBS RAM e RACI matrix Stime Sviluppo del reticolo di progetto Pianificazione e gestione del rischio Pianificazione Identificazione dei rischi Analisi qualitativa Risposta ai rischi Monitoraggio e Controllo Introduzione Punti di Controllo Project Closure Chiusura di progetto Imparare dall esperienza: feedback e lesson learned 4

5 Wall of issues

6 Perché Caratteristiche Mai/Poco Usate Standish Group 2002 Successo dei progetti Standish Group 2009 Eccedono stima tempi Standish Group 2011 Eccedono stima costi Lederer 1992 Lederer % 20% 40% 60% 80% 6 6 6

7 Causa Principali di Fallimento ALTRO PRODOTTO OBSOLETO SCARSA PIANIFICAZIONE CAMBIAMENTI INCESSANTI POCO SUPPORTO MANAGEMENT ASPETTATIVE NON REALISTICHE MANCANZA RISORSE UTENTI NON COINVOLTI SPECIFICHE INCOMPLETE CHAOS Report Standish Group 000% 005% 010% 015% 020% 025% 7

8 INTRODUZIONE CONTESTO IT 8

9 Percezione della funzione IT Il ruolo percepitodell'it è rimasto ancoratoallo schema tradizionale di gestoredi un servizioinfrastrutturale importante, complesso ed essenziale. Un ruolo di trasformazione informatica, delle attività strategiche aziendali che di fatto però lo relegano a ente tecnologico dedicato principalmente al supporto delle stesse. Non viene percepita la realepotenzialitàinsita nel know-how del personale IT, dovuta al fatto che per poter concretizzare l'ideadi businessraccolta, la si deve innanzitutto esplorare, capire e relazionare al contesto esistente. Questo lo pone quindi da una posizione di mero esecutore a quella di partner aziendale strategico. 9

10 L IT Business Partner, come? E possibile bilanciare valore erogato e richiesto attraverso le seguenti attività: Comunicazionale Comportamenti e attitudini di comunicazione efficace Riconoscimento dello stile di comunicazione dell interlocutore Business Mappatura del contesto di business dell interlocutore Comprensione della ragione del valore di business Operazioni di marketinginternoe di comunicazione del valore Operativa Strategie di Time& Resources Management Assegnazione delle priorità Mantenimento degli impegni presi 10

11 INTRODUZIONE PROJECT MANAGEMENT 11

12 ESERCITAZIONE Progetto e Project Management 12

13 Il Progetto Il progetto è uno sforzo temporaneoe progressivo, intrapreso per creare un prodotto o servizio unici. PMBOK 4th Edition Un progetto è un operazione, con forti vincolidi tempi e di costi, che ha lo scopodi realizzareun insieme di risultati( deliverable ), al fine di raggiungere gli obiettividel progetto, rispettando i requisitifissatie gli standard di qualità richiesti IPMA ICB 3.0 Un progetto è la gestione di un insieme di risorse interconnesse, in grado di offrire uno o più prodotti ad un cliente o utente finale. L'utilizzo dell'insieme di risorse, ha un inizio e fine definiti e operano secondo un piano prestabilito. CMMI Capability maturity Model 13

14 Il Progetto Con Temporaneo si intende che ha un inizio ed una fine definiti. La fine si raggiunge quando: Obiettivi sono raggiunti Obiettivi non raggiungibili Progetto non più necessario Il termine temporaneo è quindi applicato al progetto, non al prodotto o servizio creato dal progetto. Il concetto di temporaneitàsi ritrova anche nell opportunità o finestra di mercato e nel gruppo di progetto, poiché il primo ha in genere un periodo di tempo limitato, ed il secondo raramente sopravvive al progetto. 14

15 Il Progetto Un progetto crea deliverable Unici: prodotto o manufatto quantificabile capacità di erogare un servizio un risultato come esiti o documenti La presenza di elementi ripetitivi non modifica la fondamentale unicità del lavoro di progetto Elaborazione progressiva è una caratteristica del progetto che affianca Unicità e Temporaneità. Ed intende lo sviluppo in passaggi successivi e la prosecuzione incrementale. 15

16 Il Progetto Progetti e pianificazione strategica I progetti sono un metodo per le attività a cui i normali limiti aziendali non possono dare risposta. Vengono in genere autorizzati per: Richieste di mercato Necessità aziendali Richieste di un cliente Progresso tecnologico Adempimento legale 16

17 Project Management Il Project management è l arte di pianificare, organizzare, dirigeree controllarele risorsedi un azienda, per un periodo di tempolimitato, al fine di perseguire gli obiettivi prefissati dal progetto. Questa attività si muove su differenti piani lavorativi e richiede facoltànelle aree della comunicazionee delle risorseumane, della finanza e del marketing, degli acquisti e della logistica, aggiunte a conoscenze tecnichespecifiche del settore di applicazione del progetto stesso. 17

18 Project Manager Il Project Manager è la persona incaricata del raggiungimento degli obiettivi di progetto. Identificare i requisiti Fissare obiettivi chiari e raggiungibili Individuare l equilibrio tra esigenze di qualità, ambito, tempo e costi Adattare specifiche di prodotto, piani e approccio alle diverse aree di interesse e alle diverse aspettative degli stakeholder 18

19 Il Triplo Vincolo 19

20 Project Management Cultura aziendale Standard, normative, politiche Infrastrutture Skill risorse umane Mercato di riferimento Propensione al rischio Progetto e Organizzazione 20

21 Progetto e Contesto Qualsiasi progetto è pianificato, eseguito e terminato in un contestoben definito. Percepirne correttamente i contorni, può fare la differenza tra successo e fallimento. POLITICI RELIGIOSI ETICI CULTURALI ETNICI LEGISLATIVI GEOGRAFICI ECONOMICI NORMATIVI 21

22 Hard vs Soft Skills Sono più importanti questi? o questi? 22

23 Hard vs Soft Skills Figure 1.3 Technical and Sociocultural Dimensions of Project Management (Gray & Larson, 2006, p13) 23

24 Stakeholders Gli stakeholders sono individui o organizzazioni, attivamente coinvolti nel progetto, i cui interessi possono essere influenzati positivamente o negativamente dal progetto stesso. PMBOK 4th Edition 24

25 Project Life Cycle - Effort Figure 1.1 Project Life Cycle (Gray & Larson, 2006, p6) 25

26 COMUNICAZIONE e PROJECT TEAM 26

27 PRINCIPI DI COMUNICAZIONE Il 90% del tempo di un Project Manager è comunicazione 27

28 La comunicazione filtro filtro PMI.org- PMBOK Filtro: esperienza personale, percezione realtà, ecc. Codifica: tradurre idee e pensieri in un linguaggio comprensibile ai destinatari Messaggio: output della codifica Mezzo: utilizzato per trasmettere il messaggio Rumore: qualsiasi evento esterno che interferisce con la trasmissione del messaggio (es. distanza) Decodifica: reinterpretare il messaggio in idee e pensieri 28

29 Elementi non verbali nella comunicazione Uno studio condotto nel 1972 ha mostrato che ciò che viene percepito in un messaggio vocale può essere così suddiviso: Aspetto verbale Aspetto vocale Movimenti del corpo 0% 10% 20% 30% 40% 50% 60% Mehrabian, Albert (1972). Nonverbal Communication L efficacia di un messaggio dipende quindi solamente in minima parte dal significato letterale di ciò che viene detto. Il modo in cui questo messaggio viene percepito è influenzato pesantemente dai fattori di comunicazione non verbale. 29

30 La mappa non è il territorio! Chi confonderebbe una cartina dell Italia con il suo reale territorio? Ognuno di noi percepisce il mondo attraverso i 5 sensi. Sensori che noi utilizziamoper decodificare, organizzare, immagazzinaree dare significato a ciò che percepiamo dal mondo esterno. Ci costruiamo quindi una personale mappa della realtà. Quello che giornalmente accade è che erroneamente crediamo che ciò che pensiamo e percepiamo, sia effettivamente la realtà. La nostra realtà diventa la REALTA. 30

31 Motivazioni Motivo Azione Il MOTIVO, il bisogno, il desiderio, l esigenzafanno scaturire l AZIONE. Più il motivo è forte e più ci attiviamo per raggiungere uno scopo e soddisfare le nostre esigenze. La motivazione è determinante per il raggiungimento degli obiettivi. La motivazione sviluppala ricerca dei mezzi o delle scelte per il raggiungimento degli scopi prefissati. Spesso molte azioni intraprese non giungono a buon fine perché sono venute a mancare le motivazioni iniziali. 31

32 Teorie Motivazionali Piramide di Maslow il cui concetti chiave sono: Una serie di bisogni non nascono se prima non è soddisfatta la categoria di bisogni inferiore Le imprese coinvolgono le persone tanto più soddisfano i loro bisogni essenziali e quelli più evoluti 32

33 Teorie Motivazionali Teoria di McClelland Ogni individuo, in forma diversa è mosso da tre bisogni fondamentali: 1. Bisogno di successo e paura del fallimento 2. Bisogno di potere. Desiderio di dominio e paura di dipendenza 3. Bisogno di appartenenza. Bisogno di protezione e socialità e paura del rifiuto 33

34 Teorie Motivazionali Teoria dell attribuzione di Heider. Si può tendere verso due distinte direzioni per giustificare le proprie prestazioni. Attribuzione Esterna. Casualità ed agenti esterni di cui non si ha il controllo, limitano le possibilità di scelta, pertanto non ci si ritiene responsabili. Attribuzione Interna. Si è comunque sempre nella possibilità di scegliere, quindi si è responsabili si successi ed insuccessi. 34

35 Team Condizioni di esistenza Per definiredelle persone un Teamsi devono quindi verificare quattro condizioni minime: 1. Coinvolgimento dei Membri 2. Condivisione dei risultati 3. Fiducia nel Team 4. Responsabilità individuale I Team non sono tutti uguali Varia il grado di Autonomia nel Team Varia il grado di parcellizzazione dei compiti Varia il grado di sostituibilità degli individui Un Team è un collettivo di individui le motivazioni dei singolo concorrono a formare la natura del Team 35

36 Team Comunicazione nel Team Il Team deve conoscere la direzione del progetto, e saper collocare il proprio sforzo e i propri risultati Ricordarsi che un obiettivo deve essere sempre SMART Specifico Misurabile Accessibile Realistico Temporalmente definito Aumentare la visibilità con: Riunioni di tutto il Team. Centralizzazione delle informazioni di progetto Brainstorming - Coinvolgere i membri nelle decisioni di progetto. Tecniche di sviluppo Agile (Small releases, Iterative and incremental dev.) 36

37 Il valore del feedback Quello che conta è il risultato più che l intenzione Paul Watzlawick Il feedbackè il fattore fondamentale di ogni processo di comunicazione, soprattutto della comunicazione finalizzata a favorire l apprendimento e di conseguenza alla crescita. E' solo attraverso il feedback che saremo sicuri di aver appreso correttamente il messaggio del mittente. La comunicazione ottimale utilizza il feedback attraverso: domandedi verifica, ridondanza, per poter riproporrequanto compreso e averne un riscontro. 37

38 LA RACCOLTA DEI REQUISITI 38

39 Customer business value Aumento Profitti - Riduzione costi - Opportunità di crescita Innovazione - Costi del non fare Fidelizzazione clientela Differenziazione competitiva Promozione Brand Il giusto prodotto, al giusto prezzo, nei giusti tempi Fornire effettivo valore di business al cliente, in tempi brevi e con un occhio di riguardo ai costi 39

40 PREPARAZIONE DELL INTERVISTA 40

41 Problemi riscontrabili AMBITO I contornidel sistema da progettare nonsono ben definiti, esiste il rischiodi ampliaretroppoil campo di esplorazione. COMPRENSIONE Gli utentihanno comprensione soloparzialedei loro bisognie della tecnologia. Chi raccoglie i requisiti ha invece conoscenza limitata del dominio del problema, e del linguaggio. CONFLITTO Stakeholdersdiversi hanno punti di vista diversi sul problema. Necessario farli emergere con chiarezza e affrontarli. VOLATILITÀ I requisitievolvononel tempo: mutazioni del mercato, ricambio del management, ristrutturazionidell organizzazione, acquisizioni o vendite societarie, evoluzioni della tecnologia. 41

42 Stakeholders Analysis 1/2 E una tecnica che permette di analizzarel importanza strategicadi personeo organizzazioni, direttamente o indirettamente coinvolte in un progetto. Pone in risalto la loro influenza positiva o negativa. Il project manager ha il compito di trovare il giusto equilibrio tra gli interessi dei diversi stakeholders. 42

43 Stakeholders Analysis 2/2 Elencodegli stakeholders e identificazione influsso positivo o negativo Aspettative, benefici o perdite, relazioni, conflitti Gradodi influenza e possibile Impattodelle decisioni sul progetto Stakeholder Tipo (Pos/Neg) Aspetti Chiave Grado di Influenza Impatto 43

44 Successo dell intervista Innanzitutto è necessario aver condotto le attività di preparazione sopra descritte. Usare frasi brevi e semplici, uniformandone la struttura Noa domandeche influenzinol intervistato o contengano implicitamente già la risposta Concentrarsi sui problemi, nonsulle soluzioni. Identificare i requisiti, non effettuare scelte di progetto Non usare termini tecnici, ma utilizzo gergo del business Mantenere un livellodi astrazionecostante rispetto alle specificità Evitarel'uso di sinonimi(termini diversi con medesimo significato) e omonimi(termini uguali con differenti significati) 44

45 Principio di Pareto (regola 80/20) Buona parte degli effetti riscontrabili in un fenomeno lo si deve a un numero piuttosto ristretto di cause L 80% dei risultati è raggiungibile grazie al 20% delle attività. Il 20% delle funzionalità soddisfa l'80% delle esigenze Pareto 45

46 Criteri di prioritizzazione Una volta collezionate le necessità utente, al fine di procedere ad eventuali sessioni di approfondimento, è necessario assegnare loro una priorità. Questi i criteri di cui tenere conto. 1. Il valoredi businessche si ottiene sviluppando la funzionalità 2. Il costo di sviluppo/mantenimento della funzionalità 3. Il peso del knowledge che verrebbe acquisito grazie allo sviluppo della funzionalità 4. La capacità di abbattimento dei rischi grazie allo sviluppo della funzionalità 46

47 Rapporto valore/rischio funzionalità Rischio Rischio ALTO Valore BASSO Rischio ALTO Valore ALTO Finita la scomposizione è necessario assegnare un indice qualitativoa rischioe valoredi business delle funzionalità. Rischio BASSO Valore BASSO Rischio BASSO Valore ALTO Valore POSSIBILMENTE EVITARE PRIORITA 1 Quelle a rischioe valorepiù alti dovranno essere approfondite e implementate per prime, cercando di evitarequelle ad alto rischio e basso valore. Rischio FARE ALLA FINE Valore PRIORITA 2 Agile Estimating and Planning Mike Cohn 47

48 PIANIFICAZIONE 48

49 May June July August September ID Task Name Duration Start Finish SAP System Development 50 days Mon 25/05/98 Fri 31/07/98 2 Formal Demo 47 days Mon 25/05/98 Tue 28/07/98 3 Prepare for demo 10 days Mon 25/05/98 Fri 05/06/98 4 Invite & brief participants 5 days Mon 25/05/98 Fri 29/05/98 5 Develop demo scripts 5 days Mon 25/05/98 Fri 29/05/98 6 Practice demo 5 days Mon 01/06/98 Fri 05/06/98 7 Give Demo to Biz Units 10 days Mon 08/06/98 Fri 19/06/98 8 Formal Demo Complete 1 day Mon 22/06/98 Mon 22/06/98 9 Demo f ixes & Integration test 25 days Tue 23/06/98 Mon 27/07/98 10 Demo Fixes complete 1 day Tue 28/07/98 Tue 28/07/98 11 NON EDI Interface Integration 50 days Mon 25/05/98 Fri 31/07/98 12 Develop Non EDI 20 days Mon 25/05/98 Fri 19/06/98 13 Permanent Interfaces 29 days Mon 22/06/98 Thu 30/07/98 14 Write Schedules 5 days Mon 22/06/98 Fri 26/06/98 15 Interf ace Re-test 10 days Mon 13/07/98 Fri 24/07/98 16 QA 4 days Mon 27/07/98 Thu 30/07/98 17 Develop & Re-test One Time Interf aces 30 days Mon 25/05/98 Fri 03/07/98 18 Non-EDI Interf aces ready f or integration testing 1 day Fri 31/07/98 Fri 31/07/98 19 EDI Interface Integration 49 days Mon 25/05/98 Thu 30/07/98 20 Develop EDI 20 days Mon 25/05/98 Fri 19/06/98 21 Write Schedules 5 days Mon 22/06/98 Fri 26/06/98 22 Interf ace Re-test 10 days Mon 13/07/98 Fri 24/07/98 23 QA 4 days Mon 27/07/98 Thu 30/07/98 24 EDI Interf aces ready f or integration testing 1 day Mon 25/05/98 Mon 25/05/98 25 Master data 50 days Mon 25/05/98 Fri 31/07/98 26 Prepare Master Data for testing 50 days Mon 25/05/98 Fri 31/07/98 27 Prepare 30 days Mon 25/05/98 Fri 03/07/98 28 Master Data conversion - load 19 days Mon 06/07/98 Thu 30/07/98 29 Master data loaded f or testing 1 day Fri 31/07/98 Fri 31/07/98 30 Prepare master data for Roll-out 49 days Mon 25/05/98 Thu 30/07/98 25/05 29/05 25/05 29/05 01/06 05/06 08/06 19/06 22/06 25/05 19/06 23/06 27/07 22/06 26/06 25/05 03/07 25/05 19/06 25/05 22/06 26/06 25/05 03/07 13/07 24/07 28/07 27/07 30/07 13/07 24/07 31/07 27/07 30/07 06/07 30/07 31/07 Project Management Planning Steps Strategia Piani ausiliari Curva a S Risorse Project Charter Piano di progetto Piano dei costi Piano delle risorse Descrizione ambito Gantt e Milestone Piano dei tempi Scomposiz. Lavoro Ruoli e responsabilità Pianificazione e stime WBS OBS / RAM Rischi Reticolo 49

50 Work Breakdown Structure (WBS) WBS:Progetto = Aspirina: Essere Umano WBS: Project Manager = Coltellino Svizzero : MacGyver Descrizione gerarchica del lavoro Scomposizione delle attività Assegnazione delle responsabilità Supporto analisi Stakeholder Supporto analisi dei rischi 50

51 WBS - Deliverable La deliverablerappresenta un risultatotangibiledi progetto, da consegnare al cliente. Un deliverable può essere di due tipi: Fisico: rappresenta a tutti gli effetti parte del prodotto/servizio in realizzazione; Documentale: rappresenta la documentazione, o parte di essa, dei prodotti e servizi in realizzazione. Un deliverable deve essere verificabile in termini di adeguatezza a determinate specifichee standardper il suo completamento. Tali specificheguidano siala fase di realizzazionesia quella di teste verifica(scope Management) sotto forma ad esempio di una checklist di attributi e valori di cui assicurare la compatibilità con quanto concordato con la committenza. 51

52 WBS - Structure E una rappresentazione strutturata del lavoro del progetto Specifica COSAe non COME E focalizzata sugli out come (prodotto e/o servizi) NONrappresenta i task E una scomposizione gerarchica facilmente capibile dagli stakeholder Molto spesso è una rappresentazione graficama può essere rappresentata anche in altri formati Include sempre una WBS ed un WBS Dictionary 52

53 WBS - Structure Questa struttura rappresenta il 100% di tutto quello definito nello scope del progetto Se un prodotto o servizio non è compreso nella WBS allora il prodotto non fa parte del progetto Your WBS Coach Josh Nankivel 53

54 WBS Una visione condivisa Creare una visione condivisa. Le persone hanno interessi differenti a rami differenti della WBS. Il Managementè interessato di più ad un livello alto della WBS e quindi dello Scope (Visione Generale) Gli sviluppatorisono interessati ad un livello di dettaglio maggiore e danno meno importanza alla visione globale. Cosa quella singola parte di codice dovrà fare. (visione di dettaglio) Altri Team possono avere interessi in rami separati della WBS Altrei Team possono avere interesse solo alle parti di integrazione di rami differenti 54

55 WBS Cosa non è La WBS NONuna Task List Può venir naturale cercare di dare una struttura ordinata alle attività da fare, ma NON è una WBS Una lista di Task svia l attenzione dal risultato focalizzando già sul come e sulle dipendenze Una lista di Task non chiarisce come dovrà essere il risultato La WBS NON è un Organizational Chart Non rappresenta la struttura organizzativa La WBS NONè basata sul tempo o su fasi di progetto 55

56 WBS Cosa non è Cosa è Rappresenta lo Scope Grafica Ha un Dictionary Cosa NON è NON è una Task List NON è un Organizational Chart Non rappresenta fasi o tempi Definisce Chiarisce Comunica 56

57 WBS - Struttura Wikipedia 57

58 WBS 100% rule Questa regola cita che nella WBSdeve essere inclusoil 100% del lavoronecessario, e soloquellonecessario, per la realizzazione del prodotto/servizio richiesto, compresele attività di project management previste. Deve contenere Prodotti e/o servizi Non Task Il Risultato deve essere tangibile, deve rispondere alla domandacosae non a COME, QUANDO, PERCHE o CHI. La somma di tutti i Work Package deve dare il 100% dello Scope Your WBS Coach Josh Nankivel 58

59 WBS 100% rule E la baseper tutte le attività di progetto Ogni cosa che accade durante la gestione del progetto ha un riferimento alla WBS Rappresenta tutti e tre i vincoli base di un progetto. Costi, Scope e Schedule Senza la WBS non è possibile definire i deliverablesda associare alla schedulazione dei Task Senza questa associazione non è possibile stimare i costi Una WBS ben strutturata semplificala gestione del progetto 59

60 WBS Work Package Una WBS ben strutturata facilita i processi di stima Scomponendo il lavoro in parti sempre più piccole, si arriva all ultimolivello dove ogni singolo elemento è chiamato Work Package. Solitamente il work package ha una dimensione inferiore alle 80 ore di lavoro. E più facile stimare parti più piccole rispetto a parti più grandi. Una WBS ben strutturata facilita l assegnazione delle responsabilità Isolando ed assegnandosingole deliverables(prodotti e servizi) a persone o team. 60

61 WBS Work Package Una WBS ben strutturata facilita il controllo dei cambiamenti (Change Control process) Una richiesta di cambiamento deve riferirsi obbligatoriamente ad uno o più chunkdella WBS 61

62 WBS RAM Combinando un OrganizationalBreakdown Structure(OBS)con la Work Breakdown Structure(WBS), è possibile creare il documento di progetto ResponsabilityAssignmentMatrix (RAM), che assegna la responsabilità per ogni Work Package. Your WBS Coach Josh Nankivel 62

63 WBS Strumento per il monitoring Una WBS ben strutturata facilita le misurazioni E più facile misurare i progressi e capire qual è lo stato del progetto. Attraverso l applicazione di formule e calcoli come L Earned Value e basandosi sui tempi e costi stimati e quelli effettivi, è possibile monitorare lo stato di salute del progetto e intraprendere le necessarie azioni. 63

64 WBS Chi fa la WBS Spesso viene creata in autonomiadal Project Manager che successivamente la condivide con il Team Questo approccio è limitante e pericoloso, nel Team sono presenti persone con competenze tecniche e/o esperienza più adatta alla scomposizione e definizione di alcuni branch Il PM individua chi deve partecipare alla creazione della WBS. Più occhi e cervelli vedono quello che al singolo sfugge In alcuni casi può essere utile far partecipare a questo processo Stakeholder NON tecnici ma con ruolo chiave nella condivisione dei criteri di accettazione delle delivery. Se non si coinvolgonole persone giuste al momento giusto, probabilmente queste successivamente chiederanno perché di scelte e decisioni 64

65 WBS Regole Non deve essere presente ridondanza Ogni Work Package deve essere unico Ogni elemento della WBS deve avere almeno due figli Deve esistere una Naming Convention precisa e chiara La regola deve essere rispettata e presente anche nel documento di Dictionary Deve esserci il giusto grado di dettaglio Progetti differenti possono avere grado di dettaglio differente Scomporre fino ad avere dei work package sufficientemente dettagliati ma non troppo piccoli. (Standard 80 ore) Alcuni Branch possono avere numero di livelli differenti Possono esserci attività di Integrazione tra altri elementi 65

66 WBS Metodo del Post It Strumento molto comune Ottimo per Team che condividono lo stesso spazio War Room Favorisce l interazione tra gli elementi del Team Nonè lo strumento ideale su team distribuiti Un incaricato nel team, trasferisce in forma elettronica per poter utilizzare la WBS come base per le altre analisi Your WBS Coach Josh Nankivel 66

67 WBS Gantt Strumento e punto di partenza fondamentale per gli altri processi di pianificazione La numerazione della WBS è un riferimento per tutti gli altri Tools del Progetto Utilizzata nel processo di stima Your WBS Coach Josh Nankivel 67

68 WBS Gantt Utilizzata nel processo di schedulazione Dalla stima si passa all individuazione dei Task e delle dipendenze Ogni voce dello schedule fa riferimento ad un elemento della WBS Ad ogni elemento della WBS possono corrispondere più Task Your WBS Coach Josh Nankivel 68

69 WBS Monitoring & Controlling Utilizzata nel processo di Monitoring& Controlling La WBS ha le delivery ed i costi Lo Schedule (Gantt) ha i tempi e le dipendenze Monitorare lo stato di salute del progetto Cosa è stato fatto e cosa invece era pianificato Cosa è stato speso e cosa invece era previsto Qual è il rapporto tra i due valori Quando finirà il progetto? Quanto costerà alla fine? Con tutte queste informazioni è possibile creare a scadenze dei report sullo stato del progetto 69