Lavorare per obiettivi di progetto Scuola di Management per le Università, gli Enti di ricerca e le Istituzioni Scolastiche Lavorare per obiettivi di progetto Luisella Erlicher l.erlicher@mip.polimi.it 11-12 dicembre 2007

Indice Introduzione ai progetti Le fasi di un progetto Gli obiettivi di un progetto Il principio chiave nella gestione dei progetti L’organizzazione di progetto Il piano di progetto Le tecniche per la gestione dei progetti

Quali dei seguenti sono dei progetti? Costruzione di un tunnel Edizione di un quotidiano Sposarsi Sviluppare un nuovo prodotto Comprare un vestito Fondare una new venture

Cosa è un progetto Juran 1989 D. Archibald Un Progetto e’ un problema di cui sia stata pianificata una soluzione Juran 1989 Combinazione di uomini, risorse e fattori organizzativi, riuniti temporaneamente per raggiungere obiettivi unici, definiti, con vincoli di tempo, costi, qualità e con risorse limitate”. PMI’ 2000 Un’impresa complessa, unica e di durata determinata, rivolta al raggiungimento di un obiettivo chiaro e predefinito mediante un processo continuo di pianificazione e controllo di risorse differenziate e con vincoli interdipendenti di costi-tempi-qualità D. Archibald Complessità: alla sua realizzazione , infatti, partecipano di norma numerosi settori aziendali di differente estrazione tecnica, ciascuno dei quali opera svolgendo molteplici attività tra loro correlate da stretti vincoli di interdipendenza di natura sia logica che temporale. ( es. costruzione grande oleodotto o realizzazione centrale termo-nucleare) Unicità: una serie di fattori contribuisce a rendere improponibile una rappresentazione schematica già collaudata nel passato. Ogni volta, infatti, si presenta mutato lo scenario economico.finanziario nel contesto del quale l’azienda si trova a operare (es. variabilità nel tempo dei tassi di cambio)

1. Il progetto Un processo che richiede uno sforzo concentrato nel tempo, finalizzato a realizzare un output unico Realizzazioni di soluzioni su misura Problemi una tantum Innovazione sistemica e radicale

Ambiente organizzativo a processo CAPO UOMINI/DONNE PROCESSI INPUT - OPERATIVI - PROFESSIONALI OUTPUT SISTEMA GESTIONALE

Ambiente organizzativo a progetto C O R D I N A M E T UFFICIO A - P U F - SPECIALISTI DIREZIONE G L S / V Z UFFICIO B

Il progetto come processo a impulso interno esterno impulso flusso Innovazione organizzativa, gestionale e strumentale Ricerca Produzione interna Manutenzione Amministrazione e controllo Pianificazione Gestione risorse Processi di vendita Processi di assistenza cliente Processi di sviluppo di nuovi prodotti e processi Iniziative di marketing

Principali obiettivi di un progetto Qualità Costo Tempo

Alcuni esempi di progetti Realizzazione di un impianto industriale Costruzione di una nave Realizzazione di un aeroporto Realizzazione di un nuovo modello d’automobile Realizzazione di uno stampo per la produzione del guscio di un cellulare Sviluppo di un software per il riconoscimento vocale Apertura di una nuova filiale commerciale Realizzazione di un sistema informativo …

Il caso Scaldo (1) La Scaldo, una piccola impresa veneta che produce caldaie e stufe, ha attivato un progetto per aprire un nuovo ufficio commerciale in Germania. Le fasi del progetto sono state: L’innesco è nato dalla necessità di incrementare il fatturato in Germania, mercato presso il quale in precedenza l’azienda vendeva i prodotti affidandosi a distributori non esclusivi. Da diversi anni l’imprenditore aveva preso in considerazione di operare presso un mercato così importante con un ufficio di commercializzazione e distribuzione proprio. L’esigenza si è fatta più pressante quando il distributore locale ha cominciato a privilegiare più i fornitori tedeschi, curando sempre meno i prodotti della Scaldo. Dopo aver valutato a lungo diverse opzioni (continuare con il distributore attuale cercando di rinsaldare la relazione, cambiare distributore o operare sul mercato direttamente), l’azienda ha deciso di aprire un ufficio commerciale proprio, data la strategicità del mercato, pur a fronte dell’investimento da sostenere e del rischio di operare direttamente in un’area non ben conosciuta. Il progetto è stato affidato al figlio dell’imprenditore (che nell’azienda si occupa della gestione della logistica), con un budget di 10 milioni di euro e con il target temporale di aprire l’ufficio commerciale entro un anno dall’attivazione del progetto. Il progetto è stato pianificato dal figlio dell’imprenditore. Sono state individuate altre persone nell’organizzazione che avrebbero potuto aiutare nello svolgimento del progetto, sono stati identificati e isolati i principali rischi e sono state quindi pianificate le attività, i tempi e i costi.

Il caso Scaldo (2) All’inizio il progetto si è focalizzato sulla scelta della localizzazione più opportuna dell’ufficio commerciale (dato che l’ufficio deve essere affiancato da un magazzino da cui i prodotti sono distribuiti in tutta la Germania). In parallelo, è stata condotta un’analisi della regolamentazione e delle leggi relative all’avviamento di attività commerciali in Germania. Successivamente, si è proceduto alla ricerca, alla selezione e alla formazione del personale locale. In particolare, la figura chiave era quella del responsabile dell’ufficio commerciale. In seguito, mentre si provvedeva alla sistemazione fisica dell’ufficio (arredamento, installazione della strumentazione informatica, allestimento del magazzino), sono stai stipulati i nuovi contratti con i grossisti locali. Nel periodo dell’apertura dell’ufficio commerciale il figlio dell’imprenditore ha dedicato particolare cura nel passaggio di consegne al responsabile locale. In particolare, nei primi mesi dell’avviamento, egli si è recato ogni settimana per due giorni presso l’ufficio, per coordinarsi, verificare l’operato del responsabile locale e supportare nella soluzione di eventuali problemi pendenti. L’analisi dei risultati del progetto in fase di chiusura ha rilevato un ritardo nell’apertura dell’ufficio di quasi un anno (ovvero, il progetto si è trascinato per il doppio del tempo previsto inizialmente). Un’analisi delle motivazioni di questo ritardo ha fatto emergere che gran parte del tempo è stato perso nella selezione del personale (soprattutto del responsabile), a causa della scarsa conoscenza del contesto locale. Si è quindi evidenziato che per progetti futuri simili (apertura di uffici commerciali in altri paesi esteri) è opportuno coinvolgere, fin dall’inizio del progetto, persone di fiducia che conoscano il contesto locale (nel caso dell’ufficio in Germania, l’imprenditore ha sottovalutato per esempio l’aiuto che avrebbe potuto fornire un affezionato cliente tedesco, con cui l’azienda ha relazioni consolidate).

Le fasi di un progetto PROGETTO Concezione Definizione Realizzazione Non è un istante, ma una fase. L’output viene rilasciato per il funzionamento a “regime”. Questo richiede particolare cura nel passaggio di consegne tra chi ha gestito il progetto e chi ne dovrà gestire l’output. Si verifica il grado di raggiungimento degli obiettivi e si analizzano a posteriori i risultati Momento di nascita e ideazione del progetto. Si identifica quale potrebbe essere una risposta al problema/opportunità, si valuta la fattibilità e la convenienza economica e strategica. A valle si decide se attivare il progetto e i suoi vincoli e obiettivi strategici PROGETTO Concezione Definizione Realizzazione Chiusura Criticità/ Risultato Opportunità Fase di definizione e pianificazione del progetto. Si identificano le attività di progetto, la struttura organizzativa e si formula il programma di lavoro in termini di tempi e costi Progettazione e realizzazione concreta dell’output. Momento di massimo impiego delle risorse e di tempo

