Project Management - Module 3 Training (Fabio Moioli)

Slide 1: Project Management Professional Training Modulo 3 Fabio Moioli (fabiomoioli@gmail.com) Milano Aprile 2008

Slide 2: Fabio Moioli (fabiomoioli@gmail.com) Agenda for today Product Scope (End deliverables) Project Scope (WBS) Time estimation Project Scheduling Cost estimating 1

Slide 3: Fabio Moioli (fabiomoioli@gmail.com) Definizione dei requisiti alla base della prima fase di progetto Impostazione Impostazione Pianificazione Pianificazione Definizione dei requisiti Controllo Controllo Esecuzione Esecuzione Chiusura Chiusura 2

Slide 4: Fabio Moioli (fabiomoioli@gmail.com) Set-up and Planning Phases In questa fase i requisiti, le attività sono definite in dettaglio. Il piano di risk management è sviluppato, l’organizzazione è confermata con l’assegnazione delle risorse, il budget con gli obiettivi di tempo sono stati confermati. Nessun costo di risorse sarà speso fino a che la pianificazione non è ultimata e l’autorizzazione a procedere non è pervenuta. Output: Product Scope: Requirements documentation Project Scope: WBS Stima durata Project Scheduling RAM Cost estimating Communication Plan 3

Slide 5: Fabio Moioli (fabiomoioli@gmail.com) Impostazione del progetto – Individuazione degli obiettivi Aspettative Contratto inespresse Aspettative del cliente dell’utenza Scope planning Obiettivi di progetto 4

Slide 6: Fabio Moioli (fabiomoioli@gmail.com) Impostazione del progetto – Caratteristiche degli obiettivi Chiari - Descrizione non ambigua, con pochi termini tecnici dei quali è illustrato il significato Misurabili - Devono prevedere una metrica ed un valore target Realistici - Deve essere raggiungibile il target degli obiettivi nel loro insieme (prodotto, tempi, costi, qualità) 5

Slide 7: Fabio Moioli (fabiomoioli@gmail.com) Impostazione del progetto – I requisiti di prodotto • È il risultato dell’analisi dei fabbisogni del committente • Si procede in modo incrementale fino a raggiungere il livello di precisione che elimini tutte le ambiguità • Inizia con lo studio di fattibilità e si completa nel corso dell’esecuzione del progetto • È un fattore critico di successo del progetto e coinvolge sia l’utente che il fornitore 6

Slide 8: Fabio Moioli (fabiomoioli@gmail.com) Planning Phase – Product vs. Project Scope Scope is defined as the sum of products or services to be provided by the project. Types of scope: • Product scope: Customer requirements Requirements Documentation • Project scope: Works to satisfy customer requirements WBS 7

Slide 9: Fabio Moioli (fabiomoioli@gmail.com) Individuazione degli obiettivi di prodotto Impostazione del progetto – Individuazione degli obiettivi • Prodotto/servizio da realizzare (definizione dei requisiti) • A quali costi • In quanto tempo • Con quale livello qualitativo La fonte di riferimento è il contratto il quale non sempre definisce in modo sufficientemente chiaro tutti gli obiettivi. Alcuni obiettivi possono essere impliciti e riguardano le aspettative inespresse del cliente. L’utenza specifica nel dettaglio gli obiettivi. 8

Slide 10: Fabio Moioli (fabiomoioli@gmail.com) Raccolta dei requisiti Tipi di Project Requirements: Functional Technical Raccolta dei requisiti: Interviste Survey Industry e Trade Information JAR e JAD sessions Informazioni “storiche” 9

Slide 11: Fabio Moioli (fabiomoioli@gmail.com) Pianificazione dei requisiti Il P.M. deve determinare ciò che lo sponsor vuole dal team di Progetto. Ciò significa che deve nella fase iniziale definire obiettivi e requisiti di base del progetto I requisiti sono la base per lo sviluppo del progetto Il processo di definizione dei requisiti include gli step seguenti: 1. Raccogliere i needs del cliente e degli stakeholder 2. Tradurre questi needs in requisiti o esclusioni di progetto 3. Validare i requisiti. 10

