PIANIFICAZIONE
Cosa significa pianificare:
-Individuare in modo consensuale gli obiettivi del progetto ed i risultati che si intendono raggiungere.
-Prevedere lo sviluppo del progetto, così da poterne ottimizzare i tempi di realizzazione, i costi, la qualità,
l’utilizzo delle risorse disponibili.
Esempio di processo di pianificazione
-Dichiarazione dell’obiettivo di progetto.
-Articolazione dell’obiettivo di progetto in obiettivi specifici ad es. individuare con precisione i prodotti, i
servizi che devono essere realizzati.
-Individuare le attività che devono essere svolte per raggiungere gli obiettivi specifici.
-Precedenza tra le attività: identificare e documentare le interdipendenze logiche tra le varie attività
-Stima della durata delle attività.
- Individuare e delegare la responsabilità di ogni attività.
-Pianificazione delle risorse: assegnare a ciascuna attività le risorse necessarie e schedulare i compiti.
-Rappresentare nel tempo le operazioni che si devono eseguire.
-Stima dei costi e cost budgetting.
-Effettuare le valutazioni economiche.
-Effettuare la valutazione dei rischi
-Selezionare i criteri da applicare in fase di controllo.
Sintesi: cosa (Scomposizione in WBS), chi (Team di progetto(OBS)), come (Organizzazione risorse(WBS)),
quando(Programmazione reticolare),quanto(Cost Engineering), controllo(Earned-value)
Aspetti fondamentali del processo di project management:
1. Essere d’accordo (agree): essere d’accordo sui parametri del progetto, sugli obbiettivi, in cosa consiste il
successo del progetto e come si misurerà,
2. Allineare (align): che tutta l’organizzazione abbia compreso gli obbiettivi e contenuti del progetto e che
tutti operino nella stessa direzione, con priorità condivise
3. Prevedere: misurare l’avanzamento del progetto facendo previsioni e programmando azioni per
mantenere ciò su cui si è d’accordo e l’allineamento dell’organizzazione
definire i gol del progetto, bisogna pianificare il
progetto e durante l'esecuzione occorre verificare se sto soddisfacendo quello che avevo programmato,
raccogliere i dati che servono per performare ad esempio l’earned value method, poi se ci sono dei
problemi si possono fare delle revisioni e ripianificare ripetendo il loop. Se non ci sono problemi non devo
compiere più azioni perché significa che i valori per formati coincidono con i valori pianificati
Ruolo del Project Manager nella pianificazione del progetto:
-Assistere i membri del team project nell’elaborazione dei loro piani.
-Individuare i conflitti attuali o potenziali e farli emergere, per risolverli.
-Individuare i principali eventi d’interfaccia, cioè dove avviene il passaggio di responsabilità dall’uno all’altro
membro del team.
Pianificazione di dettaglio
-Successiva alla pianificazione generale.
-La pianificazione di dettaglio successiva alla pianificazione generale si innesta su di essa.
-Viene effettuata dal Project Manager assieme agli specialisti di pianificazione, di controllo e di funzione, ad
esempio nel PRINCE2 prima di iniziare ogni fase.
Significato dei termini
-Progetto: insieme di attività connesse tra loro da relazioni logiche, eseguite con risorse limitate, avente un
obiettivo ben determinato.
-Programma: un’iniziativa a lungo termine, di norma implicante più progetti correlati tra loro (i diversi
progetti possono avere tra loro un rapporto serie/parallelo) che sono gestiti in modo integrato per ottenere
benefici generali non ottenibili da un singolo progetto, aventi in generale una qualche finalità comune. In
alcuni contesti danno lo stesso significato di progetto.
-Portfolio: si riferisce a progetti, programmi, gestiti per raggiungere gli obiettivi strategici dell’Impresa. I
progetti o programmi del portafoglio potrebbero non essere interdipendenti o direttamente correlati. Per
esempio, una società di infrastrutture che ha l'obiettivo strategico di "massimizzare il ritorno dei propri
investimenti" può mettere insieme un portafoglio che includa un mix di progetti in petrolio e gas,
elettricità, acqua, strade, ferrovie e aeroporti. Tutti i progetti idrici possono essere raggruppati in un
programma di risorse idriche.
-Fase: parte del progetto caratterizzata dal raggiungimento di uno o più risultati (deliverable) concreti,
verificabili e ben definiti atti ad eseguire un controllo sull’avanzamento, in genere delimitate da milestone
(inizio, fine, phase gate, phase review, control gate)
-Work package: l’insieme di attività cui sono connesse le informazioni rilevanti per la creazione di uno o più
deliverable, contenente la descrizione del lavoro da svolgere, del prodotto/i, dei vincoli sulla realizzazione,
oggetto dell’accordo tra il Project Manager e il Team Manager che garantisce che il risultato potrà essere
realizzato con i vincoli imposti. Il lavoro definito al livello più basso della WBS per il quale il costo e la
durata sono stimati e gestiti.
-Attività: parte elementare di un progetto (work) ad elevato livello di dettaglio caratterizzato da una
descrizione, da una durata, da legami logici con altre attività, dal fabbisogno di risorse e da un risultato.
NB: La definizione di Work Package, task e attività può cambiare in funzione dell’ambiente di lavoro ed è
una decisione del PM, per es. una WP può essere suddivisa in attività oppure una task può essere suddivisa
in WP oppure un’attività in sotto-attività
-Risorse: personale, macchine, materie prime, servizi e qualsiasi entità necessaria per completare
un'attività.
- Project schedule: le date pianificate in cui saranno svolte le attività, la loro durata, le relazioni tra le
attività e le milestone, le risorse impegnate nelle attività (lo schedule del progetto è il migliore strumento
per gestire giorno per giorno le comunicazioni del progetto).
-Scheduling (schedule): processo attraverso la quale si crea il Project Schedule, che tiene conto dei vincoli
logici nonché della disponibilità delle risorse .
-Milestone: un punto di riferimento che segna un evento importante in un progetto, molte volte l’inizio o
la fine di una fase, è usato per monitorare l’avanzamento del progetto e anche prendere una decisione.
Generalmente una milestone è un’attività di durata zero.
-Deliverable (risultato): è un prodotto del lavoro che sia misurabile e verificabile come un rapporto sulla
fattibilità, un disegno di progetto, un prototipo. In alcuni casi possono essere output di processi del
Project Management, in altri casi prodotti finali del progetto o loro componenti (aereo, fusoliera).
PROJECT STAKEHOLDERS (Portatori d’interesse)
-Uno stakeholder è un individuo, gruppo o organizzazione, che può influenzare o essere influenzato da una
decisione, attività o risultato di un progetto.
-Gli Stakeholdes possono essere attivamente coinvolti nel progetto o avere interessi che possono essere
influenzati positivamente o negativamente dal progetto.
-Gli stakeholders, quando partecipano ad un progetto, hanno diversi livelli di responsabilità e autorità. Tali
livelli possono cambiare durante il ciclo di vita del progetto.
Esempi:
-Project Team: Project Manager, Project Management team.
-Portfolio Manager, Program Manager, Project Management Office.
-Clienti, utenti
-Fornitori
-Partner commerciali: organizzazioni esterne che hanno un rapporto “speciale” con l'impresa. Forniscono
competenze specialistiche o ricoprono un ruolo specifico come l'installazione, personalizzazione, training,
formazione o assistenza.
-Gruppi organizzativi: stakeholders interni che sono influenzati dalle attività del Project Team (marketing e
vendita, risorse umane, etc.).
-Manager Funzionali: individui chiave che svolgono un ruolo di gestione all'interno di un'area
amministrativa o funzionale del business.
-Altri stakeholders: istituzioni finanziarie, consulenti, coloro che hanno interessi finanziari nel progetto,
forniscono input o hanno interessi nei risultati del progetto, soggetti pubblici o privati che devono rilasciare
autorizzazioni
-Sponsor: è una persona o gruppo di persone che fornisce le risorse e il supporto per lo svolgimento del
progetto. Lo sponsor del progetto è molte volte un dirigente dell'organizzazione che ha il potere e l'autorità
di prendere decisioni e risolvere le controversie o i conflitti più importanti riguardanti il progetto, è
l'autorità finale e decide le questioni più importanti di progetto, definisce le priorità. Dalla concezione
iniziale fino chiusura del progetto, lo sponsor promuove il progetto.
Lo sponsor guida il progetto attraverso il processo di inizializzazione e svolge un ruolo fondamentale nello
sviluppo del project charter. Quando i problemi vanno oltre il controllo del project manager, l’escalation fa
riferimento allo sponsor. Lo sponsor garantisce anche il trasferimento dei risultati forniti dal progetto dopo
la chiusura del progetto.
In genere i vari stakeholder hanno obiettivi diversi che possono anche essere in conflitto tra loro ed in
alcuni casi con gli obiettivi di progetto. Per esempio il manager desidera un basso costo della fornitura,
mentre il fornitore desidera massimizzare il suo profitto. Oppire, il manager della divisione ingegneria
identifica il successo con l’innovazione, il manager del reparto produttivo con il ciclo produttivo
d’avanguardia, il manager del reparto marketing con il numero di nuove caratteristiche del prodotto.
Il Project Manager
Il Project Manager: è il responsabile di tutto il progetto, può avere autorità su tutti i partecipanti al
progetto oppure solo funzione pianificatoria, di coordinamento, comunicazione e controllo o ruolo
intermedio.
Compiti del Project Manager
-Pianifica le seguenti attività:
-determinazione consensuale degli obiettivi. ovvero condivisi con le parti coinvolte. È uno dei
principali compiti del PM a livello alto (obiettivi del progetto) e basso (obiettivi di dettaglio)
-definire la WBS.
-negoziare con i responsabili delle attività l’impegno tra le parti (può essere un contratto con effetti
legali nel caso di soggetti esterni).
-programmare le attività sulla base delle risorse necessarie e disponibili utilizzando le tecniche di
pianificazione.
-identificare i responsabili per le diverse attività. Le responsabilità vengono definiti in modo più
accurato dal Prince2 e corrisponde alla possibilità di prendere decisioni.
-Controlla l’esecuzione: Controllare i tempi, i costi di realizzazione, la qualità del progetto utilizzando le
tecniche di controllo.
-Integra le attività di pianificazione: in base alla valutazione di tutti gli elementi informativi e la proiezione di
alcuni parametri significativi.
-Affronta i problemi che sorgono durante la gestione del progetto.
-Gestisce i processi gestionali del progetto (PMBOK sesta edizione: 49 processi in 10 aree della conoscenza)
-Assume decisioni riguardo: Richieste fondi addizionali per le attività, Richieste di Modifica dello scope,
Conflitti non previsti nell’utilizzo delle risorse, Attività in ritardo che possono ritardare il
Progetto, Non previste influenze da parte dell’esterno (incidenti, fattori metereologici, nuove norme),
ipotesi che sono venute meno, Azioni a seguito di errori
Caratteristiche del Project Manager
- conoscenza tecnica delle tecnologie coinvolte nel progetto;
- conoscenza delle tecniche e metodi di pianificazione, monitoraggio valutazione e controllo;
-flessibilità e spirito d’adattamento;
-predisposizione alla leadership;
-predisposizione all’iniziativa;
-capacità di persuadere e facilità di parola;
-fiducia in se stesso;
-entusiasmo, immaginazione;
-capacità di affrontare le soluzioni tecniche con considerazioni di costi, tempi, qualità e fattori umani;
-Capacità di gestire i conflitti
-capacità di organizzare il proprio lavoro;
-un generalista e non uno specialista;
-versatilità e disponibilità nei confronti dei problemi di pianificazione e controllo;
-capacità di negoziare;
-capacità di individuare i problemi;
-capacità di analisi;
-capacità di sintesi;
-propensione a prendere decisioni;
-capacità organizzativa;
-capacità di comunicare;
-vastità interessi personali.
INTERPERSONAL SKILLS
Leadership: Riuscire a fare concentrare gli sforzi del gruppo verso un obiettivo comune, fondandosi sul
rispetto e la fiducia piuttosto che sulla paura e la sottomissione
Costruzione del team: Sono le attività e i processi attraverso i quale si porta un gruppo di persone a
lavorare assieme, con il leader, con gli stakeholder e con l’organizzazione per un comune scopo.
Decision making: -Definizione del problema - Generazione delle soluzioni -Dalle idee all’azione (Ideas to
action) -Pianificazione della soluzione: Coinvolge i partecipanti chiave per attuare la soluzione scelta Pianificare la valutazione della soluzione -Valutazione dei risultati e del processo
Conoscenza politica e culturale
Trust bulding: Costruire la fiducia nel team e negli stakeholder attraverso la cooperazione, la
comunicazione e la risoluzione efficace dei problemi.
Alcune azioni: essere aperti nella risoluzione dei problemi, tenere tutti informati, essere espliciti riguardo le
necessità e le aspettative, condividere le informazioni anche se puoi avere sbagliato, essere ricettivi
all’innovazione, andare oltre i propri interessi, preoccuparsi degli altri ed evitare di apparire che si
perseguono gli interessi di alcuni.
Gestione dei conflitti
Coaching: Sviluppare le competenze e la performance del team aiutandolo a sviluppare le loro potenzialità
o nuove competenze
Esempio PM nella pubblica amministrazione:
-Il responsabile unico del procedimento, che deve: realizzare il coordinamento tra l’amministrazione
comunale, gli assessorati o provveditorati, direttore dei lavori in funzione dei disposti legislativi; integrare le
funzioni amministrative interessate al progetto con le funzioni tecniche.
Il rup svolge i propri compiti con il supporto dei dipendenti dell'amministrazione aggiudicatrice (riferimento
ad una struttura matrice). deve essere dotato di competenze professionali adeguate all'incarico che andrà a
ricoprire, deve avere competenze tecniche in ambito e un'adeguata formazione in materia di project
management, soggetta a costante aggiornamento e commisurata alla tipologia e alla complessità
dell'intervento da realizzare. il ruolo del rup venne definito all'articolo 7 della legge Merloni, in materia di
lavori pubblici dell'undici Febbraio 1994. la precedente normativa prevedeva due figure ingegnere capo e
direttore dei lavori separando fase di affidamento da quella di realizzazione.
Nell’impresa: Una sorta di microimprenditore del progetto che gestisce in proprio le forniture, i servizi e gli
appalti necessari allo sviluppo del programma che informa continuamente l’alta direzione (concezione
americana); Coordinatore dei servizi offerti dalle unità funzionali (concezione europea).
Responsabilità delle due funzioni
Project Manager
Definisce le fasi ed il contenuto delle attività (che cosa fare, quando)
Definisce quanto denaro è disponibile per il compito (negoziazione)
Motiva l’attività che deve essere svolta
È responsabile del successo del progetto
Manager Funzionale
Decide: - chi esegue le attività, come eseguire l’attività
Ha la responsabilità di quanto deve
essere consegnato
Decide come il lavoro tecnico sarà
eseguito (direzione tecnica)
Stabilisce quanto denaro è
necessario (negoziazione)
È responsabile di come le attività
funzionali si integrano nel progetto
Suddivisione dei poteri tra
Project Manager e Manager Funzionale
La suddivisione dei poteri e quindi delle responsabilità non è facilmente schematizzabile, nella sostanza
dipende dal contesto
Project Team
-Il team di progetto comprende il PM e il gruppo di individui che agiscono insieme nello svolgimento delle
attività del progetto al fine di raggiungerne gli obiettivi.
-Il team di progetto è costituito dal PM, dallo staff di Project Management e altri membri che realizzano il
lavoro ma che non sono necessariamente coinvolti nella gestione del progetto.
-Questo team è composto da individui provenienti da diversi gruppi con specifiche conoscenze o skill che
permettono loro di realizzare il lavoro del progetto.
-La struttura e le caratteristiche del team di progetto possono variare ampiamente, ma una costante è il
ruolo del PM come il leader della squadra indipendentemente da quale autorità il PM può avere su ogni
membro.
Ruoli nel Project Team
-Staff di Project Management: membri del team che svolgono attività di Project Management
(pianificazione, budgeting, reporting e controllo, comunicazioni, gestione del rischio e supporto
amministrativo). Questo ruolo può essere effettuato o sostenuto dal PMO.
-Staff di progetto: membri del team che svolgono il lavoro necessario alla creazione dei deliverable di
progetto.
-Supporto di esperti: svolgono attività necessarie per sviluppare o eseguire il piano di gestione del
progetto. Possono ricoprire ruoli come: amministrazione, gestione finanziaria, logistica, aspetti legali,
sicurezza, ingegneria, test, controllo qualità, etc. In funzione delle dimensioni del progetto e del livello di
sostegno necessario gli esperti possono lavorare a tempo pieno o possono partecipare quando sono
richieste le loro competenze specifiche.
-Utente o rappresentante del cliente: In alcuni casi i membri dell'organizzazione che accetteranno gli
elaborati o i prodotti del progetto possono essere assegnati al team come rappresentanti per garantire un
adeguato coordinamento, per fornire consulenza sui requisiti o per convalidare l'accettabilità dei risultati
del progetto.
-Fornitori: le società esterne che hanno un accordo contrattuale rilevante finalizzato a fornire componenti
o servizi necessari per il progetto e possono assegnare delle risorse umane al progetto
-Partner Commerciali: organizzazioni esterne che hanno un rapporto “speciale” con l'impresa. Forniscono
competenze specialistiche o ricoprono un ruolo specifico come l'installazione, personalizzazione, training,
formazione o assistenza.
Composizione del Project Team
La composizione del team di progetto varia in base a fattori quali la cultura organizzativa, l’ambito
(contenuto del progetto) e la localizzazione geografica. La relazione tra PM e il team varia a seconda
dell'autorità del PM. In alcuni casi il PM può avere piena autorità sui membri del team, in altri casi può
avere poca o non avere autorità organizzativa diretta su essi.
-Team Dedicato: in un team dedicato, tutti o la maggioranza dei membri del team vengono assegnati a
lavorare a tempo pieno sul progetto. Il team di solito risponde direttamente al PM. Questa è la struttura più
semplice per un PM poiché le linee di autorità sono chiare. I membri del team possono concentrarsi sugli
obiettivi del progetto.
-Part-time: alcuni progetti sono considerati come “lavori aggiuntivi temporanei”, in tale caso il PM e i
membri del team lavorano al progetto pur rimanendo nelle loro organizzazioni e continuano a svolgere le
loro normali funzioni. I manager funzionali mantengono il controllo sui membri del team e sulle risorse
destinate al progetto mentre il PM continua a svolgere altri compiti di gestione. I membri del team a tempo
parziale possono anche essere assegnati a più progetti alla volta.
Esempio di Project Team nella pubblica amministrazione:
-Responsabile del procedimento (Project Manager).
-Ingegnere area funzionale (Project Engineer).
-Assistente area funzionale.
-Ingegnere responsabile programmazione e controllo costi.
-Assistente alla programmazione e controllo dei costi.
-Responsabile legale.
-Assistente legale.
-Responsabile della qualità.
-Assistente alla qualità.
-Direttore dei lavori.
Esempio di Project Team per l’impresa
-Project Manager.
-Ingegnere area funzionale (Project Engineer).
-Assistente di area funzionale.
-Responsabile programmazione e controllo costi.
-Addetto alla programmazione e controllo costo.
-Responsabile legale.
-Responsabile della qualità.
-Responsabile approvvigionamenti.
-Responsabile dei trasporti.
-Responsabile della costruzione (Costruction Manager).
Project Management Office
Ufficio di supporto al Project Manager avente personale addetto: -alla pianificazione; -all'identificazione
interfacce;-al budgetting;-all'assegnazione risorse, manodopera e fondi; -al controllo avanzamento; -al
controllo schedulazione; -al controllo costi; -all'aggiornamento archivio del progetto.
Alcune attività:
-Gestire le risorse condivise su tutti i progetti amministrati dal PMO
-Identificare e sviluppare metodologie di Project Management, buone prassi e standard
-Addestramento, mentoring, formazione e supervisione;
-Coordinare la comunicazione tra i progetti
-Monitorare la conformità agli standard in relazione alle direttive, alle procedure e ai modelli di documenti
di Project Management tramite verifiche di progetto;
-Sviluppare e gestire direttive, procedure, modelli di documenti di progetto e altra documentazione
condivisa (asset dei processi organizzativi)
Diversi tipi di Project Management Office secondo PMBOK
-Di supporto: forniscono un ruolo consultivo, fornendo modelli, best practice, formazione, accesso alle
informazioni e lezioni apprese da altri progetti. Il livello di controllo fornito dal PMO è basso.
-Di controllo: il controllo dei PMO fornisce supporto e richiede al team la conformità attraverso vari mezzi.
Il grado di il controllo fornito dal PMO è moderato. La conformità può riguardare:
-Adozione di metodologie di gestione del progetto; -Utilizzo di modelli, format e strumenti specifici; Conformità ai quadri di riferimento della governanace
-Funzione direttiva: I PMO assumono il controllo dei progetti gestendo direttamente i progetti. I project
manager sono assegnato dal PMO e riferiscono al PMO. Il livello di controllo da parte del PMO è elevato.
LA STRUTTURA ORGANIZZATIVA
La struttura organizzativa mostra:
-La collocazione delle singole funzioni nell’organigramma aziendale.
-La suddivisione dei compiti tra le funzioni.
-Le linee di autorità che intercorrono tra la funzioni.
-L’interdipendenza delle funzioni.
-I canali informativi attraverso i quali fluiscono, secondo la prassi, le informazioni.
-Complesso schema di comunicazioni e di altre relazioni che viene a stabilirsi in un gruppo di esseri umani.
Cultura organizzativa
La cultura organizzativa è costituita dalle comuni esperienze, visioni e modi di fare all’interno dell’azienda,
essa può riguardare:
-La visione condivisa, la missione, i valori, le aspettative
-I regolamenti, le politiche, i metodi, le procedure e i processi.
-Le motivazioni e i sistemi di ricompensa
-La tolleranza al rischio
-La visione della leadership, la gerarchia e le relazioni gerarchiche
-Il codice di comportamento, l’etica sul lavoro, le ore di lavoro
-L’ambiente operativo
Il project manager per condurre con successo un progetto deve comprendere la particolare cultura
dell’azienda, in quanto la cultura dell’organizzazione può influenzare fortemente il progetto.
Project governance
La governance del progetto è una funzione di controllo che deriva dal modello di governance
dell'organizzazione e che abbraccia tutto il ciclo di vita del progetto. La governance del progetto è un
elemento fondamentale di qualsiasi progetto, essa fornisce un metodo coerente e completo per il controllo
del progetto, definendo altresì i processi del progetto per garantire il suo successo. Essa comprende le
regole per assumere decisioni di progetto, definisce i ruoli e le responsabilità, le politiche, le procedure, gli
standard e le autorità.
Enterprise Environmental Factors EEF
Si riferiscono a condizioni non sotto il controllo del team di progetto, che l'influenzano, limitano o
orientano il progetto. Essi sono considerati input per la maggior parte dei processi di pianificazione,
possono avere un effetto positivo o negativo sui risultati.
Fattori interni:
-la cultura organizzativa, la struttura e la governance;
-La distribuzione territoriale delle strutture e delle risorse;
-Le infrastrutture (ad esempio, le strutture esistenti e beni strumentali dell’azienda );
-Le risorse disponibili (le competenze, le discipline e la conoscenza nell’ambito della progettazione, dello
sviluppo, delle forniture, legale, amministrativo, ecc.);
-Le capacità dei dipendenti
-software di tecnologia dell'informazione
Fattori esterni:
-Le condizioni di mercato;
-Influenze sociali e culturali
- Restrizioni legali (includono leggi e regolamenti nazionali o locali relativi alla sicurezza, alla protezione dei
dati, alla condotta aziendale, all'occupazione e agli appalti).
- i data base commerciali (ad esempio, dati di costo stima standardizzati, informazioni studio rischio del
settore, banche dati sul rischio, prodotti e servizi disponibili sul mercato, performance e reputazione dei
fornitori, termini e condizioni per prodotti/servizi in uno specifico settore, data base di settore per la stima
delle durate, ecc.)
-ricerche accademiche
- gli standard governativi o di settore (per esempio, i regolamenti dello stato, codici di condotta, norme
riguardanti il prodotto, standard di qualità, standard di lavorazione, linee guida di una specifica area di
applicazione);
- Considerazioni finanziarie (includono tassi di cambio, tassi di interesse, tassi di inflazione, tariffe ecc.)
-elementi ambientali fisici (clima, condizioni di lavoro, vincoli..)
ORGANIZATIONAL PROCESS ASSET (OPA)
Gli asset dei processi organizzativi sono i piani, i processi, le politiche, le procedure e le basi di conoscenza
specifiche utilizzati dalla Organizzazione. Essi comprendono qualsiasi pratica o conoscenza di tutte le
organizzazioni coinvolte nel progetto che possono essere utilizzati per eseguire il progetto.
Comprendono ad esempio le lezioni apprese e le informazioni storiche. Gli Asset dei processi organizzativi
possono includere schedulazioni completate e i dati di rischio.
Gli Asset dei processi organizzativi possono essere raggruppati in due categorie:
(1) processi, politiche e procedure, (2) knowledge base aziendale.
Processi, politiche e procedure: 1)Initiating and Planning:
-Linee guida e criteri per processi e procedure standard per soddisfare specifici bisogni del progetto;
-Standard organizzativi specifici come le politiche (ad es. Politiche delle risorse umane, politiche di salute e
sicurezza, politiche di sicurezza e riservatezza, politiche di qualità, politiche di approvvigionamento e
politiche ambientali);
-Cicli di vita del prodotto e del progetto, metodi e procedure (ad es. Metodi di gestione del progetto,
metriche di stima, audit di processo, obiettivi di miglioramento, checklist ecc.);
-Templates (ad es. piani di project management, documenti di progetto, registri di progetto, formati di
report, contratti modelli, categorie di rischio, modelli di dichiarazione di rischio, definizioni di probabilità e
impatto, matrici di probabilità/impatto e modelli di registro degli stakeholder);
-Elenchi di fornitori accreditati e vari tipi di accordi contrattuali (ad es. prezzi fissi, rimborsi spese, tempo e
materiali).
Processi, politiche e procedure: 2)Esecuzione, monitoraggio e controllo:
-Procedure per l’approvazione delle variazioni, come i documenti di progetto saranno modificati e le
eventuali modifiche approvate e convalidate;
-Matrici di tracciabilità;
-Procedure di controllo finanziario (rendiconti temporali, richieste di spesa, modalità di revisioni degli
esborsi, codici contabili, disposizioni contrattuali standard, ecc.);
-Procedure di gestione dei difetti e dei problemi;
-Controllo della disponibilità delle risorse e gestione delle assegnazioni
-Requisiti della comunicazione (ad esempio, tecnologia di comunicazione specifica disponibile, politiche di
conservazione dei record, videoconferenza, strumenti collaborativi e requisiti di sicurezza);
-Procedure per stabilire le priorità, approvare e rilasciare autorizzazioni di lavoro;
-Template (ad es. Registro dei rischi, registro dei problemi e registro delle modifiche);
-Linee guida standardizzate, istruzioni di lavoro, criteri di valutazione delle proposte e misurazione delle
prestazioni;
- procedure di verifica e convalida dei risultati
Processi politiche e procedure: 3) Chiusura:
-Linee guida o requisiti per la chiusura del progetto (ad esempio, audit del progetto finale, valutazioni del
progetto, accettazione dei deliverable, chiusura del contratto, riassegnazione delle risorse e trasferimento
della conoscenza alla produzione e/o alle operazioni).
Processi politiche e procedure: 4) Knowledge base aziendale
-Repository di knowledge management contenenti le versioni dei componenti software e hardware e le
linee di base di tutti gli standard, le politiche, le procedure e documenti di progetto;
-Archivi di dati finanziari contenenti informazioni quali ore di lavoro, costi sostenuti, budget e superamento
dei costi per altri progetti;
-Informazioni storiche e repertori di conoscenza appresi dalle lezioni (ad es. Registri e documenti di
progetto, informazioni sulla chiusura e documentazione, informazioni riguardanti sia i risultati di precedenti
decisioni e informazioni provenienti dalle attività di gestione del rischio);
-Repository di dati di gestione dei difetti e di problemi -Repository di dati per le metriche utilizzate per
raccogliere e rendere disponibili i dati di misurazione sui processi e prodotti;
-File di progetto da progetti precedenti (ad esempio, baseline, pianificazione e misurazione delle
prestazioni, calendari di progetto, reticoli, registri di rischio, rapporti sui rischi, registri di stakeholder, ecc.).
Tipi di organizzazione
-Gerarchico-funzionale: È una struttura gerarchica dove ogni impiegato ha un solo superiore distinto ed
univoco. Lo staff è raggruppato in base alla specializzazione, come ad esempio produzione, marketing,
ingegnerizzazione, contabilità e ad ogni gruppo fa capo un solo manager funzionale, naturalmente ogni
ufficio può essere in seguito suddiviso in altri reparti, come ad esempio il reparto d'ingegnerizzazione può
essere ulteriormente suddiviso in elettrica e meccanica.
-Anche l'organizzazione funzionale può eseguire dei progetti, ma l'obiettivo percepito è limitato ai confini
della funzione: infatti ad esempio il reparto ingegnerizzazione farà il suo lavoro indipendentemente dagli
altri reparti
-Potere decisionale (strategico, operativo) nelle mani della direzione, funzioni nettamente separate tra di
loro, i confini tra funzione e funzione sono tracciati con estrema precisione. Sopra i manager funzionali,
nella PA, sta il direttore generale, che rappresenta un coordinatore generale. La struttura funzionale ricorda
molto il layout per processi (o job-shop). Se l'esponente di area necessità di nuovo materiale deve richiedere
la fornitura al proprio manager funzionale, che comunica call manager funzionale dell'area acquisti che a
sua volta demanda il compito a un esponente del proprio staff. Si vuole dunque mettere in comunicazione i
due esponenti in modo diretto, gestendo una nuova interfaccia e risolvendo il problema in tempi molto più
brevi: ciò è permesso proprio dal Project Manager che gestisce le interfacce
Questa struttura va bene per situazioni economiche stabili, piccole e medie aziende. infatti problemi come
la lentezza dei canali di comunicazione, difficoltà di coordinamento inter-funzionale, difficoltà nel valutare
la performance aziendale nelle diverse attività del progetto, rendono difficile la fattibilità in aziende di
grandi dimensioni.
Project-Oriented Organization:
- All'estremità opposta dello spettro dell'organizzazione funzionale c’è l'organizzazione orientata al
progetto
-La maggior parte delle risorse dell'organizzazione sono coinvolte nel lavoro di progetto, e i PM hanno una
grande indipendenza e autorità.
-Le organizzazioni proiettate hanno spesso unità organizzative chiamate dipartimenti, ma possono riferire
direttamente al PM o fornire servizi di supporto ai vari progetti.
A matrice
Le organizzazioni per progetto e funzionale sono due aspetti estremi: la loro sovrapposizione dà originare
alla struttura a matrice, che presenta le caratteristiche di entrambe le strutture originarie. Si può fare un
parallelo con il layout per celle (o sell-manufacturing). Si distinguono:
-A matrice debole
mantiene molte delle caratteristiche dell’organizzazione funzionale e il ruolo del project manager è più
quello di coordinatore o expediter che di vera e proprio manager. Una risorsa di una determinata funzione
coordina il progetto e mette in contatto risorse di varie funzioni, senza essere difatti indipendente.
-A matrice forte
è più vicina ad una organizzazione per progetto, infatti ha dei project manager a tempo pieno con una
considerevole autorità ed un project office a tempo pieno. L’azienda è suddivisa in aree funzionali con un
proprio manager finanziario, ma allo stesso tempo sono presenti vari project manager che seguono
determinati progetti, a cui vanno assegnate risorse appartenenti a funzioni differenti.
-A matrice bilanciata
Esiste un project manager che non ha la piena autorità sul progetto e sul budget alcune approvazioni sono
congiunte
Con l’aumento del potere del PM (da sx a dx), rappresentato in modo più scuro, si individua prima una
struttura per funzioni, poi a matrice e, infine, per progetti.
Caratteristiche di una organizzazione a matrice:
In una organizzazione a matrice vi sono due linee del comando per cui molti dipendenti hanno due capi: il
manager funzionale per la direzione tecnica e il project manager per il controllo dello scheduling e il
budgetting. Tale suddivisione è comunque troppo semplicistica.
-La matrice è dunque una struttura multidimensionale che cerca di massimizzare i punti di forza e
minimizzare le debolezze dell’organizzazione funzionale e per progetto.
-I ruoli dovrebbero essere indicati con precisione nel project charter.
Difficoltà dell’organizzazione a matrice rispetto all’organizzazione per progetto:
-Due capi: il dipendente può essere facilmente stretto nel mezzo
-Difficoltà di monitorare e controllare -Complessità dei flussi informativi -Difficoltà di una reazione veloce ai
problemi
-Conflitto di leadership
-Determinazione delle priorità: sia per la presenza di più progetti che per la coesistenza delle priorità sia del
reparto funzionale sia del progetto
-Conflitto tra obiettivi del progetto e del reparto funzionale
divisionale
SELEZIONE DEI PROGETTI
-Ogni progetto è caratterizzato da benefici e costi espressi in unità di misura diverse tra di loro
-La valutazione degli indicatori non è certa
-Alcune misure degli indicatori sono quantitative, altre qualitative, alcune oggettive altre soggettive
-Non è detto che le nostre preferenze (funzione utilità) siano lineari al variare dell’indicatore
-La scelta di un portafoglio progetti è complessa a causa delle relazioni esistenti tra i progetti stessi
-Gli obiettivi da raggiungere sono in genere più di uno anche in contrasto tra loro
-I valutatori se più di uno possono esprimere giudizi diversi tra di loro
-Esistenza di vincoli più o meno rigidi
La realtà è molto complessa bisogna utilizzare dei modelli che la semplificano
I modelli utilizzati devono:
–
Avere la capacità di interpretare le diverse realtà ed obiettivi aziendali (costo, redditività richiesta,
vincoli sul personale ed altre risorse)
–
Facili da usare
–
Un basso costo rispetto al valore del problema affrontato
Premesse ai modelli decisionali
- I modelli non prendono decisioni, gli uomini prendono decisioni ed in relazione alle decisioni
assumono responsabilità
- Un modello è solo una rappresentazione parziale della realtà che serve per aiutarci nella decisione
- Un modello deve valutare quanto i progetti soddisfano gli obiettivi dell’impresa:
Conseguenza=> se non si sono predefiniti gli obiettivi non si può prendere una decisione
Tipi di modelli
•
Mono criterio: La scelta viene effettuata massimizzando o minimizzando una funzione obiettivo o
sulla base di un solo criterio
•
Multi criterio:
–
Multiobiettivo nel caso di più funzioni obiettivi e spazio delle soluzioni che può considerarsi
continuo quindi infinito
–
Multiattributo nel caso di un numero di alternative molto limitato e discreti.
•
Numerici
–
Le valutazioni possono essere: qualitative o quantitative, soggettive o oggettive ma vengono
comunque espresse sotto forma numerica
•
Non numerici
–
La valutazione viene effettuata sotto forma non numerica
I due modelli (numerici e non numerici) possono integrarsi
LA DOMINANZA E L’OTTIMO DI PARETO
una regola decisionale molto generale applicata per i problemi MCDM, quando si deve scegliere una sola
alternativa, consiste nei due seguenti passi:
–
individuare l’insieme delle alternative efficienti (non dominate, Pareto ottimali);
–
selezionare l’alternativa efficiente di compromesso utilizzando le informazioni di preferenza che il
decisore mette a disposizione.
Soluzioni efficienti, Pareto ottimali o non dominate
•
una soluzione ammissibile è non dominata se e solo non esiste nessun’altra soluzione ammissibile
che assuma valore migliore per un criterio e non peggiore per un qualunque altro.
•
si chiamano Pareto ottimali le alternative ammissibili per le quali non esiste un’altra alternativa
ammissibile in grado di produrre un miglioramento rispetto ad un obiettivo/attributo senza peggiorarne
almeno un altro.
•
una soluzione ammissibile è dominata se e solo esiste almeno un’altra soluzione ammissibile che
assuma valore migliore per un criterio e non peggiore per un qualunque altro.
Modelli non numerici
•
Sacred cow (taboo):Il progetto è suggerito dal capo dell’organizzazione
•
Necessità operative:il progetto è necessario per mantenere l’operatività del sistema (es.
inondazione)
•
Necessità competitive:Estensione della linea di prodotto per coprire un gap di mercato
Classificazione metodi multicriterio MCDM
•
multiattributo MADM (Multi Attribute Decision Making) in corrispondenza di un numero finito e
enumerabile di alternative definite in modo esplicito;
•
multiobiettivo MODM (Multi Objective Decision Making) qualora il numero di alternative fosse
molto grande e non enumerabile, o addirittura infinito e definito in modo implicito.
Classificazione metodi multicriterio
•
Compensativi (trade off) La compensazione tra criteri consiste nella possibilità, quando
valutare un'alternativa, di compensare un valore "non buono" di un attributo con un valore
"buono" di un altro attributo (trade-off tra attributi).
 Non compensativi: non permettono trade-off tra i criteri: un valore non buono di un attributo non può
essere compensato da un altro
Tipologie metodi multicriterio
Gli MCDM sono classificati secondo il metodo di analisi utilizzato:
•la teoria delle funzioni di valore e delle funzioni di utilità;
•lanalisi gerarchica:AHP
•lanalisi di concordanza e di discordanza o tecniche di surclassamento (scelta, classificazione,
ordinamento):
–
Electre
–
Promethee
•Altri metodi:
–
–
–
Evamix
Topsis
Vikor
•
metodi di aggregazione completa transitiva
–
il decisore (Decision Maker DM) è perfettamente razionale ed è in grado di esprimere, per ogni
coppia di azioni, la sua preferenza o la sua indifferenza in modo razionale
– La relazione di preferenza R è transitiva se:
∀a, b, c ∈ A tali che a R b e b R c, è anche vero a R c.
•
metodi di aggregazione parziale
–
il decisore non è perfettamente razionale e le preferenze non sono quindi necessariamente
consistenti tra loro né tanto meno transitive. (Effetto veto, Paradosso di Condorcet sulle preferenze
collettive, ecc.)
Modelli numerici di valutazione non finanziaria:
 Classificazione a punti:
- Multi criteri non pesati con valutazione 0-1
–
Vengono individuati una serie di attributi che se posseduti dal progetto determinano il
soddisfacimento ognuno di un certo criterio
–
Tutti i criteri hanno lo stesso peso
–
Viene assegnato il punteggio uno se il progetto possiede un certo attributo, il punteggio
zero se non possiede lo specifico attributo
–
Si sommano per ogni progetto il numero di attributi soddisfatti
–
Vantaggio: possono essere facilmente enumerati diversi criteri
–
Svantaggio: tutti i criteri hanno lo stesso peso e non è prevista la valutazione della forza con
cui un progetto colpisce un certo criterio
-
Multi criteri non pesati con classificazione dei progetti
–
Vengono individuati gli attributi che misurano quanto ogni progetto soddisfa un certo
criterio
–
Tutti i criteri hanno lo stesso peso
–
Per ogni progetto ogni attributo viene valutato su una scala numerica prefissata
–
Si sommano i punteggi ottenuti da ogni progetto
-
Weighted Method o Simple Additive Weighting (SAW)
Si =∑sij ×wj
j=1
–
Si = punteggio totale delli-simo progetto;
–
Sij = punteggio delli-simo progetto sul j-simo criterio;
–
wj = peso del j-simo criterio.
È un metodo compensativo e transitivo
Normalizzazione :
•
il punteggio dell’i-simo progetto sul j-simo criterio sij può essere valutato in un intervallo
qualunque, con valori discreti o continui, molte volte viene assunto l’intervallo 0-1.
•
Nel caso in cui i punteggi dei progetti siano di tipo quantitativo, quindi espressi tramite
valori numerici, il decision maker ha il problema di confrontare tra loro numeri espressi in unità di
misura e scale di valutazione differenti da criterio a criterio
•
Al fine di rendere tali punteggi indipendenti dalle scale e dalle unità di misura adottate, e
quindi confrontabili tra loro, si utilizza una trasformazione detta normalizzazione che riconduce gli
elementi della matrice di valutazione in valori compresi in un intervallo di normalizzazione in
genere tra 0 e 1.
•
Al concetto di normalizzazione è legato il concetto di direzione del punteggio o verso di
preferenza del criterio: per alcuni criteri un punteggio più alto è migliore, mentre per altri può
essere peggiore
•
La normalizzazione conviene sia effettuata in modo che al crescere del punteggio un
progetto sia sempre da considerarsi migliore, qualunque sia il verso di preferenza del criterio
Esempio: nella scelta di un automobile se un criterio è la velocità e l’altro il prezzo, si avrebbero
come unità di misura per il primo criterio i Km/ora e per il secondo il prezzo in Euro, pertanto le
valutazioni sulla base di queste due unità di misura non sono comparabili tra loro.
Notazioni:
•
Xi il punteggio che il progetto Pi (i = 1,2,….,n progetti da selezionare) assume su tale criterio;
•
Xmax e Xmin rispettivamente i punteggi migliore e peggiore tra quelli assunti dagli n
progetti su tale criterio (sono il valore massimo e il valore minimo della colonna considerata della
matrice di valutazione degli indicatori);
•
T il target del criterio, ovvero il punteggio ritenuto ottimale indipendentemente dalle
valutazioni dei progetti in esame sul criterio considerato;
•
t il nadir del criterio, ovvero il punteggio ritenuto peggiore indipendentemente dalle
valutazioni dei progetti in esame sul criterio considerato.
Esercizio nelle slide
Ni = [(Xi - Xmin)/(Xmax - Xmin)]n
•
con n = 0,5 la normalizzazione è ad incrementi decrescenti, ovvero, all’aumentare di X, a
parità di incrementi di X corrispondono incrementi decrescenti del punteggio normalizzato. Nel
caso, ad esempio, di offerta economica valutata attraverso il ribasso d’asta, l’effetto di tale tipo di
normalizzazione è di dare meno peso alle offerte via via con ribasso più elevato, rispetto ad una
normalizzazione lineare
•
con n = 1 la normalizzazione è lineare, ovvero, all’aumentare di X, a parità di incrementi di X
corrispondono uguali incrementi del punteggio normalizzato
•
con n = 2 la normalizzazione è ad incrementi crescenti, ovvero, all’aumentare di X, a parità
di incrementi di X corrispondono incrementi crescenti del punteggio normalizzato. Nel caso, ad
esempio, di offerta economica valutata attraverso il ribasso d’asta, l’effetto di tale tipo di
normalizzazione è di dare più peso alle offerte via via con ribasso più elevato, rispetto ad una
normalizzazione lineare
CICLO DI VITA DEL PROGETTO
Ciclo di vita del progetto: Una serie di fasi attraverso cui passa il progetto dall’inizio sino al suo
completamento
Fase del progetto: Parte del progetto caratterizzata dal raggiungimento di uno o più risultati concreti,
verificabili e ben definiti atti ad eseguire un controllo sull’avanzamento. In genere delimitate da milestone
(inizio, fine, phase gate, phase review, control gate)
Generalmente i risultati di una fase devono essere approvati prima che si avvii la fase successiva ma le fasi
possono anche sovrapporsi, in genere l’inizio di una fase deve essere autorizzata.
I control gate sono quei punti in cui si controlla la fase; potrebbero essere punti in cui sono stati raggiunti
determinati obiettivi o caratterizzati da parametri temporali.
Perché si suddivide in fasi un progetto? Al fine di consentire un migliore controllo e gestione del progetto.
I nomi delle fasi indicano generalmente il tipo di lavoro svolto in quella fase, ad es.:Studio di fattibilità,
Sviluppo soluzione,Progettazione,Realizzazione prototipo,Costruzione,Installazione,Test, trasferimento
Caratteristiche delle fasi:
-Il lavoro ha un diverso focus in ogni fase (differenti organizzazioni, localizzazione e skill)
-In ogni fase si hanno risultati e obbiettivi da raggiungere, generalmente in ogni fase si ripetono i cinque
gruppi di processi.
-La fase si chiude con il raggiungimento di una milestone e con risultato del lavoro fatto, tale milestone o
phase gate può rappresentare un punto in cui si rivalutano le attività fatte, si decide se cambiare il progetto
o chiuderlo.
Generalmente i risultati di una fase devono essere approvati prima che si avvii la fase successiva � il cui
inizio generalmente deve comunque essere autorizzato (ciò è quanto previsto dal Prince 2), ma le fasi
possono anche sovrapporsi: non necessariamente dunque una fase inizia al concludersi di un’altra. Per
esempio se si deve pavimentare un edificio, è possibile considerare due fasi: pavimentazione e intonaco
pareti. Si esegue prima la fase di intonaco pareti e successivamente quella di pavimentazione, ma man
mano che si intonaca una parte, è possibile pavimentare la stessa, mentre si continua a intonacare il resto.
Ciclo di vita del progetto: L’insieme delle fasi del progetto il cui nome e numero è funzione delle necessità
di controllo dell’organizzazione o delle organizzazioni coinvolte nel progetto.
A cosa serve? - Ad identificare l’inizio e la fine del progetto -Ad identificare dei risultati intermedi in base ai
quali decidere se proseguire o meno il progetto. -A definire quale è il risultato di ogni fase e chi deve essere
coinvolto in ogni fase.
-Costi del personale: Bassi all’inizio.
Vanno aumentando man mano che si procede.
Diminuiscono verso la fine.
-Probabilità di completare con successo il progetto: Bassa all’inizio (alto rischio).
Aumenta man mano che il progetto procede.
-Possibilità degli stakeholders d’influenzare tempi, qualità e costi:
Alta all’inizio del progetto.
Diminuisce con l’avanzamento dei lavori.
-Riunioni: Più frequenti all’inizio.
Attenzione
Il ciclo di vita del progetto è diverso dal ciclo di vita del prodotto.
I sottoprogetti a loro volta in genere hanno un loro ciclo di vita.
Il numero delle fasi è variabile a secondo del progetto, in genere da quattro a nove.
Il numero e tipi di fasi si basa su: Necessità gestionali, Natura del progetto, Caratteristiche proprie della
tecnologia, industria, organizzazione, business, processi o legali,Punti decisionali
Per ogni fase bisogna almeno definire:
-Il nome
-Numero della fase
-La durata
-Le risorse necessarie (Chi deve essere coinvolto, strumentali, finanziarie)
-Criteri che devono essere soddisfatti per iniziare la fase (es. documenti completati, approvati, ecc.)
-Criteri che devono essere soddisfatti per considerare la fase completata (es. documenti completati,
approvati, ecc.)
La phase gate (Un punto alla fine della fase dove si prende una decisione). Si trova alla fine della fase, in
esso si paragonano le performance e i risultati raggiunti con quelli pianificati in:Project business case,
Project charter, Project management plan,Benefits management plan
Le decisioni generalmente sono:
-Passare alla fase successiva
-Passare alla fase successiva con variazioni
-Chiudere il progetto
-Rimanere nella fase
-Ripetere tutta o parte della fase
Esempi di ciclo di vita del prodotto e del progetto
Ciclo di vita del progetto: nuovo prodotto
-Concezione:
-analisi di fattibilità dal punto di vista tecnico, economico, normativo.
-identificazione dei vincoli.
-sviluppo WBS di massima.
-decisione di iniziare o meno il progetto.
-Definizione
-individuare le caratteristiche del prodotto finale.
-definire la proposta e produrre le specifiche di massima del progetto.
-analizzare l'investimento.
-Impostazione:
-studi e analisi di dettaglio.
-progettazione tecnica e/o organizzativa.
-Sviluppo:
-realizzazione delle soluzioni definite nella progettazione.
-Esercizio:
-Collaudo. -Vendita. -assunzione risultati (ricerca).
-Post completamento:
-Manutenzione. -rapporti finali di valutazione.
Ciclo di vita Predittivo
Chiamato anche a cascata (waterfall) è Il più tradizionale. Prima si pianifica poi si realizza in un singolo
passo. Requisiti stabili. Lo scope è ben definito e conosciuto già dall’inizio. Adatto quando è richiesto un
solo rilascio.Durata del progetto ben definita. Le fasi sono sequenziali anche in overlapping. Responsabilità
precise per ogni deleverible. Comunicazione tramite documenti. Processo stabile e formale. Con il modello
predittivo spesso è utilizzata una pianificazione rolling wave (elaborazione progressiva)
Modello a stadi
Analisi dei requisiti e progettazione preliminare effettuata per l’intero progetto all’inizio. È Possibile
scomporre il progetto in più componenti. I prerequisiti vengono sviluppati subito (1° stadio).Le altre attività
vengono sviluppate in fasi successive. Adatto quando il prodotto finale può essere rilasciato in più step.
Struttura dell’intero prodotto è conosciuta sin dall’inizio
Modello prototipale
Due cicli distinti: 1)Prototipo 2)Prodotto
-Ci si concentra nella analisi, design, test del prototipo al fine di acquisire informazioni sul prodotto
-Quando finisce la fase prototipale si inizia la fase di realizzazione del prodotto vera e propria
-Prevede un feedback sul lavoro non finito per modificare e migliorare il prodotto
-Rappresenta uno scambio continuo di feedback tra le diverse iterazioni
-Per ogni soluzione ci si confronta col cliente che fa richieste di variazioni o di requisiti incrementali, nelle
iterazioni successive si può migliorare il prodotto e si possono realizzare anche prodotti nuovi
-I cambiamenti richiesti sono integrati nel prodotto e un nuovo prodotto non definitivo è rilasciato
-Il processo si ripete sino a quando il cliente è soddisfatto
-Il numero di iterazioni non è previsto a priori, ma dipende dal raggiungimento degli obiettivi di progetto
-Adatto a progetti di grandi dimensioni, complessi e con requisiti da parte del cliente non stabili
-I cicli iterativi procedono per fasi in modo sequenziale o in overlapping
-I cicli di vita iterativi sono generalmente preferiti quando un'organizzazione deve gestire il cambiamento di
obiettivi e dello «scope», per ridurre la complessità di un progetto.
-Utile quando il progetto è soggetto a diversi stakeholder
Incremental life cycle
- Fornisce in ogni ciclo incrementale prodotti finiti, pronti per l’uso
-Utile quando il cliente ha la necessità di utilizzare prodotti intermedi o prodotti con funzionalità parziali
-I prodotti intermedi potrebbero essere dei prototipi
-Man mano che il progetto si realizza si può cambiare la visione originale del progetto
-È più importante il valore per il cliente alla fine del progetto, piuttosto che evitare i cambiamenti.
-Il feedback del cliente è utile per fornire indicazioni circa i prodotti successivi o il prodotto definitivo
Agile life cycle
-Contiene entrambi gli aspetti dei cicli iterativi e incrementali
-Prevede generalmente iterazioni rapide con tempi e costi fissati e rilasci frequenti di prodotto
-Il team rileva i feedback di cui fornisce al cliente piena visibilità e controllo del prodotto.
-Poiché sono previsti rilasci frequenti di prodotto si ha un più alto TIR (IRR) sugli investimenti
-Nel iteration based, il team lavora in iterazioni in intervalli di tempo uguale che fissa costanti per fornire
funzionalità complete. Il team lavora prima sulla funzione più importante, quindi lavora e finisce la
caratteristica successiva più importante. Il team può decidere di lavorare su alcune funzionalità alla volta e
non a tutte contemporaneamente.
-Nel flow based Agile viene fissata invece la quantità di lavoro (WIP) in ogni step che in relazione alla
funzionalità da realizzare potrebbe richiedere un tempo diverso. Il team prevede WIP piccoli per
identificare meglio i problemi in anticipo e ridurre le rilavorazioni in caso di modifiche.
Hibrid life cycle
-Non è necessario utilizzare un singolo approccio per un intero progetto alcuni progetti spesso combinano
elementi di diversi cicli di vita per raggiungere determinati obiettivi. Una combinazione di cicli predittivo,
iterativo, incrementale e/o agile è un approccio ibrido.
Modello a spirale (prototipale iterativo)
-Ciclo di vita come lo sviluppo di una serie di prototipi, sempre più ed evoluti, fino al prodotto finale.
-Adatto a progetti con requisiti non stabili e tecnologie poco conosciute
-Questo meta modello è una sorta di framework attraverso cui posso inquadrare tanti altri modelli.
Le fasi di un ciclo sono:
o
determinazione degli obiettivi, delle alternative e dei vincoli
o
valutazione di eventuali alternative e identificazione dei rischi
o
fase di sviluppo e di verifica
o
pianificazione nei dettagli della fase successiva
I PROCESSI NEL PROJECT MANAGEMENT
Un progetto si realizza attraverso processi. Processo: insieme di azioni e attività svolte per creare un
prodotto, un servizio o un risultato, in generale per raggiungere un obbiettivo. I processi sono eseguiti dal
team di progetto con l'interazione degli stakeholders
Processi del project management: Descrivono ed organizzano il lavoro del progetto; Sono simili per buona
parte dei progetti; Interagiscono l’uno con l’altro. I processi non sono fasi ma si ripetono in genere nelle
diverse fasi. Ogni processo di gestione di un progetto produce uno o più output da uno o più input
utilizzando strumenti e tecniche di gestione del progetto appropriati. Gli output sono il risultato finale di un
processo.
L'output di un processo generalmente si traduce in:
-Un input per un altro processo, oppure
-un risultato del progetto o della fase del progetto.
I 5 gruppi di processi:
-Processi di inizializzazione -Processo di pianificazione -Processi esecutivi -Processi di monitoraggio e
controllo -Processi di chiusura
Matrice Processi/Aree di Conoscenza.
Processi di inizializzazione
-Sono quei processi che definiscono un nuovo progetto o una nuova fase di un progetto esistente al fine di
ottenerne la formale autorizzazione.
-Si fa una descrizione di massima dello “scope” del progetto.
-Si definiscono le risorse che si desiderano impegnare.
-Vengono identificati gli stakeholder (interni ed esterni) che interagiranno con il progetto e ne influenzeranno il
risultato complessivo.
-Viene selezionato il Project Manager, se non è stato ancora assegnato al progetto.
-Scopo fondamentale di questo gruppo di processi è quello di allineare le aspettative degli stakeholder con
gli obiettivi del progetto, dare loro visibilità del progetto e mostrargli come la loro partecipazione al
progetto e alle fasi associate può garantire il raggiungimento delle loro aspettative.
Sviluppo del Project Charter (Develop Project Charter) è lo sviluppo di un documento che
autorizza formalmente il progetto.
-È il riconoscimento formale da parte dell’impresa del progetto. Da l’autorità al PM di utilizzare le
risorse dell’organizzazione per lo svolgimento delle attività di progetto
-Esplicita il raccordo tra il progetto e gli obbiettivi stategici dell’impresa.
Vantaggi di tale processo:
-Inizio e confini del progetto ben definiti.
-Creazione di un registro formale del progetto.
-Per i dirigenti costituisce un modo diretto per fargli accettare formalmente e per farli impegnare
per il progetto.
Identificazione degli stakeholders (Identify Stakeholders): è il processo di identificazione delle
persone, gruppi o organizzazioni che potrebbero influire o essere influenzate da una decisione,
attività o risultato del progetto.
-In tale processo vengono analizzate e documentate le informazioni utili relative agli interessi, al
coinvolgimento, alle interdipendenze, all'influenza e al potenziale impatto sul successo del progetto
degli stakeholders.
Vantaggi di tale processo: Permette al PM di focalizzare lattenzione su ogni stakeholders in modo
appropriato.
Processi di pianificazione
Sono quei processi che stabiliscono il lavoro complessivo da fare. Si definiscono e si perfezionano gli
obiettivi che il progetto si propone di raggiungere.
Si stabiliscono le azioni necessarie da svolgere per raggiungere gli obiettivi prefissati.
Se tale gruppo di processi è ben gestito è più semplice che gli stakeholders si impegnino.
Sono processi che si ripetono durante il ciclo di vita del progetto, il che è caratteristico della elaborazione
progressiva del progetto
Vantaggi: le di questo gruppo di processi è quello di delineare la strategia e la tattica da utilizzare, così
come il corso di azioni o il percorso per completare con successo il progetto o la fase.
Sviluppo del Project Management Plan (Develop Project Management Plan): Tale processo consiste
nel definire, preparare, coordinare tutti i piani ausiliari e nella loro integrazione in un piano globale di
gestione del progetto.
Il vantaggio di questo processo è avere un documento centrale che costituisce la base di tutto il
lavoro del progetto.
Project Scope Management
Gestione del Piano dello “scope” (ambito) (Plan Scope Management)
È il processo di creazione di un piano che documenta come verrà definito, validato e controllato lo
"scope" del progetto e del prodotto. Il vantaggio di questo processo è che costituisce una guida su
come lo “scope” sarà gestito durante lo svolgimento del progetto.
Raccolta dei Requisiti (Collect Requirements)
È il processo mediante il quale si determinano, documentano e gestiscono le esigenze e i requisiti
richiesti dagli stakeholders e necessari a raggiungere gli obiettivi del progetto. Il vantaggio di questo
processo è che fornisce la base per la definizione dei contenuti dello "scope" del progetto e del
prodotto.
Definizione dello "scope» (Define Scope)
È il processo mediante il quale si sviluppa una descrizione dettagliata del progetto e del prodotto. Il
vantaggio di questo processo è che descrive il prodotto, il servizio o i confini dei risultati definendo
quali tra i requisiti raccolti saranno inclusi e quali esclusi dal campo di applicazione del progetto.
Creazione della WBS (Create WBS)
È il processo di suddivisione dei deliverable e del lavoro di progetto in componenti più piccoli e più
facilmente gestibili. Il vantaggio di questo processo è che fornisce una visione strutturata di ciò che
deve essere consegnato.
Project Schedule Management
Gestione del piano dello schedule (Plan Schedule Management)
È il processo mediante il quale si stabiliscono le regole, le politiche, le procedure e la
documentazione per la pianificazione, lo sviluppo, la gestione, l'esecuzione e il controllo del progetto.
Il vantaggio di questo processo è che fornisce una guida e da la direzione su come la pianificazione
del progetto verrà gestita.
Definizione delle attività (Define Activities)
È il processo mediante il quale si identificano e si documentano le azioni specifiche da eseguire per
ottenere i deliverables di progetto. Il vantaggio di questo processo è scomporre i work package
(pacchetti di lavoro) in attività che forniscono una base per la stima, la pianificazione, l’esecuzione, il
monitoraggio e il controllo del lavoro del progetto.
Sequenza delle attività (Sequence Activities)
È il processo mediante il quale si identificano e si documentano le relazioni tra le attività del
progetto. Il vantaggio di questo processo è che esso definisce la sequenza logica del lavoro che
permette di ottenere la massima efficienza una volta definiti i vincoli di progetto.
Stima delle durate delle attività (Estimate Activity Durations)
È il processo mediante il quale si stima il numero di periodi di lavoro necessari per completare le
singole attività in funzione delle risorse stimate. Il vantaggio di questo processo è che fornisce la
quantità di tempo necessario affinché ogni attività venga completata. Tale valore è un input
importante per il processo di Sviluppo di uno schedule.
Sviluppo dello schedule (Develop Schedule)
È il processo di analisi delle sequenze delle attività, delle durate, delle richieste di risorse e dei vincoli
di schedule necessario alla creazione di un modello di pianificazione del progetto. Il vantaggio di
questo processo è che inserendo le attività, le durate, le risorse, la disponibilità di risorse e le
relazioni logiche in uno strumento di pianificazione, si genera un modello di schedule con le date
previste per il completamento delle attività di progetto.
Project Cost Management
Gestione del piano dei costi (Plan Cost Management)
È il processo che stabilisce i criteri, le procedure e la documentazione necessari alla pianificazione,
gestione, monitoraggio e controllo dei costi del progetto. Il vantaggio di questo processo è che
fornisce una guida e la direzione su come i costi del progetto saranno gestiti nel corso del progetto.
Stima dei costi (Estimate Costs)
È il processo mediante il quale si stimano le risorse monetarie necessarie per completare le attività di
progetto. Il vantaggio di questo processo è che determina l'ammontare delle risorse finanziarie
necessarie per completare ogni attività di progetto.
Determinazione del budget (Determine Budget)
è il processo di aggregazione dei costi stimati di attività individuali o di pacchetti di lavoro per
stabilire e autorizzare la cost baseline. Il vantaggio di questo processo è che determina una baseline
di costo rispetto alla quale monitorare e controllare la performance del progetto.
Project Quality Management
Gestione del piano di qualità (Plan Quality Management)
È il processo mediante il quale si identificano i requisiti e/o le norme di qualità significativi per il
progetto e i suoi prodotti e si documenta come il progetto soddisferà i requisiti di qualità e/o
standard.Il vantaggio di questo processo è che fornisce una guida e la direzione su come la qualità
sarà gestita e validata nel corso del progetto.
Project Resource Management
Gestione del piano delle risorse (Plan Resource Management)
È il processo mediante il quale si definisce come si identificano, si acquisiscono, si gestiscono e si
utilizzano risorse fisiche e umane. Si documentano i ruoli, le responsabilità, il livello di autorità, le
competenze richieste e le relazioni nel progetto e si redige un piano di gestione del personale.
Il vantaggio di questo processo è che stabilisce l’approccio e il livello di organizzazione gestionale per
gestire le risorse in funzione della complessità del progetto.
Stima delle risorse per le attività (Estimate Activity Resources)
È il processo mediante il quale si stima la tipologia e la quantità di materiale, risorse umane,
attrezzature o forniture necessarie per svolgere le attività. Il vantaggio di questo processo è che
identifica la tipologia, la quantità e le caratteristiche delle risorse necessarie per completare le
attività e che permette stime più accurate dei costi e delle durate.
Project Communications Management
Gestione del piano di comunicazione (Plan Communications Management)
È il processo di sviluppo di un approccio appropriato e di un piano per la comunicazione basato sulle
esigenze e sulle richieste di informazioni degli stakeholder (quali informazioni devono essere
comunicate, chi necessita di informazioni, chi le deve fornire, quando saranno necessarie e come
devono essere fornite).
Il vantaggio di questo processo è che identifica e documenta l'approccio di comunicazione, nel modo
più efficace ed efficiente con gli stakeholders.
Project Risk Management
Gestione del piano dei rischi (Plan Risk Management)
È il processo mediante il quale si definisce come condurre le attività di gestione del rischio per un
progetto. Il vantaggio di questo processo è che esso garantisce che il grado, il tipo e la visibilità della
gestione del rischio è commisurato sia ai rischi sia all’importanza del progetto per l'organizzazione.
Identificazione dei rischi (Identify Risks)
È il processo mediante il quale si determinano quali rischi possono influenzare il progetto e se ne
documentano le caratteristiche. Il vantaggio di questo processo è avere una documentazione dei
rischi esistenti e fornisce al team di progetto una conoscenza e la capacità di anticipare gli eventi
dovuti a rischi.
Esecuzione dell’analisi qualitativa del rischio (Perform Qualitative Risk Analysis)
È il processo di prioritizzazione dei rischi, attraverso la valutazione delle loro probabilità di
accadimento e dell’impatto, e la successiva combinazione secondo relazioni logiche, per stabilire
quali rischi eventualmente sottoporre a ulteriori analisi o azioni. Il vantaggio di questo processo è che
consente ai PM di ridurre il livello di rischio concentrandosi sui rischi ad alta priorità.
Esecuzione dell’analisi quantitativa del rischio (Perform Quantitative Risk Analysis)
È il processo di analisi numerica che valuta quantitativamente l’effetto combinato dei rischi
identificati e delle incertezze sugli obiettivi generali del progetto. Il vantaggio di questo processo è
che produce informazioni quantitative sul rischio per supportare il processo decisionale al fine di
pianificare la risposta al rischio.
Piano di risposta ai rischi (Plan Risk Responses)
È il processo di sviluppo di opzioni e azioni per aumentare le opportunità e ridurre le minacce agli
obiettivi di progetto dovute ai rischi. Il vantaggio di questo processo è che affronta i rischi in
funzione della loro priorità prevedendo time buffer, risorse e attività di contingenza nella
pianificazione e nei documenti di progetto.
Project Procurement Management
Gestione del piano degli approvvigionamenti (Plan Procurement Management)
È il processo mediante il quale si documentano le decisioni in materia di approvvigionamenti per il
progetto, specificando l'approccio usato e identificando i potenziali fornitori.
Il vantaggio di questo processo è che esso stabilisce cosa acquistare, come effettuare tale acquisto,
quanto e quando acquistare anche valutando l’opzione make or Buy”.
Project Stakeholder Management
Gestione del piano degli stakeholders (Plan Stakeholder Engagement)
È il processo mediante il quale si sviluppa un’adeguata strategia finalizzata al coinvolgimento degli
stakeholeders per tutto il ciclo di vita del progetto, basata sull'analisi dei loro bisogni, interessi e
impatti potenziali sul successo del progetto.
Il vantaggio di questo processo è che fornisce un piano chiaro e perseguibile per interagire con gli
stakeholders di progetto al fine di sostenere gli interessi del progetto stesso.
Processi Esecutivi
Sono quei processi eseguiti per completare il lavoro definito nel piano di gestione del progetto per
soddisfare le specifiche di progetto stesso.
Questi processi riguardano il coordinamento di persone e risorse, la gestione delle aspettative degli
stakeholders, così come l'integrazione e l'esecuzione delle attività del progetto secondo quanto stabilito nel
piano di gestione del progetto.
Durante l'esecuzione del progetto possono sorgere necessità di variazioni dovute a modifiche delle durate
previste per le attività, a cambiamenti della produttività e/o disponibilità delle risorse e a rischi imprevisti.
Tali variazioni possono influenzare il Project Management Plan o i documenti di progetto e possono
richiedere analisi dettagliate e lo sviluppo di adeguate risposte.
Una gran parte del budget di progetto sarà speso nello svolgimento del gruppo dei processi esecutivi.
Project Integration Management
Dirigere e gestire il Lavoro del Progetto (Direct and Manage Project Work)
Dirigere e gestire il lavoro di progetto è il processo di conduzione e esecuzione del lavoro
previsto nel piano di gestione del progetto e l’implementazione delle modifiche approvate per
raggiungere gli obiettivi del progetto. Il vantaggio chiave di questo processo è che fornisce una
gestione integrata del lavoro e dei risultati del progetto, migliorando la probabilità di successo
del progetto.
Manage project knowledge (ManageProject Knowledge)
È il processo attraverso cui si utilizzano le conoscenze esistenti nell’organizzazione per
raggiungere gli obiettivi del progetto e si creano nuove conoscenze contribuire
all'apprendimento dell’organizzazione.
Il vantaggio di questo processo è che la conoscenza dell’organizzazione è utilizzata per produrre
o migliorare i risultati di progetto e la conoscenza fornita dal progetto sarà sfruttata per fasi o
progetti futuri.
Project Quality Management
Gestire la qualità (Manage Quality)
È il processo di traduzione del piano di gestione della qualità in attività che contengano le
politiche di qualità dell'organizzazione per il progetto.
Il vantaggio di questo processo è che aumenta il probabilità di raggiungere gli obiettivi di qualità,
oltre all'individuazione dei processi inefficaci causa di scarsa qualità.
Project Resource Management
Acquisizione le risorse (Acquire Resources)
È il processo mediante il quale si acquisiscono le risorse: i membri del team, gli impianti, le
attrezzature, i materiali e altro per completare il lavoro del progetto.
Il vantaggio di questo processo consiste nel guidare la selezione delle risorse ed assegnarle alle
rispettive attività.
Sviluppo del Team (Develop Team)
È il processo mediante il quale si migliorano le competenze, le interazione tra i membri del team
e in generale l'ambiente di lavoro del team per aumentare le prestazioni del progetto.
Il vantaggio di questo processo è migliorare il lavoro di squadra, aumentare le competenze dei
membri del team, motivare i dipendenti e migliorare le prestazioni complessive del progetto.
Gestione del Team (Manage Team)
È il processo mediante il quale si monitora la performance dei membri del team, si forniscono
feedback, si risolvono i problemi e si gestiscono le modifiche del team con lo scopo di
ottimizzare le prestazioni del progetto.
Il vantaggio di questo processo è che influenza il comportamento del team, gestisce i conflitti,
risolve i problemi e valuta le prestazioni dei membri del team.
Project Communications Management
Gestione della comunicazione (Manage Communications)
È il processo per garantire la tempestiva e appropriata raccolta, creazione, distribuzione,
archiviazione, recupero, gestione, monitoraggio e archiviazione finale delle informazioni di
progetto.
Il vantaggio di questo processo è che consente un flusso di comunicazione efficiente ed efficace
tra gli stakeholders di progetto.
Project Procurement Management
Esecuzione degli approvvigionamenti(Conduct Procurements
È il processo mediante il quale si ottengono le offerte dei venditori, si seleziona un venditore e
si stipula un contratto.
Il vantaggio di questo processo è che consente l'allineamento alle aspettative degli stakeholders
interni ed esterni attraverso accordi stabiliti.
Project Stakeholder Management
Gestione del coinvolgimento degli stakeholders(Manage Stakeholder Engagement)
È il processo mediante il quale si comunica e si lavora con gli stakeholders per rispondere ai loro
bisogni/aspettative, si affrontano i problemi qualora si verificano e si promuovere un opportuno
coinvolgimento degli stakeholders nelle attività di progetto durante l'intero ciclo di vita del
progetto stesso.
Il vantaggio di questo processo è che permette al PM di aumentare il sostegno da parte degli
stakeholders e di ridurre al minimo la loro resistenza. In tal modo aumentano, in modo
significativo, le possibilità di raggiungere il successo del progetto.
Project Risk Management
Implementare le risposte al rischio (Implement Risk Responses)
È il processo di implementazione dei piani di risposta al rischio.
Il vantaggio di questo processo è di assicurare che le risposte al rischio concordate siano
eseguite come pianificato al fine di ridurre al minimo le minacce al progetto e massimizzare le
opportunità per il progetto.
Processi di Monitoraggio e Controllo
Sono quei processi necessari per monitorare e registrare i progressi e le prestazioni del progetto,
individuare eventuali settori (o aree) in cui sono necessarie modifiche rispetto alla pianificazione e avviare
le relative modifiche.
Il vantaggio di questo gruppo di processi è che la performance del progetto viene misurata e analizzata a
intervalli regolari o in corrispondenza di appropriati eventi o condizioni di eccezione per identificare gli
scostamenti dal piano di gestione del progetto.
Tali processi comprendono:
-il monitoraggio è la raccolta dei dati sulle prestazioni dei progetti, la produzione di misure di performance,
la rendicontazione e ladiffusione delle informazioni sulle prestazioni.
-il controllo: confrontare le prestazioni effettive con quelle pianificate, analizzare gli scostamenti, valutare
le tendenze per migliorare i processi, valutare le possibili alternative e raccomandare le opportune misure.
per migliorare il processo, valutare le possibili alternative e raccomandare le azioni correttive necessarie.
azioni correttive, se necessario.
Misure per un monitoraggio efficace
-Fornire una base condivisa per assumere decisioni
-Facilmente comprensibili
-Essere generalmente applicabili
-Essere interpretabili in modo univoco
-Essere economica la loro valutazione
-Fornire allarmi tempestivi riguardo la necessità di intervenire
-Fornire le informazioni alle persone cui sono necessarie
-Essere semplici
Monitoraggio e Controllo del lavoro del progetto (Monitor and Control Project Work)
È il processo di monitoraggio degli avanzamenti complessivi nonché le revisioni e le segnalazioni al
fine di raggiungere gli obiettivi definiti nel piano di gestione del progetto.
Il vantaggio di questo processo è che consente agli stakeholder di capire lo stato attuale del
progetto, riconoscere le azioni intraprese per affrontare qualsiasi problema che influenza la
performance, ed effettuare previsioni di costo e di tempi.
Project Integration Management
Controllo integrato delle variazioni (Perform Integrated Change Control)
È il processo di revisione, di approvazione e di gestione di tutte le richieste di modifiche. Tale
processo esamina tutte le richieste di cambiamenti o modifiche ai documenti di progetto, ai
deliverables, alle baseline o al piano di gestione del progetto e le approva o le respinge.
Il vantaggio di questo processo è che permette di considerare in modo integrato le modifiche
documentate avvenute all'interno del progetto, riducendo così i rischi che spesso derivano da
modifiche apportate senza considerare gli obiettivi o i piani di progetto.
Project Scope Management
Validazione dello “scope” (Validate scope)
È il processo di approvazione formale dei deliverables di progetto completati.
Il vantaggio di questo processo è che tramite la validazione di ogni deliverable, rende oggettivo il
processo di accettazione e aumenta la possibilità di accettazione del prodotto finale, servizio o
risultato.
Controllo dello “scope” (Control scope)
È il processo di monitoraggio dello stato del progetto e del prodotto e di gestione dei cambiamenti
rispetto alla baseline dello “scope”.
Il vantaggio di questo processo è che permette che la baseline dello “scope” sia preservata nel
corso del progetto.
Schedule Management
Controllo dello schedule (Control schedule)
È il processo di monitoraggio dell’avanzamento delle attività del progetto. Tale processo serve ad
aggiornare i progressi del progetto e a gestire i cambiamenti della schedule baseline per realizzare
quanto pianificato.
Il vantaggio di questo processo è che fornisce i mezzi per riconoscere le deviazioni rispetto a quanto
pianificato e adottare azioni correttive e preventive per minimizzare i rischi.
Project Cost Management
Controllo dei costi (Control Costs)
È il processo di monitoraggio dello stato del progetto tramite il quale si aggiornano i costi del
progetto e si gestiscono le modifiche alla baseline di costo.
Il vantaggio di questo processo è che fornisce i mezzi per riconoscere le variazioni rispetto a quanto
pianificato al fine di intraprendere azioni correttive e ridurre al minimo il rischio.
Quality Management
Controllo della Qualità (Control Quality)
l processo di monitoraggio e registrazione dei risultati delle attività di gestione della qualità per
valutare le prestazioni e garantire che i risultati del progetto siano completi, corretti e soddisfino le
aspettative dei clienti. I principali vantaggi di questo processo sono:
Verificare che i risultati del progetto e il lavoro soddisfino i requisiti specificati dagli stakeholder per
l'accettazione finale.
Individuare le cause della scarsa qualità dei prodotti o del processo per consigliare azioni e/o
intervenire con azioni per eliminarle.
Communications Management
Monitorare le comunicazioni (Monitor Communications)
È il processo di monitoraggio e controllo delle comunicazioni lungo tutto il ciclo di vita del progetto
per garantire le esigenze di informazione del progetto e dgli stakeholders.
Il vantaggio di questo processo è garantire il flusso di informazioni definito nel piano di gestione
delle comunicazioni e nel piano di coinvolgimento degli stakeholder.
Risk Management
Monitoraggio dei rischi (Monitor Risks)
È il processo di monitoraggio dell'implementazione di piani di risposta al rischio concordati,
tracciando i rischi, identificando e analizzando nuovi rischi e valutando l'efficacia del processo di
gestione del rischio durante tutto il progetto.
Il vantaggio di questo processo è che migliora l'efficienza dell'approccio al rischio e che consente ai
decisori di basarsi su informazioni correnti riguardo l’esposizione al rischio.
Procurement Management
Controllo degli approvvigonamenti (Control Procurements)
È il processo mediante il quale si gestiscono le relazioni in materia di approvvigionamenti, si
monitorano le prestazioni del contratto e si apportano le modifiche e le correzioni ai contratti a
seconda dei casi e si chiudono i contratti.
Il vantaggio di questo processo è che garantisce che le prestazioni del compratore e del venditore
soddisfino le esigenze del progetto e i requisiti legali in materia di acquisti.
Project Stakeholders Management
Monirorare l’Impegno degli Stakeholder (Monitor stakeholder engagement)
È il processo di monitoraggio delle relazioni con gli stakeholders di progetto e di adeguamento delle
strategie e dei piani per coinvolgere gli stakeholders.
Il vantaggio di questo processo è che manterrà o aumenterà l'efficienza e l'efficacia delle attività di
coinvolgimento degli stakeholder durante il progetto.
Project Resourse Management
Controllo delle Risorse (Control Resources)
È il processo per assicurare che le risorse assegnate al progetto siano disponibile secondo le
previsioni, inoltre è monitorato l'utilizzo pianificato delle risorse rispetto all’utilizzo effettivo e
vengono adottate misure correttive se necessarie.
Il vantaggio di questo processo è garantire che le risorse assegnate siano disponibili per il progetto
al momento giusto e nel posto giusto e che vengano rilasciate quando non sono più necessarie.
Processi di Chiusura
Si compone di quei processi eseguiti per concludere tutte le attività di tutti i gruppi di processi per
completare formalmente il progetto, la fase o gli obblighi contrattuali.
Questo gruppo di processi formalizza anche l’eventuale chiusura prematura del progetto.
In casi specifici, quando alcuni contratti non possono essere formalmente chiusi o alcune attività devono
essere trasferite ad altre unità organizzative, si devono prevedere procedure specifiche.
La chiusura del progetto o fase, può significare:
-l'accettazione da parte del cliente o sponsor per chiudere formalmente il progetto o la fase;
-Una chiusura anticipata in quanto il progetto è stato cancellato;
-L’aggiornamento dei processi organizzativi;
-L’archiviazione di tutti i documenti relativi al progetto nel sistema informativo di gestione del progetto
(PMIS) da utilizzare come dati storici;
-La chiusura di tutte le attività di acquisto assicurandosi della risoluzione degli accordi;
-la valutazione dei membri del team e il rilascio delle risorse del progetto.
Chiusura del progetto o della fase (Close Project or Phase)
È il processo di chiusura di tutte le attività del progetto, fase o contratto.
Il vantaggio di questo processo è che sono archiviate le informazioni sul progetto o sulla fase, il
lavoro pianificato è completato e le risorse vengono rilasciate per essere nuovamente assegnate
Project Information
Durante il ciclo di vita del progetto vengono raccolte molte informazioni, analizzate, trasformate e
distribuite. I dati vengono raccolti durante l’esecuzione del progetto ed elaborati nei processi di controllo.
Le informazioni sono comunicate e conservate
Tipi di informazioni:
Work performance data – Le osservazioni e misure grezze effettuate nel corso della realizzazione del
progetto. (completamento fisico delle attività, misure della qualità e della performance tecnica, inizio e
fine delle attività schedulate, numero di variazioni richieste, numero di difetti, costi e durate effettive, ecc.)
Work performance information - I dati sulle performance derivate dai vari processi di controllo e dai Work
performance data, analizzati nel contesto e integrati sulla base di relazioni tra le aree (es.: lo stato dei
deliverable, il grado di implementazione delle richieste di variazione, le previsioni al completamento,
earned value, SV, SPI, CV, CPV, cause di rifiuto, rielaborazioni richieste, elenchi di risultati verificati, stato
delle metriche di qualità, ecc.). Le metriche specifiche sulla performance del lavoro per ambito,
programma, budget e qualità sono definite all'inizio del progetto come parte del piano di gestione del
progetto.
Work performance report - La rappresentazione di informazioni sulle prestazioni del lavoro riportate in
documenti di progetto, destinate a produrre decisioni o sollevare questioni, azioni, o creare
consapevolezza. (rapporti sullo stato del progetto, memos, giustificazioni, dashboard, raccomandazioni,
note informative, ecc.)
Baseline del progetto
La versione approvata di un prodotto e del lavoro che può essere modificata solo attraverso formali
procedure di cambiamento ed è utilizzato come base per il confronto tra il realizzato e il pianificato.
La baseline del progetto comprende:
-Lo Scope baseline: Project Scope Statement, WBS, WBS dictionary, Work package,Control Account,
Planning package
-Schedule baseline
-Cost baseline
Il Tailoring significa andare a ritagliare le modalità di gestione di un processo e determinare l'appropriata
combinazione di processi, input, tool, output e life cycle per un determinato progetto: un progetto
complesso ha bisogno di maggiore formalità
Project Business Case
È un tema fondamentale del Prince 2: bisogna mettere alla base del progetto le motivazioni per cui si sta
realizzando il progetto; se vengono meno i motivi, il progetto va arrestato. Le motivazioni potrebbero
essere di carattere legale: se tali motivazioni vengono variate, esistono buoni motivi per sospendere il
progetto. Se da una successiva analisi costi-benefici emerge che il progetto non rende sufficienti benefici, è
consigliato sospendere il progetto. Il Prince 2 definisce il business case e specifica, a differenza del PMI,
come utilizzarlo. Fornisce le informazioni necessarie, da un punto di vista economico, per valutare se
realizzare il progetto. È comunemente usato per il processo decisionale da manager o dirigenti. Lo sponsor
dovrebbe condividere lo “scope” e i limiti del business case.
Un business case deve documentare:
•
Cosa spinge il progetto
•
Documentare il problema o l'opportunità e il suo valore
•
Identificare gli stakeholder
•
Definire lo scope
•
Identificare le strategie, le finalità e gli obbiettivi dell'organizzazione
•
Identificare le cause alla radice del problema o i fattori che creano l'opportunità
•
Analizzare il gap tra le capacità dell'organizzazione esistenti e disponibili.
•
Identificare i rischi conosciuti
•
Identificare i fattori critici di successo
•
Identificare i criteri decisionali per assumere decisioni.
Project benefits management plan
Il piano di gestione dei benefici del progetto è il documento che descrive come e quando si avranno i
benefici del progetto e descrive i meccanismi per misurare tali benefici. I benefici sono risultati di azioni,
prodotti, servizi e cultura che forniscono valore allo sponsor ed ai beneficiari.
Esso dovrebbe contenere:
-Benefici target (ad esempio, il valore tangibile e intangibile che si prevede di ottenere
dall'implementazione del progetto; il valore finanziario è espresso come valore attuale netto).
realizzazione del progetto; il valore finanziario è espresso come valore attuale netto);
- Allineamento strategico (ad esempio, il grado di allineamento dei benefici del progetto alle strategie
aziendali dell'organizzazione).
dell'organizzazione);
-Tempistica per la realizzazione dei benefici (ad esempio, benefici per fase, a breve termine, a lungo
termine e in corso).
in corso);
-Proprietario dei benefici (ad esempio, la persona responsabile del monitoraggio, della registrazione e della
rendicontazione dei benefici realizzati nel corso dei tempi stabiliti.
benefici realizzati per tutto l'arco di tempo stabilito nel piano);
- Metriche (ad esempio, le misure da utilizzare per mostrare i benefici realizzati, le misure dirette e quelle
indirette).
misure indirette);
-Ipotesi (ad esempio, i fattori che si prevede siano presenti o in evidenza); e
- Rischi (ad esempio, i rischi per la realizzazione dei benefici).
PROJECT INTEGRATION MANAGEMENT
Comprende i processi e le attività volte a individuare, definire, combinare, unificare e coordinare i vari
processi e le attività di gestione del progetto.
Il Project Integration Management riguarda:
- L’allocazione delle risorse.
- Il bilanciamento delle competenze.
- Esaminare l’approccio alle alternative.
- Effettuare il tailoring dei processi per raggiungere gli obbiettivi di progetto.
- Gestire le interdipendenze tra le diverse aree della conoscenza.
Configuration Management System : Un sottosistema del sistema complessivo di gestione del progetto che
fa parte del PMIS. Si tratta di una collezione di procedure documentate e formali utilizzate per:
-identificare e documentare le caratteristiche fisiche e funzionali di un prodotto, risultato, servizio o
componente;
stato di attuazione;
-sostenere il controllo dei prodotti, risultati, o componenti per verificare la conformità ai requisiti. Esso
comprende la documentazione, i sistemi di tracciamento, i livelli di approvazione necessari per
l'autorizzazione e controllo delle modifiche.
Develop Project Charter
È lo sviluppo di un documento che autorizza formalmente il progetto.
-Da l’autorità al PM: di utilizzare le risorse dell’organizzazione per lo svolgimento delle attività di progetto;
per pianificare ed eseguire il progetto.
-Il PM dovrebbe partecipare allo sviluppo del Project Charter in modo da comprendere i requisiti del
progetto, questo consentirà una migliore allocazione delle risorse alle attività di progetto.
-Dovrebbe essere approvato dallo sponsor.
-Tale processo deve altresì garantire il collegamento tra il progetto e gli obbiettivi strategici dell’azienda.
-I progetti sono realizzati per soddisfare esigenze di business interne o esterne.
-Non è di per se un contratto, ma un contratto può fare parte del Project Charter.
Vantaggi: La formalizzazione del progetto; Inizio e confini del progetto ben definiti; L’ approvazione del
Project Charter da parte dello sponsor è un modo affinché i dirigenti accettino e riconoscano formalmente
il progetto e si impegnino nel realizzarlo.
INPUT per il project charter: BUSINESS DOCUMENT
 BUSINESS CASE:
-In genere contiene l’analisi di fattibilità, la necessità di business e l'analisi costi-benefici che permettono di
stabilire i limiti che rendono fattibile sotto un punto di vista tecnico ed economico il progetto. Tale analisi
sono eseguite da analisti di business che utilizzano gli input provenienti dai vari stakeholder.
-Lo sponsor deve condividere lo “scope” e i limiti del business case.
-Esso deriva generalmente da: domanda di mercato, necessità, organizzative, esigenze dei clienti,
innovazione tecnologica, ragioni legali, motivi sociali (problema da risolvere o opportunità da cogliere).
Nelle prime fasi del ciclo di vita del progetto, revisioni periodiche del business case da parte degli sponsor
possono essere utili a confermare che il progetto è allineato con il business case.
Il PM deve assicurarsi che il progetto soddisfi gli obiettivi dell'organizzazione come definito nel business
case.
Il business case può contenere: le necessità di business, l’analisi della situazione, il set delle opzioni per
risolvere il problema o cogliere l’opportunità, le raccomandazioni, la valutazione dei benefici.
 Benefits Management Plan:
Il piano di gestione dei benefici del progetto è il documento che descrive come e quando i benefici del
progetto saranno realizzati e descrive come saranno misurati tali benefici. Il piano di gestione dei benefici
descrive gli elementi chiave dei benefici e può includere ma non è limitato a documentare quanto segue:
-I Target dei benefici
-L’allineamento strategico del progetto con le strategie aziendali
-I tempi nei quali si realizzeranno i benefici
-I responsabili riguardo i report dei benefici
-Le metriche da utilizzare
-Le ipotesi e i rischi
INPUT per il project charter: AGREEMENTS
Agreemets: ad es. contratti (solitamente usati quando il progetto è eseguito per un cliente esterno), lettere
di intenti, verbali, e-mail, etc. Gli agreement si riferiscono a documenti che definiscono l'intento del
progetto e di solito sono di tipo legale. Per esempio, un contratto è un esempio di un agreement. Altri
accordi potrebbero includere un protocollo d'intesa, email, un contratto di agenzia intergovernativa, un
impegno verbale, e così via.
INPUT per il project charter: ENTERPRISE ENVIRONMENTAL FACTORS
-Standard governativi e di settore -Leggi, regolamenti e vincoli -Condizioni del mercato -Cultura
dell’organizzazione -Sistema organizzativo aziendale, politiche aziendali -Aspettative e rischi accettati degli
stakeholder
INPUT per il project charter: Organizational Process Assets
-Standard organizzativi, processi e procedure -Quadro di governance del portfolio, dei programmi e dei
progetti
-Metodi di monitoraggio e relativi report -Modelli di documenti (Templates)
-Modalità di conservazione delle informazioni storiche e delle lesson learned
TOOL & TECHINIQUES
1.
Expert Judgment: è spesso usato per valutare gli input utilizzati per sviluppare il Project Charter.
Tale competenza è fornita da qualsiasi gruppo o individuo con conoscenze specializzate sotto il profilo
tecnico, organizzativo e in relazione all’identificazione del rischio.
2.
Data gathering: Le tecniche di raccolta dei dati includono ma non sono limitate a: Focus groups,
Brainstorming, Interviews.
3.
Interpersonal and team skill: capacità interpersonali, sono ma non soltanto:
-Gestione dei conflitti (9.5.2.1)
-Tecniche di facilitazione
-Modalità di gestione delle riunioni (10.2.2.6)
4.
Meeting: servono per identificare gli obbiettivi, individuare i criteri di successo, i risultati chiave, i
requisiti (requirements) di alto livello, milestone principali, ecc.
OUTPUTS
1. Project Charter: documento che autorizza formalmente il progetto; da l’autorità al PM di utilizzare le
risorse dell’organizzazione per lo svolgimento delle attività del progetto.
Esso contiene informazioni di alto livello sul progetto, sul prodotto, sul servizio o risultati in generale che il
progetto intende realizzare, come: Lo scopo del progetto
Chi redige il Project Charter? In teoria il Project Sponsor (Senior Management) in pratica il PM o lideatore
del progetto.
Chi approva il Project Charter?:Il Project Sponsor (chi fornisce le risorse finanziarie in cash o kind), a volte
congiuntamente con il cliente. Tale approvazione autorizza il PM alla spesa.
Alcune volte può essere un documento legale come ad esempio un contratto, un ordine o un’offerta
2. Assumption Log: Il log delle assunzioni è un registro che viene utilizzato per registrare tutte le ipotesi e i
vincoli durante l’intero ciclo di vita del progetto e quindi a partire dal business case e dal project charter
SVILUPPO DEL PROJECT MANAGEMENT PLAN
Consiste nel definire, preparare, coordinare tutti i piani ausiliari e nella loro integrazione in un piano globale
di gestione del progetto.
-Il piano di gestione del progetto definisce come deve essere realizzato, monitorato, controllato e chiuso il
progetto.
-Il contenuto di tale piano varia a seconda del campo di applicazione e della complessità del progetto.
-Il risultato di questo processo è un piano di gestione del progetto che è elaborato progressivamente,
aggiornato, controllato e approvato.
-Tale piano deve essere coerente con il piano di gestione del programma.
Il vantaggio di questo processo è avere un documento che costituisce la base di ogni lavoro del progetto e
di come sarà realizzato.
Il project management plan può essere sommario o dettagliato in funzione dello specifico progetto.
Il project management plan dovrebbe costituire la baseline almeno per lo scope, il tempo e il costo da
utilizzare durante la realizzazione per paragonare il realizzato con il pianificato e approvato.
INPUT
1.Project Charter: la dimensione di tale documento dipende dalla complessità del progetto e dalle
informazioni che si hanno al momento della sua creazione. La dimensione minima del documento è quella
che contiene i confini del progetto. Il Project Team usa il Project Charter come start per la pianificazione
iniziale.
2.Output From Other Process: le baseline e i piani ausiliari che sono gli output per i processi di
pianificazione costituiscono gli input per questo processo.
3. Enterprise Enviromental Factors sono costituiti ma non solo da: Standard governativi e di settore; Leggi,
regolamenti e vincoli; Project management body of knowledge e focalizzazione sull’area; Condizioni del
mercato; Cultura dell’organizzazione; Sistema organizzativo aziendale, politiche aziendali, quadro
strutturato di riferimento organizzativo; Aspettative e rischi accettati degli stakeholder
4. Organizational Process Assets: sono costituiti ma non solo da: Standard organizzativi, processi e
procedure; Modelli di documenti (Templates) e linee guida del PM; Metodi di monitoraggio e relativi
report, procedure di controllo del rischio, esigenze di comunicazione; Procedure per l’approvazione delle
variazioni; Modalità di conservazione delle informazioni storiche e delle lesson learned; Informazioni da
progetti già eseguiti («scope», costi, calendari, registro dei rischi, misure della performance, ecc.);
TOOL & TECHINIQUES
1.Expert Judgment: il giudizio degli esperti è usato ad esempio per ritagliare il progetto per soddisfarne le
richieste, sviluppare dettagli tecnici e gestionali, determinare le risorse e il loro livello di skills necessarie
per il progetto, determinare quali documenti saranno soggetti al processo formale di controllo delle
variazioni, priorizzare il lavoro da svolgere in modo tale da assicurare che le risorse del progetto sono
allocate in modo appropriato e al tempo adatto.
2.Data gathering: le tecniche che possono essere usate per questo processo includono, ma non sono
limitate, le seguenti: Brainstorming; Checklist; Focus group; Interviews
3.Interpersonal and Team Skills: gli skill interpersonali e di team usati quando si sviluppa il piano di gestione
del progetto includono: Conflict management; Facilitation ; Meeting Management
4.Meetings: le riunioni vengono utilizzate per discutere l'approccio del progetto, determinare come il
lavoro verrà eseguito per raggiungere gli obiettivi del progetto e stabilire il modo in cui il progetto sarà
monitorato e controllato. Il kick-off può avvenire in diversi momenti nel tempo a seconda delle
caratteristiche del progetto: i progetti multifase in genere includono un incontro iniziale all'inizio di ogni
fase.
OUTPUTS
1.Project Management Plan: E’ il documento che descrive come verrà eseguito, monitorato e controllato il
progetto. Integra e consolida tutti i piani ausiliari e le baseline provenienti dai processi di pianificazione.
Le baseline del project management plan possono comprendere: Scope baseline; Schedule baseline; Cost
baseline.
I componenti del project management plan possono includere ma non sono limitati a:
-I piani ausiliari, che possono comprendere:Scope Management Plan; Requirements Management Plan;
Schedule Management Plan; Cost Management Plan; Quality Management Plan
-baseline
-Additional component:
-Piano di gestione dei cambiamenti: descrive come le richieste di modifica nel corso del progetto
saranno formalmente autorizzate e incorporate.
-Piano di gestione della configurazione: descrive come le informazioni sugli elementi del progetto
saranno registrate e aggiornate in modo che il prodotto, il servizio o il risultato del progetto
rimangano coerenti e/o operativi.
-Modi di misurare le prestazioni: Un metodo integrato scope-time-cost rispetto al quale viene
misurata e gestita la performance del progetto.
-Ciclo di vita del progetto: descrive la serie di fasi che il progetto attraversa dalla sua iniziazione alla
sua chiusura.
-Approccio di sviluppo: descrive il prodotto, il servizio o l'approccio di sviluppo dei risultati, come
predittivo, iterativo, agile o un modello ibrido.
-Revisione della gestione (management reviews): identifica i punti nel progetto dove il project
manager e gli stakeholder rilevano l'avanzamento del progetto per determinare se le prestazioni
sono quelle previste o se sono necessarie azioni preventive o correttive.
Dirigere e gestire il lavoro del progetto
E’ il processo mediante il quale si dirige e si svolge il lavoro definito nel Project Management Plan e
si attuano le modifiche approvate per raggiungere gli obiettivi del progetto.
Il vantaggio di questo processo è che fornisce la gestione complessiva del lavoro del progetto.
Il PM, insieme con il team di gestione del progetto, dirige lo svolgimento delle attività previste e
gestisce le varie interfacce tecniche e organizzative che esistono all'interno del progetto.
Durante l'esecuzione del progetto vengono raccolti e opportunamente comunicati i dati di
performance del lavoro (work performance data). Tali dati costituiscono i dati di input per il gruppo
di processo di Monitoraggio e Controllo.
INPUT
INPUT 1.Project Management Plan.
INPUT 2.Project Documents:
-Change log. Il change log contiene lo stato di tutti i cambiamenti richiesti.
-Lessons learned register.
-Milestone list.
-Project communications. Contiene le comunicazioni di progetto comprese le performance, lo stato
dei risultati (deliveribles) e altre informazioni in generale
-Project schedule.
-Requirements traceability matrix.
-Risk register.
- Risk report.
INPUT 3.Approved change request(spiegato in seguito).
INPUT 4.Enterprise Enviromental Factors: Infrastrutture (attrezzature e capitale)
Livello di rischio accettato dai portatori di interesse
INPUT 5. Organizational Process Assets: -Standard organizzativi, processi e procedure -Procedure
per la gestione dei difetti e dei problemi, -database contenenti difetti e problemi precedenti, stato
della procedura e delle azioni per la correzione dei difetti. -Data base delle misure di performance
sui processi e sul prodotto;-Procedure per l’approvazione delle variazioni -Modalità di
conservazione delle informazioni storiche e delle lesson learned -Informazioni da progetti già
eseguiti («scope», costi, calendari, registro dei rischi, misure della performance, ecc.); -Informazioni
da precedenti progetti.
TOOL & TECHINIQUES
1.Expert Judgment: sono fornite dal PM, dal team di gestione del progetto, da unità organizzative,
consulenti, stakeholders, associazioni professionali, etc.
2.Project Management Information System (PMIS):
Il PMIS fornisce l'accesso agli strumenti software IT (information technology), come strumenti
software di pianificazione, sistemi di autorizzazione del lavoro, sistemi di gestione della
configurazione, sistemi di raccolta e distribuzione delle informazioni, nonché si interfaccia con altri
sistemi automatizzati online come i repository di knowledge base aziendali. Raccolta automatizzata
e segnalazione di indicatori chiave di prestazione (KPI) può far parte di questo sistema.
Dirigere e Gestire il lavoro del progetto
3.Meeting: sono utilizzati per discutere e dare indirizzi riguardo temi del progetto, che riguardano la
direzione e la gestione del lavoro di progetto.
OUTPUTS
1.Deliverables: sono in genere componenti unici e verificabili per completare un processo, una fase
o il progetto.
2.Work Performance Data: sono le osservazioni grezze e le misure individuate durante lo
svolgimento delle attività. I dati vengono raccolti durante i processi di esecuzione e passati ai
processi di monitoraggio per analisi future (costituiscono il livello più basso di dettaglio
dell’informazione). Alcuni esempi di dati sono: il lavoro completato, KPI, date di inizio e fine delle
attività schedulate, numero di cambiamenti richiesti, etc.
3.Issue Log: è un documento dove i problemi sono registrati e tracciati, può includere:
-Il tipo di problema; -Chi lo ha rilevato; -La descrizione; -La priorità;
-A chi è affidato il problema -La data ultima per la sua risoluzione -Lo stato del problema
-La soluzione per risolvere il problema
4.Change request: (spiegato in seguito) una proposta formale di cambiamento di un prodotto,
baseline o documento. Può includere:
-Azioni correttive: attività che riallinea l'esecuzione del lavoro del progetto con il Project
Management Plan.
-Azioni preventive: attività che assicura che l’andamento futuro del lavoro del progetto sia allineato
con il Project Management Plan.
-Riparazione dei difetti: attività che modifica (“ripara”) un prodotto o un componente del prodotto
non conforme.
-Updates. Aggiornamento di documenti formali del progetto, di piani per riflettere i cambiamenti
proposti.
5.
Project Management Plan Update.
6.
Project Document Update. -Activity list. -Assumption log. -Lessons learned register.
-Requirements documentation.
-Risk register. -Stakeholder register.
7.
Organizational process assets updates
Manage Project Knowledge
Gestire la conoscenza del progetto è il processo attraverso cui si utilizzano le conoscenze esistenti e
si creano nuove conoscenze per raggiungere gli obiettivi del progetto e contribuire
all'apprendimento organizzativo.
I vantaggi chiave di questo processo sono che le conoscenze organizzative acquisite da precedenti
progetti sono sfruttate per produrre o migliorare i risultati del progetto e la conoscenza creata dal
progetto è disponibile per supportare operazioni organizzative e progetti o fasi futuri.
INPUT 1. Project Management Plan
2. Project Documents: -Lessons learned register. -Project team assignments. -Resource breakdown
structure. -Stakeholder register.
3. Deliverables
4.Enterprise Enviromental Factors: -Cultura organizzativa degli stakeholder e del cliente. L'esistenza
di rapporti di lavoro basati sulla fiducia e una cultura della non colpevolizzazione è particolarmente
importante nella gestione della conoscenza. Altri fattori includono il valore attribuito
all'apprendimento e alle norme comportamentali sociali.
Distribuzione geografica delle risorse. La posizione dei membri del team aiuta a determinare i
metodi per ottenere e condividere conoscenze. Esperti di conoscenza organizzativa. Alcune
organizzazioni hanno una squadra o un individuo specializzato nella gestione della conoscenza.
INPUT 4. Organizational Process Assets:
Politiche, processi e procedure standard organizzativi.
Modalità di amministrazione del personale.
Requisiti della comunicazione nell’organizzazione.
Procedure di condivisione delle conoscenze e di condivisione delle informazioni.
TOOL & TECHINIQUES
1.
Expert Judgment:
2.
Knowdledge Management: sono strumenti che consentono al team la condivisione della
conoscenza
3.
Information Management: gli strumenti di gestione dell’informazione sono utilizzati per
consentire di trasferire le informazioni alla gente, ad esempio: -Metodi per codificare la
conoscenza; -Registro delle lesson learned; -Project management information system (PMIS).
4.
Interpesonal and Team Skills: Ascolto attivo (Active listening). -Facilitare. -Leadership. Networking.-Capacità politica.
OUTPUT
1.
Lesson Learned Register: il registro delle lezioni apprese può includere la categoria e la
descrizione della situazione. Il registro delle lezioni apprese può anche includere l'impatto, le
raccomandazioni e le azioni proposte associate alla situazione. Il registro delle lezioni apprese può
registrare sfide, problemi, rischi e opportunità realizzati o altro contenuto appropriato.
2.
Project Management Plan Update
3.
Organizational Process Assets Updates
Monitoraggio e Controllo del lavoro del progetto
-Sono quei processi necessari per monitorare e registrare i progressi e le prestazioni del progetto.
-Il vantaggio di questo gruppo di processi è che permette di far comprendere agli stakeholders lo
stato attuale del progetto, gli step intrapresi, le previsioni sul budget, sullo schedule e sullo “scope”.
Il monitoraggio è un aspetto della gestione del progetto che si svolge durante il progetto. Il
monitoraggio continuo permette al team di gestione del progetto di avere informazioni sullo stato
di salute del progetto e individua le aree che richiedono particolare attenzione.
Il controllo comprende la determinazione delle azioni correttive o preventive o di ripianificazione e
una successiva analisi sui piani d'azione per stabilire se le azioni intraprese hanno risolto i problemi.
Tali processi riguardano:
-il confronto delle prestazioni attuali del progetto con quelle pianificate;
-la determinazione di eventuali azioni correttive o preventive e quindi la raccomandazione di
svolgere tali azioni, a seguito della valutazione della performance;
-l’identificazione di nuovi rischi, l'analisi e il monitoraggio dei rischi di progetto già identificati, la
segnalazione dell’accadimento degli eventi rischiosi e che di conseguenza appropriati piani di
risposta sono in corso di esecuzione;
-il mantenimento di un accurato e tempestivo database di informazioni riguardanti il prodotto del
progetto e la relativa documentazione;
-il fornire previsioni per aggiornare i costi correnti e le informazioni di pianificazione;
-il fornire segnalazioni sullo stato di avanzamento del progetto.
-il fornire informazioni che supportino le previsioni;
-il monitoraggio dell'attuazione delle modifiche approvate.
-Assicurarsi che il progetto sia allineato con le esigenze di business.
INPUT
1.Project Management Plan.
2.Project documents: -Assumption log. -Basis of estimates -Cost forecastsle previsioni di costo
derivano dal confronto tra il progresso e la baseline di costo e dal calcolo calcolato delle stime a
completamento (Estimate to Complete, ETC). Le previsioni sono solitamente espresse tramite i
seguenti indici: Cost Variance (CV) e Cost Performance Index (CPI). La stima al completamento
(EAC) può essere confrontata con il budget a completamento (BAC) per vedere se il progetto è
ancora nel range di tolleranza o se sono necessarie richieste di modifica.
-Issue log.
-Lessons learned register
-Milestone list
-Quality reports.
-Risk register.
-Risk report.
-Schedule forecasts:Le previsioni di pianificazione derivano dal confronto tra l’avanzamento e la
baseline dello schedule e dal calcolo delle stime del tempo a completamento (Estimate to
Complete, ETC). I confronti sono solitamente espresse tramite i seguenti indici: Schedule Variance
(SV) e Schedule Performance Index (SPI). La previsione può essere utilizzata per determinare se il
progetto è ancora all'interno dei campi di tolleranza definiti e per identificare eventuali richieste di
modifica.
3.Work performance information: sono le informazioni sulle prestazioni raccolti da vari processi di
controllo. Esempi di informazioni di performance sono: lo stato dei deliverables, lo stato di
implementazione delle richieste di variazioni e le stime di previsioni per il completamento.
4. Agreements: Un accordo che include termini e condizioni ed eventualmente altri elementi che
l'acquirente specifica in merito a ciò che il venditore deve eseguire o fornire.
5.Enterprice environmental factors:Sistemi di informazione sulla gestione di progetti (PMIS) quali
strumenti di pianificazione, costi, risorse, indicatori di prestazione, banche dati, registrazioni di
progetti e dati finanziari; Infrastrutture (ad esempio, strutture e attrezzature esistenti, canali di
telecomunicazione dell'organizzazione); Aspettative aspettative degli stakeholders e loro soglie di
rischio; Norme governative o industriali (ad es. Regolamenti delle agenzie di regolamentazione,
standard di prodotto, standard di qualità e standard di lavorazione).
5. Organization process assets:
esempio, revisioni spese e esborsi, codici contabili e disposizioni contrattuali standard);
-Metodi di monitoraggio e segnalazione;
-Procedure di gestione per l’identificazione e i controlli dei problemi, e il tracciamento delle azioni
per risolvere i problemi;
-Procedure per la gestione dei difetti che definiscono l’identificazione e i controlli dei difetti,
nonché la soluzione e il tracciamento delle azioni per la correzione dei difetti;
-Conoscenze organizzative di base, in particolare i processi di misura e il repository delle lezioni
apprese.
TOOL & TECHINIQUES
1.
Expert Judgment: usato per interpretare le informazioni provenienti dai processi di
monitoraggio e controllo.
2.
Data Analysis: Alternatives analysis; Cost-benefit analysis; Earned value analysis; Root cause
analysis; Variance analysis; Trend analysis.
3.
Decision Making
4.
Meeting: ad esempio meeting “faccia a faccia” o virtuali, formali o informali.
Monitoraggio e controllo del lavoro del progetto
OUTPUTS
1.
Work Performance Reports: sono la rappresentazione
(cartacea o digitale) delle informazioni sulla performance del lavoro che possono essere utilizzati
per generare decisioni o azioni. Le informazioni sul progetto possono essere comunicate
verbalmente da persona a persona. Tuttavia, al fine di registrare, memorizzare e, talvolta,
distribuire informazioni sulla performance del lavoro è necessaria una rappresentazione cartacea o
digitale). Tali report sono un sottoinsieme dei documenti di progetto, che sono destinati a creare
consapevolezza e generare decisioni o azioni.
2.
Change Request:
3.
Project Management Plan Update.
4.
Project Document Update. -Cost forecasts. -Issue log. -Lessons learned register.-Risk
register. -Schedule
Controllo integrato delle variazioni
E’ il processo di approvazione di tutte le richieste di modifiche. Tale processo esamina tutte le
richieste di cambiamenti o modifiche ai documenti di progetto, ai deliverables, alle baseline o al
piano di gestione del progetto e le approva o le respinge. Il vantaggio di questo processo è che
permette di considerare in modo integrato le richieste di modifiche riducendo così i rischi di
progetto. Tali rischi infatti spesso derivano da modifiche apportate senza considerare le variazioni
in modo integrato rispetto agli obiettivi e ai piani di progetto.
E’ un processo che si sviluppa dall’inizio del progetto fino al suo completamento e la cui
responsabilità è del PM.
Le variazioni possono essere richieste da qualsiasi stakeholders.
Anche se le variazioni possono inizialmente essere richieste in forma verbale vanno poi trascritte e
inserite nel sistema di gestione delle variazioni.
Ogni richiesta di variazione documentata deve essere approvata o respinta da un responsabile (di
solito è lo sponsor o il PM).
L’approvazione di variazioni può richiedere variazioni nelle stime dei costi, nelle sequenze di
attività, nelle date schedulate, nella richiesta di risorse, etc. Questi cambiamenti dunque implicano
variazioni nei documenti di pianificazione.
INPUT
1.
Project Management Plan: le variazioni sono documentate nel Project Management Plan
che viene anche aggiornato.
2.
Project Documents
3.
Work Performance Reports: includono la disponibilità delle risorse, dati di schedule e costi,
report sull’Earned Value, etc.
4.
Change Request: (spiegato precedentemente)
5. Enterprise Enviromental Factors:
-Regolamenti nazionali o locali;
-Norme industriali (ad esempio standard di prodotto, standard di qualità, standard di sicurezza e
standard di lavorazione);
-Altri requisiti legali e regolamentari e/o vincoli; -Quadro della governance organizzativa e -Vincoli
contrattuali e di acquisto.
Controllo integrato delle variazioni
6. Organizational Process Assets:
-Procedure per il controllo delle modifiche, compresi i passaggi in base ai quali verranno modificati
gli standard organizzativi, le politiche, i piani, le procedure o eventuali documenti di progetto;
-Procedure per l'approvazione e l'emissione delle autorizzazioni delle modifica;
-Configurazione della gestione della Knowledge Base contenente tutti gli standard, le politiche, le
procedure e tutti i documenti di progetto ufficiali dell'organizzazione.
Controllo integrato delle variazioni
TOOL & TECHINIQUES
1.Expert Judgment: possono essere fornite da consulenti,
stakeholders, associazioni professionali e tecniche, gruppi industriali, PMO, etc.
2.Change Control Tools: per facilitare la gestione delle configurazioni e delle variazioni sono usati
strumenti manuali o automatici.
3.Data Analysis
4.Decision Making: Voting; Autocratic decision making; Multicriteria decision analysis.
5.Meeting: il board di controllo dei cambiamenti (Change Control Board, CCB) è responsabile dei
meeting,di rivisitare le richieste di variazioni, di approvare, rigettare o dare altre disposizioni sulle
variazioni.
OUTPUTS
1.Approved Change Request: (già spiegato)
2.Project Management Plan Update.
3.Project Document Updates.
CHIUSURA DEL PROGETTO O DELLA FASE
E’ il processo di chiusura di tutte le attività di tutti i gruppi di processi di gestione del progetto per
completare formalmente il progetto o la fase.
Il vantaggio di questo processo è che fornisce le lezioni apprese, la fine formale del progetto e il
rilascio di risorse organizzative per perseguire nuovi impegni.
Quando il progetto si chiude il PM si deve assicurare che tutti i lavoro del progetto sono completati
e che il progetto abbia raggiunto i suoi obiettivi.
Questo processo definisce anche le procedure per indagare e documentare le ragioni delle azioni
intraprese nel caso in cui un progetto venga terminato prima del suo completamento.
Le attività necessarie per la chiusura amministrativa del progetto o della fase includono, a titolo
esemplificativo ma non esaustivo:
Azioni e attività necessarie per verificare il soddisfacimento dei criteri di completamento della fase
o del progetto o di interruzione anticipata come:
-Accertarsi che tutti i documenti e i deliverable siano aggiornati e che tutti i problemi siano risolti;
-Confermare la consegna e l'accettazione formale dei prodotti da parte del cliente;
-Garantire che tutti i costi siano addebitati al progetto;
-Chiusura degli account di progetto;
-Riassegnazione del personale;
-Gestire le rimanenze del progetto.
-Rilascio delle strutture, attrezzature e altre risorse del progetto;
-Elaborazione dei report di progetto finali come richiesto dalle politiche organizzative.
Attività relative al completamento degli accordi contrattuali applicabili alla fase al progetto quali:
-Accettazione formale del lavoro da parte del cliente
-Chiusura dei reclami aperti
-Aggiornamento dei record che riflettano i risultati finali
-Archiviare le informazioni per l’uso futuro.
Attività necessarie per:
-Raccogli record di
-Gestire la condivisione e il trasferimento delle conoscenze,
-Identificare le lezioni apprese
-Archiviare le informazioni sul progetto per uso futuro da parte dell'organizzazione.
Azioni e attività necessarie per trasferire i prodotti, i servizi i risultati del progetto alla fase
successiva o alla produzione e/o alle operations.
Raccolta di suggerimenti per migliorare o aggiornare le politiche e le procedure dell'organizzazione
e inviarli all'unità organizzativa appropriata.
Misurare la soddisfazione degli stakeholder.
INPUT
1.Project Charter
2.Project Management Plan.
3.Project Documents: Assumption log; Basis of estimates; Change log; Issue log; Lessons learned
register; Milestone list; Project communications; Quality control measurements; Quality reports;
Requirement documentation; Risk register; Risk report
4.Accepeted Deliverables: può includere le specifiche approvate per il prodotto, ricevute di
consegna, e i documenti di performance del lavoro.
5.Business Documents
6.Agreement
7.Procurement Documentation
8.Organizational Process Assets
TOOL & TECHINIQUES
1.Expert Judgment: gli esperti assicurano che la chiusura del progetto o della fase segue opportuni
standard. Essi possono essere altri PM all’interno dell’organizzazione, PMO, associazioni
professionali e tecniche.
2.Data Analysis
3.Meeting: ad esempio meeting “faccia a faccia” o virtuali, formali o informali.
OUTPUTS
1.Project Document Updates.
2.Final product, service or result transition
3.Final report
4.Organizational process assets updates: -Project documents. -Operational and support documents.
-Project or phase closure documents. -Lessons learned repository.
LA WBS
Work: Il lavoro fisico o mentale necessario per raggiungere un obiettivo o un risultato.
Breakdown: Significa dividere il progetto in parti più piccole per capire cosa deve essere fatto.
Structure: è il modello di rappresentazione basato su relazioni logico-gerarchiche.
WBS secondo il PMBOK: Il raggruppamento gerarchico degli elementi di progetto in base ai
deliverable che organizza e definisce il contenuto totale dei lavori del progetto. Ciascun livello
inferiore dello schema rappresenta una definizione sempre più dettagliata del progetto.
Deliverable: Qualsiasi risultato, esito o elemento misurabile, reale, verificabile che deve essere
realizzato per completare un progetto o parte di un progetto.
Caratteristica della WBS: Deve contenere tutto e soltanto il lavoro necessario per la realizzazione
del progetto. È comune a progetti dello stesso tipo.
A chi è diretta? Sia all’esterno: Verso il cliente ed altri portatori d’interesse, strumento di
accountability.
Sia all’interno: Per tutte le fasi di gestione del progetto.
A cosa serve? Una buona WBS contribuisce a condurre il progetto con successo.
Ha diverse finalità tra le quali: Aiuta a capire il progetto; A gestire il progetto; A comprendere le
relazioni tra le attività; È un input per altri processi di pianificazione; Consente di gestire il controllo
sull’avanzamento; Consente il controllo sui costi; È uno strumento di comunicazione ai portatori
dinteresse (fornitori); Facilita lo sviluppo del piano di gestione del rischio.
Scomposizione del progetto
1)
Identificare i principali elementi di un progetto, in genere caratterizzati dai deliverables.
Esempio: fasi del ciclo di vita.
2)
Decidere se il livello di dettaglio è adeguato in funzione del processo, se adeguato si passa
al punto 4) altrimenti si passa al punto 3).
3)
Per ogni elemento se non c’è un adeguato livello di dettaglio si suddivide l’elemento in
elementi di livello inferiore, ripetere il passo 2) per ogni elemento della WBS.
4)
Identificare gli elementi che costituiscono ogni risultato tangibile ed intangibile e descriverli
in modo da facilitare la misura della performance. Verificare la correttezza della scomposizione:
Dettaglio necessario e sufficiente.
Chiarezza descrizione dell’elemento.
Verificare la possibilità di schedulare, budgettizzare, assegnare la responsabilità.
Non tutti gli elementi principali avranno lo stesso numero di livelli.
Il numero massimo di livelli è compreso fra 3 e 5.
Il fornitore avrà una sua WBS di maggiore dettaglio.
La WBS del committente è diversa da quella del contractor.
Livelli della WBS
1.
Nome del progetto
1.1
Principali sottosistemi del progetto
1.1.1Compiti (task)
1.1.1.1 Sub-compiti (subtask)
1.1.1.1.1
Work package
1.1.1.1.1.1 Componenti
1.
Nome del progetto
1.1
Principali sottosistemi del progetto
1.1.1Compiti (task)
1.1.1.1 Work package
Dal PMBOK:
-I lavori programmati sono contenuti all'interno del livello più basso della WBS e sono chiamati
work package.
-In un work package possono essere raggruppate le attività attraverso le quali il lavoro è pianificato
e stimato, monitorato e controllato.
-Nel contesto della WBS, per lavoro si intende non l'attività stessa, ma il prodotto del lavoro o
risultati (deliverable) che sono l’output della attività stessa.
Fattori a favore di WP più piccoli e quindi maggior numero di WP
-Monitoraggio e controllo (valutare l’avanzamento di una WP piccola è più semplice)
-Cash flow
-Costruzione del reticolo
-Necessità di una stima più precisa dei costi e dei tempi
Fattori a favore di WP più grandi e quindi meno WP
-Difficoltà a stimare costi e tempi o precisione non necessaria (ipotizzando +-X%)
-Workload del PM (più piccole sono le WP più elevato è il lavoro di pianificazione, controllo e
gestione per il PM)
Fattori che costituiscono vincoli per la dimensione della WP
-Assegnazione delle responsabilità
-Coesione interna (risorse richieste, periodo di esecuzione, criteri di completamento, condizioni di
avvio)
-Rischio (un’attività molto rischiosa è meglio costituisca una WP)
Organizzazione della WBS
-Orientata al prodotto: Prodotti principali; Servizi; Risultati
-Orientata alle fasi
-Orientata alle funzioni o all’organizzazione
-Orientata al lavoro
-Orientata agli obiettivi
-Orientata alla localizzazione
OBS – Organizational Breakdown Structure
Essa è una struttura funzionalmente orientata, contenente le relazioni tra le componenti
organizzative coinvolte nel progetto, che è usata come quadro logico per l’assegnazione delle
responsabilità dei diversi elementi della WBS. Il dettaglio della struttura organizzativa arriva al più
basso livello della gestione che è quel livello organizzativo a cui vengono assegnate le risorse e le
responsabilità necessarie per realizzare il progetto.
MATRICE RACI
La matrice di assegnazione responsabilità RAM (Responsibility Assignment Matrix) pone in relazione
le risorse con le attività delle quali sono responsabili. Una tipologia specifica di matrice di
responsabilità è la matrice RACI prende la propria denominazione dalle iniziali dei ruoli previsti in
lingua inglese per l'esecuzione delle attività dei processi aziendali.
I ruoli previsti dalla matrice RACI sono:
Responsible (R): è colui che esegue ed assegna l'attività
(per ogni attività vi può essere più di un responsible
Accountable (A) è colui che ha la responsabilità del risultato dell'attività. A differenza degli altri 3
ruoli, per ciascuna attività deve essere univocamente assegnato. Solitamente è
la persona a cui si deve riferire il/i Responsible nell’organigramma di progetto o che comunque è il
supervisione del lavoro del/dei Responsible e quindi il responsabile dei risultati.
Consulted (C) è la persona che aiuta e collabora con il Responsible per l'esecuzione dell'attività.
Informed (I) è colui che deve essere informato al momento dell'esecuzione dell'attività.
RBS (Resourse Breakdown Structure)
Secondo il PMBOK rappresenta una variante della OBS utilizzata quando il lavoro è assegnato a
singoli individui.
Anche in questo caso si utilizzerà la RAM per mettere in relazione la persona che svolge il lavoro o il
lavoro o responsabile agli elementi della WBS.
Altri autori considerano la RBS come una rappresentazione strutturata delle
risorse umane e materiali necessarie per realizzare il progetto.
Risk Breakdown Structure (RiBS) Struttura di ripartizione del rischio (RiBS)
Una struttura gerarchica degli eventi casuali che possono influenzare negativamente il progetto.
influenzare negativamente il progetto, passando dai livelli più alti a quelli più bassi,
gli eventi casuali vengono rappresentati in modo più dettagliato, ad esempio la gestione tecnica
I rischi di gestione tecnica possono essere suddivisi in rischi di ingegneria, rischi di fornitura, rischi di
subappalto, rischi di costruzione, rischi di subappalto, rischi di costruzione e rischi di gestione del
progetto.
Tipi di WBS
-Le WBS sono diverse a seconda degli obiettivi che l'organizzazione deve
organizzazione deve raggiungere.
-Per esempio, l'appaltatore e la stazione appaltante generalmente hanno WBS diverse per lo stesso
progetto.
Esercizio slide
PROJECT SCOPE MANAGEMENT
Sono i processi necessari per garantire che il progetto comprenda tutto il lavoro richiesto, e soltanto il
lavoro richiesto, per completare il progetto con successo.
Il termine “scope” si può riferire allo:
-“scope” del prodotto: caratteristiche e funzioni che caratterizzano un prodotto, servizio o risultato;
-“scope” del progetto: lavoro svolto per offrire un prodotto, un servizio o un risultato con le caratteristiche
e le funzioni specificate.
Il completamento dello «scope» del progetto è misurato rispetto al project management plan, mentre il
completamento dello «scope» del prodotto è misurato rispetto ai requisiti del prodotto.
Relazione tra lo “scope” e il project life
il modello di ciclo di vita del progetto può variare lungo la vita del progetto da approcci predittivi ad
approcci adattativi o agili. In un ciclo di vita predittivo, i risultati finali del progetto sono definiti all'inizio del
progetto e le eventuali modifiche allo «scope» sono gestite progressivamente attraverso un processo
formale di gestione delle variazioni. In un ciclo di vita adattivo o agile, i risultati finali sono sviluppati su più
iterazioni in cui uno «scope» dettagliato viene definito e approvato all’inizio di ciascuna iterazione.
Nei Cicli di vita adattativi o agile i tre processi (Raccogli requisiti, Definisci ambito (scope) e Crea la WBS)
vengono ripetuti per ogni iterazione. Al contrario, in un progetto predittivo, questi processi vengono
eseguiti verso l'inizio del progetto e aggiornati secondo necessità, utilizzando il processo integrato di
controllo delle modifiche.
In un ciclo di vita adattivo o agile, i rappresentanti degli sponsor e dei clienti devono essere costantemente
coinvolti nel progetto per fornire feedback. I due processi (Validate Scope e Control Scope) vengono
ripetuti ad ogni iterazione. Al contrario, in un progetto predittivo, Validate Scope si esegue per ogni
deliverable o fase e il Control Scope è un processo in continuo.
In un ciclo di vita predittivo:
La baseline dello “scope” è la versione approvata del Project Scope Statement, della Work Breakdown
Structure (WBS), del dizionario della WBS associato, Workpackage, Plannig package, Control account. La
baseline pu essere cambiata solo attraverso procedure formali di controllo delle variazioni ed è usata come
base di confronto.
Project Scope Management
In un ciclo di vita adattativo a agile: si utilizzano in modo iterativo i blacklog per riflettere i bisogni non
esiste quindi una baseline.
I blacklog sono un elenco di cose che pensiamo dovremmo fare, (es. bisogni del cliente, ecc.). Inoltre, hanno
una priorità, quindi le cose in cima sono le cose più importanti fare mentre le cose in basso potranno non
essere attuate.
La baseline diventa una sorta di istantanea nel tempo (accordo) che va variando man mano che il progetto
va avanti.
Nei progetti con requisiti in evoluzione, alto rischio o incertezza significativa, lo «scope» spesso non è
compreso all'inizio del progetto o si evolve durante il progetto. I metodi agile impiegano meno tempo a
cercare di definire e concordare «lo scope» nella fase iniziale del progetto e impiegano più tempo nella sua
continua scoperta e perfezionamento.
Plan Scope Management
E’ il processo mediante il quale si crea un piano di gestione dello “scope” che documenta come verrà
definito, sviluppato, monitorato, convalidato e controllato lo “scope” del progetto.
Lo sviluppo del piano di gestione dello “scope” inizia dall’analisi delle informazioni contenute nel Project
Charter, nei piani ausiliari del Project Management Plan, delle informazioni storiche, etc.
Il vantaggio di questo processo è che fornisce una guida e la direzione su come lo “scope” sarà gestito nel
progetto.
Plan Scope Management
INPUT
1.Project Charter.
2.Project Management Plan: Le componenti del project management plan includono ma non solo:
-il piano della qualità
-La descrizione del ciclo di vita del progetto.
-Approccio allo sviluppo del ciclo di vita del progetto ( waterfall, iterativo, adattativo, agile o ibrido).
3.Enterprise Enviromental Factors: Cultura dell’organizzazione, Infrastrutture, Amministrazione del
personale, Condizioni di mercato
4. Organizational process assets: Politiche e procedure aziendali, Informazioni storiche e lesson leaned
registrate.
TOOL & TECHINIQUES
1.Expert Iudgement: sono fornite da gruppi o persone che hanno l’appropriata conoscenza, skill, esperienza
nello sviluppo dei piani di gestione dello “scope”.
2.Data Analysis
3.Meetings: i partecipanti ai meetings possono essere ad esempio il PM, lo sponsor, i membri del team di
progetto, selezionati stakehlders, etc.
OUTPUT
1.Scope Management Plan: fa parte del piano di gestione del progetto o del programma e descrive come
sarà definito, sviluppato, monitorato, controllato e validato lo “scope”. Tale piano definisce come svolgere i
seguenti processi:
-Processo per preparare un dettagliato Project Scope Statement.
-Processo che consente la creazione della WBS.
-Processo che stabilisce come la WBS sarà mantenuta e approvata.
-Processo che specifica come avverrà l'accettazione formale dei deliverables completi di progetto.
Il piano di gestione dello “scope”, in funzione delle esigenze del progetto, può essere formale o informale,
sviluppato sommariamente o in modo dettagliato.
2.Requirement Management Plan: fa parte del piano di gestione del progetto e descrive come saranno
analizzati, documentati, e gestiti i requisiti. Alcuni componenti di tale piano sono:
-come saranno programmati, tracciati e descritti i requisiti delle attività;
-attività di gestione delle configurazioni come ad esempio: come saranno avviate le modifiche al prodotto,
come sarà analizzato l'impatto, i livelli di autorizzazione necessarie per approvare tali modifiche, etc;
-processi di priorizzazione dei requisiti;
-metriche di prodotto che verranno utilizzate;
-struttura di tracciabilità che rifletta i requisiti che saranno presenti nella matrice di tracciabilità.
COLLECT REQUIREMENT
E’ il processo mediante il quale si determinano, si documentano e si gestiscono le esigenze degli
stakeholders e i requisiti per soddisfare gli obiettivi del progetto.
Il vantaggio di questo processo è che fornisce la base per la definizione e la gestione dello “scope” del
progetto includendo anche lo “scope” del prodotto.
Il successo del progetto è direttamente influenzato dal coinvolgimento attivo degli stakeholders nella
determinazione e decomposizione delle esigenze in requisiti e nella cura posta nella determinazione, nella
documentazione e nella gestione dei requisiti del prodotto, del servizio o del risultato del progetto.
I requisiti includono condizioni o capacità che devono essere soddisfatte dal progetto o presenti nel
prodotto, nel servizio o nel risultato per soddisfare un accordo.
I requisiti diventano il fondamento della WBS.
I costi, lo schedule, la qualità e gli approvvigionamenti sono legati ai requisiti.
Lo sviluppo dei requisiti inizia dall’analisi delle informazioni contenute nel Project Charter, nel registro degli
stakeholders e nel piano di gestione degli stakeholders.
INPUT
1.Project Charter
2.Project Management Plan: -Scope Management Plan fornisce chiarezza su come il team di progetto
determinerà quali requisiti bisogna collezionare per il progetto.
-Requirements Management Plan: definisce il processo che verrà usato per definire e documentare le
necessità degli stakeholders.
-Stakeholders Management Plan: usato per capire il livello di impegno degli stakeholders necessario e a
garantire il livello di partecipazione degli stakeholders alle attività di determinazione dei requisiti.
3.Project Documents. Assumption log, Lesson learned register,
Stakeholders Register: identifica gli stakeholders che possono fornire informazioni sui requisiti. Tale registro
cattura sia i principali requisiti che le aspettative che gli stakeholders possono avere per il progetto.
4. Business Documents: Project business case; Project benefits management plan
5.Agreements
6.Enterprise environmental factors: Cultura organizzativa, Infrastrutture,Amministrazione del personale,
Condizioni di mercato
7.Organizational process assets:Politiche e procedure aziendali, Informazioni storiche e lesson leaned
registrate.
TOOL & TECHINIQUES
1.Expert Judgment
2.Data gathering:
-Brainstorming
-Interviews: è un approccio formale o informale per ottenere informazioni dagli stakeholders parlando
direttamente con loro. Di solito i colloqui sono svolti in modo individuali tra l’intervistatore e l’intervistato
ma possono anche coinvolgere più intervistatori e/o più intervistati. I colloqui sono usati anche per
ottenere informazioni confidenziali.
-Focus Group: riunisce gli stakeholders prequalificati e gli esperti in materia per conoscere le loro
aspettative. Un moderatore esperto guida il gruppo attraverso una discussione interattiva.
-Questionare and Surveys: è una serie di domande scritte volte a accumulare velocemente informazioni da
un gran numero di intervistati. Sono più efficaci se sottoposti ad un pubblico vario, quando è necessaria una
rapida inversione di tendenza, quando gli intervistati sono geograficamente dispersi, etc.
-Benchmarking: si tratta di confrontare le pratiche effettive con quelle previste. Le organizzazioni
paragonate durante il benchmarking possono essere interne o esterne.
3.Data Analysis: L’analisi dei dati che consiste tra l’altro nel rivedere e valutare qualsiasi informazione
pertinente documentata.
TOOL & TECHINIQUES
4.Decision making: Votazione
-Unanimità: decisione che si raggiunge e verso la quale tutti sono d’accordo
-Maggioranza assoluta: decisione che è raggiunta con il supporto del 50% dei membri del gruppo.
-Pluralità (maggioranza relativa): decisione che si raggiunge con un numero
5.Data Representation:
-Affinity diagrams
1.
descrivere il problema
2.
affrontare la questione con un brainstorming
3.
segnare ogni idea emersa singolarmente utilizzando dei post it
4.
clusterizzare le idee all’interno di 5 massimo 9 temi
5.
trovare 3 – 5 parole che descrivono le affinità emerse
6.
raggruppare ulteriormente le informazioni emerse all’interno delle categorie, che devono rimanere
significative
7.
trovare un titolo per ogni categoria
8.
tracciare le linee di affinità
9.
alla fine si ottiene una struttura che evidenza le relazioni esistenti
-Mind Mapping
6.Interpersonal and team skills:
-Nominal group technique: il brain storming si fa seguire da un processo di voto usato per classificare le
idee più utili per un ulteriore brainstorming o pre stabilire delle priorità
-osservazioni: fornisce un modo diretto per vedere gli individui nel loro ambiente e come svolgono il
proprio lavoro o attività. E’ particolarmente utile quando chi utilizza il prodotto ha difficoltà o è riluttante
ad articolare le proprie esigenze. L'osservazione è conosciuta anche come "job shadowing". Di solito è fatta
da un osservatore esterno anche se pu essere fatta da un "osservatore partecipante".
-Facilitazioni : sono sessioni che riuniscono i principali stakeholders per definire i requisiti del prodotto. I
workshops sono considerati una tecnica per definire rapidamente i requisiti funzionali del prodotto e per
riconciliare gli stakeholders. A causa della loro natura di gruppo interattivi possono costruire la fiducia,
favorire le relazioni e migliorare la comunicazione tra i partecipanti. Questo pu determinare un aumento
del consenso degli stakeholders. Tale approccio facilita anche l’individuazione di problemi che possono
essere risolti in modo più veloce rispetto alle sessioni individuali.
Esempi di “facilitated workshops” sono: Joint application design/development (JAD): usato nell’industria di
sviluppo software; Quality function development (QFD). Usate nelle industrie manufatturiere; User stories.
brevi descrizioni testuali della funzionalità richiesta, sono spesso sviluppate durante un workshop sui
requisiti.
7.Context diagram: rappresentano visivamente lo “scope” del prodotto. Mostrano gli input al sistema, gli
attori che forniscono gli input, gli output gli attori che li ricevono.
8.Prototypes: si tratta di un metodo per ottenere, in maniera rapida, risposte sui requisiti del prodotto
fornendo un modello di lavoro del prodotto (prototipo) previsto prima della sua reale costruzione. I
prototipi supportano il concetto di elaborazione progressiva in cicli iterativi di creazione, sperimentazione
con l’utente, risposte e revisioni del prototipo. Quando si sono eseguiti un numero sufficiente di cicli, i
requisiti del prototipo sono sufficientemente completi e si pu passare alla fase di progettazione vera e
propria o costruzione.
OUTPUT
1.Requirement Documentation: descrive come i requisiti individuali incontrano le necessità di business.
Preliminarmente i requisiti sono descritti ad alto livello per diventare progressivamente più dettagliati.
Come prima cosa i requisiti devono essere inequivocabili misurabili e verificabili, tracciabili, completi,
coerenti e accettabili per i principali stakeholders. Il formato di un documento di requisiti pu variare da un
semplice documento che elenca semplicemente i requisiti a forme più elaborate contenenti una sintesi,
descrizioni dettagliate e allegati.
Tale documentazione può includere:
-Requisiti di business: obiettivi, necessità, regole, ecc. -Requisiti degli stakeholders: impatto
sull’organizzazione, richieste di autorizzazioni, ecc..
-Requisiti delle soluzioni: funzionali, non funzionali, qualità, ecc.. Requisiti funzionali: descrivono le
caratteristiche del prodotto;Requisiti non funzionali: supplementari ai requisiti funzionali, descrivono
condizioni ambientali o qualità richieste. Esempi includono:
affidabilità, la sicurezza, le prestazioni, la sicurezza, il livello di servizio, sostenibilità, ritenzione / spurgo,
etc.
-Requisiti di transizione e prontezza: questi descrivono funzionalità temporanee, come la conversione dei
dati, requisiti di formazione, necessari per passare dallo stato corrente as-is allo stato futuro desiderato..
-Project requirements: questi descrivono le azioni, i processi o altre condizioni che il progetto deve
soddisfare, ad esempio date salienti, obblighi contrattuali, vincoli, ecc.
-Quality requirements: Riguardano condizioni o criteri necessari per convalidare il completamento con
successo di un risultato del progetto o l'adempimento di altri requisiti del progetto., ad esempio test,
certificazioni, validazioni, ecc.
2. Requirement Treceability Matrix:
-lega i requisiti del prodotto ai deliverables che li soddisfano. La matrice tracciabilità dei requisiti è una
griglia che collega i requisiti del prodotto dalla loro origine al deliverable, workpackage che li soddisfano. La
matrice di tracciabilità dei requisiti aiuta a garantire che ciascun requisito aggiunga valore di business,
collegandolo anche agli obiettivi di business e di progetto
-L'implementazione di una matrice tracciabilità dei requisiti fornisce un mezzo per monitorare i requisiti per
tutto il ciclo di vita del progetto, contribuendo a garantire che requisiti approvati nella documentazione
vengano realizzati e consegnati al termine del progetto. Fornisce altresì una struttura per la gestione delle
variazioni del prodotto.
La tracciabilità include, ma non è limitata a: esigenze del business, opportunità;obiettivi di progetto;
scope/WBS, deliverable; design del prodotto; sviluppo del prodotto; test; requisiti di alto e basso livello.
Define Scope
E’ il processo mediante il quale si sviluppa una descrizione dettagliata del progetto e del prodotto.
Il vantaggio di questo processo è che descrive il prodotto, il servizio, il risultato e i criteri di accettazione
definendo quali tra i requisiti raccolti saranno inclusi e quali esclusi dallo “scope” del progetto.
INPUT
1.Project Charter: fornisce una descrizione di alto livello del progetto e delle caratteristiche del prodotto.
2.Project Management Plan
3.Project Documents: Assumption log; Requirements documentation; Risk register
4.Enterprise Enviromental Factors: Cultura dell’organizzazione; Infrastrutture; Amministrazione del
personale;Condizioni di mercato
5. Organizational process assets: Politiche, procedure aziendali e template per il project scope
management; File da progetti precedenti; Informazioni storiche e lesson leaned registrate.
TOOL & TECHINIQUES
1.Expert Judgement:è fornita da qualsiasi gruppo o individuo con l’opportuna conoscenza. Può essere
fornita da consulenti, stakeholder, clienti, sponsor, associazioni tecniche e professionali, gruppi industriali,
etc.
2.Data Analysis
3.Decision Making
4.Interpersonal and Team Skills
5. Product Analysis: è uno strumento efficace nel caso in cui il risultato finale di un progetto è un prodotto.
Comprende tecniche quali ad esempio la product breakdown structure, i sistemi di analisi, l’analisi dei
requisiti,etc.
OUTPUT
1. Project Scope Statement: è la descrizione dello “scope”, compresi i principali deliverables, le ipotesi e i
vincoli del progetto. Documenta l'intero “scope” cioè sia lo “scope” del progetto che quello del prodotto.
Esso descrive, in dettaglio, i risultati finali del progetto e il lavoro necessario per creare tali risultati.
Fornisce inoltre una comune comprensione dello “scope” del progetto tra gli stakeholders. Tale
documento aiuta il team di progetto ad eseguire una pianificazione più dettagliata, li guida durante
l’esecuzione del lavoro e fornisce una base per valutare se le richieste di modifiche o lavori supplementari
sono all'interno o al di fuori dei confini del progetto.
Il Project Scope Statement, direttamente o con riferimento ad altri documenti, include quanto segue:
-Descrizione dello “scope” del prodotto: elabora progressivamente le caratteristiche del prodotto, del
servizio o del risultato descritto nel Project Charter e nei documenti dei requisiti.
-Criteri di accettazione: un insieme di condizioni che è devono necessariamente essere soddisfatte affinché
vengano accettati i deliverables.
- Deliverable: qualsiasi prodotto o risultato unico e verificabile, o la capacità di svolgere un servizio che è
necessario per completare un processo, una fase o il progetto. I deliverables includono anche risultati
accessori, quali ad esempio i report di gestione del progetto e la documentazione. I deliverables possono
essere descritti in modo dettagliato o sommario.
- Ci che è escluso dal progetto: generalmente identifica ci che è escluso dal progetto. Affermando
esplicitamente ci che è fuori portata del progetto aiuta a gestire le aspettative degli stakeholder.
Anche se il Project Charter e il Project Scope Statement vengono talvolta considerati simili e quindi
contenenti nozioni ridondanti nella realtà sono diversi nel livello di dettaglio di ciascuno di essi. Il Project
Charter contiene un livello elevato di informazioni mentre il Project Scope Statement contiene una
descrizione dettagliata degli elementi dello “scope”.
Provare a creare il project scope statement per una festa importante come un matrimonio
2. Project Documents Updates: Assumption log; Requirements documentation; Requirements traceability
matrix; Stakeholder register.
CREATE WBS
E’ il processo mediante il quale si suddividono i deliverables e il lavoro del progetto in componenti più
piccoli e più gestibili.
Il vantaggio di questo processo è che fornisce una visione strutturata di ci che deve essere consegnato.
La WBS è una scomposizione gerarchica dello “scope” totale del lavoro che deve essere svolto dal team di
progetto per raggiungere gli obiettivi del progetto e creare i deliverables richiesti.
La WBS organizza e definisce lo “scope” totale del progetto ed è una rappresentazione strutturata del
lavoro specificato nel Project Scope Statement approvato.
Ciascun livello inferiore rappresenta una definizione sempre più dettagliata del progetto.
Il lavoro pianificato è contenuto nel livello più basso di componenti WBS, chiamati work package.
Un work package può essere utilizzato per raggruppare le attività in cui il lavoro è pianificato e stimato,
monitorato e controllato. Nel contesto della WBS, il lavoro è quello riferito a ben precisi prodotti o
deliverable che sono il risultato dell’attività e non all'attività stessa.
INPUT
1.Project Management Plan
2.Project Documents:
-Project Scope Statement: descrive il lavoro che sarà svolto e quello che sarà escluso. Specifica inoltre le
specifiche restrizioni interne ed esterne e le limitazioni che possono influenzare l’esecuzione del progetto.
-Requirements Documentation:la documentazione dettagliata dei requisiti è utile per stabilire cosa è
necessario produrre come risultato del progetto e ci che deve essere fatto per consegnare il progetto e i
suoi prodotti finali.
3.Enterprise Environmental Factors: standard e WBS specifici del settore
4.Organizational Process Assets:Politiche, procedure aziendali e template per il project scope management;
File da progetti precedenti; Informazioni storiche e lesson leaned registrate.
TOOL & TECHINIQUES
1. Expert Judgment
2. Decomposizione: è una tecnica utilizzata per dividere e suddividere lo “scope” del progetto e i
deliverables di progetto in parti più piccole e più gestibili. Il WP è il lavoro definito al livello più basso della
WBS per il quale è possibile stimare e gestire il costo, la durata e l’avanzamento. Il livello di scomposizione
è spesso guidato dal grado di controllo necessario per gestire efficacemente il progetto . Il livello di
dettaglio varia a seconda della dimensione e della complessità del progetto.
La scomposizione del lavoro totale del progetto in pacchetti di lavoro generalmente coinvolge le seguenti
attività:
-identificare e analizzare i deliverables e relativi lavori;
-strutturare e organizzare le WBS;
-scomposizione dei livelli superiori nella WBS in componenti di dettagliato a livelli inferiori,
-sviluppo e assegnazione di codici di identificazione dei componenti della WBS,
-verifica se il grado di decomposizione dei deliverable è appropriato .
La struttura della WBS può essere creata mediante diversi approcci quali ad esempio un approccio topdown, un approccio bottom-up, con l’uso di specifiche linee guida o di templates.
Inoltre la struttura della WBS pu essere rappresentata in diversi modi come ad esempio:
-Utilizzando le fasi del ciclo di vita del progetto come il secondo livello di decomposizione, e il prodotto e i
deliverables di progetto come terzo livello.
-Utilizzando i principali deliverables come secondo livello di scomposizione.
-Integrando i sottocomponenti che possono essere sviluppati da organizzazioni esterne al team di
progetto.
Verificare la correttezza della decomposizione consiste nel verificare che i componenti a basso livello della
WBS sono quelli necessari e sufficienti per il completamento dei corrispondenti deliverable più alto livello.
Diversi deliverable possono avere diversi livelli di decomposizione, il lavoro di alcuni deliverables è
rappresentato ad un certo livello mentre altri hanno bisogno di ulteriori livelli di decomposizione. La
decomposizione del lavoro in maggiori livelli di dettaglio migliora la capacità di pianificare, gestire e
controllare il lavoro. Tuttavia una decomposizione eccessiva può comportare uno sforzo di gestione non
produttivo, un uso inefficiente delle risorse, una diminuzione dell’efficienza nello svolgimento del lavoro e
una difficoltà nell’aggregare i dati. Le Work Package devono rappresentare prodotti, servizi o risultati
comunque verificabili.
La decomposizione inoltre può non essere possibile per un deliverable o un sottocomponente che verrà
realizzato nel futuro (elaborazione progressiva). Il team di gestione del progetto di solito attende che venga
concordato il risultato finale o sottocomponente e poi sviluppa i dettagli della WBS. Questa tecnica è
chiamata pianificazione a finestra mobile (Rolling Wave Planning). Il totale del lavoro ai livelli più bassi
dovrebbe ribaltarsi ai livelli più alti in modo che nulla sia lasciato fuori. Questo è chiamato la regola 100 per
cento.
OUTPUT
1.Scope Baseline: la baseline dello”scope” è la versione approvata del project scope statement, della WBS,
del dizionario ad essa associato, ecc., che pu essere modificata solo attraverso le procedure formali di
controllo delle variazioni e viene utilizzata come base di confronto. Si tratta di un componente del Project
Management Plan.
Scope Baseline:
Le componenti della baseline dello “scope” includono:
-Project Scope Statement: include la descrizione dello “scope”, i principali deliverables, le ipotesi e i vincoli.
-WBS: scomposizione gerarchica del lavoro totale che deve essere svolto dal team di progetto per
raggiungere gli obiettivi del progetto e creare i deliverables richiesti. Ogni livello successivo della WBS
rappresenta una definizione sempre più dettagliata del lavoro. La WBS è utile anche per identificare i
control point account.
Le componenti della baseline dello “scope” includono:
-Work package: Il livello più basso della WBS, è un pacchetto di lavoro con un identificativo univoco. Questi
identificatori forniscono una struttura di riferimento per la gestione dei costi, la pianificazione e le
informazioni sulle risorse e formano il codice dei conti. Ogni work package fa parte di un control account.
-Control account: un punto di controllo di gestione nel quale ambito, budget e pianificazione sono integrati
e confrontato pianificato con realizzato per la misurazione delle prestazioni. Un control account ha due o
più workpackage, e ciascun work package è associato a un singolo account di controllo.
-Plannig package: Un control account di controllo può includere uno o più plannig package. Un plannig
package è un componente della WBS sotto il control account e sopra il work package con contenuto di
lavoro noto ma senza attività di pianificazione dettagliata.
I componenti della baseline dello “scope” includono:
-WBS Dictionary: il dizionario della WBS è un documento che supporta la WBS stessa.
2.Project Documents Updates:Assumption Log; Documentazione riguardo i requisiti (Requirements
documentation)
Validate Scope
E’ il processo mediante il quale si formalizza l'accettazione dei deliverables di progetto completati.
Il vantaggio di questo processo è che da oggettività al processo di accettazione e aumenta la possibilità di
accettazione del prodotto finale, del servizio o del risultato tramite la convalida di ogni deliverables.
I deliverables, output dal processo di controllo della qualità, sono rivisti con il cliente o lo sponsor per
assicurarsi che essi siano stati completati in modo soddisfacente e riceveranno così da essi l'accettazione
formale.
Il processo «validate scope» si differenzia dal processo di controllo di qualità in quanto il primo riguarda
principalmente l'accettazione dei deliverable (in generale da parte del cliente), mentre il secondo è un
processo interno orientato a monitorare e registrare la qualità dei risultati ai fini della valutazione della
performance raccomandando eventualmente delle varianti e per soddisfare le richieste degli stakeholders.
Il controllo di qualità è generalmente eseguito prima di «Validate Scope» anche se i due processi possono
essere eseguiti in parallelo.
CONTROL QUALITY
Measuring deliverables (products)
Performed internally
Usually performed before validate scope
Product may fail control quality and the customer
may accept it anyway as part of validate scope
VALIDATE SCOPE
Measuring deliverables (products)
Performed by the customer
Usually performed after control quality
Product may pass control quality and the customer
may not accept it as part of validate scope
INPUT
1.Project Management Plan: -Scope Management Plan -Requirement Management Plan -Scope Baseline
2.Project Document: -Leasson Learned register -Quality Report -Requirement Documentation -Requirement
Traceability Matrix
3.Verified Deliverables: sono risultati del progetto che sono stati completati e la cui correttezza è stata
controllata nel processo di controllo della qualità.
4.Work Performance Data: possono comprendere il grado di conformità ai requisiti, il numero di non
conformità, la severità delle non conformità, etc.
TOOL & TECHINIQUES
1.Inspection: comprende attività come la misurazione, l'esame e la convalida necessarie a determinare se il
lavoro e i deliverables soddisfano i requisiti e i criteri di accettazione del prodotto.
2. Decision-Making: queste tecniche vengono utilizzate per raggiungere una conclusione quando la
convalida viene eseguita dal team di progetto e da altri stakeholders.
OUTPUT
1.Accepeted Deliverables: i deliverable che soddisfano i criteri di accettazione sono formalmente firmati e
approvati dal cliente o dallo sponsor.
2.Work Performance Information: contiene informazioni sullo stato di avanzamento del progetto, come ad
esempio quali deliverable sono stati completati e quali sono stati accettati.
3.Change Requestes: i deliverable che non sono stati formalmente accettati sono documentati, insieme con
le ragioni della mancata accettazione. Tali deliverables possono richiedere una richiesta di variazione, che
vengono elaborate nel Perform Integrated Change Control Process
4.Project Documents Updates:-Lesson Learned register -Requirement Documentation -Requirement
Traceability Matrix
Control Scope
E’ il processo di monitoraggio dello stato del progetto, dello “scope” del prodotto e della gestione delle
variazioni della baseline dello “scope”.
Il vantaggio di questo processo è che permette di preservare la baseline dello “scope” nel corso del
progetto.
Le variazioni in un progetto sono inevitabili quindi per ogni progetto è fondamentale un processo che le
controlla.
INPUT
1.Project Management Plan: di tale piano sono usate le seguenti informazioni per controllare lo “scope”:
-Change Management Plan: definisce i processi per gestire le variazioni.
-“Scope” Management Plan: una sezione di tale piano descrive come lo “scope” del progetto sarà
monitorato e controllato.
-“Scope” baseline: è paragonata con i risultati attuali per determinare se sono necessarie variazioni, azioni
correttive o preventive.
-Configuration Management Plan: definisce quali sono gli elementi che richiedono un controllo delle
variazioni formale e il processo per controllare le variazioni di tali elementi.
-Requirement Management Plan: fa parte del Project Management Plan e descrive come i requisiti del
progetto saranno analizzati, documentati e gestiti.
-Performance Measurement Baseline
2.Project Document: Lesson Learned register -Requirement documentation -Requirement traceability
matrix
3.Work Performance Data: possono includere il numero di richieste di variazioni ricevute, il numero di
variazioni accettate o il numero di deliverables accettate, etc.
4.Organizational Process Assets: Politiche, procedure, linee guida di controllo, Metodi di monitoraggio e di
docomentare, template..
TOOL & TECHINIQUES
1.Data Analysis:
-Variance Analysis: permette di determinare la causa e il grado di scostamento rispetto alla baseline dello
“scope”. Determinato lo scostamento bisogna decidere se sono necessarie azioni correttive o preventive. Trend analysis: sulla base della variazione della performance nel tempo, si effettuano delle previsioni.
OUTPUT
1.Work Performance Information: fornisce informazioni correlate e contestualizzate sullo stato attuale
dello “scope” del progetto rispetto alla baseline. Può includere informazioni sulle categorie di variazioni
ricevute, l’identificazione della variazioni dello “scope” e le loro cause, come tali variazioni impattano la
pianificazione o il costo, e la previsione della performance dello “scope”. Queste informazioni forniscono
una base per prendere decisioni sullo “scope”.
2.Change Requestes: l’analisi della performance dello “scope” pu determinare una richiesta di variazione
della baseline dello “scope” o di altri componenti del Project Management Plan. Le richieste di variazioni
possono includere azioni correttive, preventive o riparazione dei difetti. La richiesta di cambiamenti pu
pervenire da diversi processi.
3.Project Management Plan Update: Scope management plan; Scope baseline; Schedule Baseline; Cost
Baseline; Performance Measurement baseline
4.Project Documents Update:Lesson learned register; Requirement documentation; Requirements
traceability matrix
PROJECT SCHEDULING MANAGEMENT
Lo Schedule Management è il controllo consapevole del tempo necessario per svolgere le attività.
Eisenhower diceva: ‘plans are nothing, but planing is everthing’
Comprende i processi necessari per gestire il completamento puntuale del progetto.
Un modello di schedule è una rappresentazione del piano di esecuzione delle attività del progetto e include
informazioni, quali ad esempio la durata e le dipendenze, utili per produrre lo schedule di progetto.
La schedulazione del progetto fornisce un piano dettagliato che rappresenta come e quando il progetto
fornirà prodotti, servizi e risultati definiti nell'ambito del progetto e funge da strumento per la
comunicazione, gestendo le aspettative degli stakeholder.
Su alcuni progetti, in particolare quelli più piccoli, la definizione delle attività, la loro sequenza, la stima
delle risorse, la stima delle durate, lo sviluppo di un modello di schedule sono così strettamente collegati
che sono visti come un unico processo che pu essere eseguito da una sola persona e in un breve periodo di
tempo. Questi processi sono presentati nel PMBOK in modo distinto.
-E’ il processo mediante il quale si stabiliscono le politiche, le procedure e i documenti necessari per la
pianificazione, sviluppo, gestione, esecuzione e controllo dello schedule di progetto.
Il vantaggio di questo processo è che fornisce una guida e la direzione su come la schedule del progetto
sarà gestito. Tale processo è realizzato una volta o in predeterminati punti del progetto.
INPUT
1.
Project Charter.
2.
Project Management Plan include ma non sono limitati a:
-Scope management plan: Il piano di gestione dello «scope» descrive come verrà definito e sviluppato lo
«scope» e fornisce informazioni su come verrà sviluppato lo schedule.
-Developement approach: Aiuterà a definire l'approccio alla schedulazione, le tecniche di stima, gli
strumenti di schedulazione e le tecniche per il controllo della schedulazione
3. Enterprice Environmental Factors: possono influenzare il processo di pianificazione del piano includono
ma non sono limitati a: Cultura organizzativa e struttura, Disponibilità delle risorse del team e disponibilità
di risorse fisiche e altre risorse, Software per la schedulazione, Linee guida e criteri per adattare l'insieme
dei processi dell'organizzazione e procedure standard alle esigenze specifiche del progetto, Database
commerciali, come dati di stima standard.
4. Organizational Process Assets: includono ma non sono limitati a:
-Informazioni storiche e repository delle lezioni apprese;
-Esistenti schedulazioni e politiche di gestione formali e informali, e linee guida;
-Template -Strumenti di monitoraggio e reporting.
TOOL & TECHINIQUES
1.
Expert Judgement: il giudizio degli esperti pu suggerire l’utilizzo di determinate metodologie,
fornire informazioni utili, software, etc.
2.
Data Analysis: tale processo pu comportare la scelta di opzioni strategiche per stimare e schedulare
il progetto quali ad esempio metodologie e strumenti di scheduling, approcci di stima, format e software di
gestione dei progetti. Tali decisioni possono influenzare il rischio del progetto. Le tecniche che possono
essere utilizzate per tali decisioni sono ad esempio il rolling wave planning, leads, analisi delle alternative e
metodi per riesaminare la performance dello schedule.
3. Meetings: i partecipanti a tali meetings possono essere ad esempio il PM, lo sponsor, alcuni membri del
team, stakeholders e i responsabili della pianificazione ed esecuzione dello schedule.
OUTPUT
1. Schedule Management Plan: è un componente del Project Management Plan che stabilisce i criteri e le
attività per sviluppare, monitorare e controllare lo schedule. Può essere formale o informale, dettagliato o
sommario, basato sulle necessità del progetto e include appropriate soglie di controllo. Tale piano può
stabilire:
-Project Schedule Model Development nel quale sono specificate le metodologie e gli strumenti di
scheduling che sono usate nello sviluppo dello schedule di progetto.
-Con AGILE se si utilizza un ciclo di vita adattivo, vengono specificati i periodi time-boxed per i rilasci, e le
iterazioni. I time-boxed sono la durata durante la quale la squadra lavora costantemente verso il
completamento di un obiettivo. Il timeboxing aiuta a ridurre il creep dello scope in quanto costringe i team
a elaborare prima le caratteristiche essenziali, poi altre funzionalità quando il tempo lo consente.
-Livello di accuratezza cioè il range di accettazione usato per determinare la stima realistica della durata
per quantificare le risorse (ad esempio ore e giorni di personale, metri, litri, kilometri, etc.).
-Organizational procedures links coerenza con la WBS.
-Project Schedule Model Maintenance, definisce il processo usato per aggiornare e registrare i progressi del
progetto nello scheduling durante l’esecuzione del progetto.
-Soglie di controllo utilizzate per monitorare la performance dello schedule che rappresentano una quantità
di variazione concordata prima di essere autorizzati ad eseguire qualche azione. Le soglie generalmente
sono espresse come una deviazione percentuale rispetto alla baseline pianificata.
-Regole di misura della performance che stabiliscono regole di gestione dell’Earned Value o altre
metodologie di misure della performance. Ad esempio:
Regole per stabilire la percentuale di completamento di un’attività.
Tecniche di misura dell’Earne Value (ad esempio baselines, percentuale di completamento, etc.).
Misure di performance dello schedule quali ad esempio lo Schedule Variance (SV) e lo Schedule
performance Index (SPI) .
-Reporting format: format per i diversi report.
Define Activities
E’ il processo mediante il quale si identificano e si documentano le azioni specifiche che si devono svolgere
per produrre i deliverables di progetto.
Il vantaggio di questo processo è quello di suddividere i pacchetti di lavoro in attività che forniscono una
base per la stima, lo scheduling, il monitoraggio e il controllo del lavoro del progetto.
INPUT
1.Project Management Plan: - schedule management plan
-Scope Baseline: durante la definizione delle attività vengono considerati la WBS del progetto, i
deliverables, i vincoli e le ipotesi documentati nella baseline dello “scope”.
2. Enterprice Environmental Factors: includono ma non sono limitati a: Cultura e struttura organizzativa,
Informazioni commerciali da database, Project Management Information System (PMIS).
3. Organizational Process Assets: includono ma non sono limitati a:
-Template che contengono attività standard o attività di progetti precedenti
-Politiche, procedure e linee guida relative alla schedulazione
TOOL & TECHINIQUES
1.
Expert Judgement: i membri del team di progetto o altri esperti che hanno esperienze e conoscenze
nello sviluppo dettagliato del Project “Scope” Statement, della WBS e degli schedule di progetto.
2.
Decomposition: è una tecnica usata per dividere lo “scope” e i deliverables di progetto in parti più
piccole e gestibili. Il processo Define Activity definisce l’output finale come attività necessarie facenti parte
di una work package. La lista delle attività, la WBS e il suo dizionario
possono essere sviluppati sequenzialmente o contemporaneamente.
Define Activities
TOOL & TECHINIQUES
3.
Rolling Wave Planning: è una tecnica di pianificazione iterativa in cui il lavoro da svolgere nel breve
periodo è pianificato nel dettaglio, mentre quello da svolgere in futuro è pianificato ad un livello superiore.
Quindi il lavoro può esistere a vari livelli di dettaglio in dipendenza di dove si è arrivati rispetto al ciclo di
vita del progetto.
4.
Meeting possono essere faccia a faccia, virtuali, formali o informali.
OUTPUT
1.
Activity list: lista delle attività
2.
Activity Attributes: è una lista che include tutte le attività richieste per il progetto. Le attività hanno
una durata durante la quale viene svolto il lavoro e a tale lavoro possono essere associate risorse e costi. I
componenti delle attività hanno un’evoluzione temporale. Durante la fase iniziale del progetto gli attributi
comprendono un identificativo di attività (ID), un ID di WBS e il nome dell’attività. In seguito possono
comprendere il risultato, la descrizione delle attività, i predecessori e i successori, le relazioni logiche, gli
anticipi e i ritardi, la richiesta di risorse, la date imposte, i vincoli e le ipotesi, il
responsabile, l’area geografica o il posto dove il lavoro deve essere svolto, il calendario di progetto, etc.
OUTPUT
3. Milestone List: la milestone è un punto o evento significativo per il progetto. La lista di milestone è una
lista che identifica tutte le milestone del progetto e specifica quali tra queste sono obbligatorie, cioè quelle
richieste da contratto, quali opzionali, cioè basate su informazioni storiche. Le milestone sono simili alle
attività schedulate, hanno la stessa struttura e gli stessi attributi ma hanno una durata pari a zero perché
rappresentano un momento ben specifico nel tempo in cui accade un evento significativo per il progetto.
4. Change requests: una volta che è stata fatta la baseline, si può rivelare necessari lavori che inizialmente
non facevano parte della baseline del progetto. Ciò comporta una richiesta di modifica. Le richieste di
modifica vengono elaborate per la revisione e la disposizione tramite il processo Perform Integrated
Change Control.
5. Project Management PlanUpdates: le variazioni richieste per il project management plan includono ma
non sono limitate a: -Schedule baseline -Cost baseline.
Sequences Activities
E’ il processo mediante il quale si identificano e si documentano le relazioni tra le attività del progetto.
Il vantaggio di questo processo è che definisce la sequenza logica del lavoro che permette di ottenere la più
elevata efficienza che si può ottenere con i vincoli del progetto.
Le relazioni logiche dovrebbero essere individuate per creare uno schedule del progetto realistico.
Potrebbe essere necessario usare degli anticipi e ritardi di tempo tra le attività per ottenere un realistico e
accettabile schedule di progetto.
La sequenza delle attività può essere eseguita usando software di gestione dei progetti o usando tecniche
manuali o automatiche.
INPUT
1.
Project Management Plan:
-Schedule Management Plan: identifica i metodi e gli strumenti di scheduling che sono usati per il progetto
e che daranno una guida su come le attività saranno sequenziate.
-Scope Baseline
2.
Project Documents: -Activity Attributes: può definire le relazioni di predecessori e successori.
-Activity List: contiene tutte le attività schedulate richieste per il progetto che saranno sequenziate. La
dipendenza e i vincoli tra queste attività possono influenzare la sequenza delle attività. -Assumption log Milestone list
3. Enterprice Environmental Factors: includono, a titolo esemplificativo ma non esaustivo: Norme
governative o industriali,Sistema di informazione sulla gestione dei progetti (PMIS), Strumenti di
schedulazione, Sistemi di autorizzazione del lavoro.
4. Organizational Process Assets includono, a titolo esemplificativo ma non esaustivo:
-Portfolio e programmi
-Politiche, procedure e linee guida relative alla metodologia di schedulazione
-Template
-Informazioni sugli attributi dell'attività
-Lesson learned contenente informazioni storiche
TOOL & TECHINIQUES
1. Precedence Diagramming Method (PDM): è una tecnica usata per costruire un modello di schedule nel
quale le attività sono rappresentate da nodi e sono graficamente collegate da una o più relazioni logiche
che mostrano la sequenza con la quale le attività verranno svolte. Un metodo di rappresentazione del
diagramma delle precedenze è il metodo Activity-OnNode (AON).
2. Dependency Determination and integration: le dipendenze possono essere mandatorie o discrezionali,
interne o esterne, Anche se le dipendenze hanno 4 attributi 2 di essi possono essere applicati
contemporaneamente:
-dipendenze esterne mandatorie,
-dipendenze interne mandatorie,
-dipendenze esterne discrezionali
-dipendenze interne discrezionali.
Dipendenze mandatorie: sono le dipendenze richieste legalmente o contrattualmente o tecniche inerenti
alla natura del lavoro. Tali dipendenze spesso coinvolgono limitazioni fisiche (non è possibile costruire una
struttura se prima non sono state costruite le fondazioni). E’ il Team di progetto che determina qual sono le
dipendenze mandatorie. Tali dipendenze mandatorie non devono essere confuse con i vincoli di scheduling.
Sequences Activities
Dipendenze discrezionali: sono sequenze logiche generalmente stabilite basandosi su best practices (ad
esempio prassi interne, sequenze desiderabili, etc.). Dovrebbero essere documentate in quanto possono
limitare le successive opzioni di pianificazione. E’ il team di progetto che determina quali sono le
dipendenze discrezionali.
Sequences Activities
Dipendenze esterne: relazioni tra le attività che fanno parte del progetto e attività che non ne fanno parte
(ad esempio l’attività di testing in un progetto software dipende dalla consegna dell’hardware da parte di
un fornitore). Solitamente tali dipendenze non sono sotto il controllo dei membri del team. E’ il team di
progetto che individua quali sono le dipendenze esterne.
Dipendenze interne: relazioni di precedenze tra attività del progetto, sono generalmente sotto il controllo
dei membri del team. E’ il team di progetto che determina quali sono le dipendenze interne.
3. Leads and Lags: il Lead è l’anticipo, rappresenta cioè la quantità di tempo di cui pu essere avanzata
un’attività successore rispetto ad un’attività predecessore. Il Lag è il ritardo, rappresenta cioè la quantità di
tempo di cui si deve ritardare un’attività successore rispetto ad un’attività predecessore.
4. Project management information system (PMIS): I sistemi informatici di gestione del progetto includono
software di schedulazione per pianificare, organizzare e regolare la sequenza delle attività in funzione delle
relazioni logiche, i valori di lead e lag, differenziare i diversi tipi di dipendenza e differenziare i diversi tipi di
dipendenza.
OUTPUT
1.
Project Schedule Network Diagrams: è una rappresentazione grafica delle relazioni logiche. Tale
diagramma può essere fatto manualmente o sfruttando dei software di gestione dei progetti. Può
includere tutti i dettagli del progetto, può contenere anche una spiegazione che descrive l’approccio usato
per sequenziare le attività.
2.
Project Document Updates: ad esempio l’activity list, l’activity attributes, la milestone list, il risk
register, etc.
Estimates Activity Durations:
E’ il processo mediante il quale si stimano il numero di periodi lavorativi verosimilmente necessari per
completare le singole attività con le risorse stimate.
La stima della durata delle attività usa una stima e informazioni sulla tipologia e quantità delle risorse
richieste, disponibilità delle risorse, il calendario delle risorse, etc.
La stima della durata è elaborata progressivamente è un processo che tiene in considerazione la qualità e la
disponibilità dei dati di input.
Tutti i dati e le ipotesi che supportano la stima della durata devono essere documentati.
Alcuni fattori da prendere in considerazione quando si stima la durata delle attività sono:
-La legge dei rendimenti decrescenti.
-Numero di risorse
-Innovazioni tecnologiche.
-Motivazioni dello staff.
INPUT
1.Project Management Plan:
-Schedule Management Plan:definisce il metodo usato, il livello di accuratezza e i criteri per stimare la
durata delle attività.
-Scope baseline:
2.Project Documents:
-Activity Attributes: fornisce i dati di input principali da usare per la stima della durata richiesta per ogni
attività dell’activity list.
-Activity List: identificano le attività che necessitano una stima della durata.
-Assumption Log
-Lesson Learned register
-Milestone list
-Project risk assignment
2. Project Documents:
-Resource Breakdown Structure
-Resource Calendars
-Resource Requirements: la stima dei requisiti delle risorse delle attività avrà un effetto sulla durata delle
attività perché il livello con il quale le risorse assegnate alle attività incontra i requisiti influenzerà
significativamente la durata di molte attività.
-Risk Register: fornisce la lista dei rischi, i risultati dell’analisi di rischio e il piano di risposta al rischio.
3. Enterprice Environmental Factors: includono ma non sono limitati a:
Database di stima della durata e altri dati di riferimento, Metriche di produttività, Informazioni commerciali
pubblicate Posizione dei membri del team.
4. Organizational Process Assets: includono ma non sono limitati a:Informazioni storiche sulle durate,
Calendari di progetto, Politiche di stima, Metodologie di schedulazione, Lesson learned
TOOL & TECHINIQUES
1. Expert Judgement
2. Analogous Estimating (Stima per Analogia): è una tecnica per stimare la durata o il costo di un’attività di
un progetto usando dati storici su attività o progetti simili. Usa parametri provenienti da progetti
precedenti simili quali la durata, il budget, la taglia, il peso e la complessità come base per stimare gli stessi
parametri o misure per i progetti futuri. Tale approccio è frequentemente usato per stimare la durata del
progetto quando ci sono pochi informazioni sul progetto. E’ meno costosa e più veloce di altre tecniche ma
anche meno accurata.
3. Parametric Estimating: è una tecnica di stima nella quale viene usato un algoritmo per calcolare il costo o
la durata basandosi su dati storici e parametri di progetto. Usa una relazione statistica tra i dati storici e
altre variabili per calcolare una stima per i parametri delle attività quali ad esempio il costo, il budget e la
durata. Può essere applicata all’intero progetto o ad una sua parte contemporaneamente ad altri metodi di
stima.
4. Three-point Estimating: l’accuratezza della stima della durata può essere migliorata considerando anche
le incertezze e i rischi. Questo concetto è concretizzato dal PERT (Program Evaluation and review
technique). Il PERT usa 3 stime per definire per definire un range di approssimazione per la durata di
un’attività:
-La più probabile (TM): questa stima è basata sulla durata dell’attività, sulle risorse probabilmente
assegnate, la loro produttività, la disponibilità attesa, le dipendenze e le interruzioni.
-Ottimistica (TO): la durata dell’attività è basata sull’analisi dello scenario migliore per l’attività.
-Pessimistica (TP): la durata dell’attività è basata sull’analisi dello scenario peggiore per l’attività.
Tale tecnica fornisce una durata attesa (media). In funzione della distribuzione di probabilità usata la durata
attesa (TE) pu essere calcolata usando l’opportuna formula. Le due distribuzioni di probabilità
comunemente usate sono la distribuzione triangolare e la beta.
triangolare: TE = (TO + TM + TP) / 3 ; Distribuzione Beta: TE = (TO + 4TM + TP) / 6
5.
Bottom-up estimating: è una tecnica per stimare la durata o il costo di un progetto attraverso
l’aggregazione delle delle componenti della WBS partendo dal basso
6.
Data Analysis:
-Alternatives analysis L'analisi delle alternative viene utilizzata per confrontare alternative ad esempio:
valutazione delle tecniche di compressione; diversi strumenti (manuale contro automatico); make or buy.
-Reserve Analysis: le stime delle durate possono includere delle riserve di contingenza nello schedule del
progetto per tenere in considerazione l’incertezza, di solito indicate come “riserva di tempo” o “buffer”. Le
riserve di contingenza sono stimate nella baseline dello schedule e sono allocate per i rischi identificati
accettati e per i quali sono sviluppate risposte di contingenza o di attenuazione. Le riserve di contingenza
sono associate con rischi “conosciuti-non conosciuti” nel senso di eventi conosciuti che possono accadere
ma di cui non siamo in grado di stimarne l’impatto.
ad esempio: sappiamo che la durata di un’attività pu aumentare rispetto a quella stimata ma non
sappiamo di quanto; abbiamo il rischio di rilavorazioni ma non sappiamo quanto dureranno. Possono
essere una percentuale della durata stimata per l’attività, un numero fisso di periodi o si pu applicare un
metodo di analisi quantitativo quale ad esempio la simulazione Monte Carlo. Tali risorse possono essere
inserite nella durata dell’attività o separate e aggregate in un “buffer” separato (critical chain). Quando si
hanno informazioni più precise sul progetto la riserva può essere usata, ridotta o eliminata. Tali
contingenze dovrebbero essere chiaramente identificate nella documentazione dello schedule.
Possono prevedersi anche riserve di gestione che sono un ammontare specifico della durata del progetto
trattenuta con lo scopo di tenere sotto controllo la gestione del progetto stesso e per lavori imprevisti
all’interno dello “scope” del progetto. Sono associate con rischi “conosciuti-non conosciuti” nel senso di
eventi non conosciuti che possono accadere e di cui non siamo in grado di stimarne l’impatto. Tale riserva
non è inclusa nella baseline dello schedule ma è parte dell’intera durata richiesta per il progetto. In
funzione delle condizioni contrattuali l’utilizzo di tali riserve di gestione può richiedere una variazione della
baseline dello schedule.
Riserva di contingenza
Riserva di Gestione
-known unknowns
unknown unknowns
-Fa parte della baseline del progetto e quindi
Fuori dalla baseline del progetto
sotto il controllo del project manager
(es. critical chain method)
-Può essere una percentuale della durata stimata
-Andando avanti con il progetto possiamo stimarla
Spesso stimata sulla base dei dati storici
meglio
7.
Decision making
8.
Meetings: possono essere utilizzati per stimare la durata delle attività.
OUTPUT
1. Durations Estimates: sono valutazioni quantitative del probabile numero di periodi di tempo che più
verosimilmente (opportunamente) saranno necessari per completare un’attività. La stima delle durate non
comprende ne gli anticipi ne i ritardi precedentemente descritti. Tali stime dovrebbero includere alcune
indicazione dei range (ampiezza) dei possibili risultati, ad esempio 2 settimane +/- 2 giorni (ossia l’attività
impegnerà un minimo di 8 ngiorni e un massimo di 12 giorni) o 15% di probabilità di superare 3 settimane,
etc.
2.
Basis of estimates includono:Documentazione alla base delle stime , Documentazione delle ipotesi ,
Documentazione dei vincoli , Indicazione del range delle possibili stime (as. +-10%) , Indicazione del livello
di confidenza della stima finale , Documentazione riguardo i rischi che possono influenzare la stima.
3.
Project Documents updates: Activity attributes, Assumption log , Lesson Learned Register
Develop Schedule: E’ il processo mediante il quale si analizzano le sequenze delle attività, le durate, i
requisiti delle risorse e i vincoli di schedule per creare un modello di schedule di progetto.
Lo sviluppo di un accettabile
usato per determinare le date di inizio e fine pianificate per le attività e milestone di progetto basandosi
sull’accuratezza degli inputs.
Lo sviluppo dello schedule può richiedere la revisione delle stime delle durate e delle risorse per creare
schedule approvato che possa fungere da baseline per tracciare i progressi del progetto.
bisogna verificare che le date di inizio e fine non siano in conflitto con i calendari delle risorse.
Input
1.Project Management Plan: Schedule Management Plan: identifica il metodo e gli strumenti di scheduling
e come lo schedule è stato calcolato; Scope Baseline
2.Project Documents:
-Activity Attributes: fornisce i dettagli delle attività
-Activity List
-Assumption Log
-Basis of estimates
2. Project Documents:
-Duration Estimates: contiene le valutazioni quantitative della durata di un’attività che sarà usata per
calcolare lo schedule.
-Lesson learned
-Milestone list
-Project Team Assignments: specifica quali risorse sono assegnate alle attività.
-Resource Calendars: contiene informazioni riguardo la disponibilità delle risorse durante il progetto.
-Resource Requirements: identifica la tipologia e la quantità di risorse richieste per ogni attività usata per
creare il modello di schedule
-Risk Register: fornisce i dettagli di tutti i rischi identificati e le loro caratteristiche che influenzano il
modello di schedule.
-Project schedule network diagrams
3. AGREEMENTS
4.Enterprice Environmental Factors: includono ma non sono limitati a: Standard industriali e governativi;
Canali di comunicazione
5.Organizational Process Assets: includono ma non sono limitati a:Metodi di schedulazione;Calendario/i di
progetto(s).
TOOL & TECHINIQUES
1. Schedule Network Analysis: è una tecnica che genera il modello di schedule di progetto. Impiega varie
tecniche analitiche quali il Critical Path Method (CPM), il Critical Chain Method, l’analisi what-if e le
tecniche di ottimizzazione delle risorse per calcolare le date di inizio e fine al più presto e al più tardi. È la
tecnica generale utilizzata per generare il modello di schedulazione del progetto. Impiega alcune tecniche
come il metodo del percorso critico, le tecniche di ottimizzazione delle risorse e le tecniche di modellazione
2. Critical Path Method: è un metodo usato per stimare la durata minima del progetto. Questa tecnica di
analisi calcola le date di inizio e fine al più presto e al più tardi per tutte le attività senza considerare
limitazioni legate alle risorse attraverso una fase “in avanti” e una “all’indietro”del reticolo di attività. Il
cammino critico è la sequenza di attività che rappresenta il percorso più lungo che determina la minima
durata possibile del progetto. Le date di inizio e fine al più presto e al più tardi rappresentano il periodo di
tempo all’interno del quale possono svolgersi le attività.
Il CPM permette inoltre di calcolare la flessibilità dello schedule che misura l’ammontare di tempo di cui pu
essere ritardata o anticipata la data di inizio al più presto di un’attività schedulata senza ritardare la data di
fine del progetto o violare i vincoli. Tale quantità è chiamata ritardo totale (Total Float). Il cammino critico è
caratterizzato da un ritardo totale nullo.
Le attività lungo il cammino critico vengono chiamate attività critiche. Un reticolo può avere più cammini
critici. Una volta calcolato il ritardo totale è possibile calcolare anche il ritardo libero, ossia la quantità di
tempo di cui si può ritardare un’attività senza ritardare l’inizio al più presto del suo successore o violare
vincoli. Le date di inizio e fine al più presto e al più tardi rappresentano il periodo di tempo all’interno del
quale possono svolgersi le attività.
TOOL & TECHINIQUES
3. Resource Optimization : possono essere usate per effettuare la schedulazione tecniche di ottimizzazione
delle risorse quali ad esempio: Livellamento delle risorse: è una tecnica mediante la quale le date di inizio e
fine sono modificate in funzione dei vincoli delle risorse con l’obiettivo di bilanciare la domanda delle
risorse con la disponibilità. Il livellamento delle risorse può essere usato quando le risorse sono condivise,
critiche, disponibili sono in certi intervalli di tempo, in quantità limitate, sovrassegnate, etc. Il livellamento
delle risorse può causare variazioni al cammino critico generalmente lo allunga.
Develop Schedule
Possono essere usate per aggiustare il modello di schedule tecniche di ottimizzazione delle risorse quali ad
esempio:
-Smooting delle risorse: è una tecnica che “aggiusta” le attività di un modello di scheduling in modo tale che
la richiesta delle risorse non ecceda certi limiti predefiniti per esse. A differenza del livellamento delle
risorse il cammino critico non varia e di conseguenza la data di completamento non sarà ritardata. In altri
termini le attività possono essere ritardate solo all’interno del loro ritardo. Tale tecnica pu non avere la
capacità di ottimizzare tutte le risorse.
-Minimizzazione del makespan: il makespan è definito come l’intervallo di tempo tra linizio e la fine del
-Minimizzazione dei costi divisi in:
-Costo delle attività: in relazione al tempo in cui viene realizzata l’attività, ai costi di penale, al modo
in cui viene realizzata l’attività (multi-mode). -Costo delle risorse: il costo del progetto è influenzato
dal modo in cui vengono utilizzate le risorse e da quante risorse vengono utilizzate.
4. Data Analysis esempi di tali tecniche sono:
-What-If-Scenario Analysis: è il processo mediante il quale si valutano degli scenari in modo da predire i loro
effetti, positivi o negativi, sugli obiettivi di progetto. Consiste nell’analizzare la seguente domanda “Qual è
la situazione rappresentata dal verificarsi dello scenario X?”. Il risultato di tale analisi può essere usato per
assicurare la fattibilità dello schedule del progetto al variare di diverse condizioni (ad esempio introduzione
di fattori esterni, ritardo di alcune durate, etc.) e nel preparare i piani di risposta e di contingenza per
superare o mitigare l’impatto dovuto a situazioni inaspettate.
-Simulazione: riguarda il calcolo di diverse durate del progetto con differenti set di assunzioni per le attività
del progetto, di solito usando la distribuzione di probabilità basata sulla stime di 3 punti che tiene in
considerazione l’incertezza. La tecnica può comune di simulazione è l’analisi Monte Carlo, nella quale
viene definita una distribuzione di durate possibili per ogni attività usata per calcolare una distribuzione di
possibili risultati per l’intero progetto.
5. Leads and Lags: sono parametri applicati per sviluppare una pianificazione praticabile regolando il tempo
di inizio delle attività successori. Gli anticipi (leads) sono usati in circostanze limitate per avanzare
un’attività successore rispetto al suo predecessore, mentre i ritardi (lags) sono usati in circostanze in cui i
predecessori necessitano di un determinato periodo di tempo prima che inizino i successori.
6. Schedule Compression: sono tecniche usate per diminuire la durate dello schedule senza variare lo
“scope” del progetto, rispettando i vincoli dello schedule, le date imposte o altri obiettivi di schedule.
Alcune di tali tecniche sono:
-Crashing: è una tecnica usate per diminuire la durata delle attività al minimo incremento di costo
aumentando le risorse. Il crashing lavora con le attività del cammino critico. Non sempre produce
un’alternativa attuabile e può determinare un aumento del rischio e/o costo.
-Fast tracking: è una tecnica di compressione dello schedule nella quale le attività o fasi generalmente
svolte in sequenza vengono eseguite in parallelo per almeno una parte della loro durata. Pu causare
rielaborazioni e un aumento del rischio. Tale tecnica ha senso solo se la sovrapposizione delle attività
determina una riduzione della durata del progetto.
7.Project Management Information System (PMIS) I sistemi informativi di gestione del progetto includono il
software di schedulazione che genera date di inizio e fine basate sugli input delle attività con durate, sui
diagrammi di precedenze, sulle risorse.
8.AGILE release planning è una pianficazione di alto livello (in genere da 3 a 6 mesi) in funzione dello
sviluppo del prodotto.
9.Relationship between product vision, realease planning and iteration planning
OUTPUT
1. Schedule Baseline: è una versione approvata del modello di schedule che pu essere variata solo con un
processo formale di variazione ed è usata come base per i confronti con i risultati effettivi. E’ accettata e
approvata da appropriati stakeholders come baseline dello schedule con le date di inizio e la date di fine.
Durante il Monitoraggio e Controllo le date approvate della baseline vengono confrontate con le date di
inizio e fine effettive per determinare se si sono verificate variazioni. E’ un componente del Project
Management Plan.
2. Project Schedule: lo schedule del progetto è un output del modello di schedule che rappresenta le
attività legate con le date pianificate, le durate, le milestones e le risorse. Come minimo lo schedule di
progetto comprende le date di inizio e fine pianificate per ogni attività. Se viene fatta una pianificazione
delle risorse, lo schedule rimane preliminare finché l’assegnazione delle risorse non viene confermata. Lo
schedule del progetto può essere presentato in modo sommario o in modo dettagliato.
Anche se può essere presentato in forma tabellare generalmente viene rappresentato in forma grafica
usando uno o più format quali ad esempio:
-Bar Charts (diagramma a Barre): tali barre rappresentano informazioni sullo schedule. Le attività sono
elencate nell’asse verticale del grafico, in quello orizzontale vengono mostrate le date e le durate delle
attività sono rappresentate da una barra posizionata tra le date di inizio e fine. Sono semplici da leggere e
sono frequentemente usate nelle presentazioni.
-Milestones Charts: sono simili al Bar Charts ma servono per identificare l’inizio di attività schedulate o il
completamento dei principali deliverables, etc.
-Project Schedule Network Diagrams: è comunemente rappresentato nella forma “activity on node” e
mostra le attività e le relazioni tra esse, alcune volte è chiamato anche diagramma logico. Delle volte pu
essere presentato in un format con una scala temporale chiamato Bar Chart logico.
3. Schedule Data: è una collezione di informazioni per descrivere e controllare lo schedule. Esso include
come minimo le milestones schedulate, le attività schedulate e i relativi attributi e la documentazione di
tutte le ipotesi e vincoli. L’ammontare di ulteriori dati dipende dalla particolare area di applicazione.
Le informazioni frequentemente fornite a supporto includono ad esempio: la richiesta di risorse in funzione
del tempo, spesso in forma di istogramma; Schedule alternativi, ad esempio miglior e peggiore situazione,
con o senza il livellamento delle risorse, con o senza date imposte, etc.
Può includere elementi quali ad esempio istogrammi delle risorse, proiezioni di cash-flow, etc.
4.
Project Calendars: individua i giorni lavorativi e i turni che sono disponibili per lo svolgimento delle
attività. Un modello di schedule può richiedere più di un calendario di progetto . Esso può essere
aggiornato.
5.
Change request
6.Project Management Plan Updates: Schedule management plan;Cost baseline
7. Project Documents Updates: ad esempio: Activity attribute; Assumption log; Duration estimates; Lesson
learned register; Resource Requirement: il livellamento delle risorse può avere un effetto notevole sulle
stime preliminari a causa della tipologia e della quantità di risorse richieste. Il livellamento delle risorse può
causare delle variazioni della richiesta delle risorse; Risk Register
Control Schedule
E’ il processo mediante il quale si monitora lo stato delle attività del progetto per aggiornare il progresso
del progetto e gestire i cambiamenti.
Il vantaggio di tale processo è che fornisce il modo per riconoscere le deviazioni rispetto al pianificato e
attuare le azioni correttive e preventive e quindi minimizzare i rischi
È una componente del Perform Integrated Change Control e riguarda:
-la determinazione dello stato corrente della schedulazione, che influenza i cambiamenti della
schedulazione
-Riconsidera la necessità di ulteriori riserve
-Verifica se la pianificazione del progetto è cambiata e gestisce tali variazioni.
INPUT
1. Project Management Plan: Schedule manegement plan; Schedule baseline; Scope baseline; Performance
measurement baseline
2. Project documents: Lesson learned register ; Project calendars; un modello di schedule può richiedere
più di un calendario di progetto; Project schedule è la schedulazione realizzata più aggiornata con notazioni
che riportano gli aggiornamenti, le attività completate, le attività iniziate con la data di inizio, etc; Resource
calendars ; Schedule data durante tale processo sarà rivisto e aggiornato.
3.Work Performance Data: si riferiscono alle informazioni riguardanti i progressi del progetto ad esempio
quali sono le attività iniziate, i loro progressi (durata attuale, durata rimanente, percentuale fisica di
completamento, etc.) e quali attività sono finite.
4.Organizational process assets Possono includere ma non sono limitati a:
-Politiche di controllo, procedure formali e informali dello schedule
-Strumenti di controllo
-Metodologie di monitoraggio e reporting
TOOL & TECHINIQUES
1. Data analysis:
-Earned Value Analysis: indici quali SV ed SPI sono usati per misurare la grandezza della variazione rispetto
alla baseline dello schedule. Aspetti importanti del controllo dello schedule includono la determinazione
delle cause e del grado di variazioni relative alla baseline dello schedule, la stima delle implicazioni di
queste variazioni per il completamento futuro del lavoro e decidere se sono necessarie azioni correttive o
preventive
-Iteration burndown chart: Tale grafico tiene traccia del lavoro che rimane da completare nel backlog di
iterazione. Viene utilizzato per analizzare la varianza rispetto a un burndown ideale basato sul lavoro
eseguito dalla pianificazione iterativa (vedere la Sezione 6.4.2.8). Una linea di tendenza di previsione pu
essere utilizzata per prevedere la probabile varianza al termine dell'iterazione e prendere le azioni
appropriate durante il corso dell'iterazione. Viene quindi tracciata una linea diagonale che rappresenta il
burndown ideale e il lavoro rimanente giornaliero effettivo. Viene quindi calcolata una linea di tendenza
per prevedere il completamento in base al lavoro rimanente.
-Performance reviews Le revisioni delle prestazioni misurano, confrontano e analizzano le prestazioni della
pianificazione rispetto alla baseline del programma, come le date di inizio e fine effettive, la percentuale di
completamento e la durata rimanente per il lavoro in corso, ecc.
-Trend Analysis esamina la perfomance del progetto per determinare se sta migliorando o peggiorando. Le
tecniche di analisi grafiche sono preziose per comprendere la performance.
-Variance analysis. Analizza le variazioni di ci che è stato realizzato rispetto al pianificato, determinando le
cause e il grado di variazione rispetto alla baseline
-What-if scenario analysis: è utilizzata per valutare i vari scenari qui dati dai processi per la gestione dei
rischi
2. Critical Path Mehod: considerare i progressi lungo il cammino critico può aiutare a determinare lo stato
dello schedule. Le variazioni del cammino critico avranno un impatto diretto sulla data di fine del progetto.
Valutare il progresso delle attività del cammino critico può identificare il rischio di non rispettare le date di
consegna.
3. Project Management Information Systems (PMIS)
4.
Resource Optimization: coinvolge la programmazione delle attività e le risorse necessarie per
svolgere tali attività tenendo in considerazione la disponibilità delle risorse e il tempo di progetto.
5.
Leads and Lags: gli aggiustamenti tramite anticipi e ritardi durante l’analisi del reticolo sono utili ad
allineare le attività del progetto con il pianificato.
6.
Schedule Compression: sono utili ad allineare le attività del progetto con il pianificato.
OUTPUT
1.
Work Performance Information: sono documentati e comunicati agli stakeholders gli indici SV e SPI
e altre informazioni sulla performance.
2.
Schedule Forecasts: sono stime e previsioni di condizioni o eventi futuri del progetto basate su
informazioni e conoscenze disponibili al momento della previsione. Le informazioni sono basate sulle
performance passate del progetto e includono gli indicatori di performance dell’Earned Value che
potrebbero influenzare il progetto in futuro.
3. Change Request: l’analisi della varianza dello schedule, i risultati delle misure di performance e le
modifiche allo “scope” o allo schedule del progetto pu comportare richieste di variazioni alla baseline dello
schedule e dello “scope” e/o ad altri componenti del Project Management Plan e documenti.
4. Project Management Plan Updates: ad esempio:
-Schedule Baseline: cambiamenti alla baseline dello schedule fanno parte della risposta alle richieste di
variazioni approvate dovute alle variazioni dello “scope” del progetto, delle risorse o alla stime delle durate.
La baseline dello schedule può essere aggiornata per riflettere le variazioni causate dalle tecniche di
compressione, fast tracking, ecc.
-Cost Baseline: può essere aggiornata per riflettere le variazioni causate dalle tecniche di compressione.
-Performance measurement baseline
5. Project Documents Updates: ad esempio: Assumption Log; Basis of estimates; Lesson Learned; Project
Schedule: verrà generato uno schedule aggiornato sulla base dei dati aggiornati per riflettere i cambiamenti
e gestire il progetto; Resource Calendars; Risk Register: il registro dei rischi e il piano di risposta al rischio
possono essere aggiornati sulla base dei rischi che possono insorgere a causa delle tecniche di
compressione della pianificazione. Schedule Data: nuovi diagrammi dei reticoli di progetto possono essere
sviluppati per mostrare le durate residue e le modifiche approvate allo schedule. In alcuni casi i ritardi di
pianificazione possono essere così severi che lo sviluppo di un nuovo schedule con date di inizio e fine
previsti è necessario per fornire dati realistici per dirigere i lavori, misurare la performance e misurare i
progressi.
PROJECT RISK MANAGEMENT
Project Risk Management (PMBOK)
- L'area di conoscenza della gestione dei rischi di progetto riguarda la conduzione dei processi legati alla
pianificazione e gestione dei rischi: alla loro identificazione e analisi, alla predisposizione delle risposte ai
rischi, all’implementazione delle risposte ai rischi e al loro monitoraggio e controllo nel corso del progetto.
- Gli obiettivi della gestione del rischio del progetto sono incrementare la probabilità e l’impatto degli
eventi positivi e diminuire la probabilità e l’impatto degli eventi negativi del progetto.
- Il rischio del progetto è un evento incerto o una condizione che, se avviene, ha un effetto positivo o
negativo su uno o più elementi di progetto quali lo “scope”, lo schedule, il costo e la qualità. - Un rischio
può avere una o più cause e, se si verifica, può avere uno o più impatti.
- Ogni progetto contiene rischi individuali che possono influenzare il raggiungimento degli obiettivi del
progetto. Inoltre è importante considerare Il rischio complessivo del progetto, che deriva dalla
combinazione dei singoli rischi del progetto e di altre fonti di incertezza.
- I processi di Project Risk Management riguardano entrambi i livelli di rischio nei progetti e sono definiti
come segue:
- Il rischio di progetto individuale è un evento o una condizione incerta che, se si verifica, ha un effetto
positivo o negativo su uno o più obiettivi del progetto.
- Il rischio complessivo del progetto è l'effetto dell'incertezza sul progetto nel suo insieme, derivante da
tutte le fonti di incertezza inclusi i rischi individuali, che rappresentano l'esposizione complessiva delle parti
interessate alle implicazioni delle variazioni nei risultati del progetto, sia positive che negative e di altre
fonti di incertezza.
Una causa può essere un dato o un potenziale requisito dell’evento rischioso; un’ipotesi, un vincolo creano
la possibilità di un risultato positivo o negativo.
- Il rischio del progetto ha origine dalle incertezze presenti nel progetto stesso.
- I rischi conosciuti sono quelli che sono stati identificati e analizzati e per essi è possibile fare un piano di
risposta al rischio.
- I rischi sconosciuti sono quelli che non sono stati identificati.
- Ai rischi conosciuti che non possono essere gestiti in maniera proattiva dovrebbe essere assegnata una
riserva di contingenza.
-Ai rischi sconosciuti che non possono essere gestiti in maniera proattiva dovrebbe essere assegnata una
riserva di gestione.
- Un rischio negativo del progetto, quando accade, è considerato un problema. Quello positivo
un’opportunità.
- Le organizzazioni e gli stakeholders sono disposti ad accettare vari gradi di rischio in funzione della loro
propensione al rischio.
- Il livello di rischio accettabile per l’organizzazione e gli stakeholders può essere influenzato da diversi
fattori: propensione al rischio (risk appetite): funzione del -grado di incertezza che una certa organizzazione
è disposta ad assumere in previsione di una ricompensa a seguito della scelta di un’alternativa che ha un
certo costo. PMBOK2017: Il grado di incertezza che un'organizzazione o un individuo è disposto ad
accettare in previsione di un premio; -soglia di rischio: è la misura del livello di incertezza/impatto in
corrispondenza del quale uno stakeholders modifica il suo comportamento. Sotto tale soglia di rischio
l’organizzazione accetterà il rischio. Oltre tale soglia di rischio l’organizzazione non tollererà il rischio e
dovrà affrontarlo. Lexicon PMI 2017: misura di una variazione accettabile di un obbiettivo che riflette la
propensione al rischio di una organizzazione
- Escalation del rischio (risk escalation): Una strategia di risposta al rischio in base alla quale il team
riconosce che un rischio è al di fuori della sua sfera di influenza e sposta la gestione del rischio a un livello
più alto dell'organizzazione in cui è gestito in modo più efficace.
- Responsabile del rischio (Risk Owner): la persona responsabile del monitoraggio dei rischi, della selezione
e dell'attuazione di un'adeguata strategia di risposta al rischio.
Trend and emerging practices in project risk management (PMBOK) :
La gestione del rischio di progetto si sta ampliando per garantire che i rischi del progetto siano compresi in
un contesto più ampio. Le tendenze e le pratiche emergenti per la gestione dei rischi del progetto
includono, a titolo esemplificativo ma non esaustivo:
-Rischi relativi agli eventi: Esempi di rischi basati sugli eventi includono: un venditore chiave può fallire
durante il progetto, il cliente può cambiare il requisito dopo che la progettazione è stata completata, o un
subappaltatore può proporre miglioramenti ai processi operativi standard.
-Rischi non dovuti ad eventi. Vi è un crescente riconoscimento del fatto che i rischi non-evento devono
essere identificati e gestiti. Esistono due tipi principali di rischi non legati all'evento:
- rischio di variabilità : L'incertezza esiste su alcune caratteristiche chiave di un evento o attività
pianificata o decisione. Esempi di rischi di variabilità includono: la produttività può essere sopra o sotto
l'obiettivo, il numero di errori riscontrati durante il test può essere più alto o più basso del previsto, oppure
possono verificarsi condizioni meteorologiche non stagionali durante la fase di costruzione.
- Rischio di ambiguità - L'incertezza esiste su ciò che potrebbe accadere in futuro a causa di una
conoscenza imperfetta. Le aree del progetto in cui la conoscenza imperfetta potrebbe creare ambiguità e
influenzare la capacità del progetto di raggiungere i suoi obiettivi includono: elementi del requisito o
soluzione tecnica, sviluppi futuri nei quadri normativi o complessità sistemica nel progetto.
Plan Risk Management (PMBOK)
E’ il processo mediante il quale si definisce come si conducono le attività di gestione dei rischi per il
progetto.
Il vantaggio di questo processo è che il grado, il tipo e la visibilità della gestione del rischio sono
commisurati sia ai rischi sia all’importanza del progetto per l’organizzazione.
Il Plan risk management dovrebbe iniziare nel momento in cui viene concepito il progetto e dovrebbe
essere completato il più presto possibile.
INPUT
1. Project charter
2. Project Management Plan
3. Project documents tra cui: - Stakeholder register
4. Enterprice environmental factors
5. Organizational Process Assets includono: - Politica sul rischio dell’organizzazione - Categorie di rischio,
struttura della RBS - Definizione di rischio, concetti comuni e termini - Format di descrizione del rischio Template per la gestione del rischio - Ruoli e responsabilità nell’organizzazione - Livelli di autorità per
assumere le decisioni - Archivio delle lesson learned
TOOL & TECHNIQUES
1. Expert Judgement: la competenza dovrebbe provenire da un gruppo o individuo con una formazione
specialistica o con conoscenza dell’argomento specifico, come ad esempio i Senior Management, gli
stakeholders di progetto, i PM che hanno lavorato in progetti relativi alla stessa area (direttamente o
tramite lezioni apprese), gli esperti in materia, gruppi industriali o consulenti e associazioni professionali o
tecniche.
2. Data Analysis: includono ma non sono limitati l’analisi degli stakeholders
3. Meetings: i membri del team di progetto tengono riunioni per sviluppare il piano di gestione del rischio. I
partecipanti a tali riunioni sono ad esempio il PM, selezionati membri del team di progetto e stakeholders,
chiunque ha la responsabilità, all’interno dell’organizzazione, di gestire la pianificazione del rischio e
l’esecuzione delle attività, etc.
OUTPUT
1. Risk Management Plan: è un componente del Project Management Plan e descrive come la gestione
delle attività del rischio saranno strutturate ed eseguite. Il Risk Management Plan include:
- Risk strategy descrive l’approccio generale alla gestione del rischio nel progetto.
- Metodologia: definisce i modelli, gli strumenti e le sorgenti dei dati che saranno usati per la gestione del
rischio di progetto.
- Ruoli e responsabilità: definisce le modalità di gestione dei rischi da parte dei membri del team per ogni
tipologia di rischio e chiarisce le loro responsabilità.
- Budgettizzazione: stima i fondi necessari sulla base delle risorse assegnate, per includerli nella baseline dei
costi e stabilisce i protocolli di applicazione per l’applicazione di riserve di contingenza e di gestione.
- Tempificazione: definisce quando e quanto spesso i processi di gestione del rischio saranno eseguiti lungo
il ciclo di vita del progetto, stabilisce protocolli per l’applicazione delle riserve di contingenza dello schedule
e stabilisce attività di gestione dei rischi per includerle nello schedule di progetto.
- Categorie di rischio: fornisce un modo per raggruppare le potenziali cause di rischio. Possono essere usati
diversi approcci. La Risk Breakdown Structure (RBS) aiuta i membri del team a guardare diverse fonti da cui
può sorgere il rischio del progetto. Per i diversi progetti saranno appropriate diverse RBS . Ogni
organizzazione può usare un framework customizzato che può assumere la forma di una semplice lista di
categorie o può essere strutturato come RBS. L’RBS è una rappresentazione gerarchica del rischio in
funzione delle loro categorie di rischio.
-La propensione al rischio degli stakeholder. Le propensioni al rischio dei principali stakeholder sono
registrate nel piano di gestione dei rischi, in quanto forniscono informazioni dettagliate sul processo di
gestione dei rischi del piano. In particolare, la propensione al rischio degli stakeholder dovrebbe essere
espressa come soglia di rischio misurabile attorno a ciascun obiettivo del progetto. Queste soglie
determinano il livello accettabile di esposizione complessiva al rischio del progetto e sono anche utilizzate
per informare le definizioni di probabilità e impatti da utilizzare nel valutare e dare la priorità ai singoli
rischi del progetto.
-Definizione della probabilità e impatto dei rischi: la qualità e la credibilità dell’analisi dei rischi richiede che
i diversi livelli di probabilità e impatto del rischio definiti siano specifici del particolare contesto del
progetto.
- Matrice probabilità impatto: è una griglia per mappare la probabilità di ogni evento rischioso e il suo
impatto sugli obiettivi di progetto se il rischio si verifica. I rischi sono priorizzati secondo le loro implicazioni
potenziali che hanno un effetto sugli obiettivi di progetto. Un approccio tipico per la priorizzazione dei
rischi è usare una tabella o la matrice probabilità/impatto. Le combinazioni specifiche della probabilità e
dell’impatto che portano a valutarlo di importanza “alta”, “moderata” o “bassa” sono di solito stabilite
dall’organizzazione. 38 Plan Risk Management (PMBOK) OUTPUT 1. Risk Management Plan: - Matrice
probabilità impatto:
- Format dei report: definisce come i risultati del processo di gestione del rischio saranno documentati,
analizzati e comunicati. Descrive il contenuto e il format del registro dei rischi come degli altri report dei
rischi richiesti.
- Monitoraggio: documenta come i rischi saranno monitorati.
IDENTIFY RISK
E’ il processo mediane il quale si identificano i rischi che possono influenzare il progetto e si documentano
le loro caratteristiche.
Il vantaggio di questo processo è che la documentazione fornisce le conoscenze e la capacità al team di
progetto di anticipare gli eventi.
-Alle attività di identificazione del rischio partecipano ad esempio il Project Manager, i membri del team di
progetto, i team di gestione del rischio, i clienti, gli esperti, gli stakeholders e gli esperti di gestione del
rischio, che sono elementi chiave per l’identificazione del rischio, mentre tutto il personale di progetto
dovrebbe essere incoraggiato a identificare i rischi potenziali
- L’identificazione dei rischi è un processo iterativo perché nuovi rischi possono evolvere o emergere con lo
svolgere del ciclo di vita del progetto.
- Il processo dovrebbe coinvolgere i membri del team in modo che essi possano sviluppare e mantenere un
senso di responsabilità per i rischi e le azioni associate di risposta al rischio.
INPUT
1. Project Management Plan:
- Requirements management plan: Serve ad identificare quali requisiti/obbiettivi sono a rischio
- Schedule management plan: serve ad identificare quale parte della schedulazione è incerta o ambigua
- Cost management plan: serve ad identificare quale parte della identificazione dei costi e del budget è
incerta o ambigua
- Quality management plan.
- Resource management plan: serve ad identificare quale parte del piano della gestione delle risorse è
incerta o ambigua o basata su ipotesi che possono fare sorgere rischi.
- Risk management plan:. le categorie dei rischi e la struttura della RBS sono una guida per l’identificazione
dei rischi.
- Scope baseline
- Schedule baseline.
- Cost baseline.
2. Project Documents: - Assumption log. - Cost estimates. - Duration estimates. - Issue log. - Lessons
learned register. - Requirements documentation. - Resource requirements. - Stakeholder register.
3. Agreements
4. Procurement documentation: Se il progetto richiede l'approvvigionamento esterno di risorse, tale
approvvigionamento di beni e servizi esterni all'organizzazione potrebbe aumentare o diminuire il rischio
complessivo del progetto e potrebbe comportare ulteriori rischi specifici per il progetto.
5. Enterprice environmental factors includono: - Materiale pubblicato, compresi database commerciali o
liste di controllo, - Studi accademici, - Risultati di benchmarking - Studi di settore di progetti simili.
6. Organizational process assets include: - File di progetto - Processi di controllo dell’organizzazione e del
progetto - Formati per descrizione rischi - Check list da progetti pregcedenti
TOOL & TECHNIQUES
1. Expert Judgment: i rischi possono essere identificati direttamente da esperti con esperienza rilevante con
progetti simili. Tali esperti devono essere identificati dal PM e sono invitati a considerare tutti gli aspetti del
progetto e suggerire i possibili rischi basati su precedenti esperienze. Bisogna tenere in considerazione in
tale processo l’errore degli esperti.
2. Data Gathering Techniques: ad esempio:
- Brainstorming: il goal del brainstorming è ottenere una lista dei rischi del progetto. Di solito si esegue il
brainstorming con un set multidisciplinare di esperti che non fanno parte del team. Le idee circa i rischi del
progetto sono generate sotto la leadership di un facilitatore o in una sessione tradizionale di brainstorming
in forma libera. I rischi sono spesso identificati e categorizzati in funzione del tipo di rischio.
ad esempio: - Checklist : sono sviluppate basandosi su informazioni storiche e conoscenze che sono state
accumulate in progetti simili precedenti e da altre sorgenti di informazioni Una checklist può essere veloce
e semplice da costruire. Il team deve comunque esplorare anche gli elementi che non compaiono nella
checklist. La checklist deve essere revisionata durante la chiusura del progetto per incorporare le nuove
lezioni apprese e migliorarne l’so per i progetti futuri.
- Interviste: intervistare i partecipanti esperti al progetto, gli stakeholders e i soggetti esperti aiuta a
identificare i rischi.
3. Data Analysis : ad esempio:
- Analisi delle cause: è una tecnica specifica usata per identificare un problema, scoprire le cause che lo
determinano e sviluppare azioni preventive.
- Analisi dei vincoli e delle ipotesi
- SWOT Analysis: questa tecnica esamina il progetto considerandone i punti di forza, debolezza,
opportunità e minacce (strengths, weaknesses, opportunities, threats, SWOT). La tecnica inizia
identificando i punti di forza e debolezza dell’organizzazione concentrandosi sul progetto e
sull’organizzazione. Tale analisi identifica le opportunità per il progetto che possono essere influenzati da
punti di forza organizzativi e le eventuali minacce derivanti da carenze organizzative. L’analisi prende in
esame anche il grado con il quale le forze organizzative compensano le minacce così come le opportunità
possono servire a superare le debolezze. Gli allievi approfondiranno il tema predisponendo un documento
da portare agli esami
- Document analysis: può essere eseguito un riesame strutturato dei documenti di progetto che include le
pianificazioni, le ipotesi , i file di progetto, gli accordi e altre informazioni, i contratti. La qualità delle
pianificazioni, così come la consistenza tra quello pianificato e i requisiti e le ipotesi di progetto possono
essere indicatori dei rischi del progetto.
4. Interpersonal and team skills
5. Prompt list Un elenco sommario predeterminato di categorie di rischio che potrebbero dar luogo a rischi
di progetto individuali e che potrebbero anche fungere da fonti di rischio complessivo del progetto.
L'elenco sommario può essere utilizzato come una struttura per aiutare il team di progetto nella
generazione di idee quando si utilizzano tecniche di identificazione del rischio.
6. Meetings
OUTPUT
1. Risk Register: Il registro dei rischi riporta i dettagli dei singoli rischi identificati del progetto. I risultati di
Eseguire analisi qualitativa del rischio, Pianificare le Risposte al rischio, Implementare le Risposte dei Rischi
e Monitorare i Rischi sono registrati nel registro dei rischi poiché tali processi sono condotti durante tutto il
progetto. Al completamento del processo Identify Risks, il contenuto del registro dei rischi può includere
ma non è limitato a:
- Elenco dei rischi identificati. Ogni rischio di progetto individuale viene assegnato un identificativo univoco
nel registro dei rischi. I rischi identificati sono descritti in tutti i dettagli necessari per garantire una
comprensione non ambigua. Una dichiarazione di rischio strutturata può essere utilizzata per distinguere i
rischi dalla loro causa e il loro effetto.
- Potenziali responsabili di rischi. Quando è stato identificato un potenziale responsabile del rischio durante
il processo Identify Risks, il responsabile del rischio è registrato nel registro dei rischi.
- Lista delle potenziali risposte al rischio
2. Risk report:. - Relazione sui rischi presenta informazioni sulle fonti del rischio complessivo del progetto,
unitamente a informazioni sintetiche sui singgoli rischi. Il rapporto sui rischi è sviluppato progressivamente
durante il processo di Project Risk Management. I risultati dell'analisi qualitativa del rischio, esecuzione
dell'analisi quantitativa del rischio, pianificazione delle risposte al rischio, implementazione del rischio le
risposte e i rischi di monitoraggio sono via via inclusi nel rapporto sui rischi al termine di tali processi
3. Project documents updates:. - Assumption log - Issue log - Lesson learned register
Perform Qualitative Risk Analysis (PMBOK)
- E’ il processo di priorizzazione dei rischi per le analisi future o azioni valutando e combinando la
probabilità di accadimento e l’impatto.
Il vantaggio di questo processo è che permette ai PM di focalizzare l’attenzione sui rischi che hanno una
elevata priorità.
Valuta la priorità dei rischi tramite le loro probabilità di accadimento e il corrispondente impatto sugli
obiettivi del progetto, ma considera altresì i tempi di risposta e di tolleranza al rischio dell’organizzazione
associati con i vincoli di costo, schedule, “scope” e qualità del progetto.
- Tali valutazioni sono soggettive in quanto basate sulla percezione del rischio da parte del team di progetto
e di altr stakeholder.
- Tali valutazioni riflettono la propensione al rischio del project team e degli altri stakeholders.
- Tale processo pone le fondamenta per la Perform Quantitative Risk Analysis, si svolge regolarmente
durante il ciclo di vita del progetto e può portare alla Perform Quantitative Risk Analysis o direttamente al
Plan Risk Responses. Perform Quantitative Risk Analysis o direttamente al Plan Risk Responses
RISK EVALUATION:
-Analisi del rischio : analisi delle informazioni disponibili
- Stima del rischio: stimare il rischio in funzione dei criteri per determinare le priorità dei rischi, il loro
impatto.
-La probabilità dell’evento rischioso, cioè la probabilità che l’evento rischioso possa verificarsi.
- L’impatto, cioè l’effetto che l’evento rischioso può avere sugli obiettivi del progetto allorché si verifichi.
Un evento dall’alto impatto è in genere scarsamente probabile, mentre un evento molto probabile
possiede in genere un modesto impatto
Possibile classificazione dei rischi:
- Rischi catastrofici: l’impatto del rischio, valutato in relazione alle risorse e alla capacità dell’azienda, può
seriamente compromettere l’attività aziendale e persino causare la cessazione dell’attività.
- Rischi rilevanti: il rischio compromette l’equilibrio finanziario dell’azienda, imponendo il ricorso a fonti
esterne di finanziamento o alla riduzione temporanea dell’attività operativa.
- Rischi minori: sono rischi il cui impatto è ben assorbito dall’azienda. Tali rischi presentano una elevata
probabilità di accadimento; Al diminuire dell’impatto dell’evento cresce il fabbisogno di accuratezza In
funzione dell’accuratezza A si presentano due casi:
1 - IMPATTO ALTO – PROBABILITA’ BASSA: Elevati costi marginali all’aumentare di A dovuti alla difficoltà di
reperire dati sufficienti (scarseggiano i dati storici) Bassi benefici marginali, dovuti alla quasi unicità delle
decisioni.
INPUT
1. Project Management Plan
2. Project Documents: - Assumption log; Risk register: contiene le informazioni che saranno usate per
valutare e priorizzare i rischi; Stakeholder register
3. Enterprise Environmental Factors: include: Studi di progetti simili: Materiale pubblicato compresi
database o checklist relativi al rischio
4. Organizational Process Assets
TOOL & TECHNIQUES
1. Expert Judgment: è richiesto per valutare la probabilità e l’impatto di ogni rischio e per posizionarlo
nella relativa matrice. Gli esperti sono generalmente coloro che hanno esperienze su precedenti progetti
simili. La raccolta del giudizio degli esperti è spesso realizzata grazie all’ausilio di workshop o interviste.
2. Data gathering: Include le interviste
3. Data Analysis: include:
-Risk data quality assessment: valuta il grado in cui i dati sui singoli rischi del progetto sono accurati e
affidabili come base per l'analisi qualitativa del rischio.
- Risk Probability and Impact Assessment: valuta la probabilità che si verifichi ogni specifico rischio e il
potenziale effetto sugli obiettivi, schedule, costo, qualità o performance, del progetto includendo sia gli
effetti negativi delle minacce che quelli positive delle opportunità. La probabilità e l’impatto sono
valutate per ogni rischio identificato. I rischi, il loro livello di probabilità e impatto, possono essere
valutati durante interviste o i meeting dove i partecipanti sono selezionati in funzione della loro
familiarità con le categorie di rischio. Le probabilità e l’impatto dei rischi hanno dei punteggi che sono in
accordo con quanto stabilito nel Risk Management Plan. I rischi con un punteggio basso di probabilità e
impatto saranno inseriti nel registro dei rischi per futuri monitoraggi (watch list)
-Assessment of other risk parameters: Il team di progetto può prendere in considerazione altre
caratteristiche di rischio (oltre alla probabilità e all'impatto) per attribuire priorità ai singoli rischi del
progetto per ulteriori analisi e azioni. Ad esempio:
- Urgenza (Urgency): Il periodo di tempo entro il quale deve essere implementata una risposta al rischio
per essere efficace.
- Prossimità (Proximity): Il periodo di tempo prima che il rischio possa avere un impatto su uno o più
obiettivi del progetto. Un breve periodo indica un'elevata prossimità.
- Dormienza (Dormancy): Il periodo di tempo che può trascorrere dopo che si è verificato un rischio
prima che venga scoperto il suo impatto. Un breve periodo indica una bassa dormienza.
- Gestibilità (Manegeability): La facilità con cui il responsabile del rischio (o l'organizzazione
responsabile) può gestire il verificarsi o l'impatto di un rischio. Dove la gestione è semplice, la gestibilità
è alta.
- Controllabilità (Controllability) Il grado in cui il responsabile del rischio (o l'organizzazione responsabile)
è in grado di controllare l'esito del rischio. Dove il risultato può essere facilmente controllato, la
controllabilità è alta.
- Rilevabilità (Detectability). La facilità con cui i risultati del rischio che si verificano o che stanno per
verificarsi possono essere rilevati e riconosciuti. Dove l'evento di rischio può essere rilevato facilmente,
la rilevabilità è alta.
- Connettività (Connectivity) La misura in cui il rischio è correlato ad altri rischi di progetto individuali.
Quando un rischio è collegato a molti altri rischi, la connettività è alta.
- Impatto strategico (Strategic impact) Il potenziale per il rischio di avere un effetto positivo o negativo
sugli obiettivi strategici dell'organizzazione.
- Affinità (Propinquity). Il grado in cui un rischio è percepito come rilevante da uno o più stakeholder.
Dove un rischio è percepito come molto significativo, la l’affinità è alta. Calcolo dei livelli di rischio
Matrice rischi-attività e Matrice rischi-periodo
- Identificare i principali rischi del progetto e sviluppare una RBS
-Valutare magnitudo della conseguenza e probabilità del rischio elementare: l'indice di probabilità IP (110) dell'evento; l'indice di impatto II (1-10) dell'evento sul progetto; calcolare il rischio elementare RE
come prodotto IP x II
- Aggregare i rischi elementari
- Classificare i rischi
- Associare i rischi alle attività di progetto
- Collocare i rischi nel tempo
- Definire le strategie di gestione dei rischi
Calcolo dell’indice di probabilità e di impatto dei livelli superiori della WBS Ipotesi:
1) il rischio aggregato di un gruppo omogenei di rischi è uguale alla somma dei rischi elementari;
2) l'indice di rischio aggregato per un gruppo omogeneo è uguale al prodotto dell'indice di probabilità
dei rischi aggregati per l'indice di impatto degli stessi;
3) l'indice di probabilità dei rischi aggregati è proporzionale alla sommatoria degli indici di probabilità
dei rischi elementari;
4) l'indice di impatto dei rischi aggregati è proporzionale alla sommatoria degli indici di impatto dei
rischi elementari; - Si indichi con: - RA il rischio aggregato; - IPA l'indice di probabilità del rischio
aggregato; - IIA l'indice di impatto del rischio aggregato;
Rappresentazione Impatto-Probabilità
Rappresentazione degli indici di probabilità e di impatto ai diversi livelli gerarchici in uno spazio
cartesiano avente in ascisse l'indice di impatto ed in ordinate l'indice di probabilità ed identificazione
delle fasce isorischi nella matrice.
Matrici rischi-attività Matrici rischi-tempi:
Matrice le cui righe rappresentano le attività o gli intervalli di tempo e le cui colonne rappresentano gli
eventi di rischio. L'elemento rij è l'aliquota dell'indice di rischio j da assegnare all'attività i o
all’intervallo di tempo i.
Si può dedurre da tale matrice l'istogramma dei rischi per attività o per il tempo.
4. Interpersonal and team skills
5. Risk Categorization: i rischi possono essere classificati in funzione della fonte (ad esempio usando la
RBS), l’area che influenza il progetto (ad esempio usando la WBS) o altre categorie (ad esempio le fasi
del progetto) per determinare le aree del progetto maggiormente esposte all’effetto delle incertezze.
6. Data representation:
- Probability and Impact Matrix: i rischi possono essere priorizzati per analisi quantitative future e per la
pianificazione delle risposte ai rischi sulla base dei punteggi dei rischi stessi. La valutazione
dell’importanza dei rischi è tipicamente condotta usando una tabella o una matrice
probabilità/impatto. Tale matrice specifica la combinazione della probabilità e dell’impatto che portano
a valutare i rischi come a priorità bassa, moderata o alta. Possono essere usati termini descrittivi o
valori numerici in funzione delle preferenze dell’organizzazione. L’organizzazione deve determinare
quale combinazione di probabilità e impatto risulta in una classificazione di rischio alto, moderato e
basso. Probability and Impact Matrix:
- Hierarchical charts: Laddove i rischi sono stati categorizzati utilizzando più di due parametri, la matrice
di probabilità e impatto non può essere utilizzata e sono necessarie altre rappresentazioni grafiche. Ad
esempio, un grafico a bolle visualizza tre dimensioni dei dati, in cui ogni rischio viene rappresentato
come un disco (bolla) ei tre parametri sono rappresentati dal valore dell'asse x, dal valore dell'asse e
della dimensione della bolla.
OUTPUT
1. Project Documets Updates: ad esempio - Il log delle ipotesi (assumption log): deve essere aggiornato
per riflettere le nuove informazioni che si ottengono in seguito alla valutazione qualitativa del rischio.
Le ipotesi possono anche essere incluse nel Project Scope Statement. - Issue log: Il registro dei problemi
deve essere aggiornato per acquisire eventuali nuovi problemi scoperti o modifiche ai problemi già
registrati.
- Il Registro dei rischi: tale registro è aggiornato in quanto sono disponibili in seguito alla valutazione
qualitativa del rischio nuove informazioni, ad esempio la watch list dei rischi con bassa priorità
- Il Risk report: Il rapporto sui rischi viene aggiornato per riflettere i più importanti rischi individuali del
progetto
Perform Quantitative Risk Analysis (PMBOK)
E’ il processo di analisi numerica quantitativa dell’effetto dell’identificazione dei rischi sugli obiettivi del
progetto.
Il vantaggio di questo processo è che fornisce informazioni quantitative sul rischio per supportare le
decisioni relative alla riduzione delle incertezze del progetto.
Tale analisi è eseguita sui rischi che sono stati priorizzati nel processo Perform Qualitative Risk Analysis
come quelli che impattano potenzialmente e sostanzialmente le richieste contrastanti del progetto. Tale processo analizza gli effetti di questi rischi sugli obiettivi del progetto. –
Tale processo è utilizzato soprattutto per valutare l’effetto complessivo di alcuni rischi che interessano
il progetto.
Generalmente tale processo segue il processo Perform Qualitative Risk Analysis. - Eseguire analisi
quantitativa del rischio non è richiesto per tutti i progetti. L'esecuzione di una solida analisi dipende
dalla disponibilità di dati di alta qualità sui singoli rischi del progetto.
-In alcuni casi non è possibile eseguire il processo Perform Quantitative Risk Analysis a causa della
mancanza di dati sufficienti allo sviluppo di appropriati modelli.
- Il PM deve usare il giudizio degli esperti per determinare la necessità e la fattibilità di un’analisi
quantitativa del rischio.
- La disponibilità di tempo e budget e la necessità di valutazioni qualitative o quantitative circa il rischio
e gli impatti determineranno quale metodo/i usare per ogni particolare progetto.
INPUT
1. Project Management plan
- Risk Management Plan: fornisce linee guida, metodi e strumenti da usare nell’analisi quantitativa del
rischio.
- Scope baseline
- Schedule baseline
- Cost baseline
2. Project documents: - Assumption log; - Basis of estimates; - Cost estimate; - Cost forecasts; - Duration
estimatres; - Milestone list; - Resource requirements; - Risk register; - Risk report; - Schedule forecast
3. Enterprise Environmental Factors includono: - Analisi e studi di progetti simili - Materiale pubblicato
compresi database o checklist relativi al rischio
4. Organizational Process Assets
TOOL & TECHNIQUES
1. Expert Judgment: Il giudizio degli esperti è richiesto per identificare costi potenziali, per valutare la
probabilità e definire input. Il giudizio degli esperti entra in gioco anche nell’interpretazione dei dati
2. Data Gathering può essere usata per generare input per l’analisi quantitativa: - Interviste: tale tecnica si
basa sull’esperienza e su dati storici per quantificare la probabilità e l’impatto dei rischi sugli obiettivi del
progetto. L’informazione necessaria dipende dal tipo di distribuzione di probabilità che sarà usata. Per
esempio le informazioni possono essere raccolte su scenari ottimistici, pessimistici o più probabili
3. Interpersonal and team skills
4. Representantions of uncertainty: L'analisi quantitativa del rischio richiede input quantitativi. Quando la
durata, il costo o il fabbisogno di risorse per un'attività pianificata sono incerti, l'intervallo di valori possibili
può essere rappresentato nel modello come una distribuzione di probabilità. Le più comunemente usate
sono distribuzioni triangolari, normali, lognormali, beta, uniformi o discrete.
5. Data Analysis:
- Modellazione e simulazione: la simulazione usa un modello che traduce le specifiche incertezze del
progetto nel loro potenziale impatto sugli obiettivi del progetto. Le simulazioni sono tipicamente eseguite
usando la tecnica Monte Carlo. In una simulazione il modello del progetto è calcolato molte volte (iterato)
con valori di input (ad esempio la stima dei costi o la durata dell’attività) scelti in modo random in ogni
iterazione da una distribuzione di probabilità di tali variabili.
Alla fine delle iterazioni è calcolato un istogramma (ad esempio del costo totale o della data di
completamento). Per un’analisi del costo del rischio è usata una simulazione della stima dei costi, così come
per un’analisi del rischio dello schedule sono usate le stime delle durate. Simulazione - Tecnica Monte Carlo
Previsione : durata del progetto Data di completamento prove Curva S data di completamento probabilità
- Analisi di sensibilità: aiuta a determinare quali rischi hanno l’impatto potenziale maggiore sul progetto.
Aiuta a capire come è correlata la variazione degli obiettivi del progetto con le variazioni delle diverse
incertezze. Esamina in quale misura l’incertezza di ciascun elemento del progetto influenza l’obiettivo
quando tutti gli altri elementi vengono mantenuti al loro valore di baseline.
Una rappresentazione tipica dell’analisi di sensitività è il diagramma Tornado che è utile per confrontare
l’importanza relativa e l’impatto delle variabili che hanno un elevato grado di incertezza rispetto a quelle
più stabili. Il diagramma Tornado è utile anche nell’analisi di diversi scenari di rischi. E’ un particolare tipo di
grafico a barre usato nell’analisi di sensitività per valutare l’importanza relativa delle variabili. I dati
vengono visualizzati con barre verticali con la più grande in alto e la più piccola in basso dando l’apparenza
di un tornado, da qui il nome.
Il diagramma Tornado mette in evidenza in modo molto espressivo sia l’impatto esercitato da ciascun
parametro sul valore sia l’identificazione dei parametri più influenti. La rappresentazione grafica che ne
risulta traduce visivamente una classificazione dei parametri in ordine di influenza, attraverso un linguaggio
immediato e di facile lettura.
-Alberi delle decisioni: È una tecnica efficace quando è necessario considerare le influenze sulle decisioni
degli eventi futuri, di cui si è a conoscenza delle probabilità. L'albero decisionale è un diagramma che
descrive la decisione sotto esame e le implicazioni date dalla scelta tra le alternative disponibili. Esso
incorpora sia le probabilità dei rischi che i costi o i ricavi determinato dagli eventi futuri e dalle decisioni
prese.
Struttura:
- Nodi decisionali (quadrati) rappresentano variabili controllate dal decisore. L’output rappresenta il valore
attuale della decisione
- Nodi probabilità (circolari) rappresentano eventi che non possono essere controllati dal decisore. Viene
indicata sia la probabilità condizionata dell’evento sia il valore attuale del cash flow conseguenza
dell’evento
- Foglie finali: Vengono riportate l’utilità generata lungo il percorso che porta al ramo finale.
Passi per l’applicazione del metodo:
-Dividere l’analisi nelle fasi di rischio: Descrivere le fasi di rischio a cui si sarà esposti
-In ogni fase di rischio stimare la probabilità condizionata degli eventi rispetto all’evento precedente
(potrebbero essere stimate le probabilità degli eventi intersezione possibili ed applicare il teorema di Bayes
per ricavare la probabilità condizionata)
-Definire i punti in cui si assumono le decisioni (nodi decisionali)
-Definire i punti da cui dipartono gli eventi
-Calcolare il cash flow (utilità, danno ecc.) corrispondente ad ogni foglia
-Ripercorrere all’indietro l’albero:- ad ogni nodo probabilità si assegna un valore pari alla speranza
matematica di tutte i possibili valori (utilità) degli eventi legati al nodo probabilità considerato; - Ad ogni
nodo decisionale si assegna il massimo dei valori (utilità) legate alle decisioni che vengono prese in
corrispondenza del nodo
-Il processo si conclude dando un valore al nodo iniziale che può essere un nodo decisionale o un nodo
probabilità Passi per l’applicazione del metodo Utilizzo nella gestione del rischio
L’albero delle decisioni fornisce una rappresentazione di come il cash flow si sviluppa nel tempo e consente
di valutare quali sono i rischi da cui dobbiamo proteggere il progetto
Se il danno economico dipende dal cambio del $ rispetto all’€ in un certo scenario, il costo della protezione
contro tale rischio può essere facilmente paragonato con la speranza matematica della perdita in
corrispondenza dei diversi scenari
Esempio: In sede di collaudo di un’opera viene effettuata ad un contractor da parte del committente una
detrazione di € 280.000. Il contractor ha la possibilità di pagare quanto richiesto o appellarsi in giudizio. Il
costo del giudizio è di € 110.000 se il giudizio viene perduto il costo per il contractor è di € 300.000. La
probabilità che il giudizio venga vinto è del 60% e del 40% che venga perso. Se il contractor è soccombente,
si può appellare affrontando un ulteriore costo di € 45.000. Di contro se vince, la controparte si potrà
appellare con una probabilità del 90% ed il contractor dovrà sostenere un costo di € 25.000. La probabilità
di vincere in appello è pari al 25% per l’attore che lo promuove.
-Influence diagrams: possono essere valutati utilizzando una tecnica di simulazione, come l'analisi Monte
Carlo, per indicare quali elementi hanno la maggiore influenza sui risultati chiave
OUTPUT
1. Project Documets Updates: la Relazione sui Rischi (Risk Report) sarà aggiornata per riflettere i risultati
dell'analisi quantitativa del rischio, ad esempio:
- Valutazione del rischio complessivo del progetto: Il rischio complessivo del progetto si riflette in due
misure chiave: -probabilità di successo del progetto, indicata dalla probabilità che il progetto raggiunga i
suoi obiettivi chiave (ad esempio, data di fine richiesta o tappe intermedie, obiettivo di costo richiesto,
ecc.); il grado di variabilità intrinseca rimanente all'interno del progetto nel momento in cui è stata
condotta l'analisi, e cioè la gamma di possibili risultati del progetto.
esempio di aggiornamento del Risk Report: - Analisi probabilistica dettagliata del progetto. Vengono
presentati i principali risultati dell'analisi quantitativa del rischio, come le curve a S, i diagrammi dei tornado
e l'analisi della criticità, insieme a un'interpretazione narrativa dei risultati. I possibili risultati possono
includere: Ammontare della riserva di contingenza necessaria per fornire un determinato livello di fiducia;
Identificazione dei singoli rischi del progetto o altre fonti di incertezza che hanno il maggiore impatto sul
progetto; Principali fattori di rischio complessivo del progetto che hanno la maggiore influenza sui risultati
del progetto.
- Lista di priorità dei rischi quantificati: questa lista include quei rischi che creano le più grandi minacce o
presentano le principali priorità per il progetto
- Trend nei risultati quantitativi dell’analisi del rischio: poiché le analisi vengono ripetute è possibile che ci
sia un trend che porterebbe a conclusioni che influenzano la risposta al rischio.
- Raccomandazioni nei confronti del rischio complessivo e specifico che costituiranno un input per il
processo di Piano di Risposta al Rischio
Plan Risk Responses (PMBOK)
E’ il processo mediante il quale si sviluppano le opzioni e le azioni per aumentare le opportunità e ridurre le
minacce per gli obiettivi del progetto.
Il vantaggio di questo processo è che affronta i rischi in funzione della loro priorità.
- Ogni risposta al rischio richiede una comprensione del meccanismo attraverso il quale si affronterà il
rischio. Questo è il meccanismo usato per analizzare se il piano di risposta al rischio sta avendo l’effetto
desiderato.
- La risposta al rischio deve essere appropriata all’importanza del rischio, realistica, accettato da tutte le
parti coinvolte e deve essere individuato un responsabile.
- Spesso è richiesto di selezionare la risposta al rischio ottimale rispetto a diverse opzioni. Plan Risk
Responses
-Al termine di questa fase è opportuno almeno produrre per ogni rischio una scheda che sia di aiuto al
processo di monitoraggio e controllo. Questa scheda deve contenere: - la descrizione del rischio; - la
descrizione delle cause del rischio; - i sintomi del rischio; - il periodo in cui il rischio si dovrebbe
manifestare; - Le attività interessate dal rischio - il responsabile della fase di esame e controllo; - la
descrizione delle azioni di risposta da adottare.
INPUT
1. Project Managment plan: Resource Management Plan; Risk Management Plan: importanti componenti
del Risk Management Plan includono i ruoli e le responsabilità, le definizioni dell’analisi del rischio, il tempo
per riesaminare (e per eliminare i rischi riesaminati) e le soglie di rischio basso, moderato e alto; Cost
baseline
2. Project Documents:
- Lesson learned register
- Project schedule
- Project team assignments
- Resource calendars
- Risk register: si riferisce all’identificazione dei rischi, alla lista delle potenziali risposte, ai responsabili dei
rischi, i rischi che richiedono una risposta in tempi brevi, quelli che richiedono analisi aggiuntive, etc.
- Risk report
- Stakeholder register
3. Enterprice environmental factors include propensione al rischio e soglie di rischio degli stakeholder
chiave
4. Organizational process assets: - Template per la gestione del rischio - Database - Lesson learned di
progetti simili
TOOL & TECHNIQUES
1. Expert judgment
2. Data gathering
3. Interpersonaland team skills
4. Strategies for Negative Risk or Threats: esistono cinque strategie alternative che possono essere
considerate per rispondere ai rischi negativi:
- Scalare (Escalate) è appropriata quando il team di progetto o lo sponsor del progetto concorda che una
minaccia che non rientra nell'ambito del progetto o che la risposta proposta supererebbe l'autorità del
project manager. I rischi di escalation sono gestiti da altra parte rilevante dell'organizzazione e non a livello
di progetto, in molti casi a livello di programma o di portafoglio. Il project manager determina chi deve
essere informato della minaccia e comunica i dettagli a quella persona o parte dell'organizzazione.
- Evitare: è una strategia di risposta al rischio tramite la quale il Project Team agisce per eliminare le
minacce o protegge il progetto dal suo impatto. Solitamente comporta cambiamenti al Project
Management Plan. Il PM può anche isolare gli obiettivi del progetto dall’impatto del rischio o cambiare
l’obiettivo che è in pericolo. Per eludere un rischio si può chiudere uno stabilimento, un reparti, o più
semplicemente sostituire dei materiali, componenti o determinate operazioni - La strategia dell’elusione
non garantisce totalmente l’eliminazione del rischio, poiché l’elusione stessa può far nascere nuovi rischi o
peggiorare la situazione esistente.
- Trasferire: è una strategia mediante la quale il team di progetto trasferisce l’impatto della minaccia ad una
terza parte. Trasferire il rischio semplicemente da una parte ad un’altra non elimina la responsabilità della
sua gestione. Il trasferimento del rischio comporta quasi sempre il pagamento di un premio (prezzo) alla
parte che si sta assumendo il rischio. Gli strumenti di trasferimento possono essere diversi e includono ad
esempio l’uso di assicurazioni, fidejussioni, garanzie, etc. Per trasferire la responsabilità ad una terza parte
si possono usare contratti o accordi.
Trasferimento del rischio a terzi: - Trasferimento assicurativo: le conseguenze finanziarie vengono trasferite
all’assicuratore in base a ciò che viene sottoscritto nella polizza, previo pagamento del premio.
- Trasferimento non assicurativo: attraverso la stipulazione di un contratto (es. contratto di subappalto,
contratto di leasing), con correlativo pagamento delle tariffe stabilite si trasferisce la responsabilità della
gestione del rischio.
- Mitigare: è una strategia mediante la quale il team di progetto agisce per ridurre la probabilità di
accadimento e/o l’impatto del rischio. Intraprende azioni che riducono la probabilità e/o l’impatto è spesso
più efficiente che provare ad aggiustare i danni che avvengono dopo che il rischio si è verificato. Adottare
processi meno complessi, condurre test o scegliere fornitori più stabili sono esempi di azioni di mitigazione.
Abbiamo due tipologie di mitigazione:
-Prevenzione: si tende a ridurre la probabilità a parità di impatto (rivelatori d’incendio).
- Protezione: si tende a ridurre l’impatto a parità di probabilità. (es. isolare o confinare le attività
critiche o programmare le attività rischiose al di fuori del cammino critico).
Tecniche di mitigazione nel settore della sicurezza:
- Attrezzature di sicurezza: sono tutte le attrezzature che hanno lo scopo di preservare persone, beni
e operazioni;
- procedure: impongono che lo svolgimento di determinate operazioni sia fatto seguendo delle
disposizioni precise;
- formazione alla sicurezza: consiste nell’instaurare la cosiddetta “cultura della sicurezza”;
- Impianti di rilevazione fumi, fiamme, calore
- Accettare: è una strategia di risposta al rischio dove il team di progetto decide di riconoscere il rischio e
non intraprende nessuna azione fino a quando il rischio non avviene. Tale strategia è adottata quando non
è possibile gestire uno specifico rischio in altro modo. Tale strategia indica che il team di progetto ha deciso
di non cambiare il Project Management Plan per affrontare un rischio o non è in grado di identificare
qualsiasi altra strategia di risposta adeguata.
Tale strategia può essere attiva o passiva. L’accettazione passiva non richiede azioni se non per
documentare la strategia. Tra le più comuni strategie di accettazione attive del rischio è stabilire riserve di
contingenza aumentando il tempo, il denaro o le risorse
- Ritenzione consapevole: si ha conoscenza dell’esistenza e dell’entità del rischio, delle perdite che
dovranno essere affrontate dall’azienda al momento dell’evento dannoso.
- Ritenzione inconsapevole: si è indirizzati alla ritenzione sulla base di una condizione di ignoranza
che può essere originata da uno di questi fattori:
-Il rischio non viene identificato e quindi non può essere adottata alcuna azione di intervento;
-L’entità del rischio viene sottovalutata e quindi l’azione di intervento non risulta sufficiente alla
gestione del rischio;
-L’efficacia delle azioni di intervento stabilite è sopravvalutata; tipico esempio è il fraintendimento
legato all’interpretazione di certe clausole assicurative.
Il ricorso alla ritenzione è subordinato al soddisfacimento di certe peculiarità:
- Bassa variabilità della perdita: minore è l’oscillazione che ha la perdita nel tempo, maggiore è la quota del
rischio che l’azienda può ritenere. Infatti minore è l’oscillazione della perdita, minore sarà il range di
variabilità della perdita, quindi minore sarà la probabilità di subire perdite ingenti e di conseguenza sarà più
semplice pianificare le attività aziendali.
- Solidità finanziaria dell’azienda: maggiore è la solidità dell’azienda, valutabile sia in senso statico (bilancio)
che in senso dinamico (equilibrio dei flussi di cassa), maggiore sarà la quota del rischio che l’azienda può
ritenere.
- Situazione ambientale: è bene valutare la solidità e la competitività dell’azienda all’interno dell’ambiente
di riferimento.
Tecniche di finanziamento nel caso della ritenzione
- Accantonamenti contabili: Gli accantonamenti annuali vanno a far parte di un fondo contabile cioè un
fondo a cui possono non corrispondere risorse liquide per la copertura del rischio. Questo strumento
finanziario ha lo scopo di trattenere all’interno dell’azienda degli utili e l’accantonamento si può presentare
anche non sotto forma di liquidi.
- Autoassicurazione: Un fondo costituito da attività liquide (cassa, saldi attività bancarie) e attività
facilmente liquidabili in casi di necessità (titoli a largo mercato e di valore stabile). Il fondo di liquidità è
alimentato da contributi periodici stabiliti in base alla perdita attesa dei rischi ritenuti
- Captive insurance company: La captive insurance company è una compagnia di assicurazione o di
riassicurazione fondata da una azienda o da un gruppo di aziende con lo scopo di assicurare, in generale, i
propri rischi.
-La differenza invece con l’autoassicurazione sta nel dare al fondo una sua personalità giuridica; questo
permette di dedurre fiscalmente il pagamento del premio.
-La captive insurance company può fornire la copertura intera o parziale dei rischi, e ricorrere per il resto al
mercato riassicurativo.
-Lo svantaggio fondamentale che si ha nell’utilizzo di questa tecnica di finanziamento sta nei costi che si
devono sopportare per fondarla e gestirla; quando queste risiedono nei cosiddetti paradisi fiscali, il
personale non esiste proprio.
5. Strategies for Positive Risk or Opportunities: Five alternative strategies may be considered for dealing
with opportunities, as follows:
-Escalate. Il project manager determina chi deve essere informato sull'opportunità e comunica i dettagli a
quella persona o parte dell'organizzazione.
-Esplorare: tale strategia può essere usata per i rischi con impatto positivo per i quali l’organizzazione spera
che l’opportunità si realizzi. Tale strategia cerca di eliminare l’incertezza associata con un particolare rischio
assicurandosi che l’opportunità si verifichi.
-Aumentare: è usata per aumentare la probabilità e/o l’impatto positivo di un’opportunità. Identificare e
massimizzare i punti chiave di questi impatti positivi dei rischi può crescere la probabilità del loro
accadimento.
-Dividere: la divisione di un rischio positivo coinvolge l’allocazione di alcuni o tutti i vantaggi ad una terza
parte che è in grado di cogliere meglio le opportunità per i benefici del progetto.
-Accettare: significa essere disposti a sfruttare l’opportunità se si verifica ma non si persegue attivamente.
6. Contingent Response Strategies: alcune risposte sono progettate per essere usate solo se certi eventi
accadono. Dovrebbero essere definiti e tracciati eventi che innescano le risposte di contingenze.
7. Strategy for overall project risk: -Avoid -Exploit -Transfer/share -Mitigate/enahance -Accept
8. Data Analysis: -Alternative analysis -Cost-benefit analysis
9. Decision making: L'analisi delle decisioni fornisce un approccio sistematico per stabilire i criteri
decisionali chiave, valutare e classificare alternative e selezionare un'opzione preferita. I criteri possono
includere, a titolo esemplificativo i costi di risposta, probabile efficacia della risposta in termini di
probabilità e/o impatto, disponibilità delle risorse, vincoli temporali (urgenza, prossimità), magnitudo,
effetto della risposta sui rischi connessi, introduzione di rischi secondari.
OUTPUT
1. Change request
2. Project Managemet Plan Updates: ad esempio:
-Schedule Management Plan: è aggiornato per riflettere i cambiamenti. Questo include cambiamenti nelle
tolleranze o i comportamenti relativi al carico e livellamento delle risorse così come la strategia di
pianificazione.
-Cost Management Plan: è aggiornato per riflettere i cambiamenti. Questo include cambiamenti nelle
tolleranze o i comportamenti relativi nella gestione del costo, nella tracciabilità, la strategia di budget e
come sono consumate le riserve di contingenze.
-Quality Management Plan: è aggiornato per riflettere i cambiamenti. Questo include cambiamenti nelle
tolleranze o i comportamenti relativi ai requisiti, all’assicurazione della qualità, il controllo di qualità come
pure l’aggiornamento della documentazione dei requisiti.
-Resource managment plan
-Procurement Management Plan: può essere aggiornato per riflettere cambiamenti nelle strategie.
-“Scope” Baseline: può essere modificata in seguito a nuovi, modificati o omessi lavori conseguenti alle
risposte dei rischi.
-Schedule Baseline: può essere modificata in seguito a nuovi o omessi lavori conseguenti alle risposte dei
rischi.
-Cost Baseline: può essere modificata in seguito a nuovi o omessi lavori conseguenti alle risposte dei rischi.
3. Project Documets Updates:
-Assumption log; -Cost forecast;
-Lesson learned register;
-Project schedule;
-Project team assignment
-Risk register: Possono includere: Strategie di risposta concordate; Azioni specifiche per attuare la strategia
di risposta scelta; Condizioni di innesco, sintomi e segnali di allarme di un evento a rischio; Budget e
pianificazione delle attività richieste per implementare le risposte scelte; Piani di emergenza e innesco
(trigger)che richiedono la loro esecuzione; Piani di riserva da utilizzare quando si è verificato un rischio e la
risposta primaria risulta inadeguata; Rischi residui che dovrebbero rimanere dopo le risposte pianificate;
Rischi secondari che si presentano a seguito dell'attuazione di una risposta al rischio.
-Risk report
Implement Risk Responses (PMBOK)
Implementare le Risposte al Rischio è il processo di implementazione dei piani di risposta al rischio
concordati.
Una corretta attenzione al processo Implement Risk Responses assicurerà che le risposte al rischio
concordate vengano effettivamente eseguite.
INPUT
1. Project Management Plan
2. Project Documents: -Lesson learned register -Risk register -Risk report
3. Organizational process assets: includono le lesson learned di progetti simili
TOOL & TECHNIQUES
1. Expert judgment
2. Interpersonal and team skills
3. Project Management Information System (PMIS)
OUTPUT
1. Change request
2. Project Documents updates: -Issue log; -Lesson learned register ; -Project team assignments ; -Risk
register ; -Risk report
Monitor Risks (PMBOK)
Monitorare i rischi è il processo di monitoraggio dell'implementazione di piani di risposta al rischio
concordati, monitoraggio dei rischi identificati, identificazione e analisi di nuovi rischi e valutazione
dell'efficacia del processo di rischio in tutto il progetto. Il vantaggio principale di questo processo è che
decisioni relative al progetto si basano su informazioni aggiornate sull'esposizione complessiva al rischio del
progetto e sui rischi individuali del progetto. Questo processo viene eseguito durante tutto il progetto.
Il processo di monitoraggio dei rischi utilizza le informazioni sulle prestazioni generate durante l'esecuzione
del progetto per determinare se esecuzione del progetto per determinare se
o Le risposte ai rischi implementate sono efficaci,
o Il livello di rischio complessivo del progetto è cambiato,
o Lo stato dei singoli rischi di progetto identificati è cambiato,
o Sono emersi nuovi rischi individuali di progetto,
o L'approccio alla gestione del rischio è ancora appropriato,
o Le ipotesi di progetto sono ancora valide,
o Sono state seguite le politiche e le procedure di gestione del rischio,
o Le riserve di contingenza per i costi o la tempistica richiedono modifiche e
o la strategia di progetto è ancora valida.
INPUT
1. Project Managment plan
2. Project documents -Issue log; -Lesson learned register; -Risk register ; -Risk report
3. Work performance data
4. Work performance report
TOOL & TECHNIQUES
1. Data Analysis:
-Technical performance analysis: confronta le misure di prestazione durante l'esecuzione del progetto con
il programma di realizzazione. Tali misure di prestazione tecnica possono includere peso, tempi, numero di
difetti consegnati, capacità di archiviazione, ecc. La deviazione può indicare il potenziale impatto di minacce
o opportunità.
-Reserve analysis :confronta l'ammontare delle riserve di contingenza rimaste fino all'ammontare del
rischio rimasto in qualsiasi momento nel progetto al fine di determinare se la riserva rimanente è adeguata.
2. Audits
3. Meetings
OUTPUT
1. Work performance information: includono informazioni su come si svolge la gestione del rischio del
progetto confrontando i singoli rischi che si sono verificati con le previsioni di come si sarebbero verificati
2. Change requests
3. Project Management plan updates
4. Project Management updates: -Assumption log -Issue log -Lesson learned register -Risk register -Risk
report
5.rganizational process assets updates ad esempio: -Templates per la gestione del rischio -Risk Breakdown
Structure.
PROJECT COST MANAGEMENT
Comprende i processi coinvolti nella pianificazione, stima, budgeting, finanziamento, gestione e controllo
dei costi necessari affinché il progetto possa essere completato entro il budget approvato.
Su alcuni progetti, in particolare quelli più piccoli, la stima e la budgetizzazione dei costi, sono così
strettamente collegati che sono visti come un unico processo che può essere eseguito da una sola persona
e in un breve periodo di tempo.
La possibilità di influenzare il costo è maggiore nelle fasi iniziali del progetto.
Per una corretta gestione dei costi si dovrebbero tenere in considerazione le richieste degli stakeholders.
E’ legato principalmente con i costi delle risorse necessarie a completare l’attività di progetto.
Occorre inoltre considerare l'effetto delle scelte progettuali sui costi di utilizzo e manutenzione del
prodotto, servizio o risultato del progetto.
Key Concepts for Project Cost Management:
Un altro aspetto della gestione dei costi è che i diversi stakeholder misurano i costi del progetto in modi
diversi e in momenti diversi. Ad esempio, il costo di un articolo acquistato può essere misurato quando la
decisione di acquistare è presa o impegnata, l'ordine è emesso, l'articolo è consegnato, il cash flow si è
manifestato o l’acquisto è registrato ai fini della contabilità. In molte organizzazioni, la previsione e l'analisi
delle prospettive finanziarie del prodotto del progetto non fanno parte del progetto. Quando tali previsioni
e analisi sono incluse, la gestione dei costi del progetto può comportare ulteriori processi e possono essere
utilizzate numerose tecniche generali di gestione finanziaria quali il saggio di rendimento interno
dell'investimento, il flusso di cassa scontato, l'analisi dell'investimento, ecc.
Trend and Emerging Proctices in Project Cost Management
All'interno della pratica del Project Cost Management, vi è la tendenza ad ampliare Earned Value
Management (EVM) includendo il concetto di Earned Scheduling (ES).
Tailoring Considerations: Le considerazioni da fare riguardano ma non solo:
-La gestione della conoscenza
-Stima dei costi e budgeting
-Earned value management
-Uso del modello AGILE
-Tipo di governance
Considerations for Agile/Adaptive Environments
Con i progetti con alti gradi di incertezza o con quelli in cui lo «scope» non è ancora del tutto definito
potrebbe essere non opportuno effettuare calcoli dettagliati dei costi a causa dei frequenti cambiamenti.
Invece, i metodi leggeri di stima possono essere utilizzati per generare una previsione rapida e di alto livello
dei costi del progetto. Le stime dettagliate sono riservate agli orizzonti di pianificazione a breve termine in
modalità just-in-time.
Plan Cost Management
E’ il processo mediante il quale si stabiliscono le politiche, le procedure e la documentazione necessari per
la pianificazione, la gestione, la spesa e il controllo dei costi del progetto.
Il vantaggio di questo processo è che fornisce una guida e la direzione su come saranno gestiti i costi del
progetto.
Nel Plan Cost Management sono documentati i processi di gestione dei costi e i relativi Tool & Technique.
Il Cost Management Plan è un componente del Project
INPUT
1.
Project Charter: fornisce il budget di riepilogo grazie al quale si sviluppano i costi dettagliati del
progetto. Definisce anche i requisiti di approvazione del progetto che influenzeranno la gestione dei costi
del progetto.
2.
Project Management Plan: Schedule Management Plan; Risk Management Plan
3.
Enterprise Environmental Factors: includono ma non sono limitati a:
-Cultura e struttura organizzativa che possono influenzare la gestione dei costi.
-Condizioni dei mercati riguardo i prodotti, servizi e forniture disponibili.
-Produttività in paesi diversi possono essere diverse e quindi tale diversità può influenzare i costi
del progetto
4. Organizational Process Assets: includono ma non sono limitati a:
-Procedure di controllo e rendicontazione finanaziaria
-Informazioni storiche dalle lesson learned
-Database finanziari
-Modelli di stima formale e informale dei costi, modelli di budgeting, procedure e linee guida.
TOOL & TECHNIQUES
1.
Expert Judgment: fornisce informazioni importanti provenienti ad esempio da progetti precedenti
simili o nella disciplina e nell’area di conoscenza.
2.
Data Analysis: può essere utilizzata l'analisi delle alternative ma non solo. L'analisi delle alternative
può includere la revisione di opzioni di finanziamento strategiche quali: autofinanziamento, finanziamento
con fondi propri o finanziamento con debito. Può anche includere l'esame dei modi per acquisire risorse di
progetto come la produzione, l'acquisto, il noleggio o il leasing.
3.
Meetings: i membri del team del progetto possono tenere meetings per sviluppare il Cost
Management Plan.
OUTPUT
1. Cost Management Plan: è un componente del Project Management Plan è descrive come i costi del
progetto verranno, pianificati, strutturati e controllati. Il Cost Management Plan può stabilire:
-le unità di misura definite per le risorse (ad esempio ore e giorni di personale, metri, litri, kilometri, etc.);
-il livello di precisione ossia il grado con il quale saranno arrotondate le stime dei costi delle attività (es.
ordine di € 10.000)
OUTPUT
-il livello di accuratezza (es. +/- 10%) cioè il range di accettazione usato per determinare la stima realistica
dei costi delle attività, può includere una quantità per le situazioni di contingenza;
-il legame alle procedure organizzative tramite la WBS che fornisce un framework per il Cost Management
Plan. L’elemento della WBS utilizzato per il calcolo dei costi del progetto si chiama “control account”. Ad
ogni control account è assegnato un codice univoco che si collega direttamente al sistema contabile della
Performing Organization;
-le soglie di controllo per monitorare la performance dei costi, tali soglie rappresentano una quantità di
variazione concordata prima di essere autorizzati ad eseguire qualche azione. Le soglie generalmente sono
espresse come una deviazione percentuale rispetto alla baseline pianificata;
-le regole di misura della performance quali ad esempio:
-stabilire tecniche di misura dell’Earned Value (ad esempio milestone pesate, percentuale di
completamento, etc.);
-specificare le metodologie di monitoraggio e le equazioni per il calcolo della stima al
completamento del progetto (EAC);
-Stabilire i punti della WBS nei quali si misurano i control account
-i reporting format;
-i dettagli addizionali quali ad esempio:
-la descrizione delle scelte strategiche di finanziamento;
-le procedure per spiegare le fluttuazioni dei tassi di cambio;
ESTIMATES COSTS
E’ il processo mediante il quale si stabilisce una stima delle risorse monetarie necessarie per completare le
singole attività di progetto.
Il vantaggio di questo processo è che determina l’ammontare dei costi richiesti per completare il lavoro del
progetto.
Le stime dei costi sono delle previsioni basate sulle informazioni conosciute in un dato momento.
Le stime dei costi includono l'identificazione e la considerazione di diverse alternative di costo per avviare e
completare il progetto.
Le stime dei costi sono generalmente espresse in unità monetarie (€, $, etc.) anche se possono essere usate
anche altre unità di misura quali ad esempio le ore di personale.
La stima dei costi dovrebbe essere rivista e ridefinita durante lo svolgimento del progetto per riflettere le
informazioni aggiuntive quando queste diventano disponibili.
L’accuratezza delle stime aumenterà all’aumentare del progresso del progetto.
I costi sono stimati per tutte le risorse considerate nel progetto come ad esempio per il lavoro, i materiali,
le attrezzature, i servizi, etc.
La stima dei costi è una valutazione quantitativa dei probabili costi delle risorse richieste per completare le
attività.
INPUT
1. Project Management plan:
-Cost Management Plan: definisce come i costi del progetto saranno gestiti e controllati. Include i metodi
usati e il livello di accuratezza richiesto per la stima dei costi delle attività.
-Quality Managment Plan
-Scope Baseline:
- Il Project “Scope” Statement: fornisce una descrizione del prodotto, i criteri di accettazione, i
deliverables chiave, i confini del progetto, le ipotesi e i vincoli del progetto. Una decisione da
prendere quando si effettua la stima dei costi del progetto è se tale stima deve considerare solo i
costi diretti o se includere anche i costi indiretti. Uno dei principali limiti per molti progetti è un
budget limitato assegnato ai progetti. Altri vincoli possono essere le date di consegna, le politiche
organizzative, etc.
-La WBS: lega i deliverables ad ogni componente della WBS.
-Il dizionario della WBS: fornisce informazioni dettagliate circa i deliverables e una descrizione, per
ogni componente della WBS, del lavoro richiesto per produrre ogni deliverable.
INPUT
2. Project Documents:
-Lesson Learned Register
-Project Schedule: i principali fattori per la determinazione della stima dei costi sono il tipo, la quantità delle
risorse e il tempo di utilizzo. Input di tale processo sono la schedulazione delle risorse per realizzare le
attività e le rispettive durate. La stima delle risorse consiste nel determinare la disponibilità del personale, il
numero di ore di personale richieste e la quantità di materiale e attrezzature necessarie per svolgere le
attività schedulate. Si può avere una dipendenza dal tempo dei costi (ad esempio variazioni di costi di
materiali stagionali).
-Resorce Requirements
-Risk Register: i rischi, che possono essere minacce o opportunità, hanno un impatto sia sulle attività che
sui costi di progetto. In genere quando nel progetto si verifica un evento rischioso negativo si possono
avere un aumento dei costi e ritardi nella pianificazione. Analogamente il team di progetto dovrebbe essere
sensibile a potenziali opportunità che possono dare benefici all’attività sia riducendo i suoi costi sia
accelerando la pianificazione.
3.Enterprice Environmental Factors: ad esempio:
-Condizioni di mercato: descrivono quali prodotti, servizi e risultati sono disponibili nel mercato, da chi e
sotto quali termini e condizioni.
-Informazioni commerciali pubbliche: le informazioni sui costi sono spesso disponibili su database
commerciali che tracciano gli skills e i costi di risorse umane e forniscono costi standard per i materiali e le
attrezzature.
-Tassi di cambio e inflazione. Per grandi che si estendono per molti anni nel temo la fluttuazione dei cambi
e l’iflazione devono essere conosciuti per effettuare una corretta stima dei costi.
4. Organizational Process Assets: Politiche per la stima dei costi; Template per i costo; Informazioni storiche
e lesson learned
TOOL & TECHNIQUES
1.
Expert Judgment: fornisce informazioni preziose per l’ambiente e informazioni provenienti da
progetti simili sviluppati precedentemente, informazioni nell’area di applicazione.
2.
Analogous Estimating: Usa misure di scale quali ad esempio taglia, peso e complessità provenienti
da progetti precedenti simili utili come base per la stima de costi per il progetto corrente. In altri termini
questa tecnica si basa sul costo effettivo di progetti precedenti simili come base per la stima del costo del
progetto attuale.
Essa è spesso utilizzata per stimare un valore quando si ha una quantità limitata di informazioni sul
progetto, soprattutto nelle prime fasi del progetto stesso. Tale tecnica usa informazioni storiche e il giudizio
degli esperti, generalmente è meno costosa e più veloce rispetto ad altre tecniche ma è anche meno
accurata. Può essere applicata all’intero progetto o ad un suo segmento contemporaneamente ad altri
metodi. E’ più affidabile quando i progetti precedenti sono realmente simili e non solo in apparenza e i
membri del team della stima hanno una reale esperienza.
3.
Parametric Estimating: usa una relazione statistica tra i dati storici rilevanti e altre variabili per
calcolare una stima del costo per il lavoro del progetto. Tale tecnica può fornire un elevato livello di
accuratezza in dipendenza della bontà dei dati e con l’uso contemporaneo di altri metodi di stima.
4.
Bottom-up Estimating: E’ il metodo di stima di ogni componente di dettaglio, valori che vengono
successivamente sintetizzati al livello superiore. Il costo e l’accuratezza di tale tecnica dipendono dalla
grandezza e complessità delle attività.
Stima per analogia
Basata su progetti precedenti
Dati disponibili limitati
Poco costosa
Rapida
Meno accurata
Stima parametrica
Basata su dati statistici
Necessità di parecchi dati per essere valida statisticamente
Più costosa
Meno rapida
Più accurata
5. Three-point Estimating: l’accuratezza della stima del costo può essere migliorata considerando anche le
incertezze e i rischi e usando “Three-Point Estimating” per definire un range approssimato per il costo
dell’attività:
-Molto probabile (CM): costo dell’attività basato sulla valutazione dell’impegno effettivo per lo svolgimento
del lavoro e su alcune spese previste.
-Ottimistica (CO): il costo dell’attività è basata sull’analisi dello scenario migliore per l’attività.
-Pessimistica (CP): il costo dell’attività è basata sull’analisi dello scenario peggiore per l’attività.
Estimate Costs
Three-point Estimating: Tale tecnica fornisce un costo atteso. In funzione della distribuzione usata il costo
atteso (CE) può essere calcolato usando l’opportuna formula. Le due formulazioni comunemente usate
sono la distribuzione triangolare e la beta.
Le formule sono:
-Distribuzione triangolare: CE = (CO + CM + CP) / 3
-Distribuzione Beta: CE = (CO + 4CM + CP) / 6
6. Data Analysis:
-Alternative Analysis
-Reserve Analysis: La stima dei costi può comprendere riserve di contingenza per tenere in considerazione
l’incertezza dei costi. Tali riserve sono comprese nella baseline dei costi e costituiscono risposte di
contingenza. Sono spesso viste come il budget legato a eventi “Conosciuti - Non conosciuti” che possono
affliggere il progetto. Tali riserve possono essere considerate per una specifica attività, per l’intero progetto
o per entrambi.
La riserva può essere una percentuale del costo stimato, un numero fisso o sviluppata usando metodi di
analisi quantitative. All’aumentare della disponibilità delle informazioni su progetto le riserve possono
essere utilizzate, ridotte o eliminate. Esse dovrebbero essere chiaramente identificate nel Cost
Documentation. Si può considerare anche un ammontare per riserve di gestione per finanziare il progetto.
Le riserve di gestione sono un ammontare del budget di progetto trattenuto con lo scopo di controllo del
progetto e servono per lavori imprevisti non conosciuti. Esse sono destinate a eventi
“Non conosciuti-Non conosciuti” che possono affliggere il progetto. Non sono incluse nella baseline dei
costi ma sono parte del budget del progetto e delle esigenze di finanziamento. Quando viene utilizzata una
quantità di riserva di gestione per finanziare lavori imprevisti essa viene aggiunta alla baseline del costo e
quindi è necessaria un’approvazione della variazione alla baseline del costo.
-Cost of Quality: possono essere usate assunzioni relative ai costi di qualità per la stima dei costi delle
attività.
7. Project Management Information Systems (PMIS)
8. Decision Making: Le tecniche decisionali che possono essere utilizzate nel processo di Stima dei Costi
includono, a titolo esemplificativo e non esaustivo, la votazione.
Costi includono, ma non solo, la votazione.
OUTPUT
1. Cost Estimates: sono valutazioni quantitative dei probabili costi richiesti per realizzare il lavoro del
progetto. Possono essere presentare in modo sommario o dettagliato. I costi sono stimati per tutte le
risorse che sono applicate alle attività di stima dei costi. Questo include, ma non è limitato, al lavoro
diretto, ai materiali, alle attrezzature, ai servizi, all’Information Technology, ai costi di finanziamento,
inflazione, tassi di cambio, riserve di costo di contingenza, etc. I costi indiretti, se sono inclusi nel progetto
di stima, possono essere inclusi a livello di attività o ad un livello superiore.
2. Basis Of Estimates: l’ammontare e il tipo di dettagli addizionali che supportano la stima del costo varia in
funzione dell’area applicativa. La documentazione di supporto dovrebbe fornire una chiara e completa
comprensione di come la stima dei costi è fatta.
I dettagli di supporto alla stima delle attività possono includere:
-Documentazione della base della stima (cioè come è stata sviluppata).
-Indicazioni del range di possibili stime (es. € 10,00 +/- 10%), cioè indica il fatto che l’elemento ha
un costo atteso compreso in un range di valori.
-Indicazioni del livello di confidenza della stima finale.
3. Project Documents Updates: ad esempio Assumption Log; Lesson Learned register; Risk register
Determine Budget
E’ il processo mediante il quale si aggregano le stime dei costi delle attività individuali per stabilire una
baseline dei costi autorizzata.
Il vantaggio di questo processo è che determina la baseline dei costi rispetto alla quale si può monitorare e
controllare la performance del progetto.
Il budget di progetto include tutti i fondi autorizzati per eseguire il progetto.
INPUT
1.Project Managment Plan:
-Cost Management Plan: descrive come i costi del progetto saranno gestiti e controllati.
-Resource Management Plan
-Scope Baseline:
-Project Scope Statement: sono riportate le limitazioni formali per periodo per la spesa dei
fondi del progetto.
-WBS: lega i deliverables ad ogni componente della WBS.
-WBS dictionary: fornisce l’identificazione dei deliverables e una descrizione del lavoro di
ogni componente della WBS richiesto per produrre ogni deliverables.
2.
Project Documents:
-Basis Of Estimates: dettagli di supporto per la stima dei costi che dovrebbero specificare le ipotesi
di base che si occupano dell’inclusione o dell’esclusione dei costi diretti o di altri costi nel bilancio
del progetto.
-Cost Estimates: le stime dei costi di ogni attività sono aggregate per ottenere la stima dei costi dei
livelli superiori.
-Project Schedule: include le date di inizio e fine pianificate per le attività di progetto, milestones,
etc. Queste informazioni possono essere usate per aggregare i costi ai periodi del calendario nei
quali i costi sono pianificati.
Risk Register: dovrebbe essere revisionato per considerare come aggregare i costi di risposta al
rischio.
3.
Business Documents: Business Case; Benefits Management Plan
4.
Agreement: Sono gli accordi relativi ai costi riguardanti i prodotti, servizi o risultati che sono stati o
saranno acquistati.
5.
Enterprise Environmental factors: Variazione dei cambi, per grandi progetti che si estendono su più
anni la fluttuazione dei tassi di cambio e l’inflazione.
6. Organizational Process Assets: I processi organizzativi che possono influenzare il budget sono ma non
solo:
-Politiche, procedure e linee guida per la determinazione del budget
-Informazioni storiche e lesson learned
-Strumenti di cost budgeting
-Modelli e metodi di report.
TOOL & TECHNIQUES
1.Expert Judgment: l’esperienza in una particolare area applicativa aiuta nel determinare il budget. Tali
esperienze possono fornire da alcuni gruppi o persone con conoscenze, skill, esperienze e formazione
specifica. E’ disponibile da varie sorgenti come ad esempio altre unità all’interno della Performing
Organization, consulenti, stakeholder, consumatori, associazioni tecniche e professionali, gruppi storici, etc.
2. Cost Aggregation: i costi aggregati sono aggregati dal livello inferiore a quello superiore in accordo con la
WBS fino ad arrivare all’intero progetto.
3. Data Analysis: include ma non è limitata all'analisi delle riserve, per quantificare le riserve di gestione del
progetto. Le riserve di gestione rappresentano una parte del budget del progetto riservate a lavori
imprevisti nell'ambito del progetto, destinate ad affrontare fatti incogniti sconosciuti che possono
influenzare il progetto. La riserva di gestione non è inclusa nella baseline dei costi, ma fa parte del budget
complessivo del progetto e del finanziamento. Quando una parte della riserva di gestione viene utilizzata
per finanziare un lavoro imprevisto, l'ammontare utilizzato viene aggiunto alla cost baseline, attraverso
un’ìapprovazione formale della variazione.
4. Historical Information Review: qualsiasi relazione storica da utilizzare in stime parametriche o analoghe
che coinvolgono l’uso di caratteristiche (parametri) del progetto per sviluppare modelli matematici per
predire i costi totali del progetto. Hanno una maggiore probabilità di essere affidabili quando:
-Le informazioni storiche usate per sviluppare il modello sono accurate; -I parametri usati sono
prontamente quantificabili; -Quando i modelli sono scalabili in modo che tali modelli possono andar bene
sia per grandi che piccoli progetti o per le fasi di un progetto.
5. Funding Limit Reconciliation: la spesa dei fondi dovrebbe essere legata ai limiti temporali dei fondi.
L’eventuale scostamento tra i limiti temporali dei fondi e le spese pianificate necessita la rischedulazioni
delle attività. Ci si ottiene inserendo vincoli di data per il lavoro nella pianificazione in modo da svolgere le
attività nei periodi in cui sono disponibili i fondi.
6. Financing: è l'acquisizione di finanziamenti per realizzare il progetto. È comune che progetti
infrastrutturali, industriali e di servizi pubblici a lungo termine richiedano fonti di finanziamento esterne, in
tal caso, il tipo di finanziamento può richiedere determinati requisiti che devono essere soddisfatti.
OUTPUT
1.
Cost Baseline: è la versione approvata del budget del progetto, escluse le riserve di gestione, che
può essere cambiata solo attraverso procedure per varianti formali ed è usata come base per il confronto
con i risultati effettivi. E’ ottenuta come la somma dei costi approvati per le diverse attività schedulate.
2.
Project Funding Requirements: le necessità di fondi e le esigenze periodiche di finanziamento
derivano dalla baseline dei costi. Il finanziamento avviene spesso in quantità incrementali che non sono
continue e può non essere distribuito in modo uniforme. I fondi totali richiesti sono quelli inclusi nella
baseline dei costi oltre a riserve di gestione.
3.
Project Documents Updates: Cost Project Schedule; Risk register; Cost Estimate
Control Costs
E’ il processo mediante il quale si monitora lo stato del progetto per aggiornare i costi del progetto e gestire
le variazioni della baseline di costo.
Il vantaggio di questo processo è che fornisce i mezzi per riconoscere le variazioni rispetto al pianificato al
fine di intraprendere o meno azioni correttive e minimizzare i rischi.
Qualsiasi incremento al budget autorizzato può essere solo approvato attraverso il processo Perform
Integrated Change Control.
Gran parte degli sforzi di controllo dei costi consiste nell’analisi della relazione tra il consumo dei fondi del
è la gestione della baseline dei costi approvati rispetto alle sue variazioni.
Il controllo dei costi include le seguenti attività:
-Influenzare i fattori che creano le variazioni rispetto alla baseline dei costi autorizzata.
-Assicurarsi che tutte le decisioni che riguardano le variazioni richieste siano assunte in modo tempestivo.
-Gestire secondo procedure le variazioni.
-Assicurarsi che la spesa non superi i fondi autorizzati per periodo, per componente di WBS, per attività e in
totale per il progetto.
-Monitorare i costi per isolare e capire le variazioni rispetto alla baseline dei costi approvata.
-Monitorare il lavoro in relazione ai fondi spesi.
-Informare gli opportuni stakeholders di tutte le variazioni approvate e dei costi associati.
-Prevenire variazioni non approvate dei costi
-Portare l’aumento previsto dei costi entro limiti accettabili.
INPUT
1. Project Management Plan: contiene le seguenti informazioni che saranno usate in Control Costs:
-Cost Management Plan: descrive come saranno gestiti e controllati i costi del progetto.
-Cost Baseline: la baseline del costo è confrontata con i risultati effettivi per determinare se sono necessarie
variazioni, azioni correttive o preventive.
-Performance Measurement Baseline
2.
Project Documents
3.
Project Funding Requirements: derivano dalla baseline dei costi. le necessità totali di fondi e le
esigenze periodiche di finanziamento
4.
Work Performance Data: includono informazioni circa i progressi del progetto, come ad esempio
quali attività sono iniziate, il loro progresso e quali deliverables sono completati. Le informazioni includono
anche i costi che sono stati autorizzati e sostenuti.
5. Organizational Process Assets: includono ma non sono limitati a:
-Politiche, procedure e linee guida connesse al controllo dei costi
-Strumenti per il controllo dei costi
-Metodi di monitoraggio e reporting
TOOL & TECHNIQUES
1. Expert Judgment: esempi: -Analisi delle varianzioni; -Earned value analysis; -Previsioni; -Analisi finanziarie
2. Data Analysis:
-Earned Value Management (EVM): è una metodologia che usa le misure dello “scope”, schedule e risorse
per valutare la performance e i progressi del progetto. Integra la baseline dello “scope” con quella dei costi
e dello schedule per misurare la performance rispetto ai costi e all’avanzamento. I principi dell’EVM
possono essere applicati a qualunque progetto e per qualsiasi organizzazione.
EVM sviluppa e monitora 3 dimensioni chiave:
-Planned Value (PV): è il budget autorizzato assegnato al lavoro schedulato. Questo budget misura il
lavoro fisico che dovrebbe essere stato compiuto. Il PV totale per il progetto è anche conosciuto come
Budget at Completition (BAC). Tale parametro è chiamato anche Budget Cost of Work Schedule
(BCWS).
-Earned Value (EV): è la misura del lavoro eseguito espresso in termini di budget autorizzato. L’EV è
spesso usato per calcolare la percentuale di completamento del progetto. I PM devono monitorare
l’EV sia in modo incrementale per determinare lo stato corrente sia in modo cumulativo per
determinare la performance di lungo periodo. Tale parametro è chiamato anche Budget Cost of Work
Performed (BCWP).
-Actual Cost (AC) il costo sostenuto per il lavoro eseguito durante uno specifico periodo di tempo. L’AC
non avrà un limite superiore. Tale parametro è chiamato anche Actual Cost of Work Performed
(ACWP).
-Variance Analysis: La variazione rispetto alla baseline approvata sarà monitorata con i seguenti indici:
-Schedule Variance (SV): è la misura della performance dello schedule SV = EV – PV
E’ un indicatore che rappresenta la condizione di anticipo o ritardo rispetto alla data di consegna
pianificata. E’ la misura della performance dello schedule del progetto. L’SV sarà comunque pari a
zero quando il progetto è completato perché il lavoro pianificato sarà stato tutto eseguito.
-Cost Variance (CV): è l’ammontare del budget speso in più o in meno in un dato istante per il lavoro già
eseguito: CV = EV – AC
E’ la misura della performance dei costi del progetto. Il CV a fine progetto sarà la differenza tra il Budget at
Completion (BAC) e l’ammontare effettivo delle spese. Un valore di CV negativo è spesso problematico per
il progetto.
Variance Analysis: l’SV e il CV possono essere convertiti in indicatori di efficienza per riflettere la
performance di costo e schedule di ogni progetto confrontandolo con altri progetti del portfolio progetti.
-Schedule Performance Index (SPI) : è la misura dell’efficienza dello schedule espressa come:
SPI = EV / PV
Un valore di SPI minore di 1 indica il fatto che è stato eseguito meno lavoro rispetto a quello pianificato,
viceversa un valore maggiore di 1 indica che è stato svolto più lavoro rispetto a quello pianificato.
L’SV e il CV possono essere convertiti in indicatori adimensionali di efficienza per fare confronti con con
altri progetti del portfolio progetti.
-Cost Performance Index (CPI) : è la misura dell’efficienza del costo espressa come: CPI = EV / AC
Un valore di CPI minore di 1 indica il fatto che il costo effettivo del lavoro completato è superiore a quello
previsto, viceversa un valore maggiore di 1 indica che il costo effettivo del lavoro completato è inferiore a
quello previsto.
-Trend Analysis: Charts: Nella Earnerd Value Analysis i parametri EV, AC, BC, CV, SV, CVI, SVI possono essere
periodicamente monitorati (tipicamente settimanalmente, mensilmente) per valutare le tendenze.
TOOL &
EarValPlanValue
Ac C
-Forecasting: si può sviluppare una previsione per la Stima al Completamento (Estimate at Completition,
EAC) che può differire dal budget al completamento (Budget at Completion, BAC) in base alla performance
di progetto. La previsione dell’EAC comporta il fare proiezioni di condizioni ed eventi che avverranno nel
futuro basandosi su informazioni sulla performance corrente e altre conoscenze disponibili nel momento
della previsione. L’EAC è generalmente basato sull’Actual Cost sostenuto per il lavoro completato più una
stima per completare (Estimate to Complete, ETC) il rimanente lavoro.
Gli approcci più comuni per la previsione dell’EAC sono manuali, somme bottom-up, etc. Il metodo bottomup dell’EAC del PM si basa sull’esperienza e sui costi attuali sostenuti per il lavoro per il lavoro completato
e richiede un’ulteriore stima per completare il rimanete lavoro del progetto.
EAC = AC + Bottom-up ETC
La stima del costo a completamento generalmente è svolta in 3 modi:
-EAC forecast for ETC work performed at the present CPI: Questo metodo assume che in futuro si avrà la
performance che il progetto ha avuto sino ad oggi. L’ETC si presume essere eseguito allo stesso Cost
Performance Index (CPI) di quello sostenuto dal progetto fino ad oggi.
EAC = BAC / CPI
EAC forecast for ETC work considering both SPI and CPI factors: In questa previsione l’ETC sarà effettuato a
un tasso di efficienza che considera sia il CPI e SPI. Questo metodo è utile soprattutto quando la
pianificazione del progetto è un fattore che influenza l’ETC.
EAC = AC + [(BAC - EV) / (CPI x SPI)]
Ognuno di questi approcci è applicabile a qualsiasi progetto e fornirà al team di progetto un primo allarme
nel caso in cui le previsione dell’EAC non sono all’interno di t
-ReserveAnalysis: è usata per monitorare lo stato di contingenza, per gestire le riserve del progetto e per
determinare se tali riserve sono ancora necessarie o se devono essere richieste riserve aggiuntive. Al
progredire del progetto tali riserve possono essere usate per ricoprire i costi degli eventi rischiosi o altre
contingenze. Se i probabili eventi rischiosi non avvengono le riserve inutilizzate possono essere rimosse dal
budget di progetto in modo da liberare risorse per altri progetti o operazioni.
3. To-Complete Performance Index (TCPI): è una misura della performance del costo. E’ il CPI che è
ottenuto sul restante lavoro per raggiungere specifici obietti quali il BAC o l’EAC.
L’equazione del TCPI è: TCPI = (Work Remainig) / (Funds Remaining)
L’equazione del TCPI basandosi sul BAC è: TCPI = (BAC – EV) / (BAC – AC)
L’equazione del TCPI basandosi sull’EAC è: TCPI = (BAC – EV) / (EAC – AC)
4.PROJECT MANAGEMENT INFORMATION SYSTEM (PMIS)
OUTPUT
1. Work Permances Information: sono documentati e comunicati agli stakeholder tutti gli indici
precedentemente calcolati (CV, SV, CPI, SPI, TCPI, etc.)
2.
Cost forecasts: è documentato e comunicato agli stakeholders l’EAC.
3.
Change Requestes: l’analisi della performance del progetto può risultare in una richiesta di
variazioni della baseline del costo o di altri componenti del Project Management Plan. Tali variazioni
possono includere azioni correttive e preventive.
4.
Project Management Plan Updates:
-Cost Management Plan
-Cost Baseline
-Performance Measurement Baseline
5.
Project Documents Updates: Assumption log, Basis of estimetes, Cost estmetes, Lesson learned
register, Risk register
AHP- ANALITIC HIERARCHY PROCESS
Sviluppato da T.L. Saaty, Wharton School of Business alla fine del 1970.
Permette di individuare la soluzione più soddisfacente per i decisori, rappresentando un problema
complesso in una struttura gerarchica, tenendo conto sia degli aspetti tangibili che intangibili. La
metodologia consente di misurare e sintetizzare la moltitudine di fattori coinvolti nelle decisioni complesse
e inoltre considera l’esperienza ed il bagaglio sociotecnologico dei decisori tanto importanti quanto lo sono
i dati che essi devono trattare.
L’utilizzo dell’AHP consente ai decisori di derivare le loro scale di preferenza tenendo conto:
• delle informazioni disponibili;
• della loro esperienza;
• della loro capacità di discernere;
• delle loro intuizioni.
Il nome Analytic Hierarchy Process, riflette sinteticamente l’approccio proprio del metodo:
-Analytic: scomporre il problema nei suoi elementi costitutivi;
-Hierarchy: strutturare il problema decisionale in forma gerarchica per migliorarne la comprensibilità;
-Process: processare i dati e i giudizi, aiutando il decisore a trovare la soluzione più soddisfacente.
È una metodologia di supporto alle decisioni compensativa in quanto i progetti che sono carenti rispetto
a uno o a più criteri, compensano la loro performance rispetto su criteri
I PRINCIPI DELL’AHP:
-DECOMPOSIZIONE GERARCHICA: Individuare gli elementi costitutivi; Strutturare il problema in forma
gerarchica.
-GIUDIZI COMPARATIVI: Esprimere giudizi tramite confronti a coppie per determinare i pesi locali degli
elementi.
-SINTESI DEI RISULTATI: Verificare la coerenza dei giudizi; Calcolare gli score delle alternative.
1) Decomposizione gerarchica:
Identificare gli elementi costitutivi
FASE 1: consiste nell'identificare, in generale, alcuni o tutti i seguenti elementi:
-lo scopo, cioè identificare l'obiettivo generale da raggiungere;
-diversi scenari possibili (economici, ambientali, sociali, ecc.);
-i DM, ovvero coloro che sono direttamente o indirettamente coinvolti nel processo decisionale processo
decisionale, esplicitando le differenze di valutazione che dipendono dalla diversità dei loro interessi e dei
loro sistemi di valori;
-i criteri e i sottocriteri, qualitativi e/o quantitativi, di valutazione;
-i criteri e i sottocriteri di valutazione;
-le alternative.
Struttura gerarchica
FASE 2: formulare il problema decisionale in una struttura gerarchica, evidenziando le relazioni logiche che
esistono tra gli elementi costitutivi individuati. Le relazioni logiche che esistono tra gli elementi costitutivi
individuati.
La struttura gerarchica può essere creata perseguendo:
• una strategia top down;
• un approccio bottom up.
Nell’individuare tale struttura si deve garantire:
•la dipendenza di un livello dal superiore;
• l’indipendenza tra gli elementi dello stesso livello
Struttura gerarchica Completa
Si ha quando ogni elemento di un livello dipende esternamente da ciascuno degli elementi del livello
superiore. In tal caso tutti gli elementi di un livello devono poter essere confrontati a coppia tra loro
prendendo come riferimento uno qualsiasi degli elementi del livello superiore.
Struttura gerarchica Incompleta
La gerarchia incompleta si ha quando almeno un elemento di un livello è indipendente da almeno uno
degli elementi del livello superiore.
2)Giudizi comparativi
-Si esprimono giudizi comparativi, confrontando coppie di elementi dello stesso livello rispetto ad un
elemento di livello gerarchico superiore, misurando la priorità attribuita ad un elemento nei confronti
dell’altro.
-Per ogni coppia, il decisore esprimerà verbalmente tali giudizi attraverso l’utilizzo di opportune scale
semantiche o numeriche o grafiche.
Assiomi dell’AHP:
-Assioma reciprocità:
Per ogni aij є A (essendo A la matrice dei confronti a coppie) vale la relazione aij=1/aji con aii=1. Ciò significa
che se il valutatore ha stimato l’elemento A 2 volte più importante dell’elemento B, vorrà dire che lo stesso
ritiene che l’elemento B abbia la metà dell’importanza (0,5) rispetto all’elemento A;
-Assioma di omogeneità:
Gli elementi che vengono confrontati non devono differire più di un ordine di grandezza
(devono essere omogenei) e inoltre le dimensioni dei livelli devono essere di norma decrescenti,
muovendosi dal basso verso l’alto della gerarchia;
-Assioma di indipendenza: I pesi di un livello non devono dipendere da un livello più basso. La preferenza
espressa fra le alternative è dipendente da un livello più alto (dai criteri o sottocriteri), ma non è
vero il viceversa;
La matrice di confronto a coppie può essere definita anche attraverso la tecnica del tecnica di valutazione.
Con questa tecnica il DM ha a disposizione un budget di 100 punti da dividere tra i due elementi che sta
confrontando.
L'indice aij sarà determinato calcolando il rapporto fra i punteggi attribuiti ai due elementi da confrontare.
Un'altra tecnica è quella grafica.
-È consigliabile esprimere i giudizi comparativi sempre nella stessa direzione, cioè di confrontare il migliore
con il peggiore nel caso di utilizzare la scala di Saaty o la scala geometrica.
Il numero di matrici di confronto a coppie per ogni livello gerarchico è pari al numero di elementi del livello
superiore rispetto ai quali gli elementi del livello in questione dovranno essere confrontati a coppie.
Se n è il numero di elementi da confrontare, la matrice sarà composta da n2 elementi.
Poiché aij=1/aji e aii=1 il numero di giudizi che il DM dovrà esprimere per ogni matrice è uguale a
esprimere per ogni matrice è pari a
(n*(n-1))/2
CALCOLO DELLE PRIORITA’ LOCALI
In questo step verranno determinati, in relazione ad ognuna delle matrici di confronti a coppie generate, il
peso che ogni elemento assume per il decisore nei confronti di ciascun elemento appartenente al livello
gerarchico superiore.
I metodi con i quali vengono determinati i pesi sono:
-Normalizzazione;
-Media geometrica;
-Metodo dell’autovettore.
Assumendo che il DM conosca i valori dei pesi degli elementi, la matrice di confronto a coppie può essere
confronti a coppie può essere espressa come segue:
In questa ipotesi il vettore dei pesi W può essere ottenuto da ogni colonna della matrice A. Consideriamo,
infatti, il prodotto tra la matrice A e il vettore W:
La matrice è detta perfettamente coerente se:
Metodo dell’autovettore:
se la matrice NON è COERENTE possiamo scrivere: A * W = λ * W
Tale equazione rappresenta il classico problema agli autovalori che ha una soluzione diversa da zero solo se
il determinannte di A - λ I è uguale a zero.
Il metodo prevede che si ricerca il massimo degli autovalori di cui il corrispondente autovettore W
rappresenta la migliore approssimazione del vettore dei pesi.
Esistono diversi metodi per determinare il vettore dei pesi:
1. Metodo degli autovalori
2. Altri metodi:
a. Media geometrica: per ogni riga della matrice di confronto a coppie, la media geometrica (cioè la
radice ennesima della produttività tra gli elementi della riga stessa) della produttività tra gli
elementi della riga stessa) e si effettua una normalizzazione delle medie ottenute rispetto al totale
delle stesse.
b. Media aritmetica: si dividono gli elementi di ogni colonna per il totale della stessa e si effettua la
media aritmetica degli elementi per ogni riga;
c. Altro: Normalizzare i totali di ogni riga rispetto alla somma di tutti gli elementi della matrice.
elementi della matrice.
Metodo degli autovettori: ricerca degli autovettori con il metodo della potenza
Consiste nell'iterazione del processo in cui a ogni passo si determinano la matrice e il relativo vettore dei
pesi:
Il vettore dei pesi viene calcolato sommando gli elementi di ciascuna riga della matrice Ai
(dove Ai rappresenta l'i-esima potenza di A) e normalizzando queste somme per la somma di tutti gli
elementi:
le iterazioni vengono ripetute fino alla convergenza di W. Cioè, il processo si ferma quando la distanza tra i
vettori dei pesi della matrice Ak ottenuti al passo k e quelli della matrice Ak+1 ottenuti al passo (k+1) è
estremamente piccola
NB un metodo semplice per misurare questa distanza è la differenza tra i valori corrispondenti delle
componenti dei vettori
3) SINTESI DEI RISULTATI
Verificare la coerenza dei giudizi:
I giudizi del decisore, sono perfettamente coerenti, quando ad esempio nel caso di tre alternative, avendo
giudicato l’alternativa A due volte migliore dell’alternativa B, e l’alternativa B due volte migliore
dell’alternativa C, giudicherà l’alternativa A quattro volte migliore dell’alternativa C.
Tale relazione logica non viene rispettata la maggior parte delle volte
Cause dell’incoerenza:
• Errori di trascrizione;
• Mancanza di informazioni;
• Mancanza di concentrazione;
• Il problema reale è caratterizzato dall’incoerenza cioè la
non transitività;
è più importante essere precisi che coerenti!
-La metodologia AHP prevede un certo grado di incoerenza e provvede a misurarla attraverso degli
indici:
Dove
CI è l'indice di coerenza
RI è il valore medio dell'indice di consistenza calcolato su un campione di matrici generate casualmente di
dimensione n.
λmax è l'autovalore massimo della matrice decisionale
W è il vettore dei pesi (w1, ..., wj,..., wn)
W' è il vettore (1/w1, ..., 1/wj,..., 1/wn)
Saaty ha simulato casualmente matrici di ordine diverso e ha calcolato la RI per ciascuna di esse.
Se la matrice è perfettamente coerente: λmax = n -> CI = 0 -> CR = 0
L'incoerenza aumenta all'aumentare di CR
Saaty ha definito delle soglie entro le quali il grado di incoerenza può essere considerato accettabile:
in generale CR<0,1, in dettaglio CR = 0,08 per n=4 e CR = 0,05 per n=3
Se questo valore limite viene superato, è consigliabile indagare sulle cause dell'incoerenza e, se necessario,
riformulare i giudizi o ridefinire il modello, quindi ripetere il processo fino a quando il CR può essere
considerato accettabile.
Calcolo della priorità totale: calcolo dei punteggi delle alternative
-Si calcolano i pesi relativi ad ogni elemento rispetto all’elemento di livello gerarchico superiore, sino al goal
(Già abbiamo questo valore nelle matrici del calcolo locale)
-La valutazione di ogni alternativa viene determinata effettuando una sommatoria ponderata delle
valutazioni dell’alternativa in corrispondenza di ogni criterio per i pesi dei criteri stessi.
La sintesi delle priorità di ciascuna alternativa rispetto alla globalità dei criteri ha quindi la seguente
espressione:
, essendo wk il peso del criterio k ed Sk (ai) la misura dell’alternativa i
sotto il criterio k;
- Se sono presenti dei sottocriteri, è necessario effettuare un'ulteriore sommatoria ponderata tra le
valutazioni delle alternative in base a ciascun sottocriterio e i pesi dei sottocriteri.
Se in corrispondenza del criterio k sono presenti i sottocriteri j, ne consegue che
dove
pkj il peso del sottocriterio j del criterio k
Skj(ai) il punteggio dell'alternativa i in base al sottocriterio j del criterio k
Tuttavia, va notato che la classifica dipende dal modo in cui i valori di Sk(ai) delle alternative vengono
normalizzati rispetto ai valori di K.
Esistono tecniche per normalizzare il vettore Sk(ai):
la tecnica distributiva e la tecnica ideale
Tecniche distributive - Sistemi chiusi
-In questo caso il vettore Sk(ai) delle misure delle preferenze delle alternative rispetto al generico criterio k,
è normalizzato a somma 1 altro valore in ogni caso uguale per tutti i criteri
-Il vettore Sk(ai) così normalizzato viene moltiplicato per il peso del criterio k e quindi è come se il peso del
criterio fosse distribuito tra tutte le alternative.
In particolare, il valore normalizzato di ogni alternativa i rispetto a un criterio/subcriterio j viene assegnato
attraverso l'espressione:
Dove
Vij è il valore della preferenza dell'alternativa i rispetto al criterio/sottocriterio j ottenuto dalla matrice di
confronto a coppie.
Tecniche ideali - Sistemi aperti
Il peso del criterio sarà assegnato all'alternativa che ha la più alta priorità rispetto a quel criterio (questa
alternativa, detta ideale, rappresenterà l'alternativa di riferimento per le altre), e alle altre alternative un
peso proporzionale.
-Ovvero, in corrispondenza del vettore delle misure delle preferenze delle alternative in base a ciascun
criterio, all'alternativa ideale verrà assegnato il valore uno e agli altri il rapporto tra la loro misura e quella
dell'alternativa ideale, e poi il peso del criterio sarà moltiplicato per questi rapporti.
-In particolare, il valore normalizzato di ogni alternativa i rispetto a un criterio/sottocriterio j viene
assegnato attraverso l'espressione:
Vij è il valore della preferenza dell'alternativa i rispetto al criterio/sottocriterio j ottenuto dalla matrice di
confronto a coppie.
-Tecnica di normalizzazione distributiva:
Inserendo una nuova alternativa anche se non preferibile rispetto alle altre (nel senso che sia dominata da
una o più dalle alternative esistenti) o rimuovendo una, l’ordinamento delle alternative che occupano le
prime posizioni potrebbe essere modificato.
-Tecnica di normalizzazione ideale:
Inserendo una nuova alternativa che non sia preferibile o rimuovendone una già esistente, la graduatoria
delle prime alternative non cambierà, in quanto sarà sempre l’alternativa ideale ad avere il max valore e le
altre un valore proporzionale.
Metodo distributivo vs metodo ideale
I metodi di normalizzazione distributiva e ideale possono essere utilizzati per determinare la classifica delle
alternative nelle decisioni che possono essere rappresentate rispettivamente da sistemi chiusi e aperti.
I sistemi chiusi e aperti riflettono realtà caratterizzate rispettivamente da risorse limitate e illimitate.
Tra i due sistemi, tuttavia, non c'è alcuna differenza nella struttura gerarchica del modello decisionale e
nella gerarchica del modello decisionale e nella fase relativa all'espressione dei giudizi di confronto.
Sistemi chiusi: un esempio può essere rappresentato dalla distribuzione dei voti di una popolazione tra i
candidati politici, in cui il numero di voti da distribuir è fisso (risorsa limitata) e pari al numero di cittadini
aventi diritto al voto.
Sistemi aperti: un esempio è l'attribuzione di punteggi a un esame scolastico, in cui ogni studente può
ottenere il punteggio (risorsa illimitata) massimo (10 punti).
PROPRIETÀ DELL’AHP: RANK REVERSAL
La differenza fondamentale relativa ai due sistemi consiste nel fatto che nel caso di modelli decisionali
relativi a sistemi chiusi, inserendo una nuova alternativa anche se non preferibile rispetto alle altre (nel
senso che sia dominata da una o più dalle alternative esistenti) o rimuovendone una, l’ordinamento delle
alternative che occupano le prime posizioni potrebbe essere modificato e non preservato, verificandosi
quello che in letteratura viene chiamato Rank Reversal.
ELECTRE
ELimination Et Choix Traduisant la REalitè (ELECTRE) method
Sviluppato dal professore B.Roy dell�Università Dauphine di Parigi a partire dalla fine degli anni �60, con lo
scopo di mettere a punto un metodo decisionale il più aderente possibile alla realtà.
Tale metodologia è stata sviluppata per affrontare varie tipologie di problemi, quali:
-problemi di scelta, quando si deve scegliere la migliore alternativa o selezionare un gruppo di proposte
all’interno di un set di possibili soluzioni;
-problemi di ordinamento, qualora si debba ad esempio stilare una graduatoria tra le alternative candidati;
-problemi di classificazione, nel caso in cui si vogliano attribuire le alternative considerate a più classi di cui
si conoscano le caratteristiche.
Il surclassamento si basa sul principio concordanza/discordanza, ossia sulla verifica dell’ esistenza di una
concordanza di ragioni/criteri mediamente a favore (o indifferenza) di un progetto rispetto ad un altro
(condizione di concordanza) e sul controllo che non esistano situazioni di forte discordanza tra le
valutazioni in grado di mettere in discussione la concordanza appena testata (espressione del veto,
condizione di discordanza).
B.Roy fornisce una definizione formale di outranking, ovvero ritiene che il progetto Pi surclassi Pj (e
scriveremo Pi S Pj) se, in relazione a quelle che sono le preferenze dei decisori e la qualità delle valutazioni
effettuate:
Esistono ragioni sufficienti per ritenere che ai sia almeno altrettanto buona di aj e non esistono buone
ragioni per rifiutare tale affermazione
In ognuno di questi metodi vengono previste quattro fasi:
- Nella prima avviene la strutturazione del problema
- Nella seconda avviene la valutazione dei progetti su ogni criterio;
- Nella terza avviene il confronto a coppie dei progetti su ogni criterio e l’aggregazione di questi risultati
mediante test o l’elaborazione di indici di concordanza/discordanza (modellizzazione del surclassamento);
-Nella quarta si applica una procedura operativa per arrivare ad un risultato finale tramite una regola
decisionale, identificata dai decisori come significativa per affrontare il problema e coerente con la
problematica di scelta, ordinamento o classificazione.
I metodi ELECTRE
-TEST DI CONCORDANZA: Indice di concordanza Ck(i,j)
In relazione al criterio k esprime quantitativamente il grado con cui si concorda sul fatto che il progetto Pi
sia preferito al progetto Pj o egualmente preferibile
-TEST DI DISCORDANZA: Indice di discordanza Dk(i,j)
per il criterio k esprime quantitativamente il grado con cui la valutazione del progetto Pi è ritenuta molto
inferiore a quella di Pj al di la di una differenza ritenuta accettabile (condizioni di veto) e quindi in contrasto
con l’ipotesi che il progetto i sia migliore del progetto j o egualmente preferibile qualunque sia l’indice di
concordanza aggregato
Il metodo ELECTRE I
-Il metodo è stato ideato al fine di selezionare un sottoinsieme delle alternative progettuali giudicate
“migliori” delle altre, ovvero per estrarre da un set di progetti quel gruppo che si ritiene surclassi tutti gli
altri;
-Punta quindi alla costruzione di una relazione di surclassamento sull’insieme delle alternative, all’interno
del quale si scelgono quelle surclassanti, che rappresentano le soluzioni soddisfacenti, mentre le altre
vengono scartate.
Il metodo si articola nei seguenti passi:
1. assegnazione del peso a ciascun criterio che può ad esempio essere ottenuta tramite il metodo AHP o
Delphi o altro strumento;
2. costruzione della matrice di valutazione di ogni progetto rispetto ad ogni criterio;
3. normalizzazione della matrice di valutazione;
4. costruzione di una matrice degli indici di concordanza, che misuri il grado con cui il progetto Pi è preferito
al progetto Pj o valutato egualmente preferibile sulla base di un confronto diretto effettuato su tutti i
criteri:
-È necessario confrontare a coppie i progetti per ogni criterio e, è necessario determinare, dopo aver
verificato per quali criteri Pi è almeno uguale a Pj, la matrice di concordanza come:
dove
J+(Pi, Pj) = insieme di criteri per i quali l'alternativa i è preferita all'alternativa j e
J=(Pi, Pj) = insieme di criteri per i quali c'è indifferenza tra i due progetti a confronto.
b. Gli indici di concordanza devono essere calcolati con la seguente formula:
dove
p+(Pi, Pj) = somma dei pesi dei criteri appartenenti all'insieme J+(Pi, Pj)
p=(Pi, Pj) = somma dei pesi dei criteri appartenenti all'insieme J=(Pi, Pj) e
p somma dei pesi di tutti i criteri
Cij ∈ [0; 1]: Esprime quantitativamente il grado in cui si concorda che Pi è preferito o uguale a Pj.
Ad esempio, se questo indice è uguale a 1, ci sarà unanimità o maggioranza ponderata del 100% del Pi
rispetto al Pj.
5. formulazione di un test di concordanza atto a verificare la condizione di concordanza:
È necessario che il DM stabilisca una soglia di concordanza C* che esprima il grado minimo di concordanza
richiesto affinché non venga scartata l'ipotesi che un progetto sia superiore a un altro.
Tale soglia viene generalmente individuata seguendo una delle due seguenti indicazioni:
 0,5 < C* < [1-minCij]
 valore medio tra i valori di Cij.