Esempio: progetto su commessa Conceptual Ingegneria di processo Sistemi Ingegneristici Procurement Front End Construction Ingegneria di dettaglio Commissioning INGEGNERIA DI PROGETTO REALIZZAZIONE Chiusura contratto PROJECT MANAGEMENT

Esempio: progettazione di un nuovo prodotto CONCEZIONE PRODUCT PLANNING PROGETTAZIONE PRODOTTO PROGETTAZIONE PROCESSO LANCIO IN PRODUZIONE E CONSUMO PRODUZIONE SVILUPPO PRODOTTI DI PROSSIMA GENERAZIONE

Esempio: Sviluppo di un Nuovo Servizio Service Conception Service Design Service Engineering Project Termination Project Audit prime attivazioni (ramp-up) delivery a regime

3. Gli obiettivi di un progetto Obiettivi strategici (di continuità) motivazioni strategiche che portano ad attivare il progetto risultati attesi come eredità del progetto Rispetto ad essi si valuta l’investimento in innovazione, giustificando l’assegnazione delle risorse e l’assunzione del rischio Obiettivi specifici Risultato atteso al termine del progetto Qualità Tempo Budget di progetto

Esempio Obiettivi della realizzazione di una nuova automobile Obiettivi di Continuità Aumento quote di mercato Aumento fatturato Accesso a nuovi segmenti di mercato Obiettivi Specifici Conformità delle prestazioni a quanto richiesto dal mercato Tempo di realizzazione: 3 anni Costo di realizzazione (prodotto e processo): 2 miliardi € Costo di produzione unitario <= 10.000 €

I ruoli chiave La committenza Il Project Manager I sub-project leader Progettisti/Staff

La Committenza Presidia il rapporto tra progetto e strategia ambiente Obiettivi e vincoli Obiettivi e vincoli piano di specifici di continuità azioni risultati COMMITTENZA DECISORI DI PROGETTO PROGETTO Presidia il rapporto tra progetto e strategia Fornisce le risorse (ritiene che risultati attesi e rischio giustifichino il consumo di risorse)

Committenza e cliente

Le forme organizzative Struttura Funzionale Struttura a Matrice Task Force Direzione Direzione Direzione RF RF RF RF RF RF RF RF RF PM PM Responsabile Team a tempo RF Funzionale parziale Legenda: Project Team a tempo PM Manager pieno

Sintesi delle forme organizzative Struttura Vantaggi Limiti Quando adottarla FUNZIONALE - Efficienza nell’utilizzo delle risorse - Potenziamento dello sviluppo specialistico-funzionale delle risorse - Soluzione vicina alla prassi normale - Scarso presidio degli obiettivi di progetto - Difficoltà di coordinamento - Disturbi provenienti da attività esterne al progetto Quando è possibile suddividere il progetto in sottoprogetti autonomi, che possano essere affidati separatamente alle singole funzioni. Si tratta tipicamente di progetti poco innovativi. MATRICE - Efficienza nell’utilizzo risorse - Presidio dei risultati di progetto - Complessità (duplicità di comando; responsabilità in assenza di autorità) - Disturbi - Conflitti e continua negoziazione Quando il progetto è innovativo o si vuole garantire un buon risultato, ma allo stesso tempo esso non è talmente vitale da giustificare un forte dispendio di risorse TASK FORCE - Focus sui risultati di progetto - Responsabilità chiare - Assenza di disturbi - Maggiore motivazione dei membri del team - Duplicazione / scarsa flessibilità delle risorse - Difficoltà a reperire le risorse - Problemi nel rilascio delle risorse - Distacco dalle funzioni (perdita di sviluppo specialistico, eccesso di autonomia e autocultura) Per progetti strategici, vitali per l’impresa, in cui non si vuole assolutamente fallire.

Responsabilità del Project Manager Responsabile del raggiungimento degli obiettivi Garante dell’integrazione Controlla l’utilizzo di risorse Risolutore di conflitti Responsabilità Autorità Autorevolezza Il PM deve gestire il progetto presidiandone e garantendone, completamente o parzialmente, i risultati; è responsabile dell’integrazione delle varie fasi del progetto; tiene sotto controllo il consumo delle risorse; risolve i conflitti che nascono inevitabilmente nello sviluppo di un progetto. Egli riceve dalla committenza e dai responsabili funzionali, una delega nel controllare gli obiettivi specifici del progetto, a partire dai tempi fino ad arrivare alla qualità. Tuttavia egli non ha a disposizione tutte le leve per agire, non ha cioè autorità. La sua opera di gestione del progetto è invece più sottile: si basa sulla sua autorevolezza, cioè sulla capacità di orientare le risorse e le decisioni di altri attori agli obiettivi del progetto.

Autorità e autorevolezza LIVELLO ORGANIZZATIVO GRADO DI INFLUENZA POTERI DELEGATI AUTORITÀ Autorità Livello gerarchico Deleghe ricevute Controllo del budget Partecipazione al sistema di valutazione Autorevolezza Competenze tecniche Competenze gestionali Stile di leadership Capacità di comunicazione COMPETENZE GESTIONALI STILE DI LEADERSHIP TECNICHE AUTOREVOLEZZA AUTORITA’ – dipende dalle variabili organizzative che possono contribuire a far crescere l’autorevolezza del PM, quali: LIVELLO GERARCHICO: un PM che risponde direttamente a un committente di alto livello (l’imprenditore per esempio) ha una maggiore autorevolezza; DELEGHE RICEVUTE/CONTROLLO DEL BUDGET: la committenza e i responsabili funzionali possono delegare specifiche aree su cui il PM ha autorità completa. Per esempio, il PM potrebbe decidere come allocare e spendere il budget, oppure potrebbe avere controllo completo sulle risorse, pur nei limiti dei tempi in cui queste sono assegnate al progetto; PARTECIPAZIONE AL SISTEMA DI VALUTAZIONE: un PM che, all’interno della struttura organizzativa permanente, ricopre una posizione di alto livello (per esempio un responsabile funzionale) ha un maggiore grado di influenza nel controllo delle risorse e nelle negoziazioni con gli altri responsabili funzionali. AUTOREVOLEZZA – è data dalle qualità personali proprie della persona scelta. Dipende da: COMPETENZE TECNICHE: deve conoscere in profondità i diversi aspetti, campi applicativi e aree problematiche del progetto; COMPETENZE GESTIONALI: deve conoscere i principi e i metodi della gestione per progetti. Soprattutto deve essere un buon anticipatore; STILE DI LEADERSHIP: deve essere un buon gestore di risorse umane, saper negoziare e saper gestire i conflitti; CAPACITA’ DI COMUNICAZIONE.

Il ruolo del Project Manager

Forme organizzative e Project Manager Struttura Funzionale Peso leggero (light weight) Struttura per Progetti (task force) Peso massimo (heavy weight) Struttura a Matrice

Il ruolo del sub-project leader E’ un PM su scala più tecnica e operativa E’ sostanzialmente un’interfaccia funzionale La criticità del ruolo dipende dalla struttura organizzativa (referente funzionale o team-leader)

4. Il principio chiave nella gestione dei progetti Nei progetti vi sono tipicamente numerose interdipendenze reciproche tra le fasi Questo comporta la creazione di numerosi cicli di problem solving Per gestire efficacemente tali cicli è fondamentale anticipare i vincoli

