Il progetto è un processo in cui risorse umane, materiali e finanziarie sono organizzate in modo nuovo per realizzare un output unico all'interno di vincoli definiti di tempo e di costo. Elementi che caratterizzano un progetto rispetto a un processo: 1) L'Unicità Dell'Output l'oggetto che deve essere realizzato è significativamente differente da ciò che è stato fatto in precedenza. Tale unicità comporta quindi un grado più o meno elevato di novità nell'output realizzato: può essere un prodotto completamente nuovo; oppure mostrare alcuni elementi di unicità, può essere nuovo per l'impresa. Ne consegue che non è possibile definire modelli standard ma è necessario comprendere i fattori contingenti che rendono critici diversi aspetti del progetto. 2) Unicità Della Realizzazione anche la modalità di realizzazione del progetto presenta elementi di novità rispetto a quanto l'impresa svolge normalmente e quindi ogni progetto richiede di fatto un flusso di attività che va identificato e messo a punto ad hoc. E’ necessario definire un'opportuna struttura organizzativa per la sua gestione, in quanto è necessario che le risorse vengano impiegate in modo differente da come sono utilizzate per la gestione dell'attività correnti (può essere richiesto il coinvolgimento di risorse che sono effettivamente nuove per l'impresa). 3) Temporaneità i progetti hanno una vita la cui durata è definita da quando l'output deve essere reso disponibile; questo aspetto richiede anche di progettare un sistema organizzativo in grado di esistere per un periodo limitato; può essere richiesta la costruzione di un'organizzazione non esistente con nuovi addetti oppure nel caso opposto (organizzazione già esistente) si rende necessario specificare modalità di coordinamento e interazione delle unità esistenti. 4) Riduzione Dell'Incertezza raramente all'inizio di un progetto è completamente chiaro cosa il progetto va a realizzare e come. La definizione degli obiettivi e la loro traduzione in attività è una operazione raramente lineare, ma si basa su un'elaborazione progressiva, in cui, attraverso approssimazioni successive e grazie alle informazioni generate nel corso della elaborazione stessa, si va a chiarire e dettagliare cosa il progetto realizza e come. 5) Competenze spesso nei progetti è necessario utilizzare competenze nuove, mai adottate in precedenza. Può anche capitare che sia necessario sviluppare nuova conoscenza direttamente durante il progetto stesso. 6) Finalizzazione è necessario dedicare tempo e risorse alla definizione di cosa il progetto debba realizzare prima di poterlo avviare, anche al fine di poter valutare la qualità dell'output generato. Tipologie Di Progetti 1) Progetti Su Commessa sono compresi tutti i progetti per i quali un cliente richiede esplicitamente un determinato output con ben definite caratteristiche; caratteristica comune di questa tipologia di progetti è la presenza di un cliente ben definito con cui viene solitamente redatto un contratto. 2) Progetti A Catalogo sono i progetti in cui non vi è un determinato cliente che esplicitamente richiede la realizzazione di un progetto, ma un cliente potenziale (o target) che il progetto mira a soddisfare. Fasi Di Un Progetto 1) Initiating la fase della nascita, in cui, identificato un problema da risolvere o una opportunità da cogliere, si valuta la fattibilità tecnica, economica, strategica di svolgere un progetto. Questa fase mia quindi a decidere se eseguire un progetto e, in caso, definire cosa esso debba realizzare. L'input può essere molto diverso da progetto a progetto (acquisizione contratto da parte di un cliente, acquisizione particolare tecnologia, ecc). Questa fase termine tipicamente con la definizione degli obiettivi specifici (scope, tempi e costi di realizzazione) e con l'autorizzazione formale a procedere. 2) Planning fase in cui si definisce e si pianifica il progetto, definendone lo scope. Questa fase culmina nella stesura del piano di progetto cioè il documento che fa da riferimento per tutte le attività di realizzazione.
3) Executing & Controlling è la fase in cui effettivamente viene realizzato l'output, dove si effettuano gli investimenti si controlla le attività svolte per verificarne l'aderenza al piano. Inoltre durante questa fase viene anche la revisione dà pianificazione stessa laddove il progetto subisca nel tempo delle modifiche. 4) Chiusura era fasi in cui l'output del progetto viene rilasciato per il funzionamento regime si verifica il grado di raggiungimento degli obiettivi. Project Management è l'insieme dei principi, logiche e metodi generali per la gestione di progetto. La gestione di progetto è costituito innanzitutto dalla filosofia di gestione; e inoltre un'impostazione organizzativa riguardante la gestione delle risorse dell'attività e da ultimo è un insieme di strumenti che permettono di pianificare, controllare e organizzare le attività che costituiscono un progetto.
Le principali fasi in cui si compone un progetto sono: inizializzazione, pianificazione, esecuzione e controllo, la chiusura. Ogni fase riceve alcun input da altre fasi in genere output necessari per le altre fasi. Queste fasi non sono sempre perfettamente sequenziali, ma possono essere logicamente e temporalmente sovrapposte. La sequenza e la sovrapposizione è legata alla diversa natura dei progetti descritti ma anche diverse modalità con cui le imprese decidono di gestirli. Ciò che spesso rende necessario sovrapporre differenti fasi e che esse generano informazioni necessarie per far sì che logicamente vengono prima. Le fasi fondamentali in questo articolo un progetto sono spesso complesse, multidisciplinari, sovrapposte interconnesse tramite generazione di output intermedi.
1) Inizializzazione ha un output fondamentale la decisione se procedere o meno con lo svolgimento del progetto. I progetti che prevedono gare di aggiudicazione si parla di decisioni di Bid/No Bid per sottolineare come, in ambienti molto strutturati come il più delle volte le offerte costituiscono impegni vincolanti, le imprese lavorino per decidere se partecipare alla gara (bid). È opportuno sottolineare come la decisione di partecipare non costituisca di per sé la partenza del progetto. La gara potrebbe infatti anche essere persa, o potrebbe aprirsi una fase di negoziazione che potrebbe modificare il progetto stesso al punto da rimettere in discussione la decisione di Bid. In questi casi l'output finale di questa fase è, nel caso di assegnazione del lavoro, la firma del contratto mentre, nel caso di non assegnazione, l'archiviazione dell'offerta. Le attività fondamentali di questo processo riguardano le analisi relative alla fattibilità tecnica ed economica del progetto e alle valutazioni dell'opportunità strategiche, tecnologiche e di mercato. Il processo di pianificazione strategica (che, definendo le priorità strategiche, individui rapporti di precedenza tre progetti) è seguito dal processo di pianificazione economica e finanziaria (l'individuazione vincoli al portafoglio dei progetti) infine dal processo di definizione della strategia tecnologica (identificazione tecnologie future). È possibile distinguere tra parti fondamentali di questa fase: A) Generazione Statement of Work è la richiesta di progetto e contiene le informazioni relative alla necessità che devono essere soddisfatte, il tipo di output, le richieste del mercato, le innovazioni di processo, le necessità di rispettare i nuovi standard imposti da nuove leggi,ecc. tale descrizione è però solitamente non molto dettagliata poiché contiene per esempio i requisiti funzionali del prodotto, i requisiti prestazionali ma non le specifiche di dettaglio dell'output. Praticamente tale documento descrive cosa dovrà fare l'output del progetto ma non come. Nel caso di progetti su commessa è costituito da un documento formale di richiesta da parte del cliente; solitamente tale documento è creato da un membro interno o esterno dell'azienda. Nel caso di membro esterno in esso farà pervenire all'impresa una richiesta specifica che potrà essere, a seconda dei casi una RFI (Request for Information cioè una richiesta su come potrebbe essere soddisfatto un bisogno partire dalle conoscenza dell'impresa) oppure una RFP (Request for Proposal cioè la richiesta di un'offerta formale per la progettazione e realizzazione di un output) oppure una RFQ (Request for Quotation cioè la richiesta di una quotazione per un prodotto di cui è stato già definito un progetto di alto livello). B) Generazione Project Charter le informazioni contenute nel SOW non sono sufficienti per alimentare il processo decisionale e quindi tale documento deve essere tradotto in un Project Charter cioè un
documento più completo poiché contiene informazioni dettagliate aggiuntive. Lo scopo del PC piccolo di fornire un insieme di informazioni sufficienti per decidere se procedere o meno con lo svolgimento del progetto. Informazioni contenute: a) Motivazioni Alla Base Del Progetto questa sezione è corredata da un documento che mostra sia gli impatti attesi dal l'output del progetto sia gli impatti della sua non realizzazione. b) Obiettivi Specifici Di Progetto e necessario identificare gli obiettivi di dettaglio cioè specifiche del prodotto stesso (tutte le sue funzioni prestazioni), del processo di produzione, il tempo entro cui il prodotto deve essere lanciato sul mercato e dal costo di produzione. La definizione degli obiettivi specifici sarà influenzata dalla strategia aziendale cioè dai suoi obiettivi strategici. Esistono stretti legami tra ogni singolo progetto gli obiettivi strategici aziendali, nel senso che al progetto è richiesto un determinato contributo per la realizzazione di tali obiettivi. Il singolo progetto nascerà quindi per soddisfare obiettivi strategici ma, per poterlo svolgere, e si dovranno essere tradotti in obiettivi specifici. Il responsabile del raggiungimento degli obiettivi specifici di progetto e l'project manager ma sarà la committenza (cioè chi ha la responsabilità del budget su cui graverà il progetto) a definire gli obiettivi strategici; inoltre la committenza il compito di definire quali progetti entreranno nel portafoglio aziendale e cosa dovranno produrre come output specifico. La committenza presidia dunque anche la relazione tra obiettivi strategici aziendali e obiettivi specifici di progetto. È possibile che più progetti agiscono contemporaneamente per realizzare uno stesso obiettivo strategico; per questo motivo non è sensato misurare come performance dei progetti raggiungimento degli obiettivi strategici ma bensì va misurata la loro capacità di raggiungere gli obiettivi specifici. In questa sede vengono anche definiti i principali deliverable di progetto, ossia ogni forma di output, si intermedio che definitivo, che fluisce dal progetto verso il cliente, esterno all'interno (documentazione di progetto, prototipi, documenti progettuali,ecc). c) Macro Attività E Organizzazione è opportuno definire quali saranno le macro attività da svolgere e quali risorse organizzative saranno coinvolte. Vengono effettuate anche le stime di fattibilità tecnica e si analizza la reale capacità dell'impresa di svolgere le attività di progetto; si esegue inoltre una pre-analisi per decidere se e quali attività saranno svolte interamente all'interno dell'azienda o delegate esternamente (decisioni di “make or buy”). d) Tempi E Costi e) Rischi Il PC comprende quindi indicazioni strategiche, tecniche, di tempo, di costo, di rischio ecc; a qui mi una natura fortemente multidisciplinare. Dal punto di vista organizzativo, la sua elaborazione richiedente reazioni diverse competenze aziendali (funzioni tecniche, funzioni amministrative, funzioni finanziarie, legali, esperti in materia,ecc). Ne consegue che è necessario curare il coordinamento di tale fase e ciò viene portato a termine da uno specifico ruolo denominato Proposal Manager. C) Approvazione Del Progetto è necessario realizzare una valutazione di carattere economico-finanziario che fa riferimento allo schema tipico di analisi degli investimenti. Il costo complessivo legato all'utilizzo delle risorse può essere calcolato in modo simile per tutte le tipologie di progetto presentate. I progetti invece si differenzia per quanto riguarda il calcolo dei ricavi; nel caso di progetti su commessa all'analisi semplice in quanto viene stabilito a priori tra le parti il controvalore monetario che il cliente riconosce così come il piano di pagamenti in relazione al avanzamento del progetto. Per le altre tipologie di progetti invece la definizione dei ricavi comporta maggiori difficoltà; nel caso di progetti a catalogo vi è la necessità per l'azienda di stimare alcuni parametri fondamentali quali le unità vendute, il prezzo di vendita e la durata del ciclo di vita del prodotto. La necessità di effettuare tale stime rende più complessa ed aleatoria l'analisi economiche finanziarie del progetto, aumentando il livello di rischio. Anche la valutazione economica finanziaria di un progetto va integrata con valutazioni strategiche più ampia (esempio incominciare a lavorare con un cliente di riferimento del settore, possibili effetti sull'immagine dell'impresa, progetti tecnologici).
D) Lancio Del Progetto il decisore ultimo del processo di inizializzazione è la committenza. Al fine di ottenere la massima integrazione tra i processi è considerata buona pratica coinvolgere il project manager fin dal processo di inizializzazione, come garante delle stime di tempo di costo che saranno fatte, essendo poi lui la persona che dovrà risponderne. Il PM sarà solo una delle risorse coinvolte presterà al processo le proprie competenze ove necessario. Colui che coordinerà l'intero processo sarà il Proposal Manager. 2) Pianificazione, Esecuzione E Controllo il processo di pianificazione ha come output finale la creazione del piano di progetto (project management plan), che copre tutti gli aspetti del progetto: scope, tempi, costi, risorse umane, organizzazione, rischi, qualità, comunicazione e acquisti. Il piano di progetto è l'evoluzione del project charter, sia per quantità di aspetti trattati che per la profondità il dettaglio della loro analisi. Per le successive pianificazioni, durante l'esecuzione progetto, l'imput sarà la versione precedente il piano di progetto, unitamente ai risultati dei controlli sull'avanzamento il piano stesso. Tali risultati sono dunque l'output fondamentale del processo di controllo che alimentato non solo dalla versione aggiornata del piano di progetto ma anche, e soprattutto, dei risultati dei controlli di avanzamento svolti sulle attività. Decentramento Il project manager, essendo responsabile del raggiungimento degli obiettivi specifici di progetto, dovrebbe pianificare controllare tutti gli aspetti nei minimi dettagli; nei casi di progetti di grosse dimensioni ciò è impossibile ed è necessario ricorrere al decentramento decisionale. Il team di progetto sarà in grado di definire nel dettaglio il lavoro da svolgere e di pianificare i tempi e le risorse necessarie. Il compito del PM sarà quello della messa a fattor comune delle pianificazione di dettaglio, controllandone la coerenza in termini di tempi, di costi e di contenuto. Anche per quanto riguarda il controllo dell'avanzamento di progetto il discorso analogo; solo che svolge realmente l'attività in grado di definirne con cognizione di causa quale sia il suo avanzamento. Ancora una volta, il project manager avrà il compito di mettere sotto il cumulo tutte le informazioni di controllo distribuito e di ricavarne una visione unitaria. Nel caso il controllo avrà necessario un secondo livello di attenzione. Soprattutto sui progetti di grosse dimensioni, la quantità di dati di controllo potrebbe essere ingente e il loro processamento in modo centralizzato da parte del project manager potrebbe richiedere molto tempo, trasformandosi rapidamente in un collo di bottiglia. Per tale motivo opportuno che il controllo a livello centrale sia filtrato attraverso il concetto di "allarme". Nel momento in cui avverrà un disallineamento tra pianificazione attività correnti, pare d'avere impatti su altre sotto parti del progetto, bisognerà allarmare il PM che valuterà gli impatti sistemici del disallineamento vaglierà le possibili contromisure. Livello di dettaglio non tutti progetti vengono pianificati controllati con lo stesso livello di dettagli e addirittura anche all'interno di un singolo progetto alcuna attività potrebbero essere pianificate e controllate con livelli di dettaglio distinti. Fattori che incidono: A) L'Esperienza Dei Componenti Del Team Di Progetto per team di progetto particolarmente esperti può risultare non indispensabile scomporre al massimo dettaglio le attività di progetto, in quanto attività anche aggregate saranno comunque facilmente identificabile controllabili grazie all'esperienza. B) Politiche di Outsourcing nel caso di attività affidate in outsourcing a fornitori, potrebbero essere necessaria dettagliare le attività richieste per realizzare un certo compito. Può essere comunque importante definire delle scadenze intermedie per evitare perdite di controllo delle attività esternalizzate. C) Rolling Wave descrive con il massimo dettaglio attività di un progetto che saranno svolte a grande distanza di tempo è difficile e inutile. Utilizzando la logica di RW è possibile eseguire un'elaborazione progressiva della pianificazione, nella quale il lavoro da svolgere nel prossimo futuro programmati in dettaglio, mentre il lavoro da svolgere in futuro più remote pianificato in maniera più aggregata. Controllo in Feed-Forward e Feed-Back il modificarsi di variabili interne ed esterne impatti era sul progetto discostando dalla pianificazione eseguita. Il controllo diventa quindi cruciale, al fine di implementare tempestivamente le azioni correttive necessarie per raggiungere gli obiettivi. Esistono due approcci distinti:
A) FB si basa sull'osservazione di quanto accaduto realmente durante il progetto, sul confronto tra quanto osservato e ciò che la pianificato e sull'analisi delle cause e gli eventuali spostamenti al fine di definire gli interventi correttivi. B) FF si cercano di anticipare gli effetti che le variabili interne ed esterne potrebbero avere sui risultati finali, quando il progetto è ancora in corso. L'osservazione continua delle variabili interne ed esterne del progetto, permette la previsione del loro andamento nel tempo e la stima del loro impatto futuro sul progetto. Per è un efficace controllo è necessario combinare i due cicli; infatti, per ripianificare opportunamente progetto, è necessario integrare le informazioni derivanti dal FB con quelle del FF , in modo da identificare interventi correttivi che, da una parte, siano basati sui risultati finora ottenuti e sullo stato di avanzamento del progetto e, dall'altra, tengano conto di quanto anticipato in termini di evoluzione delle variabili esterne e interne. Anche le attività di controllo devono essere pianificate (cosa viene controllato, con che frequenza e da chi)
EVM Earned Value Management; è un metodo di controllo molto efficace per il controllo integrato di tempi e costi; fornisce indicazioni puntuali sullo stato di avanzamento del progetto, indicazioni previsionali sul futuro andamento del tempo dei costi di progetto e permette di simulare i piani di recupero è di esprimere un giudizio sulla loro reale fattibilità. Non viene in nessun modo analizzata la qualità del lavoro già eseguito. BCWS Budgeted Cost Work Scheduled; rappresenta l'andamento dei costi cumulati di progetto per ogni intervallo di tempo. La BCWS di progetto sarà determinata dalle aggregazioni delle BCWS dei differenti control account. Normalmente assume una forma ad S dovuto al fatto che solitamente nelle prime fasi di progetto di una spesa ridotta; successivamente tale curva cresce più velocemente in corrispondenza della fase di esecuzione, nella quale si sostengono i maggiori costi. La curva infine rallenta la propria crescita quando ci si avvicina alla fase di chiusura. Non esisterà mai una BCWS discendente poiché essa è la sommatoria dei costi dei mesi precedenti; al massimo, se non vengono effettuate spese, sarà costante cioè con derivata nulla. La costruzione prevede l'incrocio dei dati della pianificazione temporale con quella dei costi.
ACWP Actual Cost Work Performed; grazie alla contabilità aziendale è possibile ricavare questo parametro che indica quanto si sia in realtà speso per il control account fino a un certo istante. Fino al termine del control account non è possibile confrontare il preventivo con il consuntivo e non è possibile capire quale sia la causa dello scostamento. La differenza tra preventivo e consuntivo dipende da due incognite distinte: A) efficienza/inefficienza (esborso maggiore/minore rispetto al preventivo) B) anticipo/ritardo. BCWP Budget Cost Work Performed; esprime l'avanzamento fisico dell'attività del control account valorizzato a costi di budget. Confrontando questa curva con ognuna delle altre due è possibile comprendere il reale andamento del control account. BCWP < BCWS il control account è in ritardo BCWP > BCWS il Control Account è in anticipo BCWP < ACWP il control account è inefficiente BCWP > ACWP del Control Account è efficiente Indicatori Relativi [calcolati in %] CPI Cost Performance Index CPI = BCWP / ACWP se maggiore di uno indica efficienza SPI Schedule Performance Index SPI = BCWP / BCWS se maggiore di uno indica anticipo L'analisi dell’andamento del progetto non può basarsi solo sugli indicatori relativi in quanto essi descrivono l'andamento delle performance solo in termini percentuali rispetto alla pianificazione e quindi non
permettono di valutare la reale portata economica di tali performance; per questo sono basilari gli indicatori assoluti. Indicatori Assoluti [calcolati in unità monetarie] CV Cost Variance CV = BCWP – ACWP se maggiore di zero indica efficienza SV Schedule Variance SV = BCWP – BCWS se maggiore di zero indica anticipo Earned Schedule rappresenta l'istante a budget in cui si sarebbe dovuto raggiungere il lavoro attuale in termini di costi. Indicatori particolarmente positivi o negativi, non permetteranno di definire se l'errore sia effettivamente nell'esecuzione del progetto o nella sua pianificazione che potrebbe essere stata eccessivamente conservativa o ottimistica; l'errore di pianificazione ha impatti negativi sulle performance aziendali in quanto non permette a quest'ultima di utilizzare le risorse in eccedenza per altri progetti. Time Report è uno strumento che rileva in modo puntuale frequenza fissa (settimanale o mensile) come stato speso il tempo di ogni risorsa (cioè su quali control account e su quali progetti). Per calcolare la curva BCWP è necessario rilevare un parametro critico da misurare cioè la percentuale di completamento (o POC) dell'attività. BCWP = POC * BAC (Budget at Completion cioè la stima complessiva del Control Account). La misurazione del POC può risultare in alcuni casi semplice (esempio di un'attività che comporta un output fisico e misurabile) mentre in altri casi può essere molto complessa e poco oggettiva (esempio avanzamento attività di pianificazione). Esistono 7 differenti metodi per il calcolo del POC: Metodi Discreti (cioè Oggettivi) A) Milestone: all'interno del progetto vengono determinate un numero variabile di Milestone e ad ognuna di essa viene attribuito un peso percentuale; al raggiungimento della milestone la percentuale di completamento verrà incrementato del peso della milestone stessa. Il peso della milestone dovrebbe combaciare con la quantità di risorse utilizzate sul totale. È uno dei metodi oggettivi e l'errore avviene solo per difetto poiché i risultati intermedi non vengono contemplati. B) 50/50: vengono posizionate solamente due milestone ognuna di peso specifico del 50%; di solito una posta a metà del lavoro e l'altra al suo completamento. L'errore avviene sia per difetto che per eccesso. C) 0/100 : viene posizionata un'unica milestone al termine dell'attività con peso specifico pare il 100% D) Unità Completate: questo metodo si applica ad attività che prevedono un certo numero di output uguali; l'avanzamento sarà qualcosa tramite rapporto fra l'unità prodotte e quelle totali. Il calcolo non tiene conto delle curve di apprendimento della produzione. Metodi Soggettivi A) Percentuale Di Completamento: la percentuale di avanzamento è in questo caso stimata dal responsabile del Control Account che si basa sulla propria esperienza e sulla conoscenza del lavoro da svolgere. È semplice e a basso costo. B) Sforzo Proporzionale: viene stimata la percentuale di completamento dell'attività associandola alla percentuale di avanzamento di un'altra attività a cui la prima è logicamente collegata (esempio controllo della produzione legata all'avanzamento della produzione stessa) C) Level of Effort: si prevede che l'avanzamento sia proporzionale al tempo trascorso (BCWP= BCWS); viene imposto un SPI sempre uguale a 1. È pertanto altamente sconsigliata poiché vengono comparate l'ACWP e il BCWS praticamente il consultivo e il preventivo.
Dato che i metodi soggettivi dovrebbero essere utilizzate il meno possibile, molte imprese definiscono vincoli formali al loro utilizzo fissando un tetto al valore massimo delle attività controllate con tali metodi. Tuttavia l'applicabilità di un dato metodo dipende dalla natura dell'attività stessa. Ad esempio un metodo ad unità completate si adatta ad attività di produzione, ma non ad attività di gestione che non prevedono un output fisico. Inoltre nel caso dei metodi a milestone la scelta si basa sulla relazione fra durata dell'attività frequenza del controllo; e in generale falso che un numero maggiore di milestone corrisponda a un maggior controllo. È evidente che aumentando il numero di milestone si ridurrebbe la discrepanza tra il completamento reale il completamento misurato; è però altrettanto vero che aumentare la granularità del controllo comporta maggiori costi e maggior tempo dedicato. La scelta del metodo di misurazione degli avanzamenti da utilizzare per ogni WP prevede la gestione di un trade-off tra precisione del controllo e costo ad esso correlato. Il controllo dell'avanzamento delle attività appaltate a fornitori esterni viene svolto dal PM. Nel caso di contratti Fixed Price (in cui il prezzo delle forniture è definito a priori del fisso a meno di cambiamenti di scope) il fornitore non è tenuto all'evidenza della propria struttura dei costi; per tale motivo, anche se si è in grado di identificare eventuali ritardi, non è possibile identificare eventuali inefficienze. Ciò significa che il CPI di tali attività sarà sempre pari a 1; Calcolo della Stima al completamento (EAC Estimate at Completion) dopo avere calcolato gli indicatori sintetici delle performance si procede a elaborare le nuove stime di tempo di costo per il WBE stesso. Prima di valutare eventuali azioni correttive deve essere chiaro quale sarebbe l'andamento nel caso in cui progetto continuasse senza alcun intervento correttivo; solo in questo modo sarà possibile effettuare un'analisi differenziale per capire se e quali interventi andranno implementati. Per il calcolo del EAC è necessario determinare la natura delle cause che hanno portato agli scostamenti rispetto alla pianificazione; 1) Cause Contingenti: cause che hanno influito sul WBE ma che si suppone abbiano esaurito il proprio impatto (esempio vertenza sindacale conclusa). 2) Cause Strutturali: cause che hanno influito sul WBE e continueranno impacchettarlo anche in futuro (esempio tensione sul mercato delle materie prime dovuta una guerra). La scelta delle cause strutturali non risulta essere più conservativa ma bensì tende a propagare l'errore (sia positivo che negativo). I due casi i meccanismi per il calcolo del EAC saranno differenti: 1) Cause Contingenti EAC (€) = BAC – CV = BAC – (BCWP – ACWP) EAC (t) = durata – SV (t) = durata – (BCWP (t) – BCWS (t)) 2) Cause Strutturali EAC(€) = ACWP + ETC Per calcolare l’ETC (cioè Estimate to Complete) si suppone che le performance mantenute fino al time now (CPI e SPI) si mantengano identiche fino alla fine del WBE. L’ETC, dato dalla differenza tra BAC e BCWP, indica il lavoro rimanente valorizzato a costi preventivi, ma siccome abbiamo supposto che l'efficienza futura sarà uguale a quella passata dobbiamo scontare tale effetto ETC (€) = (BAC – BCWP) / CPI ETC (t) = time now + (durata – tempo mancante) / SPI Le stime differiscono molto tra il caso di errore contingente quello di errore strutturale. A parità di indici di prestazione, la supposizione di errore strutturale amplifica (sia in positivo che negativo) gli effetti sulle stime e tale effetto si riduce con l'avanzamento delle attività. Questo effetto deve essere prese attenta considerazione soprattutto durante le fasi iniziali dell'attività da svolgere; in tali periodi, piccoli scostamenti di CPI ed SPI possono comportare elevate variazioni di stime, anche di ordini di grandezza, sul tempo e sul costo del WBE che spesso sono irrealistiche. Per evitare tale distorsione è buona norma quindi porre dei limiti alla variazioni di stima (solitamente + o – 10%) fintanto che l'attività non sia stabilizzata cioè si è
raggiunto il 20% del POC (cioè BCWP = 20% BAC). È opportuno sottolineare inoltre che la stima delle EAC è stata effettuata supponendo che le performance di costo (CPI) e di tempo (SPI) si mantenessero uguali a quelle misurate nell'istante di controllo (time now); si tratta in realtà di un'ipotesi semplificatrice in quanto tali parametri possono subire modifiche dal time now in poi. Valutazione piani di recupero Si tratta di tecniche di valutazione dell'effettiva fattibilità di un piano di recupero proposto. Stante la situazione attuale è possibile calcolare quali dovrebbero essere le performance, da qui in avanti, per rispettare le nuove stime di costo e tempo espresse dal responsabile del WBE e dal suo team. Si considerano le nuove stime di durate di costo come valori noti e si calcola quali performance di tempo (SPI) e di costo (CPI) dovrebbero essere mantenute d'ora in avanti per rispettarle. TCPI (to Complete CPI) = (BAC – BCWP) / (New Cost – ACWP) TSPI (to Complete SPI) = (Durata – Tempo mancante) / (New Time – Time Now) New Cost e New Time nuove stime effettuate dal responsabile del WBE Una ricerca del DOD americano mostra che una volta che il progetto è oltre il 20% del suo completamento, gli indicatori CPI ed SPI non possano essere incrementati più del 10% alla fine del progetto. Stime inverosimili potrebbero essere causate dalle approssimazioni usate per calcolare la percentuale di completamento delle attività e quindi la BCWP (ad esempio potremmo essere in prossimità di una milestone non ancora raggiunta). Ciò rende ancora più evidente come la scelta del metodo di controllo di avanzamento di un WP che viene presa in fase di planning sia essenziale per la corretta gestione dei progetti. Il metodo di controllo viene deciso da chi gestisce il progetto e non dal PM poiché è il primo a conoscere al avanzamento del lavoro ai costi da caricare.
GESTIONE DEL RISCHIO (CIOÈ DELL'INCERTEZZA) Rischio evento incerto che se accade ha un significativo effetto (positivo o negativo) sul raggiungimento degli obiettivi di progetto. PARAMETRI DEL RISCHIO: 1)impatto/opportunità 2)probabilità di accadimento Il rischio è una caratteristica intrinseca del progetto a causa del carattere di un'unicità; ciò implica un aumento della rischiosità associata alla sua realizzazione. AREE DI IMPATTO: 1) le attività del progetto: ad esempio l’incertezza relativa alla sperimentazione in quanto al momento dell'attivazione del progetto è difficile prevedere i risultati della simulazione. 2) gli attori coinvolti nel progetto:ad esempio il rischio legato al fatto che un fornitore che deve eseguire dei compiti non abbia le adeguate competenze tecniche. 3) Output: rischi che si potrebbero manifestare durante il ciclo di vita dell'output (utilizzo da parte degli utenti). TIPI DI RISCHIO: 1) rischi certi: non sono rischi ma problemi o opportunità che è necessario affrontare; 2) rischi conosciuti: rischi di cui si è consapevoli che potrebbero tradursi in problemi; 3) rischi non conosciuti: cioè dei quali a priori non si conosce neppure l'esistenza. La gestione del rischio si occuperà dei rischi conosciuti. FASI GESTIONE RISCHIO: 1) Identificazione del rischio: identificazione dei rischi principali mediante il coinvolgimento dei principali attori e tramite l'ausilio di opportuni metodi e strumenti. Da eseguire iterativamente lungo la vita del progetto. Strumenti: A) checklist: l'identificazione di rischio viene per aree di competenza (Risk Breakdown Structure). La suddivisione per aree permette di intraprendere azioni di mitigazione diversa per ogni area; domande a cui rispondere Si/No B) archivi storici C) diagrammi causa/effetto: sono rappresentazioni grafiche spine di pesce nelle quali vengono identificate tutte le cause, divise per aree di competenza, che portano ad un determinato effetto D)Brainstorming: meeting composti da 6/10 persone che analizzano il problema da punti di vista diversi poiché fanno parte di ambiti aziendali diversi; tutti hanno lo stesso valore. E) SWOT Analysis : elenco dei punti di forza, debolezze, opportunità e minacce del progetto; stesso numero per ogni elenco al fine di espandere l'analisi senza tralasciare nulla. Risk Register documento in cui vengono riportati e caratterizzati i rischi individuati; è in continua evoluzione. 2) Valutazione del rischio: l'analisi identificativa al fine di valutarne possibili impatti e la probabilità di accadimento. Fase strumentale alla definizione della scala di priorità dei rischi di progetto, la valutazione dell'azione di risposta e alla definizione delle contingency. Tutto ciò permette l’arricchimento del risk register con dati di dettaglio sui singoli rischi. Tipi di analisi: A) analisi qualitativa determinazione dei rischi più critici e attribuzione di una valutazione di tipo alto, medio, basso o su scala numerica. La valutazione si riferisce sia la probabilità che esso si verifichi, sia al suo impatto in termini di tempi costi e prestazioni. Tale analisi permette di determinare la matrice di probabilità/rischio che riporta nelle celle i fattori di rischio cioè il prodotto della probabilità per l'impatto del rischio. Esso consente di definire la priorità dei rischi attraverso una classifica in ordine crescente in base al rischio calcolato. B) analisi quantitativa viene eseguita sui rischi più importanti determinati dall'analisi qualitativa attraverso stime numeriche della probabilità di ogni rischio e del suo impatto atteso (espresso in termini di extra costi, ora giunge di lavoro, tempi). Impatto atteso = probabilità[%]*impatto[€]. Probabilmente il ranking stilato precedentemente varierà. 3) Pianificazione delle azioni di risposta: viene eseguita poiché è necessario stabilire mediante quali azioni si intendono affrontare i singoli rischi/opportunità di progetto. L'attività deve essere supportata da un'analisi delle cause scatenanti dei singoli rischi e deve mirare alla diminuzione dell'impatto e/o probabilità di accadimento del rischio. Solitamente ci si concentra sul parametro che permette di migliorare di più le performance cioè verranno eseguite quelle operazioni con il costo minore ma che ridurranno
maggiormente il rischio. Minor impatto Protezione (es. Airbag) Minor probabilità prevenzione (es. ABS). Strategie di risposta al rischio: A) Avoid: modificare il piano di progetto al fine di eliminare la minaccia oppure rendendo gli impatti del rischio non più rilevanti. B) Transfer: spostare il rischio verso una terza parte in modo da lasciare la responsabilità della gestione del rischio quest'ultima rendendo così di fatto il progetto insensibile all'occorrenza di un rischio. (es. contratti che bilanciano il rischio tra cliente fornitore oppure assicurazioni sul rischio). C) Mitigate: ridurre la probabilità che un rischio si presenti o ridurre il suo impatto attraverso azioni specifiche che comportano un costo certo. L'azioni di mitigazione diventa parte integrante dal progetto quindi va aggiunta alla WBS con l'allocazione di costi e tempi. D) Crisis Managment : non viene effettuata alcuna azione preventiva e viene deciso di intervenire solo nel caso in cui il rischio effettivamente accada. Le quattro strategie si differenziano tra loro nella gestione del trade-off tra costi certi iniziali (per la messa in atto dell'azione di risposta) e i costi probabili in caso di accadimento del rischio. Tutte queste azioni permettono di traslare la curva del profilo di rischio verso sinistra. Strategie di risposta alle opportunità: A) Exploit: si cerca di rendere una data opportunità più probabile, assegnando all'attività destra associate le risorse migliori in grado di coglierla più facilmente. B)Share: si assegnano all'attività coloro che sono più incentivati a realizzarle al meglio. La scelta delle azioni di risposte da implementare richiede anch'essa una valutazione. Infatti, associata tale azione di un costo certo che fa fronte però vantaggi aleatori sia in termini di possibile riduzione di un effetto negativo sia in termini di possibili vantaggi. Per consentire tale valutazione è necessario determinare il beneficio al netto degli interventi. A tal fine può essere utile ad esempio calcolare la differenza tra valore atteso del rischio prima e dopo le azioni di risposta al netto dei costi delle azioni stesse e verificare così se si ottiene un beneficio netto positivo al termine della fase di pianificazione dell'azione di risposta possibile arricchire il Risk Register con nuovi dati di dettaglio relativi alle azioni da implementare. 4)Definizione delle contingency: a valle dell'analisi dei rischi e dell'individuazione delle azioni di risposta da eseguire, occorre definire l'ammontare delle contingency da allocare a fronte dei rischi residui per ogni work package (è impossibile eliminare completamente il rischio da un progetto tramite le azioni di risposta). L’accadimento di uno dei tali rischi porterebbe a degli extra costi per la sua gestione impattando sulla dimensione economico-finanziaria del progetto; si decide allora di accantonare alcune contingency per creare un "margine di sicurezza". Solitamente viene assegnato come contingency una quantità almeno pari all'impatto atteso del rischio a valle dell'azione di risposta. Dato che le contingency sono legate a rischi specifici è possibile collocarle nel tempo dato che è stato già definita la pianificazione temporale dei control account; in questo modo è possibile monitorare il consumo su base temporale, misurando per ogni periodo la quantità cantonata, quella utilizzata e quella non più necessaria. CONTROLLO DEL RISCHIO : innanzitutto si occupa di verificare che i rischi stimati in fase iniziale vengono opportunamente aggiornati, alla luce delle nuove informazioni che emergono durante lo sviluppo del progetto. In alcuni casi può risultare utile adottare anche un'analisi a livello di progetto, per valutare il grado di esposizione al rischio del progetto complessivo. La valutazione del profilo di rischio del progetto parte dalla valutazione della distribuzione di probabilità di singoli rischi e dalla valutazione del loro impatto. Attraverso software di simulazione numerica è possibile eseguire l'analisi di tipo Montecarlo andando a determinare la distribuzione di probabilità degli impatti legati al verificarsi dei rischi che vengono rappresentati mediante una curva cumulata di tale probabilità (grafico ad S probabilità[%]/impatto[€]). Attraverso questo grafico è possibile stimare la probabilità che gli extra costi legati ai diversi rischi superino le contingency totali allocate andando così ad erodere il margine di progetto. Man mano che il progetto avanzerà la curva del profilo di rischio si sposterà verso sinistra indicando che il profilo di rischio dell’intero progetto si sta riducendo.
Gestione di progetto Un progetto si caratterizza per l'unicità dell'output, nelle modalità di realizzazione, dalla specificità degli obiettivi definiti perseguiti, dalla durata limitata nel tempo, dalla necessità di reperire e di coordinare diverse risorse. Tutte queste caratteristiche non consentono di contare sull'opportunità offerte dalla continuità dei processi nel tempo ed alla conseguente possibilità di affinamento delle soluzioni di apprendimento progressivo. Queste caratteristiche invece richiedono di individuare e di adottare le soluzioni appropriate definendole caso per caso a partire quando possibile da esperienze simili. I progetti presentano così alcune problematiche tipiche che richiedono approcci e soluzioni specifiche. Un progetto viene realizzato in condizioni non del tutto definite in presenza di elementi di incertezza più o meno marcati; si configura così come un processo di problemi solving cioè un processo decisionale volto ad individuare una soluzione soddisfacente per uno specifico problema nel rispetto degli obiettivi e dei vincoli noti. Il progetto stesso diventa così la combinazione di un insieme di processi decisionali. Tuttavia può capitare che la soluzione individuata non sia congruente con gli obiettivi e i vincoli di altre attività e che tali vincoli emergano solo in una fase successiva non essendo noti al momento in cui l'attività viene svolta. Esistono tre principali classi di interdipendenza che possono verificarsi nel corso di un progetto: 1) Interdipendenza Fra Attività O Fasi Successive: nello svolgimento di fasi temporalmente e logicamente successive emergono vincoli non considerati nello svolgimento di una fase precedente 2) Interdipendenza Fra Parti Del Progetto: le scelte progettuali fatte nello sviluppo di parti diverse del progetto non sono tra loro coerenti e richiedono un ripensamento delle scelte fatte. 3) Interdipendenze Fra Progetti Diversi: le decisioni prese nella realizzazione di un progetto risultano incongruenti con quanto deciso per altri progetti correlati. A causa di questi interdipendenze può accadere che la soluzione che appare migliore o soddisfacente all'interno di una specifica attività non lo sia invece a livello di progetto (il massimo locale non è sempre un massimo globale); la difficoltà nel caso di un progetto nasce dal fatto che non tutti i legami esistenti fra l'attività sono conosciuti e vincoli esterni non sono sempre completamente esplicitati. Tutto ciò può provocare degli effetti negativi sul progetto: 1) Ricicli: vengono riconsiderate le scelte fatte in precedenza modificando la soluzione adottata per renderla compatibile con i vincoli emersi successivamente; ciò induce una perdita di tempo e di risorse per eseguire un'attività già svolta e considerata conclusa. 2) Rimandare La Soluzione Dei Problemi Alle Fasi Successive 3) Degrado Della Qualità Dell'Output: si può essere costretti a rivedere lo scope di progetto rinunciando a risolvere il problema qualora i costi tempi di una modifica si rivelino ormai troppo elevati; risulta essere una scelta conveniente sul breve termine ma non sul lungo periodo a causa della perdita d'immagine aziendale. Ci si trova dunque di fronte ad un trade-off tra due aspetti: da una parte l'incertezza e dall'altra il costo e il tempo necessario per realizzare un intervento correttivo (figura). I ricicli sono fortemente legati all’incertezza associata al progetto; esistono fattori di incertezza interni (associati a elementi propri del progetto non chiaramente identificati nelle fasi iniziali) e fattori di incertezza esterni (legati tipicamente al
contesto esterno in cui viene realizzato il progetto). Dalla figura si può vedere come l'incertezza è di solito molto elevata negli stadi iniziali a causa anche dell'unicità del progetto. Man mano che si sviluppa il progetto l'incertezza tende a diminuire dato che vengono prese decisioni che limitano l'ambito delle scelte successive, si riducono le alternative aperte, emergono quali sono i problemi da risolvere, vengono elaborate le informazioni necessarie per gestire le diverse parti del progetto. L'incertezza viene meno fine progetto quando le scelte sono completamente definite e ne sono chiari gli effetti. È evidente che nelle fasi iniziali e difficile identificare la soluzione giusta e invece emerge progressivamente nel corso del progetto. Per tale ragione nelle prime fasi conviene dedicare tempo all'analisi di progetto proprio per ridurne l'incertezza (è possibile acquisire conoscenza tramite l'intervento degli stakeholders). I tempi e i costi necessari per realizzare un intervento correttivo presentano invece l'andamento opposto. All'inizio del progetto le modifiche possono essere implementate senza difficoltà: avendo avviato da poco l’ attività, un eventuale cambiamento non comporta problemi. Man mano che il progetto evolve però la realizzazione di un intervento correttivo diventa sempre più onerosa a causa del fatto che anche piccoli cambiamenti possono richiedere la revisione delle soluzioni assordate e di riprendere attività ormai completate. Per questo dopo un certo punto conviene evitare di apportare modifiche al progetto a causa degli alti costi. Il progetto può essere realmente gestito nelle fasi in cui l'incertezza non è troppo elevata ed è ancora possibile modificare le scelte fatte (FINESTRA DELL'OPPORTUNITÀ). A questo scopo è necessario fare leva su due principi chiave: 1) Anticipazione Dei Vincoli e Delle Opportunità obiettivo la riduzione dell'incertezza nelle fasi iniziali del progetto tramite l'abbassamento della curva dell'incertezza. Per far ciò è necessario quindi anticipare il più possibile l'esame dei vincoli e delle opportunità che emergeranno nel corso del progetto o che potranno interessare l'output lungo tutto il suo ciclo di vita. Questo punto di vista la fase più importante del progetto è quella di planning dove si determineranno i modi in cui verranno consumate le risorse e impiegato il Tempo Durante La Realizzazione. Anticipazione Può Essere Realizzata Mediante Tre Categorie Di Interventi: A) Coinvolgimento Anticipato Degli Stakeholders vengono coinvolti tutti coloro che sono portatori di vincoli/opportunità al progetto (cioè gli stakeholders) fin dalle fasi iniziali dello stesso. In questa fase è necessario far leva sul lavoro in team ed è compito di chi è responsabile del progetto individuare quali attori possono dare un contributo importante a questa fase. Gli stakeholders dovranno essere consultati in modo da verificare che la strada che si sta intraprendendo sia coerente con i vincoli e consideri per tempo le diverse opportunità. Un altro strumento importante di coinvolgimento degli stakeholders è data dalla definizione di opportuni momenti di validazione; fin dalle prime fasi del progetto sarà necessario istituire opportuni momenti di revisione delle decisioni prese, volte ad avere una verifica da parte degli stakeholders e una loro formale accettazione di quanto si è stabilito fino a quel momento a livello di progetto (es. design review) B) Gestione Della Conoscenza anticipazione dei vincoli e delle opportunità avviene grazie alle conoscenze acquisite in altre esperienze simili da parte del team di progetto oppure possono esser utilizzate conoscenze intenzionalmente codificate e strutturate per essere di supporto nell'affrontare specifici problemi (elaborazione delle design rules). Il ricorso alle conoscenze pregresse è un potente strumento in quanto consente di identificare a priori problemi e soluzioni che possono essere rilevanti anche nel caso di un nuovo progetto; tuttavia a volte l'esperienza pregressa può comportare un effetto di blocco (lock-in) a causa del fatto che i nuovi progetti vengono affrontati privilegiando l'uso di metodi e approcci applicati con successo in progetti precedenti a prescindere dalla loro efficacia. Nel caso di progetti radicalmente nuovi occorre far leva sulla sperimentazione a causa dell'impossibilità di utilizzare esperienze precedenti; - Test Validativi: sono utili per verificare gli impatti delle scelte effettuate e il rispetto di specifici requisiti (es. crash test per nuove auto). Questa tipologia di test viene effettuata nelle fasi finali
della progettazione; nel caso venissero riscontrati dei problemi, la loro soluzione richiederebbe l'attuazione di ricicli complessi e onerosi; - Test Esplorativi: sono utilizzati per mettere alla prova le soluzioni ipotizzate grazie a prove realizzate durante lo sviluppo stesso del progetto; ciò permette di anticipare vincoli opportunità al contrario del caso precedente. C) Adozione Di Un Metodo l'applicazione di metodi strutturati infatti induce ad affrontare in modo sistematico specifici aspetti del progetto riducendo così il rischio di rinviare l'analisi e la messa in evidenza di possibili problemi; vengono utilizzati modelli di analisi che possono migliorare la comprensione delle problematiche di progetto e molto spesso queste metodologie sono progettate per specifiche tipologie di progetti. 2) Flessibilità obiettivo riduzione dei tempi e dei costi delle modifiche di progetto tramite l'abbassamento della curva dei costi e dei tempi di modifica. Questa filosofia è molto utile in condizioni di alta incertezza (es. sistemi in forte evoluzione) nei quali non è possibile anticipare i vincoli poiché non si conoscono minimamente. Con flessibilità s'intende la capacità di un progetto e dell'organizzazione che lo gestisce, di contenere gli impatti e gli oneri derivanti da interventi correttivi effettuati in fase avanzata del progetto. La flessibilità quindi tende a ridurre la pendenza della curva dei tempi dei costi per la realizzazione di un intervento correttivo e quindi la loro entità nelle fasi finali di un progetto. La flessibilità ovviamente comporta un aumento dei costi di progetto a fronte però della riduzione dei costi attesi nel caso di cambiamenti; quindi ha senso investire sulla flessibilità se e solo se si ritiene altamente probabile di dover introdurre cambiamenti al progetto durante le fasi conclusive; Esistono tre principali tipologie per applicare il principio di flessibilità: A) Processo si agisce sul processo, sulla sequenza sulle relazioni tra fasi di attività secondo un approccio non tradizionale. Quando si applica l'approccio flessibile, si accetta che le particolari condizioni esterne possano mutare; di conseguenza tornare indietro e modificare alcune decisioni non è più considerato sintomo di errore ma una necessità o una opportunità da sfruttare. Per far ciò l'approccio da adottare deve essere differente. E necessario in particolare sottoporre rapidamente attesta le soluzioni ipotizzate per testarne la bontà e introdurre le integrazioni e le modifiche necessarie generando così nuova conoscenza utile nel prosieguo del progetto. A questo scopo le fasi e le attività saranno temporalmente sovrapposte (overlapping) e si cercherà non appena possibile, di costruire prototipi (beta release) almeno parzialmente funzionanti da testare, anche con il coinvolgimento degli utenti, per raccoglierne i feedback e rivedere di conseguenza le scelte fatte le soluzioni adottate (identificazione bachi, interesse per le funzionalità proposte, suggerimenti e osservazioni). La gestione delle modifiche nel corso dello svolgimento del progetto comporta ingenti costi di lavorazione duplicazione degli sforzi ma d'altro canto permette di avere un prodotto aderente alle aspettative del cliente (cioè non obsoleto) e privo di bachi. B) Risorse vengono messe a disposizione di un progetto persone con elevate competenze (overskilling) rendendo così più facile realizzare integrazioni e modifiche nel corso del progetto. L’overskilling comporta un costo aggiuntivo dovuto alle maggiori competenze allocate al progetto che però è più che controbilanciato dai tempi dei costi risparmiati per introdurre le successive modifiche dovute per esempio ad innovazioni. C) Architettura Modulare l'architettura di un prodotto o di un servizio è dato dall'insieme delle sue parti e delle logiche attraverso cui esse interagiscono. Nell'architettura modulare ogni componente svolge una sola funzione (il componente viene detto modulo) e ciò aumenta la flessibilità nella gestione del progetto. I vantaggi sono molteplici e interessano sia la progettazione, sia la produzione, la logistica, il servizio postvendita, ecc. Grazie quest'architettura, qualora si volesse modificare una funzione in fase avanzata dello sviluppo, sarebbe necessario agire su una solo modulo lasciando gli altri invariati. Questa tipologia di architettura inoltre agevola la modifica
anche nelle fasi finali riducendo il tempo è il costo della riprogettazione. Non bisogna dimenticare però che i costi derivanti da tale scelta possono essere fino al 20% più alti a causa della maggior richiesta di tempo e risorse per la definizione dell'architettura. Organizzazione di progetto I progetti sono finalizzati al raggiungimento di obiettivi specifici e prevedono la messa in opera di un insieme di attività necessarie a realizzare l'output. È necessario quindi identificare una struttura organizzativa specificamente incaricata di realizzare il progetto. Il coordinamento risulta molto spesso critico a causa della collaborazione e integrazione tra funzioni organizzative differenti. Scelta Della Forma Organizzativa : dato che non esiste un unico modello organizzativo a validità generale, è necessario scegliere un'organizzazione coerente con le problematiche da gestire con le caratteristiche del contesto di progetto. Dato che l'azienda dispone già di una vera e propria struttura organizzativa consolidata, non conviene modificarla ogni volta venga avviato un nuovo progetto, ma ci si limita a introdurre le integrazioni appropriate caso per caso. Tre configurazioni principali: 1) Organizzazione Funzionale il progetto viene scomposto in sottoprogetti ed ognuno è assegnato a una specifica funzione dell'impresa. I sottoprogetti sono svolti da personale assegnato a tempo parziale a quell'attività e la loro responsabilità è affidata ai manager funzionali. All'inizio del progetti i responsabili funzionari sviluppano assieme il piano e identificano i sottoprogetti di cui ognuno di loro si occupa separatamente; periodicamente si ritroveranno a integrare risultati e a verificare lo stato di avanzamento. Punti Di Forza: - semplice da gestire - efficacia nell'uso delle risorse Punti Deboli : - problemi di coordinamento e di orientamento al risultato - scarsa efficacia progettuale 2) Organizzazione Task Force viene nominato un PM responsabile del progetto, il quale risponde direttamente al committente. Le risorse sono assegnate a tempo pieno per tutta la durata del progetto e rispondono solo al PM. Si viene quindi a creare una sorta di unità organizzativa autonoma ma temporanea (al termine del progetto la TF si scioglie). Punti Di Forza: - il PM e le risorse sono esclusivamente focalizzate sul progetto - team fortemente coeso e non soggetto a interferenze di altre attività - facilità di coordinamento e forte orientamento al risultato Punti Deboli : - dispendiosa in termini di duplicazione di risorse - inefficienza nei tempi morti del progetto - distacco dei membri del team delle funzioni di appartenenza (perdita di contatto rispetto agli sviluppi nelle proprie discipline di riferimento) - problemi di gestione delle risorse umane al momento dello scioglimento 3) Organizzazione A Matrice entrambi i casi precedenti mostrano un problema nell'equilibrio fra l'obiettivo di lungo termine delle unità specialistiche (accrescimento conoscenza tecnica) e gli obiettivi di breve termine dei singoli progetti. La struttura a matrice media tra queste due situazioni. Come nella TF viene nominato un PM che può essere parzialmente o totalmente responsabili degli obiettivi. I membri del team non vengono staccati dalle funzioni di appartenenza, ma vengono assegnati al progetto solo per una porzione di tempo. Nella matrice di timo possono essere organizzati in modo trasversale rispetto le funzioni e quindi avremo team interfunzionali e multidisciplinari. Punti Di Forza: - orientata al risultato senza compromettere l'efficienza delle risorse (le risorse continueranno a lavorare nelle loro funzioni per il tempo non impegnato nel progetto) Punti Deboli : - complessità di gestione a causa dei conflitti tra PM e responsabili funzionari sulle modalità e le priorità nell'accedere alle risorse e sulle scelte progettuali - il PM responsabile dei risultati ma non ha una autorità completa per agire sulle risorse
- i membri del team continuano a risentire dei disturbi provenienti da altre attività 4) Soluzioni Intermedie A) Matrice Debole non vengono modificati, se non marginalmente, i ruoli e poteri della struttura organizzativa aziendale. Il PM ha responsabilità limitata sui risultati da ottenere; si limita a facilitare i rapporti tra le unità organizzative coinvolte nel progetto e nel sollecitare il rispetto delle scadenze concordate. Il PM può seguire più progetti contemporaneamente. B) Matrice Forte Il PM ha un potere decisionale maggiore ed è direttamente responsabile di tutte le prestazioni di progetto ed ha il controllo sull’utilizzo delle risorse anche se queste rimangono all’interno delle proprie unità funzionali. Il PM è concentrato su un unico progetto. C) Matrice Mista o Bilanciata Il PM assume un ruolo di coordinatore e pianificatore delle risorse con la possibilità di negoziare l’uso delle risorse con i responsabili funzionali.
Condizioni Di Applicazione 1) Rilevanza Del Progetto in un progetto particolarmente importante per l'impresa, per il quale non è ammesso commettere errori, che può influenzare drammaticamente le performance dell'impresa, risulta preferibile adottare una struttura forte; gli obiettivi funzionali vengono posti in secondo ordine rispetto a quelli di progetto su cui si devono concentrare l'attenzione e gli sforzi dell'organizzazione. La rilevanza (economica e strategica) del progetto rende anche giustificata l'allocazione in modo esclusivo di risorse al progetto, cosa invece più difficile da accettare di fronte a progetti poco importanti. 2) Criticità Degli Obiettivi l'elevata criticità degli obiettivi di progetto impone la preferenza per una struttura forte. Il termine di un progetto spesso coincide con eventi non controllabili (fiere, lancio di prodotti concorrenti) e in tale situazione terminare il progetto poco prima o poco dopo la data prevista può avere impatti molto diversi sul successo del progetto. In caso di progetto su commessa la consegna oltre termine obbliga al pagamento di onerose penali 3) Novità Del Progetto progetti caratterizzati da una notevole ripetitività possono essere gestiti in modo sufficientemente efficace dalla struttura funzionale dell'impresa o da una struttura a matrice debole. Laddove invece il progetto presenti novità importanti è preferibile virare verso una struttura forte per diversi motivi; uno di questi è che operando in maniera del tutto nuova si eviterà il rischio di limitarsi ad applicare solo soluzioni affermate e consolidate a un progetto che per la sua novità richiede invece soluzioni particolari. Fattori Da Considerare Nella Scelta Del Modello Organizzativo 1) Contributo Del PM Al Progetto l'adozione di una struttura forte richiede di poter disporre di un PM in grado di governare il progetto dotato delle competenze manageriali tecniche necessarie.
2) Rilascio Delle Risorse Al Termine Del Progetto al termine del progetto le risorse rientrano nelle loro unità organizzative di appartenenza; la permanenza, anche se temporanea, fuori dalla propria funzione può rendere difficile il reinserimento, a fronte di cambiamenti intervenuti nel frattempo in fatto di procedure aziendali o di assegnazione delle mansioni. Coloro che rimangono nella funzione sviluppano una crescita della conoscenza specialistica mentre chi lavora la task force aumenta la propria conoscenza trasversale su altri campi di applicazione; crescita conoscenza trasversale >>> crescita conoscenza specialistica. 3) Sistemi Valutazioni Performance nel caso di strutture forti la responsabilità risulta in capo al PM mentre in quelle deboli la responsabilità è del responsabile funzionale. Nel caso di soluzioni miste la valutazione più complessa e rende necessario creare sistemi di rapporti per il controllo dei consumi delle risorse; vengono stilati dei time sheet periodici relativi al tempo speso da parte di ciascun individuo nelle singole attività (così viene tracciato il contributo delle funzioni al progetto). L'applicazione risulta semplice in teoria ma in pratica è molto più complessa a causa del tempo necessario richiesto per la compilazione e per la discrezionalità nell'attribuzione del proprio tempo da parte delle risorse. Definizione dei ruoli 1) PM è responsabile del raggiungimento degli obiettivi specifici del progetto, garantisce l'integrazione tra le diverse parti e risolve problemi che eventualmente si generano durante lo sviluppo. Nelle strutture deboli ha un controllo limitato sul progetto ed è tipicamente focalizzato sulla pianificazione il controllo; si occupa di concordare con le risorse il loro contributo per portare a compimento le diverse attività e ne facilita il coordinamento. In questo caso il PM non ha un controllo sulle risorse, compito che svolto direttamente da responsabili funzionali; inoltre non gestisce gli aspetti tecnici del progetto che rimangono affidati alle unità funzionali. Nel caso di strutture forti il PM ha un controllo diretto sulle scelte di progetto; gestisce direttamente le risorse, negoziandone l'utilizzo con i responsabili funzionali, ai quali compete comunque la decisione su quali risorse da allocare a fronte delle richieste del PM. Inoltre il PM gestisce la pianificazione il controllo delle attività e per questo ha solitamente un livello di competenze tecniche sufficienti relativamente allo scope di progetto. A) Autorità in relazione alle caratteristiche del progetto è opportuno conferire al PM un certo grado di autorità. L'autorità formale del PM dipende da diversi fattori: dalla posizione gerarchica del livello organizzativo cui è collocato il PM stesso, dai poteri a lui delegati dalla direzione, dal livello gerarchico della committenza a cui riferisce (es. se riferisce all'amministratore delegato la sua autorità sarà elevata) e dal suo coinvolgimento nei sistemi di valutazione delle risorse. L'autorità conferita ad essere commisurata alle responsabilità del PM. B) Autorevolezza condiziona la capacità del PM di influenzare e motivare le risorse nello svolgimento del loro compiti. Essa dipende innanzitutto dalle sue competenze tecniche, che devono essere tali da renderlo credibile agli occhi dei suoi collaboratori nel prendere le decisioni necessarie nel corso del progetto. Dipende inoltre dalle sue competenze gestionali (capacità di indirizzare coordinare e controllare le attività e le risorse) e da ultimo dipende dal suo stile di leadership, ovvero dalla sua capacità di motivare le persone al massimo. Autorevolezza costituisce una caratteristica personale non facilmente modificabili nel breve termine. È molto importante che entrambe queste caratteristiche siano bilanciate e commisurate al tipo di ruolo affidato al PM, per evitare che insorgano difficoltà ed egli non riesca a svolgerlo adeguatamente.
2) Functional Project Leader nel caso di progetti di grosse dimensioni diventa difficile per il pm assicurarne direttamente il coordinamento e la supervisione; in questi casi viene affiancato dai FPL, ovvero dei tecnici afferenti a diverse unità organizzative incaricati di gestire, su delega del PM, porzioni importanti
dell'attività di progetto (di solito hanno la responsabilità di una specifica unità organizzativa come progettazione, produzione, acquisti). In altri termini il FPL è un PM operativo focalizzato su una specifica funzione o su un particolare sottoinsieme di attività. 3) Risk Manager supporta il PM nell'identificazione nella gestione dei fattori di rischio associati al progetto; verifica che la gestione del rischio sia coerente con la specifica tipologia di progetto (esame di tutte le aree di rischio rilevanti e verifica delle azioni correttive richieste) 4) Contract Manager supporta il PM nel gestire in modo giuridicamente corretto i differenti aspetti del progetto, in particolare monitorando le varie attività alla luce dei vincoli e degli obblighi, definiti nel contratto, verso il cliente e verso possibili altri partner (licenze, penali, ecc.) 5) Responsabili Funzionali hanno il compito di gestire le risorse le attività di loro competenza dedicate al progetto. Il loro ruolo è strettamente legato a quello del PM: al crescere del "peso" del PM diminuisce quello dei responsabili funzionali. Rimangono comunque di pertinenza delle funzioni tutte le attività di sviluppo delle risorse e il presidio delle competenze funzionali stessa.
PIANIFICAZIONE Innanzitutto sia la pianificazione dello scope di progetto e tale attività permette di creare la lista delle attività che devono essere svolte cioè la WBS (Work Breakdown Structure). In modo parallelo è necessario definire un piano delle risorse disponibili sul progetto (OBS Organizational Breakdown Structure). L'unione di queste due “viste” viene effettuata tramite la RAM (Responsabilty Assignment Matrix) che permette di ottenere il mattone di base del processo di pianificazione, costituito del Control Account, cui è possibile associare tempi, costi e rischi. La successive integrazioni tutte queste informazioni generate al livello di progetto complessivo permettere pianificazione del tempo di progetto (Schedule), del suo costo (Budget) e della visione sinottica di essi (Baseline). Gestione Dello Scope Lo scope è dato dall'insieme di prodotti, servizi e risultati che devono essere forniti come output di un progetto. La gestione dello scope è definita come sotto processo che assicura che il progetto includa tutto il lavoro richiesto e solo il lavoro richiesto per completare il progetto con successo. L'input principale è dato dal project charter validato durante la fase di inizializzazione. Il processo di gestione dello scope l'obiettivo di garantire la realizzazione di quanto richiesto dal cliente, interno o esterno che stia, evitando però di realizzare più di quanto richiesto, per non incorrere i maggiori tempi e costi di progetto. Fasi fondamentali: A) Pianificazione Dello Scope questa fase l'obiettivo di definire come lo scope sarà gestito verificato e controllato e come sarà realizzata la WBS di progetto e come sarà verificata la completezza. B) Definizione Dello Scope in questa fase tutte le richieste degli stakeholders vengono analizzati convertiti requisiti, grazie allo sviluppo del cosiddetto scope statement. Questo è un documento che descrive cosa il progetto voglia realizzare in modo sufficientemente dettagliato. Il ruolo di questo documento e quindi chiarire cosa il cliente e gli altri stakeholders si aspettano dal progetto. Info contenute: -Obiettivi Del Progetto (descrizione degli obiettivi specifici del progetto dei fattori che hanno motivato il suo sviluppo) -Descrizione Dell'Output (prescrizione tecnico sistemica della soluzione proposta di come questa rispetta gli obiettivi specifici) -Deliverable (output tangibili o assimilabili che il progetto realizzerà durante il suo sviluppo) -Criteri Di Completamento (criteri che permettono di accettare i deliverable generati e quindi di proseguire nelle fasi successive) -Vincoli Di Progetto (vincoli associate al progetto in termini di persone, risorse, attori da coinvolgere, attrezzature) -Misure Di Successo (parametri di prestazione che sono dotati per valutare il successo del progetto sia internamente sia verso il cliente) -Ruoli E Stakeholders Principali Linee Guida E Approccio (linee guida in fatto di outsourcing e di interazione con il cliente) -Stime Preliminari Di Tempi E Costi -Sistemi Di Controllo -Autorizzazioni C) Creazione WBS in questa fase sono identificate tutte le sole attività necessarie al raggiungimento degli obiettivi di progetto. Il processo di costruzione della WBS si basa sulla scomposizione gerarchica che consente di identificare gradualmente le attività elementari di progetto a partire dai deliverable concordati con il cliente e gli altri stakeholders di progetto. D) Verifica Dello Scope in questa fase viene l'approvazione formale dei deliverable di progetto da parte di tutti gli stakeholders. La verifica dello scope richiede quindi momenti di revisione intermedi in cui l'output di progetto viene gradualmente approvato permettendo lo sviluppo del progetto stesso nelle diverse fasi del suo ciclo di vita. A chiusura di questa fase coincide con la pianificazione definitiva dello scope di progetto. E) Controllo Dello Scope a valle delle fasi di pianificazione si attiveranno le attività di controllo dello scope durante lo svolgimento del progetto, grazie alle quali saranno gestiti tutti i cambiamenti di esso e gli impatti sul progetto. Creazione della WBS la WBS è uno strumento che, attraverso una logica gerarchica, decompone in modo sistematico il progetto in aggregati di attività sempre più piccoli, fino ad arrivare ad identificarne le attività e i pacchetti di lavoro elementare. L'obiettivo della WBS è quello di supportare la definizione del lavoro necessario per ottenere un determinato risultato, illustrando parallelamente la struttura gerarchica dei
deliverable di progetto. La costruzione richiede lo svolgimento di un processo iterativo fatto per approssimazioni successive; a partire da una identificazione delle macro attività principali, tali micro attività sono a loro volta suddivisi attività più semplice ricorrendo all'organizzazione di progetto è quindi utilizzando competenze specifiche per ogni macro attività. Ogni elemento della WBS è chiamato WBE (Work Breakdown Element) mentre nel caso del livello più basso della WBS tale elemento viene comunemente chiamato Work Package (WP). Esistono ovviamente diverse logiche con cui disaggregare le attività di un progetto. Ad esempio si ha la scomposizione in base alle parti fisiche che costituiscono un certo deliverable, oppure quella in base alle fasi necessarie per realizzarlo o in base a rilasci progressivi dell'output, ecc. l'obiettivo prima della segmentazione del progetto è quello di semplificar nella gestione, limitando al massimo la perdita di integrazione. Occorre identificare, ciascun livello, insieme di attività che, all'interno dell'aggregato, siano tra loro fortemente interconnesse. Ciò è finalizzato a ridurre problemi di coordinamento. Inoltre occorre evitare ridondanze. È opportuno adottare sempre un'unica logica di disaggregazione per ogni nodo della WBS. Linee Guida: A) ogni WBE può essere ulteriormente segmentato usando una sola logica di scomposizione (logiche diverse possono essere usate per livelli differenti o per altri nodi sullo stesso livello) B) la profondità (intesa come numero di livelli) della WBS dipende dalle dimensioni e dalla complessità del progetto ed a livello di dettaglio necessarie per pianificarlo C) ad ogni livello, ciascun WBE deve deve poter essere chiaramente definite in termini di responsabilità D) all'interno della WBS devono essere presenti tutti i deliverable (esterni interni) di progetto E) insieme di tutti i WBE di un livello della WBS deve scrivere l'intero progetto F) la struttura della WBS indipendente da qualsiasi legame temporale. Le sequenze logiche su un problema di pianificazione temporale (scheduling) ed esulano dagli obiettivi della WBS. Controllo Dello Scope dal momento di inizio del processo di controllo dello scopo può essere possibile che avvengano cambiamenti significativi nel tempo; vi possono essere numerosi fattori che portano a cambiamenti di scope di progetto A) Scope Creep si intendono tutte quelle situazioni in cui un cambiamento del progetto fronte di richieste del cliente, che comportano la realizzazione di lavoro non previsto nel piano iniziale. Capita spesso quando le richieste iniziali del cliente non sono chiare, ma soprattutto quando, durante il progetto, non vi sono opportuni momenti di congelamento delle specifiche con il cliente. Il problema è che in molti casi tali modifiche impattano sulle altre prestazioni di progetto (tipicamente i tempi e costi di realizzazione), ma non si provvede o non si riesce a ribaltare tali effetti sull'cliente, che continuerà ad aspettarsi l'output concordato nei tempi e con i costi definiti. Questo fenomeno difficilmente si manifesta con grande significativi cambiamenti ma come una sequenza ininterrotta di piccoli cambiamenti (l'impatto di ognuno dei quali probabilmente minimo, ma la loro somma molto significativa) B) Scope Gold Plating in questo caso si alla realizzazione di lavoro aggiuntivo che porta sviluppa le funzionalità o a erogare prestazioni che il cliente non richiede e a cui non attribuisce un valore specifico. Anche in questo caso dell'impossibilità di ribaltare gli impatti sui tempi e sui costi di progetto sul cliente; spesso tale fenomeno si verifica a causa di una non chiara definizione interna delle attività da svolgere e a fronte di una descrizione non dettagliata dello scopo di attività elementari. Questo fenomeno solitamente è causato direttamente dall'impresa che gestisce il progetto, spesso dalle funzioni tecniche, che nella ricerca dell'ottimizzazione realizzano più di quanto richiesto dal cliente. Gestione Scope Change e necessario definire un processo di gestione monitoraggio dei cambiamenti di scope al fine di limitare i fenomeni visti. Tale processo è costituito da cinque fasi fondamentali: A) Identificazione e Documentazione ogniqualvolta si presenta necessità o richiesta di una modifica, è necessario documentare tale richiesta, citandone la fonte e la motivazione. B) Condivisione E Approvazione Interna la richiesta deve essere condivisa all'interno del team di progetto in quanto il lavoro degli altri membri del team potrebbe subire modifiche a causa della richiesta.
C) Validazione Da Parte Del Cliente la richiesta di cambiamento deve essere valutata in termini di fattibilità, impatti sui tempi, costi e rischi di progetto deve essere richiesta al cliente una autorizzazione a procedere al cambiamento. D) Aggiornamento Della Pianificazione una volta autorizzato il cambiamento da parte del cliente, deve essere aggiornata la WBS di progetto e quindi a cascata anche i tempi, i rischi, l'organizzazione, i costi, ecc. E) Autorizzazione è necessaria la forma autorizzazione a procedere con il cambiamento da parte della committenza di progetto. Organizzazione Di Progetto Di Allocazione Delle Responsabilità Una volta definita la tipologia di strutture da adottare per uno specifico progetto, identificate le funzioni coinvolte ed eventualmente le risorse assegnate al progetto, tali informazioni vengono sintetizzate mediante la OBS (Organization Breakdown Structure) che di fatto è un organigramma del progetto, volta individuare tutti gli attori coinvolti e a definire la struttura di governo. Il PM supervisione del progetto complessivo che coordina il progetto al livello dei Functional Project Leader i quali sono responsabili di coordinare le proprie risorse nello svolgimento del loro pacchetti di lavoro. Strumento che supporta il disegno mentre più di dettaglio del progetto, tramite l'allocazione delle risorse alle attività e la definizione del loro ruolo, è la cosiddetta RAM (cioè la Responsability Assignement Matrix). Si tratta di una schiera amatrice, che riporta sulle righe le diverse attività (ad esempio i work package derivanti dalla WBS) e sulle colonne le unità organizzative, ai diversi livelli della struttura aziendale, coinvolte a vario titolo nel progetto. All'incrocio tra unità organizzativa e le attività si definiscono il ruolo svolto nel progetto e relativo livello di responsabilità esistono diversi tipi di codifica per identificare le responsabilità e il tipo di contributo richiesta ad ogni unità organizzativa (responsabile, di supporto, consulente, informato, colui che firma, coliche verifica, colui che approva) Control Account Il control account è definito come il blocco di controllo manageriale cui possibile attribuire uno scope specifico e delle stime di tempo, costo e il rischio. È definito dall'incrocio tra la descrizione dell'elemento di WBS (cioè il WBE) da svolgere e le risorse allocate a tale WBE derivante dalla OBS. Risulta dunque evidente come la RAM descritta sia uno degli strumenti principali per la definizione di un control account. Il control account e quindi, da un lato, il blocco informativo principale per la pianificazione di un progetto e, dall'altro, è anche l'unità di analisi principale del processo di controllo. Aggregando i costi dei singoli CA, si otterrà il costo totale di progetto; aggregando i tempi dei singoli CA, si otterrà il tempo totale di progetto (bisogna tenere conto delle precedenze logiche tre pacchetti di lavoro); aggregando le stime dei dischi dei singoli CA si otterrà il rischio totale di progetto (mediante opportuni calcoli statistici). Il processo che permette di allocare a un control account una stima dei tempi dei costi e un processo complesso dato che il tempo e il costo di una attività non sono caratteristiche intrinseche dell'attività stessa (lo stesso WBE potrebbe avere tempi e costi differenti a seconda delle risorse assegnate). Il processo di definizione della durata, e quindi del costo, di un control account è composto da diversi passi: A) Definizione Dell'Output Del Control Account (in modo tale da permettere l'identificazione delle risorse necessarie e quantificare il lavoro) B) Allocazione Risorse (quante e quali risorse assegnare al control account) Durata CA = (Lavoro Necessario*Fattori Correttivi)/(Produttività*Risorse Allocate) Il parametro di produttività dipende dalla reale livello di competenza delle risorse e dalla loro esperienza nello svolgimento di attività simili (ricavato attraverso analisi storica delle passate performance delle risorse); i fattori correttivi sono dovuti alle diseconomie organizzative che si vengono a creare quando l'allocazione di più risorse alla stessa attività genera la necessità di un'attività di coordinamento per il cui svolgimento è necessario tempo addizionale. Costo CA = sommatoria dei costi di tutte le risorse * Durata CA
Così calcolato il costo tiene conto solo delle risorse interne; adesso andranno aggiunti i costi relativi ad esempio gli acquisti di beni e servizi necessari per lo svolgimento delle attività. Considerazioni: A) non sempre la durata dell'attività può essere ridotto aumentando le risorse allocate poiché alcune attività hanno delle durate minime sotto le quali non è possibile scendere; B) l'aumento del numero di risorse può comportare anche delle diseconomie organizzative a causa dell'aumento delle attività di coordinamento necessarie; C) alcune attività non possono poi essere suddivise su più risorse perché costituiscono un tutt'uno non separabile. Anche la pianificazione dell'allocazione delle risorse la gestione delle risorse umane impattano notevolmente sulla definizione del tempo di costo, in quanto bisogna tenere in considerazione che la stessa risorse non potrà essere impiegata tempo pieno su due distinti CA contemporanei. Pianificazione dei tempi Questa fase l'obiettivo di definire la distribuzione temporale delle attività (WP) e delle scadenze (milestone). L'input fondamentale, anche se non unico, per lo sviluppo dello schedule di progetto sono le stime di tempo dei CA. A partire da questi, lo sviluppo dello schedule di progetto richiede di operare seguenti passi: A) definire la sequenza logico/temporale e le relazioni tra le attività di progetto (tecniche reticolari chiusa parentesi e gestire l'incertezza sulla stima dei tempi per attività nuove (analisi PERT) B) definire il crono programma (tramite diagramma di Gant) C) verificare la fattibilità del piano dal punto di vista delle risorse utilizzate (logiche di resource levelling) D) ottimizzare il piano generato (tecnica del Critical Path Method) Tecniche Reticolari Conoscere la durata dei singoli WP non è sufficiente per conoscere la durata dell'intero progetto, in quanto alcuni dei WP potrebbero essere svolti in parallelo. E necessario quindi esplicitare e analizzare le relazioni logico temporali tra le differenti attività di progetto: - Relazione Fine/Inizio (l'inizio di un'attività richiede che una o più attività siano terminate) - Relazione Inizio/Inizio (l'inizio di un'attività è vincolato all'inizio di un'altra) - Relazione Fine/Fine (due o più attività sono vincolate terminare allo stesso momento). Le tecniche reticolari derivano il loro nome dal fatto di rappresentare il progetto con una rete (o reticolo), in cui ogni nodo rappresenta l'attività di progetto. I nodi sono collegati d'archi orientati che rappresenta le relazioni di precedenza tra le diverse attività. Le tecniche reticolari permettono di definire lo slack di ogni attività cioè la quantità massima di ritardo che l'attività può subire senza impattare sulla durata dell'intero progetto. Le attività che avranno slack = 0 saranno dette attività critiche mentre le altre saranno definite attività non critiche. Con percorso critico si intende una sequenza di attività critiche che portano dall'inizio alla fine del progetto. Il calcolo dello slack può essere eseguito tramite la caratterizzazione dell'attività in base a quattro istanti differenti: A) Early Start rappresenta il primo momento in cui una data attività può iniziare rispettando i vincoli di precedenza assegnati; l'attività potrà iniziare al più presto solo dopo la fine dell'ultima delle attività che la precedono logicamente. B) Late Start rappresenta il momento entro cui una data attività deve iniziare affinché il progetto non subisca ritardi; si calcola dati l'istante al più tardi in cui l'attività può finire senza comportare ritardo al progetto e la sua durata. C) Early Finish rappresenta il primo momento in cui l'attività può terminare dati i legami di precedenza; si ricava dati l'istante di inizio al più presto di un'attività e la sua durata. D) Late Finish rappresenta il momento entro cui una data attività deve terminare affinché non comporti ritardi all'arresto del progetto; l'attività dovrà finire al più tardi precedentemente all'inizio della prima delle sue attività successive; Slack = LS – ES = LF – EF
Le tecniche reticolari sono strumento basilare per la pianificazione dei progetti anche se hanno ovviamente dei limiti. Il principale di questi è che esse considerano la durata dell'attività con una variabile deterministica. Vi sono però molti casi in cui il calcolo della durata di un'attività risulta difficile incerto (esempio quando il grado di incertezza e molto altro). Quindi le tecniche reticolari non permettono di analizzare il piano di progetto in termini di robustezza rispetto all'incertezza connessa lo svolgimento delle attività. PERT (Project Evalation and review technique) Con il PERT si integrano le tecniche reticolari con la valutazione probabilistica delle durate delle attività. In primo luogo, si assume che la durata di un'attività presenti un andamento probabilistico secondo la distribuzione beta. Inoltre si assume che lo scostamento della durata reale di un'attività del suo valore atteso sia indipendente dallo scostamento delle altre attività del loro valore attesi. In base alla prima assunzione è possibile definire un valore medio (Durata Attesa) e una deviazione standard della durata di un'attività. Ciò è possibile individuando tre grandezze: - Durata Ottimistica (A) che corrisponda la minor durata necessaria per eseguire l'attività sotto l'ipotesi che tutto proceda al meglio; - Durata Pessimistica (B) corrisponda la maggior durata possibile per l'esecuzione dell'attività nell'ipotesi che tutto proceda nel peggiore dei modi; - Durata Più Probabile O Modale (M) corrisponda alla durata che più probabilmente sarà necessario per svolgere tale attività. Durata Attesa = (A+4M+B)/6 Deviazione Standard = (B-A)/6
Sull’intero progetto è possibile calcolare la durata attesa come la somma delle durate attese delle attività che lo compongono. È possibile inoltre effettuare alcune analisi sulla robustezza del piano utilizzando la deviazione standard di progetto calcolata come la radice delle deviazioni standard delle attività sul cammino critico al quadrato; questo valore permette di valutare quanto la durata attesa del progetto sia una stima affidabile. Un secondo aspetto utile all'analisi del piano è il concetto di sub criticità. Nel caso di un'attività con slack atteso positivo, quest'ultima può essere potenzialmente problematica; se un'attività ha uno slack atteso che sommato alla durata attesa porta un valore che è inferiore alla durata pessimistica, è possibile che l'attività diventi critica andando a impattare sulla durata dell'intero progetto. Quindi un'attività subcritica è un'attività che non è critica in termini di valore attesi ma che presenta una probabilità anche minima di diventare critica. SC = B – DA – SL. Se SC<0 allora lo slack che tale da consentire una protezione anche nel caso peggiore di durata pessimistica e quindi l'attività non potrà mai diventare critica. Se SC>0 l’attività è subcritica e quindi esiste la possibilità che l'attività diventi realtà critica. Diagramma di Gantt è sicuramente lo strumento più utilizzato per la descrizione del pianificazione temporale di progetto. Le sue caratteristiche predominanti sono la semplicità e la leggibilità. Il diagramma si basa su due assi ortogonali:
lungo l'asse verticale sono elencate tutte le attività nelle quali è stato scomposto il progetto, mentre sull'asse orizzontale compare la variabile temporale. Ciascuna attività viene rappresentato da una barra orizzontale il cui posizionamento è determinato dalla data di inizio prevista e la cui lunghezza rappresenta la durata stimata in sede di previsione. Sul diagramma verranno indicate in maniera diversa e le attività critiche da quelle non critiche ed inoltre verranno indicate anche le milestone. Infine sono esplicitate le relazioni di precedenza e sono riportate le linee continue in grassetto che indicano il reale istante di inizio fine dell'attività già svolte per favorire il confronto con quanto è stato pianificato. Limiti: A) nel caso di progetti complessi la lettura del diagramma può essere molto complicata, in quanto le relazioni di precedenza possono essere non chiaramente leggibili B) non sono chiaramente visibili gli slack delle diverse attività; quindi non è possibile valutare l'impatto dei rischi sulla pianificazione temporale dato che non è possibile evidenziare per l'attività non critiche l'entità dei loro slack. C) lo strumento pone l'enfasi esclusivamente sulla distribuzione temporale del progetto e non considera direttamente i costi associati alle attività (quindi non è possibile effettuare il controllo dei costi di progetto delle risorse)
Resource Levelling il piano temporale sviluppato fino ad ora, che tiene solo in considerazione l'le attività da svolgere, le loro relazioni logiche e la durata, potrebbe comportare dei problemi di fattibilità gestionale infatti potrebbero determinarsi delle sovra allocazioni di risorse e dunque la non fattibilità del piano poiché, nonostante aver tenuto conto della disponibilità di partenza le risorse, non è stato possibile considerare il carico derivante dalle varie attività. Per sovraallocazioni s'intende che la risorsa sarà impegnata su più di un'attività in parallelo per una quantità superiore alla reale disponibilità (ciò comporterebbe certamente dei ritardi a causa della non corretta pianificazione). E’ dunque opportuno effettuare un controllo sulla reale fattibilità gestionale del piano stesso utilizzando il diagramma delle risorse, ossia uno strumento che verifica, per ogni unità temporale di riferimento, le allocazioni di una risorsa su differenti attività di progetto normalmente calcolati in percentuale sulla risorse disponibile. Nel caso in una certa unità temporale la risorse si allocata per una percentuale superiore al 100% è necessario effettuare il resource levelling. Vi sono due possibilità distinte: la prima è di aumentare le risorse di progetto, per esempio aggiungendo una nuova risorsa (spesso tale soluzione percorribile) mentre la seconda è di evitare di far svolgere più attività in parallelo da parte di quelle risorsa nell'unità temporale in esame. Ciò di solito ha un impatto sul tempo di progetto che tende ad aumentare. Critical Path Method è un metodo euristico di analisi e ottimizzazione del piano di progetto basato sulle tecnologie reticolari. Il CPM si basa sul fatto che spesso esiste un trede-off molto forte fra i tempi e i costi associati all'attività di progetto. Infatti è spesso possibile variare la durata di un'attività (e quindi di un progetto) variando la quantità o la tipologia di risorse quest'allocate, e quindi anche il suo costo. Il CPM analizza gli effetti diverse ipotesi di allocazione delle risorse sulla durata del progetto, cercando un equilibrio tra costo è durata del progetto che meglio risponde agli obiettivi. Per modificare la durata di un progetto è necessario agire sul suo cammino critico in particolare su quell'attività critiche sulle quali si è maggiormente conveniente investire. Il CPM prevede lo svolgimento della seguente procedura iterativa: A) Identificazione Cammino Critico B) Selezione Delle Attività viene selezionata fra l'attività del cammino critico quella su cui risulta più conveniente agire al fine di contrarre i tempi di progetto (praticamente viene scelta l'attività con il rapporto ΔCosto/ΔTempo più piccolo). C) Confronto Dell'Aumento Marginale Di Costo Con Beneficio Marginale la riduzione del tempo di progetto deve essere associata con beneficio se il costo supera il beneficio non vale la pena ridurre la durata del progetto e l'applicazione del CPM può ritenersi conclusa. Condizioni di arresto iterazione: 1) i costi marginali necessari per ridurre ulteriormente la durata non sono giustificati dei benefici marginali che la riduzione permette di ottenere. 2) non è più possibile ridurre
ulteriormente alcuna attività di progetto in quanto le risorse sono state utilizzate tutte alla loro massima capacità. 3) si creano diseconomie organizzative. Pianificazione dei Costi Anche per il costo, gli elementi di base della pianificazione sono i control account. Il costo di progetto, calcolato tramite l’aggregazione e l’integrazione di dati relativi ai singoli CA, deriverà dalle risorse consumate per svolgere le attività richieste. Approcci per stimare il costo di un control account: stima analitica, stima logica, stima paramedica. La stima analitica consiste in una stima dettagliata dei costi basata sull'analisi puntuale delle risorse necessarie per ogni attività. Il vantaggio principale consiste nell'elevata accuratezza mentre lo svantaggio principale è rappresentato dei tempi e costi di formulazione delle stime. In particolare nelle prime fasi di progetto si utilizzano metodi più rapidi ma meno precisi. Il secondo metodo è la stima analogica: è un metodo più rapido e non utilizza stime basate sull'analisi puntuale ma piuttosto sull'esperienza riferita ad attività simili eseguite per progetti precedenti. Il vantaggio principale è costituito dai tempi estremamente contenuti necessari alla formulazione a fronte tuttavia dell'elevata approssimazione delle stime. A metà strada troviamo le stime parametriche: sono basate su parametri oggettivi e di uso comune legati a delle particolari tipologie di risorse e di attività che permettono di fissare il costo unitario medio di particolari risorse. Il vantaggio principale è nell'ottimo compromesso tra velocità di esecuzione e accuratezza delle stime, mentre il principale svantaggio consiste nella sua limitata applicabilità; infatti può essere eseguita solo esclusivamente per le attività di tipo ricorrente e per le quali è possibile disporre di una dettagliata base di dati e costi sostenuti nel passato. Stima Analogica è necessario partire dalla WBS. Dato un WP, il team di progetto, avendo conoscenze specifiche e delle attività da svolgere, può redigere l'elenco dei fabbisogni di risorse (sia interne che esterne). Il calcolo del costo delle risorse interne si basa su una moltiplicazione del costo unitario per la quantità di impiego. Nel caso di risorse esterne, invece, il costo equivarrà al controvalore monetario della loro acquisizione. Questa visione di dettaglio permette di redigere Cost Breakdown Structure (CBS). La CBS è lo strumento che consente di analizzare i costi totali di progetto, aggregandoli per natura e non per attività. La CBS è rappresentabile attraverso un grafo ad albero: ha un solo nodo radice al più alto livello gerarchico che rappresenta il livello di aggregazione identificato con i costi totali di progetto; eccetto il nodo radice, ogni nodo rappresenta una categoria di costo distinta per natura e appartiene a una e una sola categoria di costo di livello superiore. I nodi appartenenti all'ultimo livello invece rappresentano i singoli item di costo. La matrice che si ottiene combinando la CBS e la WBS, permette di condurre l'analisi incrociate che evidenziano: A) procedendo per riga e mantenendo fisso un elemento della CBS, la distribuzione di ogni natura di costo sui singoli gruppi. B) procedendo per colonne e mantenendo fisso un WP della WBS, il budget di ogni WP, dettagliato per le singole nature di costo. La CBS permette di allineare la contabilità di progetto con la contabilità aziendale; infatti i costi sono considerati in relazione all'attività da svolgere ma a livello di conto economico aziendale i costi sono divisi per natura e non per progetto (o per attività di progetto).
VALUTAZIONE ECONOMICA FINANZIARIA Un progetto ha valore se e solo se si ritiene che esso nel futuro sarà in grado di generare flussi netti di denaro per l’impresa e per i suoi azionisti. Input Progetto: A) Input Correnti (cioè pagati e utilizzati subito): Lavoro - Prodotti e Servizi (es. materie prime) B) Input Pluriennali (non utilizzati completamente in un solo anno): -Tecnologie (es. royalties) -Infrastrutture (es. macchinari) Output Progetto: Prodotti e/o Servizi. Capitale Di Rischio all'azionista non viene garantito che venga ripagato del suo investimento Capitale Di Debito anche in caso di fallimento la banca si riprende il capitale investito più di interessi; più è alto il rischio sul progetto più è alto il tasso di interesse. Il valore di progetto è dato dalla differenza nel futuro tra il valore degli output e quello degli input più l'interesse del debito. Lettura Finanziaria Esborsi e Incassi (cioè Flussi di Cassa) Lettura Economica Costi (es. Ammortamenti) e Ricavi Ammortamenti Depreciation Incasso (i) = Ricavi(i) – CC(i) + CC(i+1) Crediti Commerciali Account Receiveable Esborso(i) = Cmake(i) + (Cbuy(i) – DC(i) + DC(i-1)) Debiti Commerciali Account Payable I crediti commerciali vengono calcolati solo sulla parte di Costo Buy!!! Ricavo Revenue Le due letture non sono alternative ma devono essere entrambe presenti considerazione; sempre nel lungo periodo le due ottiche coincidono. Nel breve periodo invece può accadere il contrario; ciò accade perché nel lungo periodo la nostra capacità di stime è minore il rischio di commettere errori è maggiore. Analisi Differenziale nell'analisi che svolgeremo (cioè per vedere se progetto genera valore) terremo in considerazione solo i costi e il cashflow che verranno generati dal progetto. Esempi di costi non differenziali: -costi affondati (già eseguiti prima del progetto) -costi non evitabili NCF = Incoming CF – Outgoing CF Pay Back Time è il momento temporale nel quale il NCF di progetto copre i costi iniziali di progetto. ΣPBT t=0 NCF(t) = 0 oppure CNCF(t)=0 con CNCF(i) = Σi t=0 NCF(t). Problema: abbiamo bisogno di un metodo per attualizzare i futuri flussi di cassa in modo tale da poterli comparare con i soldi spesi attualmente Net Present Value NPV(0) = ΣN t=0 NCF(t) / (1+r)^t cioè il valore attualizzato creato dal mio progetto calcolato con i flussi di cassa netti. Tasse vengono calcolati in base all’EBIT e quindi sulla visione economica del progetto; sono un flusso di cassa in uscita. Cash Out (i) = Direct Cost (i) – AP (i) + AP (i-1) + Investimento (i) + Tasse (i) Cash In (i) = Sales (i) (cioè fatture) – AR (i) + AR (i-1) NCF (i) = Cash in (i) – Cash Out (i) Calcolo tanti NCF, li sconto e poi li sommo! Ricavo l’NPV !! Revenue (i) = Total Invoice*(Direct Cost (i) + Depreciation (i)) / (Total Direct Cost (i) + Investimento) Σ Revenue (i) == Total Invoice !!! EBIT (i) = Revenue (i) – Direct Cost (i) – Depreciation (i) Tasse (i) = EBIT (i) * Tax Rate EVA viene calcolato al livello d'impresa nell'intero anno. Per calcolarlo e necessario conoscere il conto economico aziendale dell'anno (cioè i costi e ricavi annuali) e lo stato patrimoniale cioè l’attivo (che comprende tutte le risorse dell'impresa, i beni immobili, il capitale liquido e i crediti commerciali) e il passivo (i soldi impiegati dagli azionisti e i debiti commerciali). Per calcolare l’EVA del progetto ha bisogno del conto economico di progetto (cioè la contabilità) e lo stato patrimoniale di progetto. Quest'ultimo viene creato partendo da quell'aziendale includendo tutti gli assi sette che il progetto utilizza. Tutti questi parametri mi servono per calcolare il Net Invested Capital (NIC). Il NIC sarà dato dalla somma del Net Working Capital (NWC) e dai Fixed Asset (FA). Il NWC sarà costituito dal WIP (work in progress) + Inventory + AR – AP. Il WACC viene calcolato in base al passivo di stato patrimoniale.
ΔWIP (i) = Revenue (i) – Sales (i) WIP (i) = WIP (i-1) + ΔWIP (i-1) NWC (i) = WIP (i) + AR (i-1) – AP (i-1) NIC (i) = NWC (i) + FA (i) Se investo all’anno 1 FA(2)=Invest FA(3)=FA(2) - 1 quota ammort FA(4)=FA(3) – 1 quota ammort EVA (i) = EBIT (i) * (1 - TAX Rate) – NIC (i) * WACC Calcolo tanti EVA, li sconto e poi li sommo! NPV ed EVA devono venire uguali a fine progetto!!!! Come miglioro l’EBIT??? 1)Riducendo i Costi 2) Aumentando l’efficienza 3) Aumento i Revenue Come riduco il NIC??? 1) Ottenendo migliori condizioni di pagamento dai fornitori e dai clienti 2) Applicando ritardi senza rischio ad attività molto dispendiose BID / NO BID Forme contrattuali: A) Lump Sum il contratto contiene un prezzo tutto compreso (cioè anche servizi ulteriori). Tutti i rischi sono concentrati sull'azienda perché è necessario stare dentro al prezzo comunicato. Alti guadagni però. B) Unit Price tutti gli output hanno lo stesso prezzo oppure se il cliente acquista più di un tot di output il prezzo diminuisce C) Cost Plus Fee il cliente paga ogni fattura emessa dall'azienda e quindi deve monitorare con un sistema di controllo contabile l'andamento del progetto al fine di pagare il valore corretto. Al termine del progetto viene riconosciuto un bonus all'azienda (Fee). Dal caso A) verso quello C) il rischio si sposta dall'azienda verso il cliente. Il caso C) tratti tipico dei casi nei quali cliente considera nulla la possibilità di variazione di costo tra quello preventivato e quello finale. Il caso A) invece sarà quello nel quale il cliente considera alta la probabilità di variazione di costo e quindi decide di allocare tutto il rischio sull'azienda; in caso di variazioni di costo questo verrà scalato dal profitto dell'azienda.