Una volta individuata questa soglia, è possibile costruire il test di concordanza mediante:
6. Costruzione di una matrice degli indici di discordanza per identificare progetti non comparabili o
fortemente in conflitto reciproco;
a. Per costruire una tale matrice è necessario identificare l'insieme di discordanza J-(Pi, Pj), cioè
l'insieme dei criteri per i quali Pj è preferito a Pi.
b. Per ogni confronto tra progetti si deve calcolare l'indice di discordanza Dij che esprime
quantitativamente il grado in cui la valutazione del progetto Pi viene considerata inferiore a quella di
Pj. L'indice è definito come segue:
dove Ak(Pj) è il punteggio assunto da Pj sul criterio k appartenente all'insieme di discordanza J-(Pi, Pj).
Dij è uguale a zero se non ci sono criteri per i quali Pj è preferito a Pi, altrimenti il suo valore è ottenuto
dalla massima differenza tra i punteggi dei due progetti confrontati su ogni criterio di discordanza.
7. formulazione di un test di non-discordanza per verificare eventuali condizioni di discordanza;
È necessario che il DM stabilisca una soglia di discordanza D* che esprima la massima discordanza
consentita.
Non esiste un metodo specifico per determinare D*, la scelta è del DM, ma il valore deve essere compreso
nell'intervallo [0; 1].
Una volta impostata questa soglia, è possibile costruire il test di discordanza mediante:
8.
costruzione, mediante l’applicazione congiunta dei test di concordanza e discordanza, della matrice
di surclassamento netto, che permetta di individuare le alternative progettuali surclassanti e quelle
surclassate.
-The outranking relationship for ELECTRE I is built by comparing the concordance and discordance indices
with specified limits (thresholds). This relationship is built according to the following rule:
o Pi outrank Pj if, with reference to the pair (Pi, Pj), both tests are passed, i.e. if Tc(Pi, Pj) = Td(Pi, Pj)= 1. In
other words, the outranking relationship relation is defined as follows:
Il metodo ELECTRE II
La seconda versione del metodo è stata sviluppata dal professore B.Roy e da P.Bertier nel 1971 con lo
scopo di determinare un ordinamento gerarchico, una vera e propria graduatoria tra le alternative
progettuali in esame. Come nel caso di ELECTRE I vengono qui utilizzati criteri di selezione che definiscano
una relazione di surclassamento certo e non sfumato, ovvero criteri per i quali qualunque scarto di
valutazione, per quanto piccolo, indica una preferenza in senso stretto; le scale di valutazione possono
essere cardinali oppure ordinali.
La prima fase del metodo consiste nel modellizzare la relazione di surclassamento tra le alternative; per
arrivare a questo risultato si utilizzano i test di concordanza e di non-discordanza.
Esattamente come nella prima versione del metodo vengono introdotti i seguenti sottoinsiemi e
sommatorie (nel caso in cui i criteri siano da massimizzare):
- J+(Pi, Pj) = insieme dei criteri per i quali Pi assume punteggio migliore di quello di Pj;
- J=(Pi, Pj) = insieme dei criteri per i quali Pi assume lo stesso punteggio di Pj;
- J-(Pi, Pj) = insieme dei criteri per i quali Pi assume punteggio peggiore di quello di Pj;
- p+(Pi, Pj) = sommatoria dei pesi dei criteri di J+(Pi, Pj);
- p=(Pi, Pj) = sommatoria dei pesi dei criteri di J=(Pi, Pj);
- p-(Pi, Pj) = sommatoria dei pesi dei criteri di J-(Pi, Pj);
- p = 1 sommatoria dei pesi di tutti i criteri.
Il metodo ELECTRE II
L’indice di concordanza relativo al confronto tra le alternative Pi e Pj è espresso,come nel caso di ELECTRE I,
da: Cij = [p+(Pi, Pj) + p=(Pi, Pj)]/ p.
Per superare il test di concordanza è invece necessario che vengano superate entrambe le seguenti
condizioni:
 Cij ≥ C*
 p+(Pi, Pj) ≥ p-(Pi, Pj)