I cicli di problem solving Ciclo interno Soluzioni (vincoli e opportunità) Ciclo interno Soluzioni (vincoli e opportunità) - tra fasi successive progettazione parti progettazione sistemica integrazione - tra le parti dell’output - con altri progetti attuali e futuri

Le conseguenze di una gestione non efficace dei cicli di problem solving ricicli e modifiche: aumento di tempi / costi complicazioni in fasi a valle per l’incompatibilità della soluzione: impossibilita’ di realizzare una soluzione soddisfacente degrado della qualità

Gestione tradizionale Le conseguenze di una gestione non efficace dei cicli di problem solving T STATO DI AVANZAMENTO DEL PROGETTO TFINE Minore probabilità di ricicli 100% Corretta attività di PM  Gestione tradizionale

I principi e i criteri della gestione dei progetti ANTICIPAZIONE DEI VINCOLI A. Controllo in feed-forward B. Periodicità e tempestività delle informazioni CRITERI OPERATIVI C. Delega e controllo per allarmi 1. Lavoro in team 2. Esperienza 3. Sperimentazione 4. Metodo

Periodicità e tempestività delle informazioni Sistemi di Controllo basati su eventi e scadenze : sulla base di questi occorre formulare piani di intervento tempestivi MILESTONES Eventi critici

Delega e controllo per allarmi I sub-project leader e i progettisti hanno obiettivi specifici da raggiungere e lavorano autonomamente all’interno dell’orizzonte temporale previsto Responsabilizzazione e Controllo per Allarmi

Criteri operativi per l’anticipazione dei vincoli 1. Lavoro in team 2. Esperienza 3. Sperimentazione 4. Metodo

L’esperienza Consultare chi ha già affrontato progetti simili Design Rules: incorporare l’esperienza in regole che aiutino a comprendere gli effetti delle soluzioni progettuali (esempio: Design for Manufacturing and Assembly, Design for recycling) Check-list per revisioni di progetto

Criticità / Opportunità Fasi di un progetto PROGETTO Concezione Definizione Realizzazione Chiusura Piano di progetto Criticità / Opportunità CRITICITA’/OPPORTUNITA’: la nascita di un progetto coincide con l’individuazione di una criticità o di una opportunità; CONCEZIONE: E’ il momento di nascita e ideazione del progetto. In generale, l’impulso iniziale può avere diverse origini: una richiesta specifica da parte di un cliente, l’emergere di un problema, il riconoscere, anche attraverso analisi di benchmarking, che è necessario attivare un progetto di innovazione. Nella fase di concezione si identifica quale potrebbe essere una risposta al problema/opportunità, si stima la fattibilità e si valuta la convenienza economica e strategica dell’intervento. A valle di queste analisi si decide quindi se attivare il progetto e, in caso affermativo, se ne definiscono gli obiettivi e i vincoli strategici; DEFINIZIONE PROGETTO: E’ la fase in cui il progetto viene definito e pianificato in tutti i suoi aspetti. Si identificano le attività del progetto, si sceglie la struttura organizzativa (quali attori coinvolgere nel progetto e a chi affidare la responsabilità delle diverse attività), si formula il programma di lavoro in termini di tempi e costi, e così via. Infine vengono chiarite le finalità del progetto (solitamente l’output di tale fase coincide con un prototipo); REALIZZAZIONE: Nel caso di un prodotto la fase di realizzazione coincide con la definizione del processo produttivo e quindi con l’ingegnerizzazione; CHIUSURA: L’output viene rilasciato per il funzionamento “a regime”. Ciò richiede particolare cura nel passaggio di consegne tra chi aveva gestito il progetto e chi dovrà gestire l’output a regime; la chiusura di un progetto è una fase spesso trascurata in quanto ritenuta “opzionale”. Durante la chiusura, si verifica inoltre il grado di raggiungimento degli obiettivi. Infine si analizzano a posteriori i risultati e l’andamento del progetto al fine di apprendere insegnamenti e esperienze utili da riapplicare a future iniziative simili. Il PIANO DI PROGETTO è uno strumento formale che consente di gestire il passaggio dalla fase di Definizione a quella di Realizzazione. Risultati

La Sperimentazione L’approccio “Stage-gate” Principio di base- Alti costi e tempi di correzione finaleevitare i ricicli e anticipare il problem solving Processo sequenziale: bisogna evitare di correggere le decisioni iniziali (riciclo come disturbo) Gate: può essere superato se gli impatti delle soluzioni progettuali sono stati tutti anticipati Problem solving basato sull’esperienza: trasferimento di esperienze da progetti precedenti Prerequisito: Elevate capacità di anticipazione - bassa incertezza

La Sperimentazione Il processo flessibile Principio di base - Incertezza elevata  sapersi adattare allo sviluppo di nuova conoscenza nel corso del progetto Sovrapposizione tra sviluppo del concept e implementazione (creatività e innovazione diffusa) Iterazioni come “motore” del processo (rapide, frequenti, intense, sistemiche, coinvolgenti i clienti) Apprendimento durante il processo: problem solving basato sulla sperimentazione Prerequisito: Elevata flessibilità

I metodi e le tecniche di anticipazione Work Breakdown Structure Linear Responsability Chart Tecniche reticolari Aree di rischio Cost/Schedule Control System Criteria Il Piano di Progetto

Criticità / Opportunità Fasi di un progetto PROGETTO Concezione Definizione Realizzazione Chiusura Piano di progetto Criticità / Opportunità CRITICITA’/OPPORTUNITA’: la nascita di un progetto coincide con l’individuazione di una criticità o di una opportunità; CONCEZIONE: E’ il momento di nascita e ideazione del progetto. In generale, l’impulso iniziale può avere diverse origini: una richiesta specifica da parte di un cliente, l’emergere di un problema, il riconoscere, anche attraverso analisi di benchmarking, che è necessario attivare un progetto di innovazione. Nella fase di concezione si identifica quale potrebbe essere una risposta al problema/opportunità, si stima la fattibilità e si valuta la convenienza economica e strategica dell’intervento. A valle di queste analisi si decide quindi se attivare il progetto e, in caso affermativo, se ne definiscono gli obiettivi e i vincoli strategici; DEFINIZIONE PROGETTO: E’ la fase in cui il progetto viene definito e pianificato in tutti i suoi aspetti. Si identificano le attività del progetto, si sceglie la struttura organizzativa (quali attori coinvolgere nel progetto e a chi affidare la responsabilità delle diverse attività), si formula il programma di lavoro in termini di tempi e costi, e così via. Infine vengono chiarite le finalità del progetto (solitamente l’output di tale fase coincide con un prototipo); REALIZZAZIONE: Nel caso di un prodotto la fase di realizzazione coincide con la definizione del processo produttivo e quindi con l’ingegnerizzazione; CHIUSURA: L’output viene rilasciato per il funzionamento “a regime”. Ciò richiede particolare cura nel passaggio di consegne tra chi aveva gestito il progetto e chi dovrà gestire l’output a regime; la chiusura di un progetto è una fase spesso trascurata in quanto ritenuta “opzionale”. Durante la chiusura, si verifica inoltre il grado di raggiungimento degli obiettivi. Infine si analizzano a posteriori i risultati e l’andamento del progetto al fine di apprendere insegnamenti e esperienze utili da riapplicare a future iniziative simili. Il PIANO DI PROGETTO è uno strumento formale che consente di gestire il passaggio dalla fase di Definizione a quella di Realizzazione. Risultati