Slide 12: Fabio Moioli (fabiomoioli@gmail.com) Steps di definizione requisiti (1/3) 1. Raccogliere i requisiti (customer needs) Leggere tutta la documentazione del progetto, contratti, tutto ciò che può contenere le problematiche del cliente Intervistare lo sponsor Intervistare gli stakeholders identificati nei documenti Quantificare e prioritizzare la quantità di risposte che lo sponsor e gli stakeholder hanno dato Sintetizzare i needs di base raccolti 11

Slide 13: Fabio Moioli (fabiomoioli@gmail.com) Steps di definizione requisiti (2/3) 2. Tradurre questi bisogni in requisiti o esclusioni di progetto Tramutare i “bisogni” in requisiti. Non non ci saranno nuovi requisiti identificati e descritti esternamente al documento originale di Piano di Progetto I requisiti devono essere documentati al massimo dettaglio perché rappresentano la base dello sviluppo di progetto. 12

Slide 14: Fabio Moioli (fabiomoioli@gmail.com) Steps di definizione requisiti (3/3) 3. Validare i requisiti I requisiti devono essere sempre validati con lo sponsor, stakeholder ed il project team. Queste revisioni servono a capire se ciò che è scritto corrisponde al reale requisito delle persone coinvolte. Si definiscono le volontà dello sponsor e quanto il project team è in grado di realizzare. I requisiti devono essere approvati dallo sponsor, stakeholders, e dai componenti chiave del project team. Per validare i requisiti, questi devono essere raccolti, documentati, distribuiti allo sponsor, stakeholders, ed i componenti del project team per essere validati. Ogni ciclo di revisione si conclude con l’arrivo di tutte le approvazioni. Dopo ogni ciclo di approvazione: – Decidere ciò che si implementa e ciò che non si implementa. Definire i “confini” del progetto – Rivedere i requisiti e scendere a ulteriore dettaglio. Continuare la documentazione dei requisiti e le fasi di approvazioni fino alla sicurezza che tutto sia dettagliato ed approvato 13

Slide 15: Fabio Moioli (fabiomoioli@gmail.com) I requisiti non potranno essere cambiati in futuro se non attraverso un processo di Change Management 14

Slide 16: Fabio Moioli (fabiomoioli@gmail.com) Product Scope - Esercizio 15

Slide 18: Fabio Moioli (fabiomoioli@gmail.com) Introduzione al Project Management – Project Scope Identificazione dei compiti di Progetto Si procede alla definizione analitica del progetto attraverso la individuazione dei sottoprogetti, dei prodotti e delle attività e delle loro componenti fino a raggiungere il livello di dettaglio che consenta un adeguato controllo del progetto in corso d’opera. 17

Slide 19: Fabio Moioli (fabiomoioli@gmail.com) Work Breackdown Structure Identificazione dei compiti Un metodo di rappresentazione: WBS Gestione ordini Gestione ordini Analisi delle funzioni Analisi delle funzioni Analisi dei dati Analisi dei dati Realizzazione e progettazione e progettazione Realizzazione Preparazione Preparazione Preparazione Definizione Definizione Individuazione Individuazione Scrittura Scrittura Preparazione Esecuzione Esecuzione Modello Modello Modello Flusso Flusso moduli e moduli e Programmi Programmi Modello Test Test logico fisico fisico informativo informativo interfacce interfacce software software logico D.F D D.F D 18

Slide 20: Fabio Moioli (fabiomoioli@gmail.com) Work Breackdown Structure - note Identificazione dei compiti • La WBS non individua la cronologia delle attività; • Devono essere definiti tutti gli oggetti da consegnare; • La funzione elementare è un’unità di lavoro (work package). 19

Slide 21: Fabio Moioli (fabiomoioli@gmail.com) Work Packages (WPs) Identificazione dei compiti Per ogni work package occorre indicare: La descrizione delle attività da svolgere comprese quelle di controllo qualità Evento di chiusura Gli input attesi eventualmente da altre attività Gli output previsti Mesi uomo richiesti Vincoli 20

Slide 22: Fabio Moioli (fabiomoioli@gmail.com) I tre tipi di Breakdown Structures 21