dove C* è un parametro che rappresenta la soglia di concordanza. Si possono scegliere le cosiddette soglie
naturali (Cf* = 0,75 detta soglia forte e Cd* = 0,67 detta soglia debole) o comunque valori prossimi a questi.
Il metodo ELECTRE II prevede che il decisore possa stabilire una condizione di veto su tutti i criteri oppure
su un sottoinsieme di essi.
Consideriamo un criterio Ck che sia discordante e che quindi appartenga all’insieme J-(Pi, Pj) cioè su tale
criterio il punteggio dell’alternativa Pj sarà migliore di quello di Pi. Ebbene il decisore può stabilire un valore
vk per il criterio Ck tale che, se la differenza tra i punteggi delle alternative Pi e Pj su tale criterio supera il
valore vk, allora l’ipotesi che Pi surclassa Pj è da rifiutare.
Quindi la condizione necessaria a superare il test di non-discordanza diventa la seguente:
Ck (Pj ) – Ck (Pi) < vk per ogni k
Si possono impostare 2 soglie di veto: la soglia forte vfk e la soglia debole vdk e vfk < vdk
-Per stabilire l'outranking di un'alternativa rispetto a un'altra, devono essere superati sia i test di
concordanza e non concordanza.
Alla fine della 1° fase di ELECTRE II possiamo riportare i risultati della modellazione della relazione di
outranking attraverso una matrice di incidenza che, per ogni confronto a coppie tra progetti, riporta i valori
di una funzione così definita:
La seconda fase di ELECTRE II prevede la costruzione di due ordinamenti, ovvero una classificazione dall’alto
(dal migliore al peggiore classificato) e una dal basso (dal peggiore al migliore candidato).
Per quanto riguarda la classificazione dall’alto si procede iterativamente partendo dall’insieme di
alternative e estraendo di volta in volta quelle che non vengono surclassate in maniera forte dalle altre.
Così facendo le alternative estratte vanno ad occupare passo dopo passo i primi posti della graduatoria (in
ordine dal primo a scendere) e al passo successivo si esamina l’insieme delle alternative restanti.
In caso di posizione di ex aequo tra due o più alternative si ricorre ad un eventuale surclassamento di tipo
“debole” tra i progetti che risultano ex equo per capire se si possono riuscire a separare in posizioni
differenti.
Per quanto riguarda invece la classificazione dal basso il procedimento è analogo al precedente soltanto
che si selezionano le alternative che vengono surclassate in maniera forte dalle altre; il prima candidato
estratto verrà però posizionato all’ultimo posto in classifica e così via.
In caso di posizione di ex aequo tra due o più alternative si ricorre ad un eventuale surclassamento di tipo
“debole” per capire se si possono riuscire a separare in posizioni differenti.
Nel caso le due graduatorie non dovessero coincidere si può:
– considerare ad uno stesso livello o incomparabili alcune alternative.
– Valutare in posizionamento medio delle alternative sulla base delle due graduatorie ottenute e definire la
graduatoria finale in funzione del posizionamento medio.
IL MEDOTO ELECTRE III
La terza versione del metodo rappresenta il primo tentativo di surclassamento “sfumato” apparso in
letteratura e risale al 1978, sempre per opera del professore B. Roy. Viene qui modellizzato un cosiddetto
surclassamento sfumato o fuzzy nel senso che per ogni coppia di alternative confrontate non è espresso un
surclassamento certo oppure un non-surclassamento certo, bensì si associa una funzione δ(Pi, Pj) che
esprima il grado di credibilità della preferenza di Pi su Pj e che può variare nell’intervallo [0, 1]. Tale metodo
si distingue da ELECTRE II perché utilizza criteri di selezione per i quali ogni scarto di valutazione tra due
alternative non rappresenta necessariamente una preferenza netta.
L’analista deve disporre sia dei dati di base del problema di scelta (alternative, criteri e punteggi) che delle
preferenze del decisore, le quali si articolano in un peso e tre valori di soglia per ogni criterio. In questo
caso il decisore, al fine di modulare le preferenze, introduce le seguenti tre soglie per ognuno dei criteri di
selezione:
-Soglia di indifferenza Ik - esprime la differenza minima, tra i punteggi riportati dalle due alternative a
confronto sul criterio k, che il decisore considera significativa per attribuire una preferenza;
-Soglia di preferenza stretta Sk - esprime la differenza minima, tra i punteggi riportati dalle due alternative a
confronto sul criterio k, al di sopra della quale il decisore attribuisce significato in termini di preferenza
stretta, netta o marcata;
-Soglia di veto Vk - esprime la differenza minima, tra i punteggi riportati dalle due alternative a confronto
sul criterio k, oltre la quale il decisore ritiene eccessivo il divario tra i punteggi, tale da non essere più
compensato dalle prestazioni sugli altri criteri. Deve sempre accadere che Ik ≤ Sk ≤ Vk
PRINCIPIO DI CONCORDANZA: bisogna calcolare la matrice dei confronti tra due progetti Pi e Pj relativi ad
un criterio, calcolare la differenza dei punteggi fra questi due progetti e confrontare questa differenza con
le soglie precedenti: quando questa differenza è inferiore alla soglia di indifferenza il progetto Pi
surclassa il progetto Pj sul criterio k-esimo (questo va ripetuto per tutti i criteri), quando la differenza è tra
la soglia di indifferenza e la soglia di preferenza stretta il progetto Pi surclassa debolmente il progetto Pj sul
criterio k-esimo, quando invece la differenza è maggiore della soglia di preferenza stretta il progetto Pi non
surclassa il progetto Pj sul criterio k-esimo.
IL PRINCIPIO DI DISCORDANZA: nuovamente bisogna calcolare la differenza dei punteggi fra questi due
progetti e confrontare questa differenza con le soglie: quando la differenza è tra la preferenza e il veto la
preferenza del progetto Pj sul progetto Pi si oppone debolmente al surclassamento del progetto Pi rispetto
al progetto j, quando la differenza è maggiore della soglia di veto la preferenza del progetto Pj sul
progetto Pi si oppone in modo forte al surclassamento del progetto Pi rispetto al progetto j (quando siamo
oltre il veto discordiamo che i surclassa j.
Esempio:
Supponiamo che il nostro criterio k sia un criterio da massimizzare e che il decisore scelga i tre valori di
soglia Ik = 5%, Sk = 10% e Vk = 20%
-Questo significa che se la differenza i punteggi di due alternative sotto tale criterio è minore del 5%, allora
le due alternative saranno considerati indifferenti;
-Se, invece, la seconda alternativa ha un punteggio maggiore rispetto alla prima, in misura compreso tra il
5% e il 10%, allora questo secondo progetto è preferito debolmente rispetto al primo. Comunque se la
prima alternativa è preferibile rispetto agli altri criteri, potrebbe essere scelto come la migliore, vale cioè il
principio di compensazione;
-Mentre se la differenza di punteggi è compresa tra il 10% e il 20%, la preferenza della seconda rispetto alla
prima diventa stretta e si può dire in questo caso che esistono delle forti ragioni che si oppongono
all’affermazione che il primo progetto surclassi il secondo;
-Diversa è infine la situazione se le due alternative differiscono di una quantità superiore al 20%; in questo
caso, infatti, va esclusa l’ipotesi che la prima alternativa possa essere considerata migliore della seconda,
indipendentemente dai valori, per quanto buoni, degli indicatori sugli altri criteri. Non vale cioè in questo
ultimo caso il principio di compensazione.
prima fase
La prima fase di ELECTRE III
Step1:
ha inizio con il calcolo dell’ indice marginale di concordanza Ck(Pi, Pj), che esprime quantitativamente il
grado con cui si concorda sul fatto che il progetto Pi surclassi progetto Pj relativamente al criterio k.
Indicando con Ck(Pi) il punteggio riportato dal progetto Pi sul criterio k (che supponiamo abbia verso di
preferenza crescente), l’indice marginale di concordanza può assumere i seguenti valori: Se Ck(Pi) ≥ Ck(Pj)
allora risulta che Ck(Pi, Pj) = 1
Step2:
Dopo avere calcolato una matrice detta di concordanza per criterio , raccogliendo gli indici marginali di
concordanza relativi ad ogni confronto a coppia, possiamo valutare una sintesi della concordanza su tutti i
criteri. Ovvero si calcola per ogni coppia di alternative, il seguente indice di concordanza aggregata:
C(Pi, Pj) = Σ pk · Ck(Pi, Pj) Cioè la somma pesata degli indici marginali di concordanza Ck(Pi, Pj), dove con pk
si intende il peso del criterio k.
Step3: In maniera analoga è possibile calcolare l’indice marginale di discordanza Dk(Pi, Pj) sul criterio k
definito come segue:
Anche in questo caso analogamente a quanto detto sulla concordanza, possiamo costruire delle matrici di
discordanza per criterio.
Calcolati gli indici di concordanza aggregati e gli indici marginali di discordanza per ogni criterio, si passa
infine a calcolare il grado di credibilità del surclassamento δ(Pi, Pj), che non è altro che l ‘aggregazione dei
risultati degli esami di concordanza/discordanza. Tale indice serve a definire la matrice di credibilità dei
surclassamenti tra le alternative e viene calcolato nel seguente modo:
La seconda fase di ELECTRE III: Prevede la costruzione di due classificazioni, una dall’alto e l’altra dal
basso, similmente a quanto accade nella seconda versione del metodo, ovvero tramite un algoritmo
iterativo di distillazione che procede alla selezione dei progetti da disporre in graduatoria, fin quando
l’insieme delle alternative progettuali rimane vuoto.
Il primo passo da compiere è quello di determinare una soglia di
discriminazione s(δmax) che dipende dal massimo valore, indicato
con δmax, tra gli elementi della matrice di credibilità del
surclassamento.
La soglia di discriminazione rappresenta la differenza minima tra due valori di credibilità che il decisore
ritiene significativa. Essa varia linearmente con δmax secondo la formula s(δmax) = α · δmax + β dove i
coefficienti, nella maggior parte delle applicazioni, assumono i valori α = - 0,15 e β = 0,3. A questo punto si
può determinare il valore discriminante δ0 = δmax - s(δmax) che rappresenta il minimo valore al quale il
decisore assegna un significativo grado di credibilità del surclassamento e serve a costruire le classi di
preferenza.
A questo punto è necessario costruire una matrice che, tenendo conto dei vincoli imposti dalla soglia di
discriminazione, sintetizza le relazioni di surclassamento tra le alternative esprimendo con variabili
booleane il così detto surclassamento netto. La matrice del surclassamento netto è booleana T (a due
valori, 0 e 1) ed è costruita nel modo seguente:
Definiamo la qualificazione q(Pi) di un progetto Pi come la differenza tra il numero di progetti da esso
surclassati e il numero di progetti che lo surclassano; ovvero non è altro che la differenza tra la somma dei
valori di riga e la somma dei valori di colonna di Pi nella matrice T. Nella distillazione dall’alto la regola
utilizzata è quella di selezionare il progetto con più alto valore di qualificazione e posizionarlo al primo
posto della graduatoria. A questo punto il progetto appena selezionato viene eliminato dalla matrice di
credibilità e si procede iterativamente con gli altri progetti restanti posizionandoli di volta in volta nei
successivi posti in graduatoria. Ovviamente il procedimento si arresta non appena sono stati assegnati tutti
i progetti nella classifica dall�alto. Qualora accada che due progetti abbiano la stessa qualificazione e che
tale qualificazione sia la massima, dovremmo selezionare entrambi i progetti, ma in questi casi si effettua
una cosiddetta sottodistillazione, cioè si applica la medesima procedura di distillazione, partendo dalla
matrice di credibilità del surclassamento che contenga solo i due progetti in questione.
Nella distillazione dal basso il procedimento è identico al precedente con la differenza che la regola di
assegnazione prevede che vengano scelti i progetti con la minore qualificazione e che vengano assegnati i
posti dall’ultimo al primo (classificazione dal basso). La graduatoria finale risulta dalla intersezione delle due
distillazioni. In certi casi le due distillazioni potrebbero portare ad ordinamenti diversi, il che comporta che
progetti per i quali vi sia un conflitto nelle graduatorie vanno considerati incomparabili.
Il metodo ELECTRE TRI
Il metodo ELECTRE TRI, sviluppato da Yu (1992), Roy e Bouyssou (1993), nasce con l’intento di supportare il
decisore nei problemi riguardanti la classificazione delle alternative (cluster di alternative). è condizionata
ad interventi migliorativi. Nell’ ambito di questa problematica decisionale si vuole aiutare il decisore ad
emettere dei giudizi sull’attitudine di ogni specifico progetto a soddisfare determinati requisiti; è quindi il
valore intrinseco del progetto, rispetto ad un progetto alternativo di riferimento che identifica una soglia di
separazione tra le classi. Si effettuano quindi confronti a coppia tra ogni progetto candidato e ogni progetto
che rappresenti lo standard di riferimento al fine di determinare l’assegnazione alle classi.
I criteri con cui valutare i progetti e i coefficienti di importanza relativa da attribuire a questi criteri devono
essere definiti e modellizzati congiuntamente con il modello di riferimento da adottare nello specifico
problema di cernita. Il modello di riferimento può includere un insieme di profili di riferimento che
rappresentino i limiti teorici fra le categorie; tali profili non sono altro che combinazioni dei valori che i
progetti di riferimento assumono sulla famiglia di criteri considerati. Il numero delle classi di attribuzione
dei candidati può essere elevato e deve, comunque, essere definito contestualmente con la scelta della
procedura e dei suoi parametri. Le condizioni di coerenza dell’insieme di riferimento permettono la
definizione di categorie che sono sufficientemente distinte da impedire un’ attribuzione multipla di un
candidato a più di una classe. Molteplici possono essere gli elementi di conoscenza utilizzabili per la
definizione formale dei progetti di riferimento, ad esempio:
•Possono derivare da preesistenti modelli normativi e da standard, ad un buon livello di formalizzazione;
•Possono, invece scaturire da un modello elaborato localmente che, anche se non particolarmente
strutturato, potrebbe nascere da un’esperienza magari pluriennale.
•Possono essere definiti ad hoc dal DM
Le classi possono essere ordinate e corrispondere a raccomandazioni come:
-Ottimo;
- Buono;
- Discreto;
- Sufficiente;
- Scarso.
Nel caso di progetti tali classi possono essere definite come intervento assolutamente non rimandabile:
- molto urgente;
- urgente;
- non urgente, e così via.
Il metodo ELECTRE TRI è caratterizzato dall'ASSEGNAZIONE DI PROGETTI A CLASSI ORDINATE progetti a
classi ordinate, adottando profili di riferimento ordinati e non intersecati tra loro.
Il metodo si compone di due fasi:
-Fase 1: consiste nello stabilire una relazione di outranking tra progetti da selezionare e i progetti di
riferimento e tra i progetti di riferimento e i progetti da selezionare.
-Fase 2: prevede l'assegnazione di ogni progetto a una classe.
Topsis Technique for Order of Preference by Similarity to Ideal
Solution
Si basa sul concetto che si dovrebbe scegliere l’alternativa che presenta la distanza minore dalla soluzione
ideale migliore e la maggiore dalla soluzione ideale peggiore.
Metodo TOPSIS: dati di input - fase 1
FASE 1: I dati di input necessari per implementare il metodo sono:
-una matrice decisionale Gij = [gij]nm in cui le n righe sono le alternative ai, (i = 1, ..., n) e le m colonne sono
i criteri di valutazione cj (j = 1, ...,m). Il generico elemento gij di questa matrice rappresenta il punteggio
dell'alternativa ai rispetto al criterio cj.
-I pesi dei criteri (ottenuti, ad esempio, con il metodo AHP o con il metodo Delphi)
STEP 2: costruzione della matrice decisionale normalizzata utilizzando la seguente formula:
STEP 3: costruzione della matrice decisionale normalizzata ponderata utilizzando la seguente formula:
STEP 4: sono state individuate la soluzione ideale positiva (Azimut A*) e quella negativa (Nadir A-).
soluzione ideale:
Dove I' e I'' sono rispettivamente i criteri di beneficio e di costo.
STEP 5: calcolo delle relative distanze
STEP 6: calcolo del coefficiente relativo di vicinanza