Passaggio tra definizione e realizzazione In molte realtà aziendali il passaggio non avviene in modo formale E’ necessario formalizzare il passaggio in un documento Tale documento deve contenere informazioni su Chi Cosa Chi fa cosa Quando Quanto Il passaggio tra Definizione e Realizzazione è spesso gestito in maniera informale dalle aziende nel senso che non vengono prodotti documenti formali che definiscano l’output della prima e l’input della seconda. La stesura di un documento formale invece consente di anticipare i vincoli e le opportunità e quindi garantisce una miglior gestione del progetto. In particolare il piano di progetto deve contenere informazioni relativamente alle seguenti domande: Chi?(chi lavora al progetto) Cosa? (quali attività è necessario svolgere) Chi fa cosa? (chi possiede le responsabilità relativamente a ciascuna attività) Quando? (quando deve essere svolta una determinata attività) Quanto? (quante risorse devono essere consumate da ciascuna attività)

5. Il piano di progetto Va inteso soprattutto come strumento di anticipazione Logiche di pianificazione e controllo: tempestività delega controllo in “feed-forward” (in avanti) milestones (anticipare le scadenze)

Il piano di progetto: le leve

Analisi della delimitazione e del contesto del progetto tempi scopo ambiente definizione inizio e fine del progetto definizione dello scopo, delle attività, del budget definizione della organizzazione del progetto PAG, PL, PTM, ecc. evento iniziale evento finale data iniziale data finale non scopi scopi progetto PAG delimitazione durata PL PTM1 PTM3 attività principali progetto PTM2 budget descrizione fase pre- e post- progetto analisi delle relazioni con altri progetti, attività e strategie dell‘impresa descrizione dell‘ambiente reparto interno contesto fornitori concorrenti fase pre- progetto fase post- progetto progetto progetto progetto varie cliente

Schema logico della pianificazione SEQUENZIAZIONE ATTIVITA’ PREPARAZIONE DELLO SCHEDULE DEFINIZIONE ATTIVITA’ STIMA DURATA ATTIVITA’ DEFINIZIONE DELLO SCOPE COST BUDGETING PIANIFICAZIONE RISORSE In conclusione, cercando di shematizzare dal punto di vista logico il processo di pianificazione, è possibile ricostruire questo diagramma: La DEFINIZIONE DELLO SCOPE è il primo passo in quanto gli obiettivi da raggiungere costituiscono un input per tutte le fasi a valle: gli obiettivi di u n progetto sono solitamente espressi in termini di tempo, costo e qualità e devono essere sufficientemente precisi per permettere una valutazione a posteriori della bontà dei risultati ottenuti; A questo punto è possibile identificare le ATTIVITA’ che compongono il progetto e individuare le RISORSE necessarie allo svolgimento del progetto stesso: in particolare è necessario evidenziare non solo le risorse disponibili ma anche quando saranno disponibili nel corso del progetto; Definite le attività, è necessario determinare il loro SEQUENZIAMENTO e stimarne la DURATA: la durata delle attività può essere stimata solo avendo a disposizione dati relativi all’assorbimento teorico di risorse da parte dell’attività stessa e disponibilità di risorse nel tempo. Nella definizione della durata delle attività è importante considerare che il numero di risorse allocate all’attività non è legato in maniera lineare alla sua durata: esistono dei tempi di coordinamento e integrazione che rendono non lineare tale relazione; Successivamente è possibile costruire lo SCHEDULE di progetto e preventivare il costo associato a ciascuna attività; Infine, attraverso lo schedule di progetto e la preventivazione di ciascuna attività, è possibile costruire il COST BUDGETING e quindi ricostruire l’andamento dei costi nel tempo. PREVENTIVAZIONE PIANO DI PROGETTO

Metodi di pianificazione progetto risultati del progetto definizione archivio della documentazione analisi della delimitazione e del contesto strutture di comunicazione definizione del grado di dettaglio definizione responsabilita WBS Sonstige piano milestone, barchart e network logico definizione delle risorse e delle classi di costo analisi dell‘ambiente del progetto definizione milestone definizione pacchetti di lavoro organigramma del progetto regole del gioco Analisi della delimitazione e del contesto del progetto Pianificazione del contenuto del progetto Pianificazione dei tempi e delle scadenze Organizzazione del progetto Pianificazione delle risorse e dei relativi costi incarico di progetto scopo del progetto fase pre- e post-progetto relazioni con altri progetti ambiente del progetto pianificazione dei risultati del progetto work breakdown structure pacchetti lavoro diagramma delle funzioni piano milestone piano a barre (barchart) piano a barre con logica organigramma strutture di comunicazione regole del gioco documentazione ruoli piano risorse piano costi analisi del rischio piano risorse finanziarie

Pianificazione del contenuto e del scopo del progetto definizione dei risultati del progetto definizione delle fasi base: attività principali definizione dei pacchetti di lavoro (WP) fase 2 PM fase 2 fase 3 fase 4 disegno definizione processuale delle attività in forma di pacchetti di lavoro concezione modifiche collaudo attività principali 1 2 3 definizione di specifici pacchetti di lavoro elaborazione delle specifiche dei pacchetti di lavoro 1.1.2 nome pacchetto lavoro (WP) contenuto risultato 4 5

Pianificazione dei tempi e delle scadenze identificazione dei milestone sulla base della WBS (work breakdown structure) elaborazione piano milestone (MS) scadenza WP MS base att. 1.1.x MSt. A 01.03. 01.03. - 1.2.x MSt. C 10.05. 10.05. - 1.3.x MSt. D 12.06. 12.06. - 1.1.x MSt. B 31.08. 12.09. - 1 2 pianificazione dei tempi e delle scadenze a base delle fasi e i milestone pianif.dettagliata dei tempi e delle scadenze con/senza logica Mar Apr Mag Giu Lug Ago Mar Apr Mag Giu 1 progetto 1.1 PM 1.2 fase MS A 1.2.1 WP MS B 1.2.2 WP 1.2 fase 1.2.3 WP MS C 1.2.4 WP 1.3 fase MS C MS D 3 4

Organizzazione del progetto definizione dell‘organigramma del progetto descrizione dei ruoli definizione dei responsabili dei pacchetti di lavoro (WP) aspettativa commitente del progetto PAG PL aspettativa collaboratore capo progetto assistente collaboratore project team capo progetto AP CS BW WR collaboratore collaboratore ruoli AP WR BW GW collaboratore AP CS WR WR collaboratore collaboratore responsabilità AP CS AP organizzazione del progetto GW 1 2 3 opzione: diagramma delle funzioni definizione delle strutture di comunicazione Gen Feb Mar Apr Mag Giu WPS- codice TS AP CS WR GW GK inizio progett WP riunione PAG 1.1.1 WP 1 M D 1.1.2 WP 2 D M riunione aggiornam. 1.1.3 WP 3 M D M 1.2.1 WP 4 M D M riunione reparto secondo necessità 1.2.2 WP 5 M D 1.2.3 WP 6 D M M 4 5

Pianificazione delle risorse del progetto scelta del tipo di risorse (reparti, competenze) pianificazione delle risorse a livello di pacchetti lavoro e fasi riassunto in tabella del personale Mar Apr Mag Giu WBS- codice WP/ fase rep-arto BC (PT) AC (PT) ETC (PT) dev. (PT) diff. (PT) 1.2 fase 1.2.1 WP 1.2 fase IT 15,0 - 15,0 0,0 - IT acquisti ReWe varie 1.2.2 WP acquisti 5,0 - 5,0 0,0 - ReWe - - - - - 1.2.3 WP varie 11,0 - 11,0 0,0 - 1.2.4 WP totale 31,0 - 31,0 0,0 - MS. C 1 2 3 verifica della disponibilità delle risorse opzione: elaborazione della tabella del fabbisogno opzione: istogramma tabella del personale tempi e scadenze Mar Apr Mag Giu WBS- codice WP/ fase rep-arto 2001 Feb Mar Apr Mag Giu Lul 1.2 fase 1.2 fase IT - 6,0 5,0 4,0 - - acquisti - 1,0 4,0 - - - ReWe - - - - - - varie - 3,0 3,0 5,0 - - IT totale - 10,0 12,0 9,0 - - acquisti ReWe varie 4 5 6