Slide 23: Fabio Moioli (fabiomoioli@gmail.com) Creazione hierarchical decomposition structure Occorre creare le product breakdown structure (PBS), un organizational breakdown structure (OBS) e un work breakdown structure (WBS). Esistono tre tipi di breakdown structures: PBS. Questa struttura è una gerarchia di prodotti che devono essere costruiti. Il focus della PBS è what deve essere prodotto. WBS. Questa struttura è una gerarchia di attività. La WBS è una struttura gerarchica di tutte le attività che devono essere fatte per produrre i dettagli della PBS. Il focus della WBS è how i prodotti devono essere costruiti.. OBS. Questa struttura rappresenta le risorse. OBS descrive la struttura del Team di lavoro e le organizzazioni di delivery. Il focus della OBS è who costruisce i prodotti. 22

Slide 24: Fabio Moioli (fabiomoioli@gmail.com) Creazione hierarchical decomposition structure Creare la Product Breakdown Structure Dal documento dei requisiti il P.M. prepara un high-level PBS che consiste di due o tre livelli. Coinvolge il team nello sviluppo della PBS se non è in grado di sviluppare tutti i dettagli a più basso livello Rivede le PBS con gli appropriati Stakeholders 23

Slide 25: Fabio Moioli (fabiomoioli@gmail.com) Creazione hierarchical decomposition structure Creare la Work Breakdown Structure La WBS è la gerarchica scomposizione di tutte le attività che il project team deve completare Il focus è how realizzare gli elementi della PBS, il cui focus è what deve essere realizzato. La seguente figura rappresenta la medesima WBS in due modi grafici: la prima a “albero” la seconda a “indice” 24

Slide 26: Fabio Moioli (fabiomoioli@gmail.com) Creazione hierarchical decomposition structure Creare la Work Breakdown Structure Si parte dal progetto globale e lo si compone in sottoprogetti in base alle conoscenze disponibili sul modo di eseguire il progetto, si individua così il primo livello di scomposizione Si procede quindi analogicamente a scomporre ciascun sottoprogetto in raggruppamenti di lavoro costituenti il secondo livello, e così via sino ad individuare le attività elementari 25

Slide 27: Fabio Moioli (fabiomoioli@gmail.com) Creazione hierarchical decomposition structure Creare la Work Breakdown Structure Una Fase è un elemento di lavoro a alto livello Il più basso livello della WBS è il work package 26

Slide 28: Fabio Moioli (fabiomoioli@gmail.com) Esempio di WBS: progetto di realizzazione di un libro di raccolta fotografica per la celebrazione di un anniversario aziendale Produzione Produzione libro libro Sviluppo Sviluppo Completamento e Completamento e Stampa Stampa editoriale editoriale invio invio Approvvigionamento Produzione copertina Predisposizione Contratto Prodotto Prodotto impianti Rilegatura Contratto editoriale editoriale Prova Stampa Spedizione Stampa Prototipo Ricerca testi Preventivazione Ricerca foto tecnica Redazione testi Predisposizione Correzione bozze contratto Firma contratto 27

Slide 29: Fabio Moioli (fabiomoioli@gmail.com) Project Break-down Flow (Example…) WBS per ogni fase di progetto Text Text Text Text Text Text Text Text Text Text Text Text 28

Slide 30: Fabio Moioli (fabiomoioli@gmail.com) WBS e Responsabilità di Stakeholders e Team members Assegnazione responsabilità Definita la struttura organizzativa del progetto e individuati i compiti si assegnano le responsabilità. Il risultato di questa attività può essere rappresentato utilizzando la matrice Compiti/Responsabilità. 29

Slide 31: Fabio Moioli (fabiomoioli@gmail.com) Assegnazione responsabilità Matrice Compiti/Responsabilità Work Breakdown Structure Livello Team di progetto 1 2 3 4 Bianchi Rossi Verdi Giorgi Sistema informativo del personale X Gestione paghe e stipendi X Analisi X Analisi dati X Analisi funzioni X Integrazione d/f X Progettazione X Realizzazione X Collaudo X 30

Slide 32: Fabio Moioli (fabiomoioli@gmail.com) Project Scope – Esercizio (WBS) 31

Slide 34: Fabio Moioli (fabiomoioli@gmail.com) Time estimation Tecniche di valutazione delle durate delle attività: Expert judgement Brainstorming Analogous estimates and historical information CPM (critical path method) Delphi method Dettagliati PERT method di seguito Monte Carlo Prediction Markets 33

Slide 35: Fabio Moioli (fabiomoioli@gmail.com) Critical Path Method (CPM) Critical Path Method, abbreviated CPM, or critical path analysis, is a mathematically based algorithm for scheduling a set of project activities. Commonly used with all forms of projects, including construction, software development, research projects, product development, engineering, and plant maintenance, among others. The essential technique for using CPM is to construct a model of the project that includes the following: A list of all activities required to complete the project (also known as Work Breakdown Structure) The time (duration) that each activity will take to completion, and The dependencies between the activities. CPM calculates the longest path of planned activities to the end of the project, and the earliest and latest that each activity can start and finish without making the project longer 34

Slide 36: Fabio Moioli (fabiomoioli@gmail.com) Delphi method The Delphi method is a systematic interactive forecasting method for obtaining forecasts from a panel of independent experts. High-level execution steps and directions: • Carefully selected experts answer questionnaires in two or more rounds. • After each round, a facilitator provides an anonymous summary of the experts’ forecasts from the previous round as well as the reasons they provided for their judgments. • Thus, participants are encouraged to revise their earlier answers in light of the replies of other members of the group. • It is believed that during this process the range of the answers will decrease and group will converge towards the "correct" answer. • Finally, the process is stopped after a pre-defined stop criterion (e.g. number of rounds, consensus, stability of results) and mean or median scores of the final rounds determine the results 35

Slide 37: Fabio Moioli (fabiomoioli@gmail.com) Project Evaluation and Review Technique (PERT) Tecnica di valutazione PERT: Formula variables: • P = Pessimistic PERT Estimate = (P + O + 4 ML) / 6 • O = Optimistic • M = Most likely Standard deviation = (P-O) / 6 Alta Most Likely PERT media ponderata = Ottimistica + 4 x Most Likely + Pessimistica Probabilit 6 à Pessimistica Ottimistica Bassa Breve Lunga Durate possibili 36

Slide 38: Fabio Moioli (fabiomoioli@gmail.com) PERT Calculation Alta Most Likely PERT (media ponderata) = Ottimistica + 4 x Most Likely + Pessimistica 6 Probabilità Pessimistica Ottimistica Bassa Breve Lunga Durate possibili 37

Slide 39: Fabio Moioli (fabiomoioli@gmail.com) Esempi distribuzioni di probabilità per simulazione Monte Carlo Probabilità Probabilità Distribuzione uniforme Distribuzione Normale Tempo/costo Tempo/costo Probabilità Probabilità Distribuzione Distribuzione Beta Triangolare Tempo/costo Tempo/costo 38

Slide 40: Fabio Moioli (fabiomoioli@gmail.com) Time estimation – Esercizio 39

Slide 42: Fabio Moioli (fabiomoioli@gmail.com) Project Scheduling La pianificazione o schedulazione di di un progetto è una roadmap che fissa durata, sequenza di eventi ed attività. Una task è una parte di attività, è il più basso livello di WBS. Una fase è una parte di lavoro fatta su un lasso di tempo significativo all’interno del Progetto: nella WBS si raccolgono logicamente più task. Punti di inIzio e di fine delle attività sono gli eventi. Un milestone è un raggiungimento o un significativo evento all’interno di un progetto, per esempio un punto di decisione o il completamento di una rilevante attività. È un’attività con zero durata e zero risorse. Una “precedence relationship” è una dipendenza tra due task e/o fasi. La precedence diagramming method (PDM) è un metodo di costruzione di un project network diagram usando nodi che rappresentano attività e li collegano al fine di evidenziarne le dipendenze. 41