STRUTTURA DI SCOMPOSIZIONE WORK BREAKDOWN STRUCTURE - W.B.S.

Articolazione delle attività Identificazione delle attività è critica Elenco delle attività è inefficace perché Verifiche a posteriori non sono possibili Rischio di confronto tra attività elementari e gruppi di attività Necessità di individuare work package Necessità di definizione delle relazioni tra work package Il primo passo nella definizione del piano di progetto consiste nel comprendere come se ne devono articolare le attività. Occorre quindi: Identificare tutte le attività necessarie per la realizzazione dell’output; Raggruppare le attività in pacchetti di lavoro o work package. Questi sono aggregati di attività sufficientemente semplici e autonomi. Ad ogni work package vanno associati gli input, gli output e le sue attività interne, nonché le risorse, i tempi di esecuzione e le responsabilità. Esso costituisce quindi la base per pianificare, preventivare, tempificare e controllare l'avanzamento del progetto. I work package possono essere considerati come un aggregato di attività elementari sufficientemente semplice ed indipendente da poter essere affidato ad un unico responsabile durante la sua esecuzione, ed essere trattato, da un punto di vista della gestione del progetto, come un compito unico. In modo più preciso, un work package è definibile come un insieme di attività elementari avente interazioni ben identificate con gli altri work package e identificato in modo univoco da input, output e attività interne. Ad esso devono essere associabili risorse, tempi di esecuzione e responsabilità in modo che costituisca la base per pianificare, preventivare, tempificare e controllare l'avanzamento del progetto; Definire i collegamenti fra i pacchetti di lavoro, ovvero la configurazione del progetto (quali sequenze, quali fasi svolgere in parallelo, e così via).

Work Breakdown Structure Obiettivo Identificare le attività necessarie per raggiungere gli obiettivi specifici Caratteristiche principali Le attività elementari vengono individuate scomponendo l’obiettivo in problemi più piccoli sufficientemente autonomi Esprime in modo chiaro e sintetico quali sono le attività da svolgere Identificare le attività di un progetto, senza tralasciare nessun aspetto e raggrupparle in modo coerente non è un impresa facile, soprattutto quando il progetto è particolarmente innovativo e non abbiamo esperienze a cui fare riferimento. Il semplice elenco delle attività è un metodo inefficace per due motivi: un elenco di attività senza criterio non consente di individuare eventuali lacune e mancanze, inoltre l’assenza di una logica nell’individuazione di attività può indurre a confrontare dei pacchetti con diversi livelli di aggregazione. Una tecnica che aiuta a questo scopo è la Work Breakdown Structure (WBS). Si tratta di uno strumento che, attraverso una logica gerarchica, decompone in modo sistematico il progetto in fasi sempre più piccole, fino ad arrivare ad identificarne le attività e i pacchetti di lavoro elementari. La WBS è uno strumento particolarmente utile perché allineato con il metodo di ragionamento della mente umana: si procede per scomposizione ed aggregazione: ad ogni livello deve essere possibile ricostruire l’intero progetto a diversi gradi di dettaglio.

Esempio di WBS Progetto nuovo auto Analisi mercato Progettazione Ingegnerizzazione Avvio della produzione Progetto Impianto frenante Progetto Motore Progetto Carrozzeria Progetto Trasmissione

Esempio di WBS I. II. III. IV. V. 1. Progetto “Mutuo Rapido” 2.1 Analisi dei fabbisogni dei clienti 2.1.1 Raccolta di dati sulla domanda di mutui 2.1.3 Raccolta di dati sull’offerta di mutui 2.2 Progettazione dell’architettura del servizio 2.2.1 Definizione delle interfacce utenti 2.2.2 Definizione della funzionalità di qualifica del cliente 2.2.3 Definizione delle modalità di gestione delle transazioni 2.3 Progettazione dei singoli moduli 2.3.1 Data Base mutui 2.3.2 Modulo di aggiornamento in tempo reale delle tariffe 2.3.3 Modulo per la qualifica dei clienti 2.3.4 Sito WWW 2.4 Test del servizio 2.4.1 Test del primo prototipo (release Beta 1) 2.4.1.1 Integrazione dei moduli 2.4.1.2 Test tecnico 2.4.1.2.1 Test di assenza di errori 2.4.1.2.2 Test di velocità 2.4.1.2.3 Test di occupazione di memoria 2.4.1.3 Test commerciale 2.4.1.3.1 Selezione clienti guida 2.4.1.3.2 Dimostrazione servizio 2.4.1.3.3 Raccolta dati di prova 2.4.2 Test del secondo prototipo (release Beta 2) 2.4.2.1 Modifiche dei moduli sulla base del primo test 2.4.2.2 Seconda integrazione dei moduli 2.4.2.3 Secondo test tecnico 2.4.2.4 Test commerciale con accesso al sito WWW 2.5 Lancio del servizio su WWW 2.5.1 Attivazione degli accessi al sito 2.5.2 Web Marketing (motori di ricerca e altri siti) 2.5.3 Monitoraggio accessi Il “Mutuo rapido” è un progetto di sviluppo di un sito per l’apertura di mutui online: il servizio consiste in una banca dati che contiene tutte le informazioni relative ai muti offerti dalle banche che collaborano con l’erogatore del servizio. Dopo che l’utente ha connotato il proprio profilo il servizio ritorna i mutui maggiormente adatti all’utente stesso.

Logiche di scomposizione Logica di scomposizione Descrizione Esempio di applicazione nel caso del Mutuo Rapido Per parti Si decompone l’output nelle sue parti componenti, in analogia con la distinta base di un prodotto Decomposizione del pacchetto 2.3 “Progettazione dei singoli moduli” Per funzioni Si decompone il progetto secondo le funzionalità che deve svolgere l’output Decomposizione del pacchetto 2.2 “Progettazione dell’architettura del servizio” Per obiettivi Si decompone il progetto secondo le prestazioni dell’otuput Decomposizione del pacchetto 2.4.1.2 “Test tecnico” Per fasi Si decompone il progetto secondo la sequenza delle fasi da svolgere Decomposizione del livello 1. “Progetto Mutuo Rapido” o del pacchetto 2.5.2 “Test del secondo prototipo” Per rilasci progressivi Si decompone il progetto identificando eventuali rilasci progressivi dell’output Decomposizione del pacchetto 2.4 “Test del servizio” Spaziale / Geografica Si decompone il progetto in base alle aree geografiche in cui il progetto viene realizzato Un provider in Europa ed uno in America 2.3 Progettazione dei singoli moduli 2.3.1 Data Base mutui 2.3.2 Modulo di aggiornamento in tempo reale delle tariffe 2.3.3 Modulo per la qualifica dei clienti 2.3.4 Sito WWW L’utilizzo della logica per parti non permette l’identificazione di attività che non presentano un output fisico: esempio di tali attività sono quelle di coordinamento tra differenti attori del team.

Logiche di scomposizione Logica di scomposizione Descrizione Esempio di applicazione nel caso del Mutuo Rapido Per parti Si decompone l’output nelle sue parti componenti, in analogia con la distinta base di un prodotto Decomposizione del pacchetto 2.3 “Progettazione dei singoli moduli” Per funzioni Si decompone il progetto secondo le funzionalità che deve svolgere l’output Decomposizione del pacchetto 2.2 “Progettazione dell’architettura del servizio” Per obiettivi Si decompone il progetto secondo le prestazioni dell’otuput Decomposizione del pacchetto 2.4.1.2 “Test tecnico” Per fasi Si decompone il progetto secondo la sequenza delle fasi da svolgere Decomposizione del livello 1. “Progetto Mutuo Rapido” o del pacchetto 2.5.2 “Test del secondo prototipo” Per rilasci progressivi Si decompone il progetto identificando eventuali rilasci progressivi dell’output Decomposizione del pacchetto 2.4 “Test del servizio” Spaziale / Geografica Si decompone il progetto in base alle aree geografiche in cui il progetto viene realizzato Un provider in Europa ed uno in America 2.2 Progettazione dell’architettura del servizio 2.2.1 Definizione delle interfacce utenti 2.2.2 Definizione della funzionalità di qualifica del cliente 2.2.3 Definizione delle modalità di gestione delle transazioni

Logiche di scomposizione Logica di scomposizione Descrizione Esempio di applicazione nel caso del Mutuo Rapido Per parti Si decompone l’output nelle sue parti componenti, in analogia con la distinta base di un prodotto Decomposizione del pacchetto 2.3 “Progettazione dei singoli moduli” Per funzioni Si decompone il progetto secondo le funzionalità che deve svolgere l’output Decomposizione del pacchetto 2.2 “Progettazione dell’architettura del servizio” Per obiettivi Si decompone il progetto secondo le prestazioni dell’otuput Decomposizione del pacchetto 2.4.1.2 “Test tecnico” Per fasi Si decompone il progetto secondo la sequenza delle fasi da svolgere Decomposizione del livello 1. “Progetto Mutuo Rapido” o del pacchetto 2.5.2 “Test del secondo prototipo” Per rilasci progressivi Si decompone il progetto identificando eventuali rilasci progressivi dell’output Decomposizione del pacchetto 2.4 “Test del servizio” Spaziale / Geografica Si decompone il progetto in base alle aree geografiche in cui il progetto viene realizzato Un provider in Europa ed uno in America 2.4.1.2 Test tecnico 2.4.1.2.1 Test di assenza di errori 2.4.1.2.2 Test di velocità 2.4.1.2.3 Test di occupazione di memoria E’ necessario sottolineare la differenza che c’è tra funzioni ed obiettivi: domandandosi cosa cerca concretamente l’utente collegandosi al sito è possibile individuare le funzioni mentre gli obiettivi sono maggiormente legati alle prestazioni con cui vengono forniti tali funzioni.

Logiche di scomposizione Logica di scomposizione Descrizione Esempio di applicazione nel caso del Mutuo Rapido Per parti Si decompone l’output nelle sue parti componenti, in analogia con la distinta base di un prodotto Decomposizione del pacchetto 2.3 “Progettazione dei singoli moduli” Per funzioni Si decompone il progetto secondo le funzionalità che deve svolgere l’output Decomposizione del pacchetto 2.2 “Progettazione dell’architettura del servizio” Per obiettivi Si decompone il progetto secondo le prestazioni dell’otuput Decomposizione del pacchetto 2.4.1.2 “Test tecnico” Per fasi Si decompone il progetto secondo la sequenza delle fasi da svolgere Decomposizione del livello 1. “Progetto Mutuo Rapido” o del pacchetto 2.5.2 “Test del secondo prototipo” Per rilasci progressivi Si decompone il progetto identificando eventuali rilasci progressivi dell’output Decomposizione del pacchetto 2.4 “Test del servizio” Spaziale / Geografica Si decompone il progetto in base alle aree geografiche in cui il progetto viene realizzato Un provider in Europa ed uno in America 1 Progetto “Mutuo Rapido” 2.1 Analisi dei fabbisogni dei clienti 2.2 Progettazione dell’architettura del servizio 2.3 Progettazione dei singoli moduli 2.4 Test del servizio 2.5 Lancio del servizio su WWW

Logiche di scomposizione Logica di scomposizione Descrizione Esempio di applicazione nel caso del Mutuo Rapido Per parti Si decompone l’output nelle sue parti componenti, in analogia con la distinta base di un prodotto Decomposizione del pacchetto 2.3 “Progettazione dei singoli moduli” Per funzioni Si decompone il progetto secondo le funzionalità che deve svolgere l’output Decomposizione del pacchetto 2.2 “Progettazione dell’architettura del servizio” Per obiettivi Si decompone il progetto secondo le prestazioni dell’otuput Decomposizione del pacchetto 2.4.1.2 “Test tecnico” Per fasi Si decompone il progetto secondo la sequenza delle fasi da svolgere Decomposizione del livello 1. “Progetto Mutuo Rapido” o del pacchetto 2.5.2 “Test del secondo prototipo” Per rilasci progressivi Si decompone il progetto identificando eventuali rilasci progressivi dell’output Decomposizione del pacchetto 2.4 “Test del servizio” Spaziale / Geografica Si decompone il progetto in base alle aree geografiche in cui il progetto viene realizzato Un provider in Europa ed uno in America 2.4 Test del servizio 2.4.1 Test del primo prototipo (release Beta 1) 2.4.2 Test del secondo prototipo (release Beta 2)

Logiche di scomposizione Logica di scomposizione Descrizione Esempio di applicazione nel caso del Mutuo Rapido Per parti Si decompone l’output nelle sue parti componenti, in analogia con la distinta base di un prodotto Decomposizione del pacchetto 2.3 “Progettazione dei singoli moduli” Per funzioni Si decompone il progetto secondo le funzionalità che deve svolgere l’output Decomposizione del pacchetto 2.2 “Progettazione dell’architettura del servizio” Per obiettivi Si decompone il progetto secondo le prestazioni dell’otuput Decomposizione del pacchetto 2.4.1.2 “Test tecnico” Per fasi Si decompone il progetto secondo la sequenza delle fasi da svolgere Decomposizione del livello 1. “Progetto Mutuo Rapido” o del pacchetto 2.5.2 “Test del secondo prototipo” Per rilasci progressivi Si decompone il progetto identificando eventuali rilasci progressivi dell’output Decomposizione del pacchetto 2.4 “Test del servizio” Spaziale / Geografica Si decompone il progetto in base alle aree geografiche in cui il progetto viene realizzato Un provider in Europa ed uno in America L’obiettivo della WBS non è evidenziare tutte gli obiettivi e tutte le funzioni, la WBS ha lo scopo di identificare tutte le attività necessarie allo sviluppo del progetto. La WBS è uno strumento che deve supportare il progetto e non lo devo costringere entro binari troppo stringenti.