Slide 43: Fabio Moioli (fabiomoioli@gmail.com) Project Scheduling - project network diagram Un project network diagram consiste di una serie di attività di progetto assemblate in un flusso logico. Ogni elemento della WBS e’ rappresentato nel network diagram, ed ogni elemento della WBS al più basso livello e’ rappresentato La WBS contiene tutte le attività necessarie a completare il progetto, ma non e’ un piano di schedulazione. Il project network diagram e’ un prodotto di schedulazione che mostra le relazioni (predecessori, successori) tra le attività precedentemente definite nella WBS. 42

Slide 44: Fabio Moioli (fabiomoioli@gmail.com) Project Scheduling Per creare un project network diagram, occorre fare la lista dei task del progetto. Da qui si disegnano i nodi nel project network diagram. Occorre chiedere al team di progetto quali sono i tasks che devono finire prima che altri task possano iniziare. Memorizzare l’ordine di esecuzione dei task. Continuando in questo modo, si continua ad identificare e disegnare le relazioni di dipendenza per creare un network diagram del progetto. Esempio di Project Network Diagram: 43

Slide 45: Fabio Moioli (fabiomoioli@gmail.com) Finish to Start La pianificazione reticolare Tipi di legami di precedenza: • Finish to Start: l’attività B non può iniziare se non è terminata l’attività A. A FS B Esempio: Un esempio non si può iniziare aa Esempio: Un esempio non si può iniziare progettare l’applicazione se non sono state progettare l’applicazione se non sono state approvate le specifiche approvate le specifiche 44

Slide 46: Fabio Moioli (fabiomoioli@gmail.com) Start to Start La pianificazione reticolare Tipi di legami di precedenza: • Start to Start: l’attività B non può iniziare se non è iniziata l’attività A. A SS B Esempio: IlIltest sui moduli di un’applicazione Esempio: test sui moduli di un’applicazione non può iniziare se non èèiniziata l’attività di non può iniziare se non iniziata l’attività di realizzazione realizzazione 45

Slide 47: Fabio Moioli (fabiomoioli@gmail.com) Start to Finish La pianificazione reticolare Tipi di legami di precedenza: • Start to Finish: l’attività B non può finire se non è iniziata l’attività A. A SF B 46

Slide 48: Fabio Moioli (fabiomoioli@gmail.com) Finish to Finish La pianificazione reticolare Tipi di legami di precedenza: • Finish to Finish: l’attività B non può finire se non è finita l’attività A. A FF B Esempio: in un ciclo di vita prototipale la fase Esempio: in un ciclo di vita prototipale la fase di realizzazione non può finire se non èèfinita la di realizzazione non può finire se non finita la fase di collaudo fase di collaudo 47

Slide 49: Fabio Moioli (fabiomoioli@gmail.com) Lags La pianificazione reticolare • Ad ogni legame di precedenza può essere associato un ritardo (lag) oppure un anticipo RITARDO FS + 2 1 2 3 4 5 6 7 48

Slide 50: Fabio Moioli (fabiomoioli@gmail.com) Anticipi La pianificazione reticolare ANTICIPO FS - 1 1 2 3 4 5 6 7 49

Slide 51: Fabio Moioli (fabiomoioli@gmail.com) Project network diagram – key points I punti fondamentali Il project network diagram inizia con una task o milestone Il project network diagram finisce con una task o milestone Ci sono predecessori o successori per tutte le attività, non ci sono task senza linee di connessione Nessun loop 50

Slide 52: Fabio Moioli (fabiomoioli@gmail.com) Project Scheduling I tipi di relazioni Finish-to-start (FS) Finish-to-finish (FF) Start-to-start (SS) In una relazione FS, una attività deve finire prima che un’altra attività possa iniziare. Nell’esempio, l’attività 1.2 non può iniziare prima che l’attività 1.2 sia finita. In una relazione FF, l’attività precedente deve completarsi nello stesso tempo del completamento della successiva attività. Esempio: Sviluppa il prodotto, sviluppa la user guide. Testi il programma, validi la documentazione del programma 51

Slide 53: Fabio Moioli (fabiomoioli@gmail.com) Project Scheduling Relationships: La relazione SS è usata quando più attività “chiave” devono Iniziare nello stesso tempo. La relazione SS richiede che il predecessore sia schedulato per iniziare prima o simultaneamente rispetto al successore. 52