Alcune considerazioni sulla WBS Quale logica per ogni livello Logica univoca nella scomposizione di un singolo nodo Logica per obiettivi o per fasi ai livelli alti Logica per parti ai livelli bassi Fino a che livello di dettaglio 5/6 livelli Visione può estendersi per 1/2 livelli, poi diviene approssimativa Definizione completa dei work package in termini di: INPUT – ATTIVITÀ – OUTPUT RISORSE – TEMPI – RESPONSABILITÀ Sebbene la costruzione della WBS non preveda delle regole estremamente precise è possibile individuare alcune linee guida: QUALE LOGICA PER OGNI LIVELLO: LOGICA UNIVOCA NELLA SCOMPOSIZIONE DI UN SINGOLO NODO: ogni nodo va scomposto adottando un’unica logica per consentire una successiva riaggregazione; LOGICA PER OBIETTIVI O PER FASI AI LIVELLI ALTI / LOGICA PER PARTI AI LIVELLI BASSI: Si afferma spesso che a livelli aggregati, ossia vicino all'obiettivo complessivo, occorre privilegiare le logiche degli obiettivi, e quella spaziale, mentre ai livelli più disaggregati prevale la logica dei processi di lavoro (per parti). Ai livelli più aggregati tipicamente viene utilizzata la logica per obiettivi nel caso di progetti di tipo organizzativo mentre nel caso di sviluppo nuovo prodotto/servizio viene spesso utilizzata la logica per fasi; ANALISI DEI CLUSTER A POSTERIORI: come visto in precedenza è opportuno effettuare un’analisi dei cluster a posteriori; Senza nulla togliere alla validità di queste considerazioni, riteniamo si debbano identificare, in modo più generale, i principi guida della scomposizione. Per fare questo è opportuno considerare che l'obiettivo primo della segmentazione del progetto è quello di semplificare il sistema di governo, limitando al massimo la perdita di integrazione e, quindi, la distanza dalla situazione “ottimale”. Lo sforzo, di conseguenza, deve essere quello di confinare le interdipendenze forti all'interno di pacchetti di attività collocati al più basso livello possibile della WBS. A ciascun livello occorre allora identificare la logica di disaggregazione che permette di identificare i sottosistemi di governo più indipendenti possibile.

Vantaggi della WBS Facilita l’anticipazione dei vincoli E’ la base per l’identificazione delle attività e dei relativi responsabili Aiuta ad individuare le attività elementari e facilita la visione di insieme attraverso l’adozione di un approccio sistematico Facilita la delega tramite la scomposizione delle attività Consente di consolidare l’apprendimento per i progetti successivi (es. WBS standard) Analisi sistemica Codifica univoca Cristallizzazione della conoscenza e trasferimento della conoscenza Ricorrere alla WBS per pianificare un progetto comporta notevoli benefici: La WBS offre un approccio sistematico che aiuta ad individuare le attività elementari perché induce completezza e facilita la visione d’insieme. In questo senso la WBS è un importante strumento di anticipazione dei vincoli; La WBS facilita il coordinamento del progetto. Essa infatti stimola il dialogo all’interno del team, permette una negoziazione chiara e trasparente in fase di pianificazione e consente un più facile ricorso alla delega, in quanto si basa su un criterio di decomposizione gerarchica. Il Project Manager può limitarsi ad identificare i primi due o tre livelli della WBS, delegando ai responsabili dei sottoprogetti l’ulteriore decomposizione di questi in attività più elementari; Un vantaggio da non sottovalutare è che l’utilizzo di tecniche esplicite di pianificazione, come la WBS, permette di consolidare meglio le esperienze di progetto, fornendo una base di apprendimento da riutilizzare in progetti futuri simili (WBS standard).

Problemi legati alla WBS ESEMPI MOTIVI/ORIGINE CONSEGUENZE PREVALENZA DI CRITERI FUNZIONALI RISPETTO ALLA SCOMPOSIZIONE LOGICA DEL PRODOTTO/PROCESSO ‑ utilizzo di criteri funzionali a livelli troppo alti della WBS ‑ accorpamento di attività relative a pacchetti diversi ‑ costituzione di pacchetti non corrispondenti al lavoro effettivo per attribuzione di responsabilità funzionali errata assegnazione dei compiti di costruzione della WBS prevalenza di logiche di controllo "funzionali" rispetto a quelle di controllo dei pacchetti ‑ difficoltà di controllo - controllo non significativo MANCANZA DI LIVELLI INTERMEDI DI AGGREGAZIONE ‑ errori "logici" di scomposizione ‑ scarsa conoscenza del prodotto - tendenza a "saltare al dettaglio" ECCESSIVA ARTICOLAZIONE DELLE ATTIVITA' ‑ separazione di attività consistenti in pacchetti "fittizi" ‑ necessità di rispondere a esigenze di consuntivazione non legate al progetto (ad esempio budget) INCOMPLETEZZA ‑ mancanza di attività o di parti del prodotto ‑ scarsa conoscenza del prodotto e del processo - errato riutilizzo di soluzioni precedenti ‑ errori di preventivazione e di budgeting "DIMENTICANZA" DI ATTIVITA' INDIRETTE ‑ mancanza di attività di coordinamento e controllo - mancanza di attività decisionali ‑ cultura "tecnologica" e scarsa attenzione per gli aspetti gestionali INCLUSIONE DI VARIANZE ‑ inclusione di pacchetti di lavoro di "imprevisti" ‑ cultura "budgettaria" (inclusione di attività al solo fine di poter contabilizzare i costi non previsti) ‑ non significatività del pacchetto I problemi principali che si riscontrano nella definizione e nell'utilizzo della WBS da parte delle aziende sono legati, per la maggior parte, a errori nella scelta della logica o del livello di disaggregazione a cui spingersi; spesso, inoltre, vi sono incompletezze legate a scarsa conoscenza della struttura del prodotto o del progetto o alla dimenticanza di attività indirette, attività cioè non legate a processi di realizzazione tecnica, ma ad attività gestionali di supporto.

WBS: esercitazione Siete una media società lombarda che progetta e costruisce biciclette sia da corsa che per il tempo libero. Siete tra i leader di mercato in Italia e possedete un nome ben riconosciuto. Come in altri settori (ad esempio quello dell'automotive) nel settore delle biciclette è ormai molto difficile che un'innovazione derivi dal produttore. Spesso, al contrario, sono i fornitori che spingono l'innovazione ad esempio con nuovi materiali o funzioni. Per l'innovatività si dovrà dunque tener conto del preponderante contributo dei fornitori esterni. Provate a stendere una WBS Standard che possa fungere da guida per i vostri progetti di biciclette innovative, specificando per ogni nodo esploso la logica utilizzata.

WBS: Soluzione (1) SPECIFICHE DI MARKETING SVILUPPO DEL PRODOTTO AVVIAMENTO PRODOTTO

WBS: Soluzione (2) 1. SPECIFICHE DI MARKETING 1.1. Analisi 1.1.1. Analisi di mercato (previsione e valutazione opportunità) 1.1.2. Analisi della concorrenza 1.1.3. Analisi delle tecnologie 1.2. Definizione del concept 1.2.1. Definizione degli obiettivi 1.2.2. Definizione dei requisiti 1.2.3. Definizione delle caratteristiche principali 1.3. Test del concept (distributori esteri e italiani) 1.4. Approvazione scheda preliminare (kill or go)

WBS: Soluzione (3) 2. SVILUPPO DEL PRODOTTO 2.1. Analisi opportunità offerte dai fornitori 2.2. Progettazione 2.2.1. Disegno funzionale (architettura di prodotto) 2.2.2. Studio stile e colori 2.2.3. Specifiche industriali (geometrie, specifiche di max) e disegni di nuovi particolari 2.3. Prototipazione nuove soluzioni 2.3.1. Richiesta componenti 2.3.2. Analisi componenti 2.3.3. Prove tecniche componenti 2.4. Verifiche 2.4.1. Analisi costi e investimenti 2.4.2. Confronto con il mercato 2.4.3. Test grafiche e colori 2.5. Approvazione dell'architettura di prodotto (kill or go)

WBS: Soluzione (4) 3. AVVIAMENTO PRODOTTO 3.1. Stima dei volumi di produzione 3.2. Industrializzazione 3.2.1. Distinta base (disegni tecnici dei singoli componenti) 3.2.2. Definizione processo produttivo 3.2.2.1. Definizione dei cicli di assemblaggio 3.2.2.2. Mezzi produttivi 3.2.2.3. Attrezzature 3.3. Ordine dei materiali con acquisizione LT per produzione primo mese 3.4. Preproduzione 3.4.1. Produzione di campioni per cataloghi 3.4.1.1. Acquisizione materiali per campioni 3.4.1.2. Costruzione campioni 3.4.1.3. Prove tecniche 3.4.1.4. Preparazione cataloghi 3.4.1.5. Test di mercato 3.4.2. Produzione di preserie 3.4.2.1. Acquisizione materiali per preserie 3.4.2.2. Costruzione preserie 3.4.2.3. Analisi criticità 3.4.2.4. Presentazione ad agenti, distributori e rete vendita 3.5. Approvazione della preproduzione e delibera a produrre (kill or go) 3.6. Ordine dei materiali con acquisizione BT per produzione primo mese 3.7. Produzione in serie

Diagramma di Gantt Obiettivi Caratteristiche principali Rappresentare in forma grafica e sintetica lo schedule di un progetto Caratteristiche principali Rappresentazione delle attività come barre su una scala temporale orizzontale Concetti basilari Attività: work package Evento: stato del progetto in un certo istante (es. inizio o fine) Schedule: schema tempificato delle attività con gli eventi di inizio e fine Il diagramma di Gantt (o diagramma a barre) è uno strumento puramente grafico. In esso la durata delle attività è indicata con linee e i momenti critici del progetto (milestone) sono indicati con simboli particolari. Il diagramma di Gantt è quindi uno schema sintetico che facilita la comunicazione tra i membri del team e illustra, con una visione rapida, il piano temporale del progetto. OBIETTIVO principale del diagramma di Gantt è proprio rappresentare in forma grafica e sintetica lo schedule di un progetto.

Diagramma di Gantt: pianificato ed effettivo Attività Pianificato 11 (oggi) 6 9 Effettivo A B C D 3 5 8 15 Tempo

Diagramma di Gantt: relazioni logiche Attività Pianificato Effettivo A B C D 3 5 6 8 9 15 Tempo 11 (oggi)

Vantaggi e problemi del diagramma di Gantt Sintesi e leggibilità Semplicità Problemi (Mancanza di relazioni tra attività) Supporto decisionale limitato I maggiori VANTAGGI legati al diagramma di Gantt sono individuabili nella sintesi, nella leggibilità e nella semplicità dello strumento; i PROBLEMI invece coincidono con la mancanza di relazioni tra attività (in realtà tale problema è risolvibile sia a livello grafico che logico) e con il supporto decisionale limitato.

Tecniche reticolari Obiettivi Caratteristiche principali Rappresentare lo schedule di un progetto specificando le relazioni logico/temporali Caratteristiche principali L’idea di base è rappresentare attività, eventi e relazioni su un reticolo orientato Relazioni di precedenza Fine - Inizio Fine - Fine Inizio - Inizio Percorso: sequenza di attività che collega l’evento inizio del progetto con l’evento fine Tempo di percorrenza o Lead Time: somma delle durate delle attività del percorso Percorso critico: percorso di durata massima (durata del progetto) Le tecniche di programmazione reticolare sono uno strumento di supporto alla pianificazione e controllo operativi dei tempi di svolgimento di un progetto e delle sue attività elementari. Esse si basano sui cosiddetti diagrammi reticolari. Essi sono rappresentazioni del progetto come serie di attività aventi tra loro delle relazioni di sequenzialità. I componenti fondamentali di un diagramma reticolare sono i seguenti: Le attività, ognuna delle quali è caratterizzata da una durata e da un assorbimento di risorse determinate; Gli eventi, che rappresentano le situazioni iniziali e finali di ogni attività, in particolare si dicono milestone quegli eventi che hanno una particolare rilevanza ai fini del controllo del progetto, in quanto le decisioni prese fino a quel momento vengono nel seguito considerate congelate; gli eventi "inizio del progetto" e "fine del progetto" sono sempre i due milestone fondamentali; Le relazioni di precedenza tra le attività determinano la sequenza richiesta: l'evento inizio di un'attività successore non può avere luogo finché tutti gli eventi fine delle attività predecessore si sono verificati. Tutte le attività che non hanno inizio con l'evento "inizio del progetto" hanno almeno un predecessore e tutte le attività che non terminano nell'evento "fine del progetto", hanno almeno un successore; I percorsi sono tutte le sequenze di attività che collegano l'evento "inizio del progetto" con l'evento "fine del progetto“; A ciascun percorso è associato un tempo di percorrenza che è dato dalla somma delle durate delle attività che lo compongono; Si dice percorso critico quello che ha massimo tempo di percorrenza. Il tempo di percorrenza del cammino critico (che eventualmente può non essere unico) determina la durata complessiva del progetto.

Esempio di tecniche reticolari Attività Predecessori Durata (mesi) A - 3 B 10 C 8 D 5 E F B, D G B, D, E H F, G 4 Percorsi Lead time A, B, F, H 27 A, B, G, H 25 A, C, D, F, H 30 A, C, D, G, H 28 A, C, E, G, H 26 Per quanto riguarda la rappresentazione grafica possono essere utilizzate due diverse convenzioni: quella delle "attività sugli archi" (AsA) e quella delle "attività sui nodi" (AsN). Noi analizziamo un esempio i cui dati sono riportati in Tabella in entrambe le notazioni. Percorso critico: 30 mesi

Esempio di tecniche reticolari ES EF LS LF I d Early Start: istante al più presto in cui può iniziare un’attività senza mutare la durata totale del progetto Early Finish: istante al più presto in cui può finire un’attività senza mutare la durata totale del progetto Late Start: istante al più tardi in cui può iniziare un’attività senza mutare la durata totale del progetto Late Finish: istante al più tardi in cui può finire un’attività senza mutare la durata totale del progetto

Esempio di tecniche reticolari 16 26 Attività sui Nodi F 10 26 30 3 13 3 11 11 14 11 16 15 18 18 26 16 26 H 4 B 10 16 24 G 8 D 5 0 3 26 30 6 16 A 3 11 16 0 3 C 8 E 3 3 11

Esempio di tecniche reticolari ES EF LS LF I d Early Start: ESi = MAXpred(i) (EFpred(i)) Early Finish: EFi = ESi + DURATAi Late Start: LSi = LFi - DURATAi Late Finish: LFi = MINsucc(i)(LSsucc(i)) Slacki = LSi – ESi = LFi - EFi

Esempio di tecniche reticolari Attività Durata (Sett.) Slack Start date Slack residuo A 3 B 10 3, 4, 5, 6 3, 2, 1, 0 C 8 D 5 11 E 4 11, 12, 13, 14, 15 4, 3, 2, 1, 0 F 16 G 2 16, 17, 18 2, 1, 0 H 26

Vantaggi e problemi delle tecniche reticolari Sintesi e leggibilità Relazioni tra attività Problemi Supporto decisionale limitato: enfasi esclusiva sui tempi Struttura intrinsecamente deterministica Sicuramente tra i vantaggi offerti dalle tecniche reticolari è necessario considerare la sintesi e la leggibilità dello strumento, inoltre esso mette in evidenza le relazioni fra le diverse attività e quindi costituisce un supporto decisionale. D’altro canto tali tecniche presentano anche dei limiti: concentrano la propria attenzione sui tempi e non sui costi, inoltre la struttura è intrinsecamente deterministica.