Slide 54: Fabio Moioli (fabiomoioli@gmail.com) Project Scheduling Lead Time and Lag Time: Lead time e lag time sono cambiamenti nelle relazioni che determinano anticipi o ritardi per l’attività successiva. Entrambi sono modi formali per correggere la schedulazione. Lag time è un ritardo imposto nella relazione tra due attività. Per esempio, in una finish-to-start dipendenza con 10 gg di lag, l’attività del successore non può partire prima di 10 gg dopo che il predecessore ha terminato. Lag time è generalmente un numero positivo. Lead time è un accelerazione per l’attività successiva. Per esempio, in una dipendenza finish-to-start con un 10 gg lead, l’attività successiva può partire 10 gg prima che il predecessore abbia finito. Lead time è generalmente un numero negativo. 53

Slide 55: Fabio Moioli (fabiomoioli@gmail.com) Project Scheduling Lead Time and Lag Time: 54

Slide 56: Fabio Moioli (fabiomoioli@gmail.com) Project Scheduling Come creare un Precedence Diagram: Per ciascuna task : The early start (ES), è la più “anticipata” data in cui l’attività può iniziare The early finish (EF), è la più “anticipata” data in cui l’attività può finire The late start (LS), è la data più “posticipata” in cui l’attività può iniziare The late finish (LF), è la data più “posticipata” in cui l’attività può finire 55

Slide 57: Fabio Moioli (fabiomoioli@gmail.com) Project Scheduling Per creare un Precedence Diagram: Il forward pass è usato per calcolare le date ES e EF di tutte le attività ES + durata = EF Il backward pass è usato per calcolare le date LS e LF di tutte le attività. Queste sono le date più posticipate che si possono fissare senza impattare le date di fine del progetto. In questo esempio, supponendo che la data finale sia 15, per calcolare la LS dell’attività “pour concrete” occorre sottrarre a 15 la durata di 4 arrivando a 11. LS = LF-durata 56

Slide 58: Fabio Moioli (fabiomoioli@gmail.com) Project Scheduling Per creare un Precedence Diagram: 57

Slide 59: Fabio Moioli (fabiomoioli@gmail.com) Project Scheduling Per creare un Precedence Diagram: 58

Slide 60: Fabio Moioli (fabiomoioli@gmail.com) Project Scheduling Il critical path è: Il più lungo path all’interno del progetto Il più critico tempo per completare il progetto Float = 0 float = LS-ES: ritardo che posso accumulare senza spostare la data fine del progetto 59

Slide 61: Fabio Moioli (fabiomoioli@gmail.com) Project Scheduling MS Office Project Workbench Project 60

Slide 62: Fabio Moioli (fabiomoioli@gmail.com) PDM - AON A A B B C C Start Start Finish Finish D D E E F F 61

Slide 63: Fabio Moioli (fabiomoioli@gmail.com) ADM - AOA B A C Start Finish D F E 62

Slide 64: Fabio Moioli (fabiomoioli@gmail.com) Resource Assignement Matrix (RAM) RAM 63

Slide 65: Fabio Moioli (fabiomoioli@gmail.com) Resource Constraints Organizational structure Collective bargaining Project team preferences Expected staff assignments Technology and complexity 64

Slide 66: Fabio Moioli (fabiomoioli@gmail.com) Project Scheduling – Esercizio 65

Slide 68: Fabio Moioli (fabiomoioli@gmail.com) Valutazione economica Stimare/valutare economicamente un progetto significa definire quantità e costi delle risorse necessarie al successo del progetto. Budget è l’allocazione del costo necessario durante il periodo del progetto per la completa copertura finanziaria del progetto stesso. Stima/valutazione economica: Non è un budget. Un budget alloca i costi stimati per singolo componente di progetto al fine di essere misurato durante lo sviluppo del progetto stesso. Stima è definire i costi delle persone necessarie alle attività progettuali partendo da mesi-persona, giorni-persona, ore-persona. Dopo aver calcolato queste entità e definito i costi per risorsa si può costruire un valutazione economica. Non è un prezzo, ma un fattore di costo. Una valutazione economica contiene tutti gli elementi relativi al costo del progetto: Staff, materiale, facilities … Il costo è interno al progetto, il prezzo è ciò che viene fatturato al cliente. Deve essere documentato. 67

Slide 69: Fabio Moioli (fabiomoioli@gmail.com) Valutazione economica I termini per la stima: Effort. È il numero di unità di lavoro richieste per terminare un task: mesi- persona, giorni-persona, ore-persona. Quando questo numero è definito ed il numero di staff, la produttività e la availability sono state fissate, la durata del singolo task può essere calcolata. Level of Effort (LOE). Descrive le attività necessarie al supporto di un progetto, ma che non possono essere pianificate e schedulate (amministrazione specifica al progetto, gestione posta, riunioni … ). È un parametro difficile da essere calcolato, ma spesso espresso in termini di percentuale, (di solito stimata al 10%). Durata. È il numero di giorni-lavoro, mesi-lavoro esclusi i giorni non lavorativi richiesti per completare un attività. È espressa in giorni lavoro, settimane lavoro. 68

Slide 70: Fabio Moioli (fabiomoioli@gmail.com) Valutazione economica Utilization Factor (produttività) descrive la quantità di tempo di un full-time equivalent (FTE) che può essere utilizzata per la durata del progetto. Le ore lavorative disponibili in un anno sono = 2.080 (52 settimane x 5 gg x 8 ore). Formazione = 80 ore Ferie e festività = 160 ore Amministrazione = 80 ore Assenze (viaggi, malattia, imprevisti) = 160 ore Total ore non produttive = 480 ore Totale ore produttive (2.080 meno 480) = 1.600 ore 1.600 diviso per 2.080 = 77% Utilization Factor 69

Slide 71: Fabio Moioli (fabiomoioli@gmail.com) Valutazione economica Availability indica QUANTO la persona può essere utilizzata durante un particolare periodo del progetto infatti una persona può non essere disponibile al 100%, ma per esempio al 75% del suo tempo Esempio : Tu hai una task che è stata stimata di 120 ore (final effort) e sei pagato per 10 all’ora, ti occorre un budget di 1.200 !!! La persona è disponibile per il 75% del suo tempo. Durante i 6 - 12 mesi del progetto, il project manager deve pianificare ferie, festività, formazione, deve prevenire malattie, festività e quindi fissa un 80 % di utilization factor (produttività) Durata = Effort/Productivity Availability = 120/.80 = 150 = 200 ore .75 .75 = 200 ore 8 ore = 25 giorni (verso gli originali 15 giorni (120/8) 70

Slide 72: Fabio Moioli (fabiomoioli@gmail.com) Valutazione economica Costo = Effort x Unit cost Productivity = 120 ore x 10 per ora .80 = 150 ore x 10 per ora = 1.500 Il budget precedente è sbagliato! 71

Slide 73: Fabio Moioli (fabiomoioli@gmail.com) Valutazione economica Metodi di stima: Top-down. Un approccio top-down di stima è usato nella fase iniziale del progetto. Un approccio top-down confronta dati storici con l’esperienza. Viene spesso chiamata “best estimate” (miglior stima). È usuale che fatta in una fase più dettagliata o avanzata del progetto coincida con quella iniziale. Bottom-up. Un approccio bottom-up di stima coinvolge la ricezione di valutazioni da parte di più persone che poi vengono sommate. Un approccio di questo tipo è molto più dettagliato. 72

Slide 74: Fabio Moioli (fabiomoioli@gmail.com) Valutazione dei costi Tecniche piú utilizzate: Analogous Parametric Top-down Bottom-up Altre: Delphi PERT 73

Slide 75: Fabio Moioli (fabiomoioli@gmail.com) Valutazione dei costi Type of Estimate Range of Accuracy Phase Order of magnitude –25% to +75% Initiation Budget –10% to +25% Planning Definitive –5% to +10% Planning 74

Slide 76: Fabio Moioli (fabiomoioli@gmail.com) Budget curve Budget totale Curva di Budget PV Costi Tempo T0 T fine 75

Slide 77: Fabio Moioli (fabiomoioli@gmail.com) Cost Estimation – Esercizio 76

Slideshare.net (beta)