Scarica l'edizione 5 del libro pm in russo. PMBOK, quinta edizione, riassunto. Organigrammi e job description

Globale standard

Istituto di gestione del progetto
UNA GUIDA AL CORPO DI GESTIONE DELLE CONOSCENZE
PROGETTI
(Guida PMBOK®) - Quinta edizione

ISBN 978-1-62825-008-4
Editore:
Project Management Institute, Inc.
Viale Campus 14
Newtown Square, Pennsylvania 19073-3299 USA
Telefono: +610-356-4600
Fax: +610-356-4647
Indirizzo email: [email protetta]
Internet: www.PMI.org
©2013 Project Management Institute, Inc. Tutti i diritti riservati.
"PMI", il logo PMI, "PMP", il logo PMP, "PMBOK", "PgMP", "Project Management Journal", "PM Network" e il logo PMI Today sono marchi registrati di Project Management Institute, Inc. "Quarter Globe Design" è un marchio di Project
Management Institute Inc. Un elenco completo dei marchi PMI è disponibile presso l'Ufficio legale di PMI.
Il Dipartimento Pubblicazioni PMI accetterà con gratitudine eventuali correzioni e commenti relativi alle pubblicazioni PMI. Segnala eventuali errori di battitura, errori di formattazione o altri errori visualizzati. Per fare ciò, fai semplicemente una copia della pagina desiderata, segna l'errore che hai notato su di essa e invia questa copia a:
Editore di libri, pubblicazioni PMI, 14 Campus Boulevard, Newtown Square, PA 19073-3299 USA.
Per informazioni sugli sconti per la rivendita o per uso didattico, contattare il PMI Book Service Center.
PMI Book Service Center
PO Box 932683, Atlanta, GA 31193-2683 USA
Telefono: 1-866-276-4764 (USA e Canada) o +1-770-280-4129 (altri paesi)
Fax: +1-770-280-4113
Indirizzo email: [email protetta]
Stampato negli Stati Uniti d'America. Nessuna parte di questo lavoro può essere riprodotta o trasmessa in qualsiasi forma o mezzo, sia elettronicamente, in forma scritta a mano, registrazione fotografica o audio, o utilizzando qualsiasi sistema di archiviazione e riproduzione delle informazioni, senza il preventivo consenso scritto dell'editore.
Questo documento è conforme allo US Permanent Paper Standard pubblicato dalla National Information Standards Organization, n. Z39.48-1984.
10 9 8 7 6 5 4 3 2 1
Record bibliografico della Biblioteca del Congresso degli Stati Uniti
Guida al Project Management Body of Knowledge (Guida PMBOK®). -- Quinta edizione.
vedi pagine
Include riferimenti bibliografici e indice alfabetico.
ISBN 978-1-62825-008-4 (copertina morbida)
1. Gestione del progetto. I. Istituto di Project Management. II. Titolo: Guida PMBOK.
HD69.P75G845 2013 658.4'04--dc23 2012046112
FSC LABEL.pdf 1 18/12/12 13:16

NOTIFICA
Pubblicato dal Project Management Institute, Inc., PMI in breve, gli standard e le linee guida, a cui appartiene questo documento, sono stati sviluppati attraverso un processo di sviluppo di standard volontario e basato sul consenso. Questo processo riunisce i volontari e/o riunisce i commenti e le opinioni di persone interessate all'argomento trattato in questa pubblicazione. Sebbene PMI gestisca questo processo e stabilisca regole per garantire che il consenso non sia distorto, PMI non scrive il documento né testa, valuta o verifica in modo indipendente l'accuratezza o la completezza del materiale contenuto negli standard e nelle linee guida pubblicate da PMI. Allo stesso modo, PMI non esamina la validità delle opinioni espresse in questi documenti.
PMI non sarà responsabile per eventuali lesioni, danni alla proprietà o qualsiasi altra perdita, speciale, consequenziale o esemplare, derivante direttamente o indirettamente dalla pubblicazione, dall'uso o dall'uso di questo documento. PMI non rilascia dichiarazioni o garanzie, esplicite o implicite, in merito all'accuratezza o alla completezza di qualsiasi materiale contenuto in questo documento e non rilascia dichiarazioni o garanzie che le informazioni contenute in questo documento soddisferanno i tuoi scopi o esigenze. . PMI non garantisce la qualità dei prodotti o servizi dei singoli produttori o fornitori derivanti dall'uso di questo standard o guida.
Nella pubblicazione e distribuzione di questo documento, PMI non fornisce servizi professionali o di altro tipo a o per conto di persone o entità; né PMI adempie agli obblighi di qualsiasi persona o entità nei confronti di terzi. Nell'utilizzare questo documento, l'utente di questo documento dovrebbe determinare da solo quale azione è necessaria nelle circostanze, basandosi esclusivamente sul proprio giudizio o, se necessario, sul consiglio di un professionista competente. Le informazioni relative all'argomento trattato dal presente documento o ai relativi standard possono essere ottenute da altre fonti, alle quali si rimanda per ulteriori informazioni non contenute nel presente documento.
PMI non ha autorità e non si assume alcun obbligo di monitorare la conformità delle pratiche esistenti al contenuto del presente documento o di allineare tali pratiche al presente documento. PMI non certifica, testa o ispeziona prodotti, progetti o progetti per il funzionamento sicuro o la sicurezza per la salute dei consumatori. Qualsiasi certificazione o altra affermazione di conformità a una qualsiasi delle informazioni sulla sicurezza o sulla salute contenute nel presente documento non può essere attribuita a PMI; in tal caso, la responsabilità è interamente a carico di chi ha rilasciato il certificato o ha fatto tale affermazione.

SOMMARIO
io
SOMMARIO
1. INTRODUZIONE............................................... .................................................. .................................uno
1.1 Scopo delle Linee guida PMBOK®
................................................................................................... 2
1.2 Che cos'è un progetto? .................................................. ................................................ .. ........3
1.2.1. Rapporti tra portfolio, programmi e progetti ................................................ ...............4
1.3 Che cos'è la gestione dei progetti? .................................................. ...................................5
1.4 Rapporti tra gestione del portafoglio, gestione del programma, governance
gestione del progetto e gestione del progetto organizzativo ................................................ .................. .....7
1.4.1 Gestione del programma ................................................. .. ................................................9
1.4.2 Gestione del portafoglio ............................................... ..................................................9
1.4.3 Progetti e pianificazione strategica ................................................ ................................... 10
1.4.4 Ufficio di gestione del progetto ................................................ ................................................... ... undici
1.5 Relazione tra project management, gestione delle operazioni
e strategia organizzativa ............................................... .................................................. ....... 12
1.5.1 Gestione delle operazioni
e gestione del progetto ............................................... ............................................. ... 12
1.5.2 Organizzazioni e gestione dei progetti ................................................ ......................................... 14
1.6 Valore aziendale ................................................. .................................................. ............................. 15
1.7 Il ruolo del project manager ................................................ ......................................................... ..... sedici
1.7.1 Responsabilità e competenze del project manager ............................................. ...... 17
1.7.2 Competenze interpersonali del project manager ................................................ ..... 17
1.8 Corpo di conoscenza della gestione del progetto ................................................ .................................................. diciotto
2. IMPATTO DELL'ORGANIZZAZIONE E DEL CICLO DI VITA DEL PROGETTO ................................................ ..................... .................. diciannove
2.1 Influenza dell'organizzazione sulla gestione del progetto ................................................ ................................................... venti
2.1.1 Culture e stili organizzativi ................................................ ................................................... venti
2.1.2 Comunicazioni organizzative ............................................... .................................................. 21
2.1.3 Strutture organizzative ................................................. .................................................. 21
2.1.4 Asset dei processi organizzativi ................................................ ................................................... 27
2.1.5 Fattori ambientali aziendali ................................................ ................................................... .. 29
2.2 Stakeholder e project management ................................................ ................. ......... trenta
2.2.1 Stakeholder del progetto ................................................ .................................................. trenta

SOMMARIO
II
©2013 Istituto di gestione dei progetti. Guida al Project Management Body of Knowledge (Guida PMBOK®) - Quinta edizione
2.2.2 Gestione del progetto ............................................... .. ................................................ ... 34
2.2.3 Successo del progetto ............................................... ............................................................. ............................. 35
2.3 Gruppo di progetto ............................................... ........................................................... ........................ 35
2.3.1 Composizione dei team di progetto ............................................... ......................................................... 37
2.4 Ciclo di vita del progetto ............................................... ................. ................................. ................ 38
2.4.1 Caratteristiche del ciclo di vita del progetto ............................. .................................. 38
2.4.2 Fasi del progetto ............................................... .. ................................................ ....... 41
3. PROCESSI DI GESTIONE DEL PROGETTO ................................................ .................................................. ........... 47
3.1 Interazioni comuni tra i processi di project management ................................................ ....................... .. 50
3.2 Gruppi di processi di gestione del progetto.................................. .................................................. 52
3.3 Gruppo di processo di avvio ................................................ ............................................................. ......... 54
3.4 Gruppo Processo di pianificazione ................................................ ............................................................. ......... 55
3.5 Gruppo processo di esecuzione ................................................ ............................................................. ........... 56
3.6 Gruppo di processi di monitoraggio e controllo ................................................ .................................................. 57
3.7 Gruppo di processi di chiusura ................................................ ................. ................................. .............. 57
3.8 Informazioni sul progetto ............................................... .................................................. ............... ..... 58
3.9 Il ruolo delle aree di conoscenza ................................................ ................................................... .................................. 60
4. GESTIONE DELL'INTEGRAZIONE DEL PROGETTO ................................................ ..................................................... .................. 63
4.1 Elaborazione di una carta di progetto ................................................. ....................................................... ........ 66
4.1.1 Elaborazione di una carta di progetto: input ............................................. ...................................... 68
4.1.2 Sviluppare una Carta del Progetto: Strumenti e Tecniche ................................................ ....... ... 71
4.1.3 Elaborazione di una carta di progetto: risultati ................................................ .................................................. 71
4.2 Elaborazione di un piano di gestione del progetto.............................................. ................................................... 72
4.2.1 Elaborazione di un piano di project management: input ............................................. ...................................... 74
4.2.2 Sviluppare un Piano di Project Management: Strumenti e Tecniche ............................. 76
4.2.3 Elaborazione di un piano di gestione del progetto: output ............................................. ...................... .... 76
4.3 Direzione e controllo del lavoro di progetto ................................................ .................................................. 79
4.3.1 Dirigere e gestire il project work: input ................................................ ..... 82
4.3.2 Direzione e controllo del lavoro progettuale: strumenti e metodi ............................. 83
4.3.3 Dirigere e gestire il project work: output ............................................. ...................... 84
4.4 Monitoraggio e controllo del lavoro a progetto ................................................ ................................... 86

SOMMARIO
III
©2013 Istituto di gestione dei progetti. Guida al Project Management Body of Knowledge (Guida PMBOK®) - Quinta edizione
4.4.1 Monitorare e controllare il lavoro di progetto: input ................................................ ...................................... 88
4.4.2 Monitoraggio e controllo del lavoro di progetto: strumenti e tecniche.................................... ............... 91
4.4.3 Monitoraggio e controllo del lavoro a progetto: output ............................. .......................92
4.5 Controllo integrato delle modifiche ................................................ ............................................................. ..... 94
4.5.1 Controllo integrato delle modifiche: input ................................................ .................. ........ 97
4.5.2 Controllo integrato del cambiamento: strumenti e tecniche ................................................ ...... 98
4.5.3 Controllo integrato delle modifiche: uscite ................................................ .................... ..... 99
4.6 Chiusura di un progetto o di una fase ................................................ ..................................................... ... cento
4.6.1 Chiusura di un progetto o di una fase: input ............................................. ...................................................... 102
4.6.2 Chiusura di un progetto o di una fase: strumenti e metodi ............................. ........ 102
4.6.3 Chiusura di un progetto o di una fase: output ............................................. .................................................. 103
5. GESTIONE DELL'AMBITO DEL PROGETTO .................................. ..................................................... ........... 105
5.1 Pianificazione per la gestione dei contenuti.................................. .................................................. 107
5.1.1 Pianificazione della gestione dei contenuti: input ................................................ .................... ... 108
5.1.2 Pianificazione della gestione dei contenuti: strumenti e tecniche............................ .......... 109
5.1.3 Pianificazione della gestione dei contenuti: output ................................................ .................. 109
5.2 Requisiti per la raccolta ............................................... ..................................................... .................... 110
5.2.1 Requisiti di raccolta: input ................................................ ................................................................... ................... 113
5.2.2 Requisiti per la raccolta: strumenti e tecniche................................................. ...................................... 114
5.2.3 Requisiti di raccolta: output ................................................ ................................................................... ..... 117
5.3 Definizione dei contenuti ................................................ ................................................................... ............... 120
5.3.1 Definizione del contenuto: input ................................................ ................................... 121
5.3.2 Definizione dell'ambito: strumenti e metodi ................................... ............................. .122
5.3.3 Determinazione del contenuto: output ............................................. ....................................... 123
5.4 Creazione di una WBS................................................. . ................................................. ................ 125
5.4.1 Creazione di una WBS: Input ................................................ ........................................................ ..... 127
5.4.2 Creazione di una WBS: strumenti e tecniche ............................................. ..................................... 128
5.4.3 Creazione di una WBS: output ............................................... ..................................................... .... 131
5.5 Conferma del contenuto ................................................ ................. ................................. ........ 133
5.5.1 Conferma del contenuto: input ................................................ .................................................. 134
5.5.2 Convalida dei contenuti: strumenti e tecniche ................................................ ..... 135

SOMMARIO
IV
©2013 Istituto di gestione dei progetti. Guida al Project Management Body of Knowledge (Guida PMBOK®) - Quinta edizione
5.5.3 Conferma dei contenuti: uscite ................................................ .................................................. 135
5.6 Controllo dei contenuti ............................................... ................................................... .................. .. 136
5.6.1 Controllo del contenuto: input .................................. .................................... 138
5.6.2 Controllo dei contenuti: strumenti e tecniche ................................................ ........ 139

Il 31 dicembre 2012, PMI ha rilasciato una nuova edizione della Project Management Body of Knowledge Guide (PMBOK® Guide - 5th Edition).

Gli specialisti di PMI nel rilascio della traduzione di PMBoK in russo promettono che questo lavoro sarà svolto entro la fine dell'anno e la comunità professionale russa sarà in grado di apprendere appieno tutte le novità e le sottigliezze della nuova edizione di PMBoK. Tenendo presente le lamentele sulla traduzione di PMBoK v.4, è meglio lasciare che la versione russa venga pubblicata in un secondo momento, ma poi lo faranno la sua qualità.

A giudicare dall'opinione degli esperti, il lungo periodo di lavoro è giustificato: è necessario spiegare molti nuovi termini, descrivere nuovi processi, chiarire la traduzione di vecchi termini e processi e armonizzare le traduzioni con altri standard rilasciati da PMI.

Cosa c'è di nuovo nel nuovo PMBOK 5?

La sezione X1 "Cambiamenti nella quinta edizione" ci dice proprio questo. Tra tutte le informazioni di carattere generale (quali “tutti i testi e la grafica del documento sono stati rivisti per rendere le informazioni più accurate, chiare, complete e aggiornate” oppure “è stato spostato in Appendice A1”), è utile anche:
1. Terminologia e armonizzazione

Gli autori affermano con orgoglio che tutta la terminologia è stata allineata al lessico PMI dei termini di gestione dei progetti. Allo stesso tempo, la terminologia del PMI Lexicon è considerata prioritaria. Se anche la traduzione di PMBOK 5 in russo inizia con la creazione della terminologia corretta, allora c'è la speranza di ottenere un corpus di conoscenze tradotto in modo competente.

Inoltre, PMBOK 5 è stato allineato allo standard ISO 21500:2012 "Guidance on project management" e all'armonizzazione di nomi, processi, input, output, strumenti e metodi con altri standard PMI (come "The Standard for Portfolio Management" , ecc.).

Alla fine, hanno smesso di mettere le persone in uno stato di torpore con il loro "rischio positivo". Dopotutto, cos'è il rischio? Questa è la possibilità di pericolo o fallimento! Il termine deriva dal greco risikon, cioè "scogliera" o "roccia". Ai tempi della grandezza e della potenza dell'Antica Grecia, "correre dei rischi" significava "affrontare una nave tra le rocce", cioè potenziale rischio di fallimento.

In PMBOK 5, sono state apportate modifiche alla descrizione della gestione del rischio di progetto e l'enfasi è stata spostata dal termine "rischio positivo" al termine "opportunità". Al testo sono stati aggiunti anche concetti come atteggiamento al rischio, propensione al rischio, tolleranza al rischio e soglie di rischio.

2. Successo del progetto

Poiché i progetti sono temporanei, il successo del progetto deve essere misurato in termini di completamento del progetto entro i limiti di ambito, tempo, costo, qualità, risorse e rischio.

Ma la dinamica dei cambiamenti nei requisiti nei progetti moderni è così alta che alla fine il progetto esce da tutte le restrizioni concepibili e inimmaginabili. Pertanto, gestire i requisiti in evoluzione, fissandoli nei documenti di progetto e rinegoziazione Le linee di base sono un'abilità sempre più richiesta dai project manager. Ciò si riflette nel PMBOK 5 nella frase "Il successo del progetto dovrebbe essere attribuito all'attuazione delle ultime linee di base approvate dalle parti interessate autorizzate". Non credo sia meglio dirlo. Se sei riuscito a concordare con il cliente sull'aumento dei termini e del budget del progetto due giorni prima della fine del progetto, il progetto ha successo, nonostante gli straordinari di 2 volte e l'aumento di 3 volte del budget.

3. Approcci di pianificazione alla gestione

In PMBOK 4, parte dei piani di supporto è apparsa dal nulla. Ad esempio, la descrizione dello Scope Management Plan è stata data direttamente nella descrizione dell'area di conoscenza “Project Scope Management” e non è indicato in quale processo viene creato. Sono stati aggiunti quattro nuovi processi di pianificazione: pianificazione della gestione dell'ambito, pianificazione della gestione della pianificazione, pianificazione della gestione dei costi e pianificazione della gestione delle parti interessate. Questo fornisce una guida chiara al team di progetto per pensare attivamente e pianificare approcci alla gestione di tutte le aree della conoscenza.

Anche se non senza i suoi difetti. Quindi due piani sono rimasti "senza supervisione": il piano di gestione del cambiamento e il piano di gestione della configurazione. È logico che il piano di gestione della configurazione venga visualizzato insieme al piano di gestione dei contenuti e il piano di gestione delle modifiche dovrebbe apparire durante lo sviluppo del piano di gestione del progetto generale, ma in PMBOK 5 ciò è solo implicito.

4. Requisiti

Il processo di raccolta dei requisiti è stato ampliato per concentrarsi sull'ottenimento di tutti i requisiti necessari per il successo del progetto.

Il processo di verifica dell'ambito è stato completamente riprogettato. Innanzitutto, è stato rinominato Validate Scope. In secondo luogo, è stato aggiunto l'accento sul fatto che questo processo non riguarda solo l'accettazione dei risultati, ma che i risultati saranno di valore per l'azienda e soddisferanno gli obiettivi del progetto.

È divertente, ma in PMBOK 4 c'era una traduzione non molto corretta di "Verify Scope", come "Conferma del contenuto". Ora questo porterà al fatto che in russo PMBOK 5 questo processo non cambierà il suo nome. Ti stai solo chiedendo come usciranno i traduttori traducendo la sezione sulle modifiche?

5. Guttaperca

In tutti i PMBOK passati combinati, la parola "agile" mai non è stato utilizzato. Nell'attuale PMBOK, si verifica fino a 10 volte.

PMI non ha mai nascosto il fatto che lo scopo principale delle Linee guida PMBOK è quello di evidenziare quella parte del Project Management Body of Knowledge che è generalmente considerata una buona pratica. Quelli. Le conoscenze e le pratiche descritte sono applicabili alla maggior parte dei progetti nella maggior parte dei casi e la corretta applicazione di queste abilità, strumenti e tecniche può aumentare le probabilità di successo per un'ampia gamma di progetti diversi.

Pertanto, il concetto di gestione agile del progetto è stato incluso nel processo di sviluppo della pianificazione del progetto.

Esatto, devi tenere il naso al vento! Questo è moderno sia alla moda che commercialmente richiesti.

6. Comunicazioni di progetto

L'ordine delle informazioni e delle conoscenze generate durante l'attuazione del progetto è in corso da tempo. Uno dei cambiamenti più rivoluzionari in PMBOK 5 è l'applicazione del modello DIKW (dati, informazioni, conoscenza, saggezza), una gerarchia di informazioni in cui ogni livello aggiunge determinate proprietà al livello precedente:

In fondo ci sono i dati.
Le informazioni aggiungono contesto.
La conoscenza aggiunge la risposta alla domanda "come?" (meccanismo di utilizzo).
La saggezza aggiunge la risposta alla domanda "quando?" (Condizioni d'uso).

Ciò è stato espresso in una chiara sequenza di raccolta, aggregazione ed elaborazione dei dati dai campi sotto forma dei seguenti documenti:

1. Dati sull'esecuzione del lavoro. Osservazioni e misurazioni "grezze" individuate nel corso del lavoro di progettazione.

2. Informazioni sull'esecuzione del lavoro. I dati sulle prestazioni lavorative vengono analizzati e integrati in base alle relazioni tra le diverse aree/fasi del progetto.

3. Rapporti sull'esecuzione del lavoro. Rappresentazione fisica o elettronica di informazioni sull'esecuzione del lavoro, destinate al processo decisionale, all'evidenziazione di problemi e problemi, alla generazione di azioni o alla comprensione della situazione.

Se aggiungiamo qui anche Lessons of Experience, il ciclo si chiude e tutte le conoscenze generate nel processo di implementazione del progetto verranno raccolte ed elaborate ed essere usato nella gestione di tutti i progetti nell'organizzazione.

Ebbene, e i processi che hanno confuso molti con l'offuscamento dei loro confini e la sequenza incomprensibile: "Diffusione delle informazioni" e "Preparazione dei rapporti di performance", sono stati rinominati, rispettivamente, in "Gestione delle comunicazioni" e "Controllo delle comunicazioni" con input logici e uscite.
7. Gestione degli "azionisti"

La gestione degli stakeholder è di grande importanza in PMBOK 5. Quasi tutte le sezioni sono state toccate per evidenziare meglio chi sono gli stakeholder del progetto e il loro impatto sul progetto. È stata aggiunta una nuova (10a) area di conoscenza, Project Stakeholder Management, che include due processi di Project Communications Management e sono stati aggiunti due nuovi processi.

Le ragioni principali di un tale germogliamento del campo della conoscenza nelle comunicazioni sono le seguenti:

1. Era necessaria una focalizzazione più chiara della gestione delle comunicazioni del progetto sulla pianificazione delle esigenze di comunicazione del progetto, sulla raccolta, sull'archiviazione e distribuzione informazioni nel progetto, oltre a monitorare le relazioni complessive del progetto per garantire la loro efficacia.

2. La vera gestione degli stakeholder include non solo l'analisi delle loro aspettative, il loro impatto sul progetto e lo sviluppo di strategie appropriate per gestirle, ma anche un dialogo continuo con interessati parti per soddisfare le loro esigenze e aspettative, risolvendo problemi come il loro verificarsi, e il coinvolgimento delle parti interessate nel processo decisionale e nelle attività di progetto.

3. La pianificazione e la gestione delle esigenze di comunicazione del progetto da un lato, e le esigenze degli stakeholder dall'altro, sono due chiavi diverse per il successo del progetto.

La separazione tra Project Stakeholder Management e Project Communications Management, oltre a risolvere i 3 problemi sopra descritti, assicura che PMBOK 5 sia in linea con le nuove tendenze in crescita nella gestione dei progetti e di grande interesse per ricercatori e project manager praticanti. all'interazione con gli stakeholder come una delle chiavi del successo complessivo del progetto. Queste tendenze si riflettono già in The Standard for Program Management e ISO 21500:2012 Guidance on project management. Quindi PMBOK ha recuperato il tempo perso.

Quindi, la nuova area di conoscenza include i processi:

Identificazione degli stakeholder.
Sviluppo di un Piano di Gestione degli Stakeholder.
Gestione del coinvolgimento degli stakeholder.
Controllo del coinvolgimento degli stakeholder.

8. "Competenze trasversali"

Aggiunta costruzione di fiducia, gestione dei conflitti alle abilità interpersonali e tutoraggio. Inoltre, è stata aggiunta una nuova sezione al Capitolo 1, Introduzione, che sottolinea l'importanza delle capacità interpersonali del project manager e rimanda il lettore all'Appendice X3 per una descrizione dettagliata di queste abilità.

9. Documentazione

Bene, e la cosa più importante per documentare il progetto: l'ordinamento generale dei documenti, iniziato in PMBOK 4, è continuato nel 5. Ora gli unici input per i processi sono i documenti che svolgono un ruolo chiave nell'esecuzione del processo. I documenti e la loro composizione sono diventati più chiari e specifici. Sebbene i nomi dei documenti stessi nel testo siano stati scritti ovunque con una piccola lettera, motivo per cui è difficile trovare visivamente i documenti nel testo e, per lavorare con i documenti, è necessario conoscere bene la terminologia PMBOK o utilizzare un pacchetto di modelli .

In generale, PMBOK 5 è diventato meglio strutturato, coerente, con normali relazioni tra processi, terminologia verificata

________________________________________________________________________________________________

1. INTRODUZIONE

2. IMPATTO ORGANIZZATIVO E CICLO DI VITA DEL PROGETTO

3. PROCESSI DI GESTIONE DEL PROGETTO

4. GESTIONE DELL'INTEGRAZIONE DEL PROGETTO

5. GESTIONE DELL'AMBITO DEL PROGETTO

6. GESTIONE DEL TEMPO DEL PROGETTO

7. GESTIONE DEI COSTI DEL PROGETTO

8. GESTIONE DELLA QUALITÀ DEL PROGETTO

9. PROGETTO GESTIONE DELLE RISORSE UMANE

10. GESTIONE DELLA COMUNICAZIONE DEL PROGETTO

11. GESTIONE DEL RISCHIO DEL PROGETTO

12. GESTIONE ACQUISTI DEL PROGETTO

13. GESTIONE DEGLI STAKEHOLDER

1. INTRODUZIONE

Progettoè un'impresa temporanea volta a creare un prodotto, servizio o risultato unico.

Il progetto può creare:

· Prodotto, che è un componente di un altro prodotto, un miglioramento di un prodotto o un prodotto finale;

· servizio o la capacità di fornire un servizio (ad esempio, una funzione aziendale che supporta la produzione o la distribuzione);

· miglioramento una linea esistente di prodotti o servizi (ad esempio, un progetto Six Sigma intrapreso per ridurre i difetti);

· risultato, come un risultato finale o un documento (ad esempio, un progetto di ricerca apporta nuove conoscenze che possono essere utilizzate per determinare se esiste una tendenza o un vantaggio per un nuovo processo per la società).

Gestione del progettoè l'applicazione di conoscenze, abilità, strumenti e metodi al progetto di lavoro per soddisfare i requisiti del progetto. Il progetto viene gestito attraverso la corretta applicazione e integrazione di 47 processi di project management raggruppati logicamente in 5 gruppi di processi.

Questi 5 gruppi di processi sono i seguenti:

iniziazione,

pianificazione,

l'esecuzione,

Monitoraggio e controllo

chiusura.

Restrizioni del progetto:

· qualità,

· orario,

il budget

le risorse

A causa del potenziale di cambiamento, lo sviluppo di un piano di gestione del progetto è iterativo e passa attraverso perfezionamenti successivi in ​​varie fasi del ciclo di vita del progetto. Il perfezionamento progressivo consente al team di gestione del progetto di definire l'ambito di lavoro e di gestirlo a un livello più dettagliato man mano che il progetto si evolve.

Programma- un insieme di progetti correlati, sottoprogrammi e attività di un programma che sono gestiti in modo coordinato per ottenere benefici che non sarebbero disponibili se fossero gestiti separatamente. I programmi possono contenere elementi di lavoro ad essi correlati, ma che esulano dall'ambito dei singoli progetti del programma. Un progetto può o non può far parte di un programma, ma un programma contiene sempre progetti.

Gestione del programma- l'applicazione di conoscenze, abilità, strumenti e metodi al programma per soddisfare i requisiti del programma e ottenere benefici e controlli che non sarebbero disponibili nella gestione separata dei progetti.

I progetti all'interno di un programma sono collegati attraverso un risultato finale comune o un'opportunità condivisa. Se il collegamento tra i progetti è solo un cliente, un fornitore, una tecnologia o una risorsa comune, lo sforzo dovrebbe essere gestito come un portafoglio di progetti, non come un programma.

La gestione del programma si concentra sulle interdipendenze dei progetti e aiuta a determinare l'approccio migliore per gestirle.

Un esempio di programma è un nuovo sistema di comunicazione satellitare con progetti per progettare le stazioni satellitari e satellitari terrestri, costruire ciascuna di esse, integrare il sistema e lanciare il satellite.

Valigettaè un insieme di progetti, programmi, sottoportfolio ed elementi di operazioni gestiti in gruppo al fine di raggiungere obiettivi strategici. I programmi sono raggruppati all'interno del portafoglio e sono costituiti da sottoprogrammi, progetti e altre attività gestite in modo coordinato a sostegno del portafoglio. I singoli progetti che sono all'interno o all'esterno del programma sono ugualmente considerati parte del portafoglio. Sebbene non siano necessariamente interdipendenti o direttamente correlati, i progetti oi programmi in un portfolio sono collegati al piano strategico di un'organizzazione attraverso il portfolio dell'organizzazione.

Gestione del portafoglio- gestione centralizzata di uno o più portafogli per il raggiungimento di obiettivi strategici. La gestione del portafoglio si concentra sulla fornitura di analisi di progetti e programmi per dare priorità all'allocazione delle risorse e allineare e allineare la gestione del portafoglio con le strategie dell'organizzazione.

Ufficio di gestione dei progetti (PMO)- una struttura organizzativa che standardizzi i processi di project management e faciliti lo scambio di risorse, metodologie, strumenti e metodi. Le responsabilità del PMO possono variare dal fornire supporto per la gestione dei progetti alla gestione diretta di uno o più progetti.

Esistono diversi tipi di strutture PMO nelle organizzazioni, ognuna delle quali differisce per il grado di controllo e influenza esercitati sui progetti all'interno dell'organizzazione, vale a dire:

· supporto. Il supporto dei PMO svolge un ruolo consultivo fornendo modelli, migliori pratiche, formazione, accesso alle informazioni e lezioni apprese da altri progetti. Questo tipo di PMO funge da repository di progetto. Il grado di controllo da parte del PMO è basso.

· controllare. Il controllo dei PMO fornisce supporto e richiede la conformità attraverso una varietà di mezzi. La conformità può comportare l'adeguamento delle strutture o metodologie di gestione del progetto, l'uso di modelli, moduli e strumenti specifici o il rispetto dei requisiti di gestione. Il grado di controllo da parte del PMO è medio.

· guida. I principali PMO controllano i progetti gestendo direttamente tali progetti. Il grado di controllo da parte del PMO è elevato.

La funzione principale del PMO è supportare i project manager in vari modi, che possono includere ma non sono limitati a:

· gestire le risorse comuni di tutti i progetti amministrati dal PMO;

· definizione e sviluppo di metodologia, best practices e standard per la gestione dei progetti;

coaching, tutoraggio, formazione e supervisione;

monitorare la conformità con gli standard, le politiche, le procedure e i modelli di gestione del progetto attraverso audit di progetto;

sviluppo e gestione di politiche, procedure, modelli di progetto e altra documentazione comune (asset dei processi organizzativi);

Coordinare le comunicazioni tra i progetti.

I project manager e i PMO hanno obiettivi diversi e quindi hanno requisiti diversi. Tutte le loro azioni sono allineate con gli interessi strategici dell'organizzazione. La differenza tra il ruolo del project manager e il PMO può essere la seguente:

· Il project manager si concentra su obiettivi specifici del progetto, mentre il PMO gestisce i principali cambiamenti nel contenuto del programma e può vederli come potenziali opportunità per raggiungere meglio gli obiettivi aziendali.

· Il project manager controlla le risorse assegnate al progetto al fine di soddisfare in modo più accurato gli obiettivi del progetto e il PMO ottimizza l'uso delle risorse totali dell'organizzazione in tutti i progetti.

· Il project manager gestisce i vincoli (ambito, pianificazione, costi e qualità, ecc.) dei singoli progetti, mentre il PMO gestisce metodologie, standard, rischi/opportunità condivisi, metriche e interdipendenze di progetto a livello aziendale.

Attività operativeè un'attività continua che produce risultati ripetitivi, con risorse allocate per svolgere un insieme di compiti sostanzialmente simili in conformità con gli standard incorporati nel ciclo di vita del prodotto. A differenza delle operazioni, che sono permanenti, i progetti sono attività temporanee.

Gestione delle operazioniè la supervisione, direzione e controllo delle operazioni aziendali. Le operazioni sono utilizzate per supportare le attività quotidiane e sono necessarie per raggiungere gli obiettivi strategici e tattici dell'organizzazione. Gli esempi includono: operazioni di produzione, operazioni di produzione, operazioni di contabilità, supporto software e manutenzione.

Valore aziendale- un concetto unico per ogni organizzazione. Il valore aziendale è definito come il valore totale di un'organizzazione, la somma totale di tutti gli elementi materiali e immateriali. Esempi di elementi tangibili sono le attività monetarie, le immobilizzazioni, il patrimonio netto e le comunicazioni. Esempi di elementi immateriali includono reputazione, consapevolezza del marchio, bene pubblico e marchi. A seconda dell'organizzazione, il contenuto del valore aziendale può essere a breve, medio e lungo termine. Il valore può essere creato gestendo efficacemente le operazioni quotidiane. Tuttavia, attraverso l'applicazione efficace delle discipline di gestione di progetti, programmi e portafogli, le organizzazioni acquisiscono la capacità di applicare processi solidi e riconosciuti per raggiungere obiettivi strategici e trarre un maggiore valore aziendale dai loro investimenti nei progetti.

Responsabile del progetto- una persona nominata dall'organizzazione performativa alla guida del gruppo e responsabile del raggiungimento degli obiettivi del progetto.

Il ruolo di un project manager è diverso da quello di un manager funzionale o di un manager delle operazioni. In genere, il manager funzionale si concentra sulla supervisione dell'unità funzionale o aziendale, mentre i responsabili delle operazioni sono responsabili di garantire l'efficacia delle operazioni aziendali.

Competenze del PR:

· Competenze di conoscenza- cosa sa il manager sulla gestione del progetto.

· Competenze in esecuzione- cosa è in grado di fare o ottenere il project manager applicando le sue conoscenze di project management.

· Competenze personali- come si comporta il project manager durante l'esecuzione del progetto o delle attività connesse. Le prestazioni personali comprendono atteggiamenti, caratteristiche fondamentali della personalità e qualità di leadership: la capacità di guidare il team di progetto nel raggiungimento degli obiettivi del progetto e nel bilanciare i vincoli del progetto.

Abilità RP:

comando,

rafforzare la squadra

motivazione,

comunicazione,

· influenza,

· prendere decisioni,

consapevolezza politica e culturale,

· trattativa,

Costruire relazioni di fiducia

risoluzione del conflitto,

istruire.

2. IMPATTO ORGANIZZATIVO E CICLO DI VITA DEL PROGETTO

Risorse del processo organizzativo sono i piani, i processi, le politiche, le procedure e le basi di conoscenza specifiche e utilizzate dall'organizzazione performante. Includono qualsiasi artefatto, metodo e conoscenza di alcune o tutte le organizzazioni coinvolte nel progetto che possono essere utilizzate per eseguire o dirigere il progetto. Inoltre, le risorse di processo includono le basi di conoscenza dell'organizzazione, come le lezioni apprese e le informazioni storiche. Le risorse di processo di un'organizzazione possono includere pianificazioni completate, dati sui rischi e dati sul valore realizzato. Le risorse dei processi organizzativi sono input per la maggior parte dei processi di pianificazione. Durante tutto il progetto, i membri del team possono aggiornare e aggiungere risorse ai processi dell'organizzazione secondo necessità. Gli asset dei processi organizzativi possono essere suddivisi in due categorie:

processi e procedure

base di conoscenza aziendale

I fattori ambientali dell'impresa variano ampiamente per tipo o natura. I fattori ambientali dell'impresa includono, ma non sono limitati a:

cultura organizzativa, struttura e leadership;

• distribuzione geografica di attrezzature e risorse;

· standard governativi e di settore (es. regolamenti, codici di condotta, standard di prodotto, standard di qualità, standard di produzione);

Infrastrutture (ad es. strutture esistenti e attrezzature principali);

• risorse umane disponibili (es. competenze, conoscenze, specializzazioni quali progettazione, sviluppo, legale, appalti e appalti);

· gestione del personale (ad esempio, linee guida per assunzioni e licenziamenti, analisi delle prestazioni e registri di formazione del personale, politiche di remunerazione e straordinari, monitoraggio del tempo);

la situazione del mercato;

tolleranza al rischio degli stakeholder;

il clima politico;

canali di comunicazione adottati nell'organizzazione;

· banche dati commerciali (es. stime dei costi standardizzate, studi sui rischi industriali e banche dati sui rischi);

· sistema informativo per la gestione del progetto (ad esempio, sistemi automatizzati come software di gestione della pianificazione, sistema di gestione della configurazione, sistema di raccolta e distribuzione delle informazioni o interfacce web con altri sistemi automatizzati online).

I membri del team di progetto svolgono i seguenti ruoli:

· Personale responsabile della gestione del progetto. Membri del team che svolgono attività di gestione del progetto come pianificazione, budgeting, reporting e controllo, comunicazioni, gestione del rischio e supporto amministrativo. Questa funzione può essere eseguita o supportata da un Project Management Office (PMO).

· Personale di progetto. Membri del team che svolgono il lavoro di creazione dei risultati finali del progetto.

· Esperti di supporto. Gli esperti di supporto svolgono le attività necessarie per sviluppare o eseguire il piano di gestione del progetto. Ciò può includere appalti, gestione finanziaria, logistica, supporto legale, sicurezza, sviluppo, test o controllo di qualità. A seconda delle dimensioni del progetto e del livello di supporto richiesto, gli esperti di supporto possono lavorare a tempo pieno o semplicemente far parte del team quando sono richieste le loro competenze specifiche.

· Rappresentanti di utenti o clienti. I membri dell'organizzazione che accetteranno i risultati oi prodotti del progetto possono agire come portavoce o intermediari per garantire un coordinamento adeguato, consulenza sui requisiti o convalida dei risultati del progetto.

· Venditori. I fornitori, indicati anche come agenti, fornitori o appaltatori, sono società di terze parti che hanno stipulato un contratto per fornire componenti o servizi necessari per un progetto. Il team di progetto è spesso responsabile della supervisione dell'esecuzione e dell'accettazione dei risultati o dei servizi del fornitore. Se i fornitori sopportano una quantità significativa di rischio nella consegna dei risultati del progetto, possono svolgere un ruolo importante nel team di progetto.

· Membri di organizzazioni partner commerciali. I membri delle organizzazioni partner commerciali possono essere assegnati al team di progetto per garantire un coordinamento adeguato.

· Soci in affari. I partner commerciali sono anche società terze, ma hanno un rapporto speciale con l'impresa, a volte acquisito attraverso un processo di certificazione. I Business Partner forniscono assistenza di esperti specializzati o svolgono un ruolo loro assegnato, come installazione, personalizzazione, formazione o supporto.

Ciclo di vita del progetto- un insieme di fasi attraverso le quali il progetto passa dal momento del suo avvio al momento della chiusura.

Tutti i progetti possono avere la seguente struttura del ciclo di vita:

inizio del progetto;

organizzazione e preparazione;

Esecuzione del lavoro a progetto;

completamento del progetto.

Fase di progetto- un insieme di attività progettuali logicamente correlate, che culminano nel raggiungimento di uno o più risultati raggiunti.

Cicli di vita predittivi(noto anche come completamente pianificato) è un tipo di ciclo di vita del progetto in cui l'ambito del progetto e il tempo e il costo necessari per completarlo sono determinati il ​​più presto possibile nel ciclo di vita.

Cicli di vita iterativi e incrementali sono cicli di vita in cui le fasi del progetto (chiamate anche iterazioni) ripetono intenzionalmente una o più attività del progetto man mano che il team di progetto acquisisce una migliore comprensione del prodotto. Iterativo definisce lo sviluppo di un prodotto attraverso una serie di cicli iterativi, mentre l'incrementalità definisce la crescita incrementale delle funzionalità di un prodotto. Durante questi cicli di vita, il prodotto viene sviluppato sia in modo iterativo che incrementale.

Cicli di vita adattivi(note anche come pratiche agili o orientate al cambiamento) mirano a rispondere a livelli elevati di cambiamento e richiedono un elevato grado di coinvolgimento degli stakeholder in ogni momento. I metodi adattivi sono anche iterativi e incrementali, ma differiscono in quanto le iterazioni sono molto veloci (la durata è in genere di 2-4 settimane) e sono fisse in termini di tempo e costi. I progetti agili in genere eseguono più processi durante ogni iterazione, sebbene le prime iterazioni possano concentrarsi maggiormente sulle operazioni di pianificazione. L'ambito generale del progetto è suddiviso in una serie di requisiti e il lavoro da svolgere è talvolta chiamato backlog (registro dei requisiti). All'inizio di un'iterazione, il team determina quanti elementi di backlog ad alta priorità possono essere ottenuti durante l'iterazione successiva. Al termine di ogni iterazione, il prodotto dovrebbe essere pronto per la revisione da parte del cliente.

3. PROCESSI DI GESTIONE DEL PROGETTO

Gestione del progettoè l'applicazione di conoscenze, abilità, strumenti e metodi al progetto di lavoro per soddisfare i requisiti del progetto. Questa applicazione della conoscenza richiede una gestione efficace dei processi di project management.

Processiè un insieme di azioni e operazioni correlate eseguite per creare un prodotto, servizio o risultato predeterminato. Ogni processo è caratterizzato dai suoi input, strumenti e metodi che possono essere applicati, nonché dai risultati che ne derivano.

I processi di progetto possono essere suddivisi in due categorie principali:

· Processi di gestione del progetto. Questi processi garantiscono l'efficace esecuzione del progetto durante il suo ciclo di vita. Questi processi riguardano gli strumenti e le tecniche associati all'applicazione delle abilità e delle capacità descritte nelle aree di conoscenza.

· Processi orientati al prodotto. Questi processi definiscono e creano il prodotto del progetto. I processi orientati al prodotto sono generalmente definiti dal ciclo di vita del progetto e variano in base all'area di applicazione e alla fase del ciclo di vita del prodotto. L'ambito di un progetto non può essere determinato senza una conoscenza di base di come creare un determinato prodotto. Ad esempio, nel determinare la complessità totale di un edificio da costruire, dovrebbe essere considerata una varietà di tecnologie e strumenti di costruzione.

I processi di gestione dei progetti rientrano in cinque categorie, note come gruppi di processi di gestione dei progetti (o gruppi di processi):

· Gruppo processo di avvio. Processi eseguiti per definire un nuovo progetto o una nuova fase di un progetto esistente ottenendo l'autorizzazione ad avviare il progetto o la fase.

· Gruppo del processo di pianificazione. I processi necessari per stabilire l'ambito del lavoro, chiarire gli obiettivi e determinare il corso d'azione richiesto per raggiungere gli obiettivi del progetto.

· Gruppo processo di esecuzione. I processi utilizzati per eseguire il lavoro specificato nel piano di gestione del progetto per soddisfare le specifiche del progetto.

· Gruppo di processi di monitoraggio e controllo. Processi necessari per tracciare, analizzare e regolare le prestazioni del progetto; identificare le aree che richiedono modifiche al piano; e l'avvio di modifiche appropriate.

· Gruppo di processi di chiusura. Processi eseguiti per completare tutte le attività all'interno di tutti i gruppi di processi al fine di chiudere formalmente un progetto o una fase.

I gruppi di processi non sono fasi del ciclo di vita del progetto!

Come parte del ciclo di vita del progetto, una quantità significativa di dati e informazioni in vari formati viene raccolta, analizzata, trasformata e divulgata ai membri del team di progetto e ad altre parti interessate. I dati del progetto vengono raccolti come risultato di vari processi di esecuzione, dopodiché vengono forniti ai membri del team di progetto.

Le seguenti linee guida riducono al minimo le incomprensioni e aiutano il team di progetto a utilizzare la terminologia corretta:

· Dati sulle prestazioni lavorative. Osservazioni e misurazioni grezze identificate durante le operazioni intraprese per lo svolgimento delle attività progettuali. Gli esempi includono percentuali di lavoro fisicamente completato, misure di qualità e prestazioni tecniche, date di inizio e fine delle attività programmate, numero di richieste di modifica, numero di difetti, costo effettivo, durata effettiva e così via.

· Informazioni sull'esecuzione del lavoro. Dati sulle prestazioni raccolti attraverso vari processi di controllo, analizzati nel contesto e sintetizzati sulla base di collegamenti in diverse aree. Esempi di informazioni sulle prestazioni includono lo stato dei risultati finali, lo stato di implementazione delle richieste di modifica e la valutazione delle previsioni fino al completamento.

· Rapporti sulle prestazioni lavorative. Una rappresentazione fisica o elettronica delle informazioni sulle prestazioni lavorative raccolte nei documenti di progetto, destinate a prendere decisioni o formulare problemi, intraprendere azioni o creare consapevolezza. Gli esempi includono rapporti sullo stato, promemoria, giustificazioni, newsletter, dashboard elettronici, consigli e aggiornamenti.

I 47 processi di gestione dei progetti descritti nella Guida PMBOK sono suddivisi in 10 distinte aree di conoscenza. Un'area di conoscenza è un sistema completo di concetti, termini e attività che costituiscono un'area professionale, un'area di gestione dei progetti o un campo di attività. Queste 10 aree di conoscenza sono quasi sempre utilizzate nella maggior parte dei progetti. I team di progetto dovrebbero utilizzare queste 10 aree di conoscenza e altre aree di conoscenza secondo necessità per il loro progetto specifico. Le aree di competenza includono:

Gestione dell'integrazione del progetto

Gestione dei contenuti del progetto

gestione del tempo del progetto,

gestione dei costi del progetto,

Gestione della qualità del progetto

Gestione delle risorse umane del progetto

Gestione della comunicazione del progetto

Gestione del rischio di progetto

Gestione degli appalti di progetto

gestione degli stakeholder del progetto.

4. GESTIONE DELL'INTEGRAZIONE DEL PROGETTO

La gestione dell'integrazione del progetto include i processi e le attività necessari per definire, perfezionare, combinare, combinare e coordinare i vari processi e attività di gestione del progetto all'interno dei gruppi di processi di gestione del progetto.

La carta del progetto contiene:

Scopo o giustificazione del progetto;

obiettivi di progetto misurabili e relativi criteri di successo;

Requisiti di alto livello

· Assunzioni e restrizioni;

Descrizione e confini di alto livello del progetto;

Rischi di alto livello

programma ampliato degli eventi di controllo;

Il bilancio allargato

un elenco delle parti interessate;

· requisiti per l'approvazione del progetto (ovvero cosa costituisce esattamente il successo del progetto, chi decide che il progetto ha avuto successo e chi firma il progetto);

Responsabile di progetto nominato, area di responsabilità e livello di autorità;

· NOME E COGNOME. e l'autorità dello sponsor o di altre persone che autorizzano la carta del progetto.

Descrizione delle opere(dichiarazione di lavoro, SOW) di un progetto è una descrizione verbale dei prodotti, servizi o risultati che il progetto deve produrre.

SOW riflette:

· Esigenza aziendale. Le esigenze aziendali di un'organizzazione possono basarsi sulla domanda del mercato, sui progressi tecnologici, sui requisiti legali, sulle normative governative o su considerazioni ambientali. Tipicamente, un'esigenza aziendale e un confronto costi-benefici sono inclusi nel business case per giustificare il progetto.

· Descrizione del contenuto del prodotto. La descrizione dell'ambito del prodotto include le caratteristiche del prodotto, servizio o risultato che il progetto sta tentando di creare. La descrizione dovrebbe anche riflettere la relazione tra i prodotti, i servizi oi risultati che vengono creati e l'esigenza aziendale che il progetto intende soddisfare.

· Piano strategico. Il piano strategico include la visione strategica, gli obiettivi e gli obiettivi dell'organizzazione e una dichiarazione di intenti di alto livello. Tutti i progetti devono essere allineati con il piano strategico dell'organizzazione. L'allineamento con il piano strategico consente a ciascun progetto di contribuire agli obiettivi generali dell'organizzazione.

Caso aziendale

Un business case o un documento simile fornisce le informazioni commerciali necessarie per determinare se un progetto vale l'investimento richiesto. È comunemente usato dai superiori in relazione al progetto per prendere decisioni. Tipicamente, un business case contiene un'esigenza aziendale e un'analisi comparativa costi-benefici per giustificare il progetto e definirne i confini, e questa analisi viene solitamente eseguita da un analista aziendale utilizzando varie informazioni ricevute dalle parti interessate. Lo sponsor deve concordare il contenuto e le limitazioni del business case. Un business case viene creato a seguito di uno o più dei seguenti fattori:

una domanda del mercato (ad esempio, una casa automobilistica autorizza un progetto per realizzare automobili più efficienti in termini di consumo di carburante in risposta a una carenza di benzina);

la necessità dell'organizzazione (ad esempio, a causa degli elevati costi generali, l'azienda può combinare le funzioni del personale e ottimizzare i processi per ridurre i costi);

· richiesta del cliente (ad esempio, un'azienda elettrica autorizza un progetto per la realizzazione di una nuova sottostazione per fornire energia elettrica a una nuova area industriale);

· progresso tecnologico (ad esempio, una compagnia aerea autorizza un nuovo progetto per lo sviluppo di biglietti elettronici in sostituzione dei biglietti cartacei basati sui progressi tecnologici);

· un requisito legale (ad esempio, un produttore di vernici autorizza un progetto per lo sviluppo di linee guida per la manipolazione di materiali tossici);

· impatti ambientali (ad esempio, un'azienda autorizza un progetto per ridurne l'impatto ambientale);

· un'esigenza sociale (ad esempio, una ONG in un paese in via di sviluppo autorizza un progetto per fornire acqua potabile, servizi igienici ed educazione sanitaria alle comunità che soffrono di alti livelli di casi di colera).

Accordi

Gli accordi vengono utilizzati per definire le intenzioni iniziali di un progetto. Gli accordi possono assumere la forma di contratto, memorandum d'intesa, accordo sul livello di servizio, lettera di accordo, lettera di intenti, accordo orale, e-mail o altro accordo scritto. Tipicamente, il contratto viene utilizzato se il progetto viene eseguito per un cliente esterno.

Fattori ambientali aziendali

I fattori ambientali dell'impresa che possono influenzare il processo di sviluppo della carta del progetto includono, ma non sono limitati a:

· norme o regolamenti governativi e di settore (ad es. codici di condotta, standard di qualità o standard di protezione dei lavoratori);

cultura e struttura organizzativa;

la situazione del mercato.

Risorse del processo organizzativo

Le risorse del processo organizzativo che possono influenzare il processo di sviluppo della carta del progetto includono, ma non sono limitate a:

processi organizzativi standard, politiche e descrizioni dei processi;

Modelli (ad esempio, un modello di carta di progetto)

informazioni storiche e base di conoscenze (ad esempio, progetti, registrazioni e documenti, tutte le informazioni e la documentazione sulla chiusura del progetto, informazioni sui risultati di precedenti decisioni di selezione dei progetti insieme a informazioni sulla performance di progetti precedenti e informazioni sulle operazioni di gestione del rischio).

Piano di gestione del progettoè un documento che descrive come verrà eseguito il progetto, come sarà monitorato e controllato. Integra e consolida tutti i sottopiani e le linee di base risultanti dai processi di pianificazione.

I piani di base del progetto includono, tra gli altri:

Piano di contenuti di base

orario di base;

piano dei costi di base.

I piani accessori includono ma non sono limitati a:

piano di gestione dei contenuti

Piano di gestione dei requisiti

piano di gestione del programma

Piano di gestione dei costi

un piano di gestione della qualità;

Piano di miglioramento del processo

· piano di gestione delle risorse umane;

un piano di gestione delle comunicazioni;

· piano di gestione del rischio;

Piano di gestione degli appalti

· Piano di gestione degli stakeholder.

Tra le altre cose, il piano di gestione del progetto può includere anche quanto segue:

· il ciclo di vita selezionato per il progetto ei processi che verranno applicati in ciascuna fase;

Dettagli delle decisioni di personalizzazione prese dal team di gestione del progetto, vale a dire:

o Processi di gestione del progetto selezionati dal team di gestione del progetto;

o il livello di attuazione di ciascun processo selezionato;

o descrizioni degli strumenti e dei metodi che verranno utilizzati per l'esecuzione di tali processi;

o Una descrizione di come i processi selezionati verranno utilizzati per gestire un progetto specifico, comprese le dipendenze e le interazioni tra questi processi, nonché gli input e gli output richiesti.

la procedura per eseguire il lavoro per raggiungere gli obiettivi del progetto;

un piano di gestione delle modifiche che documenta il modo in cui le modifiche vengono monitorate e controllate;

un piano di gestione della configurazione che documenta come viene gestita la configurazione;

descrizione della procedura per mantenere l'integrità dei piani di base;

· requisiti e modalità di comunicazione tra le parti interessate;

· attività di revisione della direzione chiave in merito a contenuto, confini e tempi per affrontare i problemi esistenti e le soluzioni in sospeso.

Previsioni di pianificazione

Le previsioni di pianificazione si basano sull'avanzamento rispetto alla pianificazione di base e sul tempo di completamento previsto (ETC). Di solito sono espressi come una deviazione temporale (RTD) e un indice di prestazione temporale (TDI). Per i progetti che non utilizzano la gestione del valore realizzato, vengono indicati gli scostamenti dalle date di fine pianificate e previste.

La previsione può essere utilizzata per determinare se un progetto rientra nell'intervallo di tolleranza e identificare le richieste di modifica necessarie.

Previsioni sui costi

Le proiezioni dei costi si basano sull'avanzamento rispetto al piano dei costi di base e sulla previsione di completamento (CPC) stimata. Di solito sono espressi come una varianza dei costi (CVA) e un indice di performance dei costi (CFI). Il Forecast-on-Completion (PCF) può essere confrontato con il Budget-on-Completion (BPC) per determinare se un progetto rientra nella tolleranza o se è necessario presentare richieste di modifica. Per i progetti che non utilizzano la gestione del valore realizzato, vengono forniti gli scostamenti dai costi pianificati ed effettivi, nonché il costo finale previsto.

Di seguito sono elencate alcune delle attività di gestione della configurazione incluse nel processo di controllo integrato delle modifiche:

· Definizione della configurazione. Definire e selezionare gli elementi di configurazione per fornire una base da cui la configurazione del prodotto viene definita e convalidata, i prodotti ei documenti vengono contrassegnati, le modifiche vengono gestite e contabilizzate.

· Report sullo stato della configurazione. Laddove sia necessario fornire informazioni pertinenti su un elemento di configurazione, le informazioni vengono documentate e riportate. Tali informazioni includono un elenco di elementi di configurazione approvati identificati, lo stato delle modifiche alla configurazione proposte e lo stato di implementazione delle modifiche approvate.

· Convalida e verifica la configurazione. La convalida della configurazione e gli audit assicurano che la struttura degli elementi di configurazione del progetto sia corretta e che le modifiche corrispondenti siano registrate, valutate, approvate, tracciate e implementate correttamente. Ciò garantisce che i requisiti funzionali definiti nella documentazione di configurazione siano soddisfatti.

5. GESTIONE DELL'AMBITO DEL PROGETTO

Project Scope Management include i processi necessari per garantire che un progetto contenga tutto e solo il lavoro necessario per completare il progetto con successo. La gestione dell'ambito del progetto è direttamente correlata alla definizione e al controllo di ciò che è incluso e ciò che non è incluso nel progetto.

Nell'ambito di un progetto, il termine "contenuto" può riferirsi a:

Classi di requisiti:

· Requisiti aziendali che descrivono i bisogni di alto livello dell'organizzazione nel suo insieme, come i problemi o le opportunità dell'organizzazione, e le ragioni per cui il progetto è stato intrapreso.

· Requisiti degli stakeholder, che descrivono i bisogni di uno stakeholder o di un gruppo di stakeholder.

· Requisiti della soluzione che descrivono le caratteristiche, le funzioni e le caratteristiche di un prodotto, servizio o risultato in grado di soddisfare i requisiti aziendali e delle parti interessate. I requisiti della soluzione, a loro volta, sono raggruppati in requisiti funzionali e non funzionali:

o I requisiti funzionali descrivono il comportamento di un prodotto. Gli esempi includono processi, dati e interazioni con i prodotti.

o I requisiti non funzionali integrano i requisiti funzionali e descrivono le condizioni o le qualità dell'ambiente necessarie per garantire l'efficacia del prodotto. Gli esempi includono: affidabilità, sicurezza, prestazioni, sicurezza, livello di servizio, supporto, requisiti di conservazione/distruzione, ecc.

· I requisiti di transizione descrivono le capacità temporali, come la trasformazione dei dati ei requisiti di formazione, necessarie per passare dall'attuale stato "così com'è" allo stato "come dovrebbe essere" in futuro.

· I requisiti del progetto descrivono le attività, i processi o altre condizioni che il progetto deve soddisfare.

· Requisiti di qualità, che includono qualsiasi condizione o criterio necessario per confermare la corretta consegna di un risultato del progetto o altri requisiti del progetto.

6. GESTIONE DEL TEMPO DEL PROGETTO

La gestione del tempo del progetto include i processi necessari per garantire che il progetto sia completato in tempo.

Tipi di dipendenza dall'operazione:

· Fine inizio(arrivo-partenza, FS). Una relazione logica in cui l'inizio dell'attività successiva dipende dalla fine dell'attività precedente. Esempio: la cerimonia di premiazione (operazione successiva) non può essere iniziata fino al termine della gara dell'operazione precedente).

· finitura-finitura(finitura, FF). Una relazione logica in cui la fine dell'operazione successiva dipende dalla fine dell'operazione precedente. Esempio: la creazione di un documento (operazione preventiva) deve essere completata prima del completamento della sua modifica (operazione successiva).

· Inizio-inizio(inizio-inizio, SS). Una relazione logica in cui l'inizio dell'operazione successiva dipende dall'inizio dell'operazione precedente. Esempio: il livellamento di una superficie in calcestruzzo (operazione successiva) non può iniziare prima del getto della fondazione (operazione precedente).

· inizio-fine(partenza-arrivo, SF). Una relazione logica in cui la fine dell'operazione successiva dipende dall'inizio dell'operazione precedente. Esempio: il primo turno di guardia (operazione successiva) non può terminare finché non inizia il secondo turno di guardia (operazione precedente).

Valutazione a tre punti

L'accuratezza delle stime della durata dell'attività a un punto può essere migliorata considerando le incertezze ei rischi di stima. Questo concetto deriva dalla tecnica di valutazione e revisione del programma (PERT). PERT utilizza tre stime per determinare l'intervallo approssimativo della durata dell'operazione:

· Più probabilmente(tM). La durata di un'operazione è determinata tenendo conto della preassegnazione delle risorse, delle loro prestazioni, di una valutazione realistica della loro disponibilità per tale operazione, delle dipendenze da altri partecipanti, nonché delle interruzioni del lavoro.

· ottimista(a). La durata dell'operazione si basa sull'analisi dello scenario migliore per l'operazione.

· Pessimista(tP). La durata dell'operazione si basa su un'analisi dello scenario peggiore per l'operazione.

Essendo dipendente dalla distribuzione prevista dei valori nell'intervallo di tre stime, la durata prevista, tE, è calcolata dalla formula. Le due formule più comuni sono la distribuzione triangolare e la distribuzione beta.

distribuzione triangolare. tE = (tO + tM + tP) / 3

· Distribuzione beta (dal metodo PERT tradizionale). tE = (tO + 4tM + tP) / 6

Metodo del percorso critico

Metodo del percorso criticoè un metodo utilizzato per stimare la durata minima di un progetto e determinare il grado di flessibilità di schedulazione su percorsi logici in una rete all'interno di un modello di schedulazione. Il metodo di analisi della rete di pianificazione calcola le date di inizio e fine anticipate, nonché le date di inizio e fine ritardate per tutte le attività indipendentemente dai vincoli di risorse, eseguendo un'analisi di passaggio avanti e indietro attraverso la rete di progetto, come mostrato in Fig. 6-18. In questo esempio, il percorso più lungo include le attività A, C e D, quindi la sequenza A-C-D è il percorso critico. Il percorso critico è una sequenza di attività che è il percorso più lungo nella schedulazione del progetto e che definisce la durata più breve possibile del progetto. Le prime date di inizio e fine ottenute non sono necessariamente la schedulazione del progetto; piuttosto, indicano i periodi di tempo entro i quali un'operazione può essere eseguita, utilizzando parametri inseriti nel modello di pianificazione relativi a durate dell'operazione, relazioni logiche, lead, ritardi e altre limitazioni note. Metodo critico

path viene utilizzato per calcolare il grado di flessibilità di schedulazione sui percorsi logici nella rete all'interno del modello di schedulazione.

Metodo della catena critica

Metodo della catena critica(CCM) è una tecnica di sviluppo della schedulazione che consente al team di progetto di posizionare buffer su qualsiasi percorso della schedulazione per tenere conto dei vincoli di risorse e delle incertezze associate al progetto. È sviluppato dal metodo del percorso critico e tiene conto degli impatti di allocazione, ottimizzazione, livellamento delle risorse e

incertezza sulla durata di un'attività sul percorso critico determinata dal metodo del percorso critico. Il metodo della catena critica include i concetti di buffer e gestione del buffer. Il metodo della catena critica utilizza operazioni la cui durata non include limiti di sicurezza, connessioni logiche e disponibilità delle risorse con

Buffer definiti statisticamente che includono i margini di sicurezza complessivi per le operazioni in punti specifici del progetto lungo il percorso della pianificazione del progetto per tenere conto delle risorse limitate e dell'incertezza associate al progetto. Un percorso critico con vincoli di risorse è noto come "catena critica".

7. GESTIONE DEI COSTI DEL PROGETTO

La gestione dei costi del progetto include i processi necessari per la pianificazione, la stima, la definizione del budget, la raccolta di fondi, il finanziamento, la gestione e il controllo dei costi per garantire che il progetto venga consegnato entro il budget approvato.

Gestione del valore guadagnato

Gestione del valore guadagnato(EVM) è una metodologia che combina l'ambito, la pianificazione e le valutazioni delle risorse per misurare i progressi e le prestazioni del progetto. Questo è un metodo ampiamente utilizzato per misurare le prestazioni del progetto. Combina una linea di base dell'ambito con una linea di base dei costi e una linea di base della pianificazione del progetto per formare una linea di base delle prestazioni che consente al team di gestione del progetto di valutare e misurare le prestazioni e l'avanzamento del progetto. È un metodo di gestione del progetto che richiede la formazione di una linea di base integrata rispetto alla quale è possibile misurare le prestazioni durante tutto il progetto. I principi EVM possono essere applicati a

tutti i progetti in qualsiasi settore. L'EVM sviluppa e monitora le tre metriche chiave seguenti per ciascun pacchetto di lavoro e account di controllo:

· Volume pianificato. Volume pianificato (PV) - il budget autorizzato stanziato per le attività pianificate. Questo è il budget autorizzato assegnato per il lavoro da completare in un'attività o componente della struttura di ripartizione del lavoro, esclusa l'indennità di gestione. Questo budget è assegnato alle fasi del ciclo di vita del progetto, ma a un certo punto l'ambito pianificato determina il lavoro fisico che deve essere svolto. Il software cumulativo viene talvolta definito una linea di base per la misurazione delle prestazioni (PMB). Il budget totale del progetto è anche noto come budget al completamento (BFC).

· Valore guadagnato. Earned Value (EV) - la quantità di lavoro svolto, espressa in termini di budget autorizzato assegnato per questo lavoro. Questo è il budget associato al lavoro autorizzato che è stato completato. Il TOE misurato deve essere associato al PMB e il TOE misurato non può superare il budget software autorizzato per quel componente. OO viene spesso utilizzato per calcolare la percentuale di completamento di un progetto. Per ogni componente della WBS dovrebbero essere stabiliti criteri per misurare lo stato di avanzamento del lavoro svolto. I project manager monitorano il TOE sia in modo incrementale per determinare lo stato attuale che cumulativamente per determinare le tendenze delle prestazioni a lungo termine.

· costo attuale. Costo effettivo (FC): i costi effettivi sostenuti per eseguire il lavoro all'interno di un'operazione per un determinato periodo di tempo. Sono i costi complessivi sostenuti per l'esecuzione dei lavori misurati dal TOE. FS, per definizione, dovrebbe corrispondere a quanto incluso nel software e misurato dal TOE (ad esempio solo i costi diretti dell'orario di lavoro, solo i costi diretti, oppure tutti i costi, compresi quelli indiretti). Le FS non hanno limite superiore; tutto ciò che viene speso per raggiungere l'EPT viene misurato.

Vengono inoltre monitorate le deviazioni dalla linea di base approvata:

· Deviazione temporale. La varianza temporale (RTV) è un indicatore di performance del programma espresso come differenza tra il valore realizzato e il valore pianificato. La quantità di tempo in cui il progetto è in ritardo o in anticipo rispetto alla data di consegna pianificata in un determinato momento. È una misura dell'esecuzione della pianificazione del progetto. Il suo valore è uguale al valore guadagnato (OO) meno il valore pianificato (PV). La varianza temporale in EVM è una metrica utile in quanto mostra quando un progetto è in ritardo o in anticipo rispetto alla sua linea di base. La variazione temporale nell'EVM alla fine sarà zero alla fine del progetto, poiché tutti i volumi pianificati avrebbero dovuto essere padroneggiati in quel momento. La varianza temporale viene utilizzata al meglio insieme alla pianificazione e alla gestione del rischio del Critical Path Method (CPM). Formula: OSR \u003d OO - PO

· Deviazione di costo. La varianza dei costi (CV) è l'importo del disavanzo o dell'eccedenza di bilancio in un determinato momento, espresso come differenza tra il valore realizzato e il costo effettivo. È una misura del rapporto costo-efficacia di un progetto. È uguale al valore realizzato (EV) meno il costo effettivo (FC). La variazione di costo alla fine del progetto sarà pari alla differenza tra il budget a completamento (BPC) e l'importo effettivamente speso. L'OST è estremamente importante in quanto dimostra la relazione tra prestazioni fisiche e fondi spesi. L'OST negativo spesso non è recuperabile per il progetto. Formula: OST \u003d OO - FS.

I valori OSR e OST possono essere convertiti in misure di prestazione per riflettere le prestazioni in termini di costi e tempi di qualsiasi progetto rispetto a tutti gli altri progetti o all'interno di un portafoglio di progetti. Le deviazioni sono utili per determinare lo stato di un progetto.

· Indice di prestazione alla scadenza. Il Timing Completion Index (TII) è un indicatore della performance del programma, espresso come rapporto tra il valore guadagnato e il valore pianificato. Misura l'efficienza con cui il team di progetto utilizza il proprio tempo. A volte viene utilizzato insieme al Cost Fulfillment Index (CFI) per prevedere le stime di completamento del progetto finale. Un valore WRI inferiore a 1,0 indica che è stato completato meno lavoro del previsto. Un valore WPI maggiore di 1,0 indica che è stato completato più lavoro del previsto. Poiché il RIMS misura tutto il lavoro del progetto, è anche necessario analizzare le prestazioni sul percorso critico per determinare se il progetto sarà completato prima o dopo la data di fine pianificata. RIVR è uguale al rapporto tra OO e software. Formula: IVSR \u003d OO/PO

· Indice di esecuzione dei costi. Il Cost Performance Index (CFI) è una misura della performance dei costi delle risorse preventivate espressa come rapporto tra il valore realizzato e il costo effettivo. È considerata la metrica EVM più importante e misura l'efficacia in termini di costi del lavoro svolto. Un valore PVCT inferiore a 1,0 indica un superamento del lavoro svolto. Un valore PICT maggiore di 1,0 indica un sottoutilizzo dei fondi quando eseguito in una data specifica. RIVR è uguale al rapporto tra TEP e FS. Gli indici sono utili per determinare lo stato di un progetto e forniscono anche una base per stimare i tempi e il costo complessivi di un progetto. Formula: IVST = OO / FS

I tre indicatori di valore pianificato, valore realizzato e costo effettivo possono essere monitorati e riportati periodicamente (di solito settimanalmente o mensilmente) o cumulativamente.

Previsione

Con l'avanzamento del progetto, il team di progetto può sviluppare un budget al completamento (CPC) che potrebbe differire dal budget al completamento (BPC) in base alle prestazioni del progetto. Se diventa evidente che il PPP non è più realistico, il project manager dovrebbe riesaminare il PPP. Lo sviluppo di un PPP implica la previsione delle condizioni e degli eventi che si verificheranno nel futuro del progetto, sulla base delle informazioni sulle prestazioni attuali e di altre conoscenze disponibili al momento della previsione. Le previsioni sono generate, aggiornate e riemesse sulla base di

dati sulle prestazioni ottenuti durante l'avanzamento del progetto. Le informazioni sulle prestazioni lavorative coprono le prestazioni passate del progetto e tutte le informazioni che potrebbero influenzare il progetto in futuro.

Il PPP viene solitamente calcolato come il costo effettivo contabilizzato per il lavoro completato più la previsione di completamento (EPC) del lavoro rimanente. Il team di progetto ha la responsabilità di prevedere ciò che potrebbe incontrare durante l'attuazione dell'EAP, sulla base dell'esperienza attuale. Il metodo EVM funziona bene insieme alle previsioni sviluppate manualmente dell'LTF richiesto. L'approccio di previsione KPP più utilizzato è la somma manuale bottom-up da parte del project manager e del team di progetto.

Il metodo PPP bottom-up utilizzato dal project manager si basa sulla contabilità dei costi effettivi e sull'esperienza acquisita dal lavoro svolto e richiede una nuova previsione da effettuare prima del completamento per il lavoro rimanente del progetto. Formula: PPP \u003d FS + PDZ "dal basso".

Il PPV, sviluppato manualmente dal project manager, viene rapidamente confrontato con un insieme di PPV calcolati che rappresentano una varietà di scenari di rischio. Nel calcolo dei valori di PPV, di norma, vengono utilizzati i valori cumulativi di TIWT e TIVR. Sebbene i dati EVM forniscano rapidamente molti PPV statistici, di seguito sono descritti solo i tre metodi più comuni:

· PPP per lavori di PPP eseguiti a tariffe preventivate. Questo metodo PPP utilizza le prestazioni effettive del progetto in una data specifica (buona o cattiva), rappresentata dal costo effettivo, e prevede che tutti i futuri lavori PPP saranno completati alle tariffe previste. Laddove le prestazioni effettive siano sfavorevoli, l'ipotesi che le prestazioni future migliorino dovrebbe essere accettata solo se ciò è supportato dall'analisi del rischio del progetto. Formula: PPZ = FS + (BPZ - OO)

· PPP per PPP lavori eseguiti con l'attuale IVST. Questo metodo presuppone che il progetto proseguirà in futuro nello stesso modo in cui è proceduto fino a questo punto. Si presume che le attività del PE verranno eseguite allo stesso livello dell'indice di prestazione dei costi cumulativo (CPI) raggiunto dal progetto fino ad oggi. Formula: PPZ = BPZ / IVST

· PPZ per lavori PDZ, tenendo conto di entrambi i fattori PVSR e CVST. In tale previsione, il lavoro del PD sarà svolto con un'efficienza che tiene conto degli indici di performance sia di costo che di tempistica. Questo metodo è particolarmente utile quando uno dei fattori che influenzano l'EAP è la pianificazione del progetto. Le variazioni di questo metodo considerano RVSI e RVSR in vari rapporti (ad es. 80/20, 50/50 o altre proporzioni), secondo il parere del project manager. Formula: PPZ = FS + [(BPZ - OO) / (IVST x EVSR)]

Ciascuno di questi approcci può essere applicato a un determinato progetto e fornire al team di gestione del progetto un segnale di "allarme rapido" se i PPP sono al di fuori delle tolleranze accettate.

Indice dalla performance al completamento (PPI)

Indice di prestazione al completamento(IBPI) è la prestazione di costo stimata di un progetto che deve essere realizzata con le risorse rimanenti per raggiungere un obiettivo di gestione prefissato, espressa come rapporto tra il costo del completamento del lavoro rimanente e il budget residuo. Il BPI è un indice di prestazione di costo calcolato che deve essere raggiunto sui lavori rimanenti per raggiungere un obiettivo di gestione specifico, come un BPP o un BPP. Se diventa evidente che il PPP non è più realistico, il project manager dovrebbe riesaminare il PPP. Una volta approvato, il PPP può sostituire il BPI nel calcolo dell'EITI. La formula per la BPHI basata sulla BPZ è (BPZ - GS)/(BPZ - FS). L'EITI è concettualmente rappresentato nella figura seguente. La formula per l'EITI è mostrata nell'angolo in basso a sinistra come il lavoro rimanente (definito come BPV meno QA) diviso per i fondi rimanenti (che possono essere calcolati come BPV meno FS o RP meno FS).

Se l'IFT cumulativa è inferiore alla linea di base (come mostrato nella figura seguente), tutti i lavori futuri sul progetto devono essere immediatamente eseguiti in conformità con l'EITI (BOI) (come indicato nella riga superiore della figura seguente) al fine di rimanere all'interno del BPO autorizzato. La possibilità di raggiungere un determinato livello di prestazione viene valutata sulla base di una serie di considerazioni, tra cui il rischio, la pianificazione e le prestazioni tecniche. Questo livello di prestazioni è rappresentato come una linea di IPDZ (PPZ). La formula per un PPP basato su PPP è (BPP - GS)/(PPP - FS). Le formule EVM sono presentate nella tabella seguente.

Analisi di performance

L'analisi delle prestazioni confronta le prestazioni in termini di costi nel tempo, le attività programmate o i pacchetti di lavoro che superano o sono inferiori al budget e le stime del denaro necessario per completare il lavoro in corso. Se viene utilizzato un EVM, vengono definite le seguenti informazioni:

· Analisi delle deviazioni. L'analisi della varianza, quando utilizzata in EVM, è il chiarimento (causa, impatto e azioni correttive) degli scostamenti per costo (CTS = TS - FS), pianificazione (SSR = TS - TS) e varianze al completamento (CPV = BPV - CPV ). Le deviazioni più frequentemente analizzate sono il costo e la tempistica. Per i progetti che non applicano l'Earned Value Management, è possibile eseguire un'analisi della varianza simile confrontando il costo pianificato di un'operazione con il costo effettivo dell'operazione per determinare gli scostamenti tra l'esecuzione effettiva del progetto e la previsione dei costi. È possibile eseguire ulteriori analisi per determinare la causa e l'entità della deviazione dalla linea di base e le necessarie azioni correttive o preventive. Le misurazioni dell'adempimento dei costi vengono utilizzate per stimare l'importo della deviazione dalla linea di base dei costi originale. Aspetti importanti della gestione dei costi del progetto includono la determinazione della causa e dell'entità della deviazione dalla linea di base dei costi e la decisione se è necessaria un'azione correttiva o preventiva. Man mano che viene svolto sempre più lavoro, l'intervallo di tolleranza percentuale tenderà a diminuire.

· Analisi delle tendenze. L'analisi delle tendenze implica l'esame dei dati sulle prestazioni del progetto nel tempo per determinare se le prestazioni del progetto stanno migliorando o peggiorando. Le tecniche di analisi grafica sono preziose per comprendere le prestazioni in una data specifica e per il confronto con gli obiettivi di prestazioni futuri nei formati BPO rispetto a PPP e data di completamento.

· Esecuzione del valore guadagnato. L'esecuzione dell'Earned Value implica il confronto di un piano di prestazioni di base con le prestazioni effettive in termini di tempo e costi. Se l'EVM non viene utilizzato, per confrontare l'esecuzione dei costi viene utilizzata l'analisi di base dei costi rispetto al costo effettivo del lavoro svolto.

8. GESTIONE DELLA QUALITÀ DEL PROGETTO

La gestione della qualità del progetto comprende i processi e le attività dell'organizzazione che effettuano le prestazioni che definiscono le politiche, gli obiettivi e le responsabilità della qualità in modo che il progetto soddisfi i bisogni per i quali è stato intrapreso. Project Quality Management utilizza politiche e procedure per implementare il sistema di gestione della qualità dell'organizzazione nel contesto del progetto e, ove appropriato, supporta le attività di miglioramento continuo dei processi intrapresi dall'organizzazione che esegue. La gestione della qualità del progetto mira a garantire che i requisiti del progetto, compresi i requisiti del prodotto, siano soddisfatti e verificati.

Qualità e grado sono concetti concettualmente diversi. La qualità come output o risultato consegnabile è "il grado in cui un insieme di caratteristiche intrinseche è conforme ai requisiti" (ISO 9000). Un voto come intento progettuale è una categoria assegnata ai risultati finali che hanno la stessa funzionalità ma specifiche diverse. Il project manager e il team di project management hanno la responsabilità di raggiungere i compromessi per garantire i livelli richiesti di qualità e qualità. Un livello di qualità che non soddisfa i requisiti di qualità è sempre un problema e un voto basso potrebbe non essere un problema.

Nel contesto del raggiungimento della conformità ISO, i moderni approcci alla gestione della qualità cercano di ridurre al minimo le deviazioni e ottenere risultati che soddisfino determinati requisiti. Questi approcci riconoscono l'importanza di quanto segue:

· Soddisfazione del cliente. Comprendere, valutare, identificare e gestire i requisiti dei clienti per soddisfare le aspettative dei clienti. Ciò richiede una combinazione di idoneità (il progetto deve produrre ciò per cui è stato intrapreso) e usabilità (il prodotto o servizio deve soddisfare bisogni reali).

· La prevenzione è più importante dell'ispezione. La qualità dovrebbe essere pianificata, sviluppata e integrata, non ispezionata nella gestione del progetto o nella consegna dei risultati del progetto. Il costo per prevenire gli errori è generalmente molto inferiore al costo per correggerli una volta scoperti attraverso l'ispezione o in uso.

· Miglioramento continuo. Il ciclo plan-do-check-act (PDCA), un modello descritto da Shewhart e migliorato da Deming, è la base per il miglioramento della qualità. Inoltre, le iniziative di miglioramento della qualità come Total Quality Management (TQM), Six Sigma e Lean Six Sigma combinate possono migliorare la qualità della gestione del progetto e anche la qualità del prodotto del progetto. I modelli di miglioramento dei processi includono il Malcolm Baldridge Quality Model, il Organizational Project Management Maturity Model (OPM3®) e il Capability Maturity Model Integrated (CMMI®).

· Responsabilità di gestione. Il successo richiede la partecipazione di tutti i membri del team di progetto. Tuttavia, la direzione mantiene, sotto la responsabilità della qualità, l'appropriata responsabilità di fornire le giuste risorse nella giusta quantità.

· Il costo della qualità(costo della qualità, COQ). Il costo della qualità è il costo totale del lavoro di conformità e del lavoro di non conformità che deve essere svolto come sforzo compensativo perché esiste la possibilità che parte del lavoro debba essere svolto o è stato eseguito in modo errato la prima volta che si tenta di eseguire il lavoro. . Il costo dell'esecuzione delle attività di garanzia della qualità può verificarsi durante l'intero ciclo di vita di un prodotto finale. Ad esempio, le decisioni prese dal team di progetto possono influire sui costi operativi associati all'utilizzo di un deliverable completato. I costi di qualità successivi alla chiusura possono derivare da resi di prodotti, reclami in garanzia e campagne di richiamo dei prodotti. Pertanto, a causa della natura temporanea del progetto e del potenziale beneficio che si può ottenere dalla riduzione del costo della qualità post-progetto, le organizzazioni promotrici possono decidere di investire nel miglioramento della qualità del prodotto. Questi investimenti sono in genere effettuati nell'area del lavoro di conformità per prevenire difetti o ridurre il costo dei difetti ispezionando unità non conformi. Inoltre, le questioni relative al COQ post-progetto dovrebbero essere affrontate nella gestione del programma e nel processo di gestione del portafoglio, ad esempio, gli uffici di gestione del progetto, del programma e del portafoglio dovrebbero applicare metodi di analisi, modelli e metodi di allocazione dei fondi appropriati a questo scopo.

Sette strumenti di qualità essenziali

I sette strumenti di qualità principali, noti nel settore anche come strumenti 7QC, vengono utilizzati nel contesto del ciclo PDCA per affrontare i problemi relativi alla qualità. Riso. di seguito è riportata un'illustrazione concettuale dei sette principali strumenti di qualità, che includono:

· Diagrammi di causa ed effetto, chiamati anche diagrammi a lisca di pesce o diagrammi di Ishikawa. La descrizione del problema, situata nella testa della lisca di pesce, viene utilizzata come punto di partenza per risalire all'origine del problema fino alla causa principale che richiede un'azione. Una descrizione del problema è solitamente una dichiarazione del problema come un divario da correggere o un obiettivo da raggiungere. La ricerca della causa viene effettuata esaminando la descrizione del problema e cercando le risposte alla domanda "perché" fino a quando non viene identificata la causa principale che richiede un'azione, o fino a quando tutte le possibilità ragionevoli su ciascuna parte dello scheletro del pesce non sono state esaurite. I diagrammi a lisca di pesce sono spesso utili quando si cerca di correlare gli effetti indesiderati visti come una particolare variazione con una causa identificata per la quale i team di progetto devono intraprendere azioni correttive per eliminare quella particolare variazione trovata sulla carta di controllo.

· Diagrammi di flusso, dette anche mappe di processo, perché mostrano la sequenza di passaggi e le possibilità di ramificazione di un processo che trasforma uno o più input in uno o più output. I diagrammi di flusso riflettono le operazioni, i punti decisionali, i cicli, i percorsi paralleli e l'ordine di esecuzione dei processi rappresentando, come una mappa, i dettagli operativi delle procedure esistenti all'interno della catena del valore orizzontale del modello SIPOC. I diagrammi di flusso possono essere utili per comprendere e stimare il costo della qualità all'interno di un processo. Ciò si ottiene utilizzando la logica di ramificazione del flusso di lavoro e le relative frequenze associate per stimare il valore monetario atteso del lavoro di conformità e del lavoro di non conformità necessari per fornire un output conforme.

· schede di raccolta dati, noti anche come fogli di conteggio, possono essere utilizzati come liste di controllo durante la raccolta dei dati. I fogli di raccolta dati vengono utilizzati per organizzare i fatti in modo da acquisire in modo efficace dati utili su un potenziale problema di qualità. Sono particolarmente utili per raccogliere i dati dei parametri durante le ispezioni per identificare i difetti. Ad esempio, i dati sull'incidenza o sulle conseguenze dei difetti raccolti utilizzando i fogli di raccolta dati vengono spesso visualizzati utilizzando i grafici di Pareto.

· Grafici di Pareto sono grafici a barre verticali di forma speciale e vengono utilizzati per identificare le poche fonti più importanti che causano la maggior parte degli effetti di un problema. Le categorie mostrate sull'asse orizzontale rappresentano la distribuzione di probabilità esistente considerando il 100% delle possibili osservazioni. Il valore della corrispondente frequenza di occorrenza di ciascuna causa etichettata, mostrata sull'asse orizzontale, diminuisce fino a raggiungere la sorgente predefinita denominata "altra", che è responsabile di cause non specificate. In genere, un grafico di Pareto è organizzato in categorie che misurano la frequenza dell'occorrenza o le conseguenze.

· Istogrammiè un tipo speciale di grafico a barre utilizzato per descrivere il centro di distribuzione, la varianza e la forma di una distribuzione statistica. A differenza di una carta di controllo, un istogramma non tiene conto dell'effetto del tempo sulla variazione che esiste all'interno di una distribuzione.

· Carte di controllo vengono utilizzati per determinare se un processo è stabile o meno e se ha prestazioni prevedibili. I limiti inferiore e superiore indicati dalla specifica si basano sui requisiti stabiliti nell'accordo. Riflettono i valori massimi e minimi consentiti. Possono essere imposte sanzioni associate alla produzione di valori oltre i limiti fissati dal disciplinare. I limiti di controllo superiore e inferiore differiscono dai limiti indicati dalla specifica. I limiti di controllo sono stabiliti utilizzando calcoli e principi statistici standard al fine di determinare finalmente la possibilità naturale di stabilizzare il processo. Il project manager e le parti interessate possono utilizzare limiti di controllo calcolati statisticamente per determinare i punti in cui verranno intraprese azioni correttive per prevenire prestazioni innaturali. Lo scopo dell'azione correttiva è solitamente quello di mantenere la naturale stabilità di un processo stabile ed efficiente. Per i processi ripetitivi, i limiti di controllo sono tipicamente ±3 sigma della media del processo, che è stata impostata su 0. Un processo è considerato fuori controllo se: (1) il punto dati è al di fuori dei limiti di controllo; (2) sette punti consecutivi sono sopra la linea mediana; o (3) sette punti consecutivi sono al di sotto della linea mediana. I grafici di controllo possono essere utilizzati per controllare vari tipi di variabili di output. Sebbene siano più comunemente utilizzati per tenere traccia delle attività ripetitive necessarie per fabbricare prodotti industriali, possono anche essere utilizzati per controllare i costi e le variazioni di pianificazione, il volume e la frequenza delle modifiche dell'ambito o altri risultati di gestione per aiutare a determinare se i processi di gestione del progetto sono sotto controllo.

· Grafici a dispersione vengono tracciate coppie ordinate (X, Y), a volte dette grafici di correlazione, perché sono usati per spiegare la variazione della variabile dipendente, Y, relativa alla variazione osservata nella variabile indipendente, X. La direzione della correlazione può essere proporzionale (correlazione positiva), reverse (correlazione negativa) o il modello di correlazione potrebbe non esistere (correlazione zero). Se è possibile stabilire una correlazione, è possibile determinare una retta di regressione e utilizzarla per stimare in che modo un cambiamento nella variabile indipendente cambierà il valore della variabile dipendente.

Strumenti di gestione e controllo della qualità

Il processo di assicurazione della qualità utilizza gli strumenti ei metodi della pianificazione della gestione della qualità e dei processi di controllo della qualità. Oltre a questo, altri strumenti disponibili includono:

· Diagrammi di affinità. Un diagramma di affinità è simile alla mappatura mentale in quanto viene utilizzato per generare idee che possono essere combinate per formare un modo ordinato di pensare a un problema. Nel processo di gestione del progetto, la creazione di una WBS può essere migliorata utilizzando un diagramma di affinità per strutturare la scomposizione del contenuto.

· Schemi del processo di attuazione del programma(grafici del programma decisionale di processo, PDPC). Utilizzato per comprendere l'obiettivo in relazione alle azioni intraprese per raggiungere l'obiettivo. Il PDPC è una tecnica utile per la pianificazione delle perdite, poiché aiuta i team ad anticipare i passaggi intermedi che potrebbero impedirgli di raggiungere il loro obiettivo.

· Grafici di relazione orientati. Adattamento dei diagrammi di relazione. I grafici relazionali orientati sono un processo di risoluzione creativa dei problemi in scenari moderatamente complessi caratterizzati da relazioni logiche intrecciate di un massimo di 50 elementi correlati. Un grafico di relazione diretta può essere costruito dai dati ottenuti da altri strumenti come un diagramma di affinità, un diagramma ad albero o un diagramma a lisca di pesce.

· Diagrammi ad albero. Conosciuti anche come diagrammi sistematici, possono essere utilizzati per mostrare la scomposizione di gerarchie come WBS, struttura di ripartizione del rischio (RBS) e struttura di ripartizione organizzativa (OBS). Nella gestione dei progetti, i diagrammi ad albero sono utili per visualizzare le relazioni padre-figlio in qualsiasi gerarchia di scomposizione che utilizzi un insieme sistematico di regole per definire le relazioni di reporting. I diagrammi ad albero possono essere orizzontali (es. gerarchia del rischio) o verticali (es. gerarchia del team o OBS). Poiché i diagrammi ad albero consentono rami nidificati che terminano in un unico punto decisionale, sono utili come alberi decisionali per determinare il valore atteso di un numero limitato di relazioni che vengono tracciate sistematicamente.

· Matrici prioritarie. Utilizzato per identificare problemi chiave e alternative idonee a cui dare priorità come insieme di soluzioni per l'implementazione. I criteri sono classificati per priorità e ponderati prima di essere applicati a tutte le alternative disponibili al fine di ottenere un punteggio matematico per classificare tutte le alternative.

· Schemi di rete operativa. Precedentemente noto come grafici a freccia. Includono formati di diagramma di rete come operazioni sugli archi (attività sulla freccia, AOA) e il formato operativo più comunemente usato sui nodi (attività sul nodo, AON). I diagrammi di rete delle attività vengono utilizzati con metodi di pianificazione del progetto come il metodo di valutazione e revisione del programma (PERT), il metodo del percorso critico (CPM) e il metodo del diagramma di precedenza (PDM).

· Grafici a matrice. Uno strumento di gestione e controllo qualità utilizzato per analizzare i dati all'interno della struttura organizzativa creata nella matrice. Con l'aiuto di un diagramma a matrice, cercano di mostrare la forza delle dipendenze tra fattori, cause e obiettivi, visualizzati in una matrice sotto forma di righe e colonne.

9. PROGETTO GESTIONE DELLE RISORSE UMANE

Project Human Resource Management include i processi di organizzazione, gestione e guida del team di progetto. Il team di progetto è composto da persone che hanno definito ruoli e responsabilità per l'attuazione del progetto. I membri del team di progetto possono avere competenze diverse, possono essere a tempo pieno o part-time e possono essere aggiunti o rimossi dal team man mano che il progetto avanza. I membri del team di progetto possono anche essere indicati come personale di progetto. Sebbene ai membri del team di progetto vengano assegnati ruoli e responsabilità specifici, la partecipazione di tutti i membri del team alla pianificazione del progetto e al processo decisionale è preziosa per il progetto. Il coinvolgimento dei membri del team consente loro di utilizzare la loro esperienza esistente nella pianificazione del progetto e rafforza l'attenzione del team sul raggiungimento dei risultati del progetto.

Organigrammi e job description

Esistono vari formati per documentare la distribuzione dei ruoli e delle responsabilità dei membri del team. La maggior parte dei formati rientra in uno di tre tipi: gerarchico, a matrice e di testo. Inoltre, alcuni incarichi di progetto vengono visualizzati nei piani di supporto, come i piani di rischio, qualità o comunicazione. Indipendentemente dal metodo utilizzato, l'obiettivo è sempre lo stesso: garantire che ogni pacchetto di lavoro abbia una responsabilità univoca per la sua esecuzione e che ogni membro del team comprenda chiaramente il proprio ruolo e le proprie responsabilità. Ad esempio, un formato gerarchico può essere utilizzato per rappresentare ruoli di alto livello, un formato testo è migliore per documentare in dettaglio le aree di responsabilità.

Il Piano di Gestione delle Risorse Umane comprende, tra l'altro:

· Ruoli e responsabilità. Quando si elencano i ruoli e le responsabilità richieste per portare a termine un progetto, considerare quanto segue:

o Ruolo. Una funzionalità accettata da un dipendente o assegnata a un dipendente del progetto. Esempi di ruoli in un progetto sono ingegnere civile, analista aziendale e coordinatore del test. Dovrebbe essere documentata una chiara descrizione del ruolo in termini di autorità, responsabilità e confini.

o Autorità. Il diritto di impegnare risorse di progetto, prendere decisioni, firmare approvazioni, accettare risultati finali e influenzare altri membri del team a svolgere il lavoro di progetto. Esempi di decisioni che richiedono un'autorità chiara e precisa includono la scelta di come eseguire un'operazione, l'accettazione della qualità e il modo in cui rispondere alle deviazioni di progettazione. I membri del team si comportano meglio quando il livello di autorità di ciascuno di loro corrisponde alla loro area di responsabilità individuale.

o Responsabilità. I compiti assegnati e il lavoro che un membro del team di progetto deve svolgere per completare le attività del progetto.

o Qualificazione. Le abilità e le abilità richieste per svolgere le attività assegnate entro i vincoli del progetto. Se i membri del team di progetto non hanno le qualifiche necessarie, il progetto potrebbe essere in pericolo. Se vengono identificate tali discrepanze, dovrebbero essere intraprese azioni preventive, come formazione, assunzione di specialisti qualificati o apportare modifiche appropriate al programma o all'ambito del progetto.

Organigrammi del progetto. Un organigramma di progetto è una rappresentazione grafica della composizione di un team di progetto e delle relazioni di reporting tra i suoi membri. A seconda dei requisiti del progetto, può essere formale o informale, dettagliato o generalizzato. Ad esempio, un organigramma di progetto per un team di risposta alle emergenze di 3.000 persone sarà significativamente più dettagliato di un organigramma di progetto interno con un team di 20 persone.

· Piano del personale. Il piano del personale è una componente del piano di gestione delle risorse umane che descrive quando e come verranno assunti i membri del team di progetto e per quanto tempo saranno necessari. Descrive come soddisfare i requisiti delle risorse umane. A seconda dei requisiti del progetto, il piano del personale può essere formale o informale, dettagliato o generalizzato. Questo piano viene costantemente aggiornato durante il corso del progetto per riflettere le attività in corso per ricostituire e sviluppare il team di progetto. Le informazioni contenute nel piano del personale variano a seconda dell'area di applicazione e delle dimensioni del progetto, ma devono comunque comprendere i seguenti elementi:

o Reclutamento. Quando si pianifica il reclutamento dei membri del team di progetto, sorgono una serie di domande. Ad esempio, le risorse umane esistenti dell'organizzazione verranno utilizzate o verranno reclutate dall'esterno su base contrattuale; se i membri del team lavoreranno nella stessa posizione o se potranno lavorare in remoto; qual è il costo corrispondente a ciascun livello di abilità richiesto per il progetto; e qual è il livello di supporto del team di progetto che il dipartimento delle risorse umane dell'organizzazione ei leader funzionali possono fornire.

o Calendari delle risorse. Calendari che determinano la disponibilità di una particolare risorsa in determinati giorni lavorativi e turni. Il piano del personale specifica la tempistica dell'ingaggio dei membri del team di progetto, sia individualmente che collettivamente, nonché la tempistica di inizio delle attività di reclutamento, come l'assunzione di personale. Uno strumento per rappresentare graficamente le risorse umane è il grafico a barre delle risorse, utilizzato dal team di gestione del progetto come mezzo per visualizzare o allocare le risorse a tutte le parti interessate. Questo grafico mostra il numero di ore di cui una persona, un dipartimento o l'intero team di progetto ha bisogno ogni settimana o mese per la durata del progetto. Il grafico può includere una linea orizzontale che rappresenta il numero massimo di ore calcolate per una particolare risorsa. Se le barre nel grafico sono al di fuori delle ore massime disponibili, è necessario applicare una strategia di ottimizzazione delle risorse, ad esempio l'allocazione di risorse aggiuntive o la riprogrammazione.

o Piano di rilascio del personale. Determinare come e quando liberare i membri del team dalle responsabilità del progetto è vantaggioso sia per il progetto che per i membri del team. Quando i membri del team sono esentati dalla partecipazione a un progetto, ciò elimina i pagamenti ai dipendenti che hanno già completato la loro parte di lavoro nel progetto e quindi riduce il costo del progetto. Il clima morale generale migliora se è già pianificata in anticipo una transizione graduale a nuovi progetti. Un piano di rilascio del personale può anche ridurre i rischi per le risorse umane che possono sorgere durante l'attuazione o alla fine del progetto.

o Bisogni di formazione. Se si teme che le qualifiche dei membri del team assegnati al progetto possano non essere sufficienti, è necessario sviluppare un piano di formazione del personale come parte del piano del progetto. Il piano può includere anche programmi di formazione per i membri del team che porteranno a certificazioni che contribuiscono al successo del progetto.

o Riconoscimento e premi. Criteri chiari e un sistema di ricompensa pianificato aiutano a stimolare e supportare il comportamento desiderato delle persone coinvolte nel progetto. Affinché il riconoscimento e le ricompense siano efficaci, devono essere basati sulle azioni, le prestazioni e le prestazioni sotto il controllo dell'individuo. Ad esempio, un membro del team può essere ricompensato per aver raggiunto una determinata tariffa di costo solo se dispone dell'autorità sufficiente per controllare le decisioni che influiscono sul costo. La creazione di un piano con tempi di ricompensa assicura che la ricompensa non venga dimenticata. Il riconoscimento e le ricompense fanno parte del processo di sviluppo del team di progetto.

o Conformità. Il piano di gestione del personale può includere strategie per garantire che il progetto sia conforme alle normative governative esistenti, alle condizioni contrattuali di lavoro e ad altre politiche stabilite in materia di risorse umane.

o Sicurezza. Il piano del personale, così come il registro dei rischi, può includere politiche e procedure per proteggere i membri del team dagli incidenti.

Un modello utilizzato per descrivere lo sviluppo del team è la scala Tuckman (Tuckman, 1965; Tuckman & Jensen, 1977), che comprende cinque fasi di sviluppo che i team devono attraversare. Di solito queste fasi vengono in ordine, ma non è raro che una squadra si blocchi in una fase particolare o ricada in una precedente. Nei progetti in cui i membri del team hanno precedentemente lavorato insieme, alcune fasi potrebbero essere saltate.

· Formazione. In questa fase, il team si riunisce e viene a conoscenza del progetto, dei ruoli e delle responsabilità formali al suo interno. I membri del team in questa fase tendono ad essere indipendenti l'uno dall'altro e non particolarmente aperti.

Tempesta. Durante questa fase, il team inizia a studiare il lavoro sul progetto, tecnico soluzioni e approccio alla gestione dei progetti. Se i membri del team non sono collaborativi e aperti a idee e prospettive diverse, l'ambiente può diventare improduttivo.

· Insediamento. Durante la fase di adattamento, i membri del team iniziano a lavorare insieme e ad adattare le loro abitudini e comportamenti di lavoro per facilitare il lavoro di squadra. I membri del team imparano a fidarsi l'uno dell'altro.

· Efficienza. Le squadre che hanno raggiunto la fase di prestazione funzionano come un'unità ben organizzata. Sono indipendenti e risolvono i problemi con calma ed efficacia.

· Completamento. In questa fase, il team completa il lavoro e passa al progetto successivo. Questo di solito accade quando le persone vengono rilasciate dal progetto dopo che i risultati finali sono stati completati o come parte del processo o della fase di chiusura del progetto.

La durata di ogni fase specifica dipende dalla dinamica, dalla forza e dalla leadership del team. I project manager devono avere una buona comprensione delle dinamiche di sviluppo del team al fine di facilitare il passaggio efficace dei membri del team attraverso tutte le fasi.

Esistono cinque metodi principali utilizzati per risolvere i conflitti.

Poiché ognuno ha il suo scopo e la sua applicazione, i metodi sono elencati in nessun ordine particolare:

· Evasione/elusione. Allontanarsi da una situazione di conflitto reale o potenziale, rinviando la soluzione del problema a una data successiva per prepararsi meglio alla sua risoluzione o trasferirne la risoluzione ad altri.

· Levigatura/raccordo. Enfatizzare punti di contatto anziché aree di contraddizione, abbandonare la propria posizione a favore dei bisogni degli altri per mantenere armonia e relazioni.

· Compromesso/accordo. La ricerca di soluzioni che siano in una certa misura soddisfacenti per tutte le parti al fine di risolvere temporaneamente o parzialmente il conflitto.

· Coercizione / istruzioni. Fare pressioni per il punto di vista di qualcuno a spese degli altri, offrendo solo soluzioni vincenti e perse, di solito da una posizione di potere, per risolvere una situazione critica.

· Collaborazione/risoluzione dei problemi. Combinando molti punti di vista e punti di vista da diverse prospettive, la necessità di cooperazione e dialogo aperto, che di solito porta al consenso e al sostegno per la decisione di tutte le parti.

Esempi di abilità interpersonali che sono più comunemente utilizzati dal project manager includono:

· Comando. Per il successo di un progetto sono richieste capacità di leadership sviluppate. La leadership è importante in tutte le fasi del ciclo di vita del progetto. Esistono molte teorie sulla leadership che definiscono gli stili di leadership che, se necessario, ogni team dovrebbe utilizzare nella situazione appropriata. È particolarmente importante comunicare la visione generale del progetto ai membri del team e ispirarli a raggiungere un'elevata efficienza ed efficacia nel loro lavoro.

· Influenza. Poiché i project manager spesso hanno poca o nessuna autorità diretta sui membri del loro team in termini di matrice, la loro capacità di influenzare tempestivamente le parti interessate del progetto è fondamentale per il successo del progetto. Le abilità chiave dell'influencer includono:

o la capacità di affermare in modo convincente e chiaro il punto di vista e la posizione;

o un elevato livello di capacità di ascolto attivo ed efficace;

o comprendere e considerare prospettive diverse in ogni situazione;

o raccogliere informazioni essenziali e critiche per risolvere problemi importanti e raggiungere accordi mantenendo la fiducia reciproca.

· Processo decisionale efficace. Ciò include la capacità di negoziare e influenzare l'organizzazione e il team di gestione del progetto. Di seguito sono riportate alcune delle raccomandazioni per il processo decisionale:

o necessità di concentrarsi sugli obiettivi da raggiungere;

o Devono essere seguite le procedure decisionali;

o è necessario studiare i fattori ambientali;

o è necessario analizzare le informazioni disponibili;

o è necessario sviluppare le qualità personali dei membri del team;

o è necessario stimolare l'approccio creativo del team al lavoro;

o il rischio deve essere gestito.

10. GESTIONE DELLA COMUNICAZIONE DEL PROGETTO

La gestione delle comunicazioni di progetto include i processi necessari per garantire la pianificazione, la raccolta, la creazione, la distribuzione, l'archiviazione, la ricezione, la gestione, il controllo, il monitoraggio e, infine, l'archiviazione/smaltimento tempestivi e appropriati delle informazioni sul progetto. I project manager trascorrono la maggior parte del loro tempo a comunicare con i membri del team e gli altri stakeholder del progetto, siano essi interni (a tutti i livelli dell'organizzazione) o esterni all'organizzazione. Una comunicazione efficace crea un ponte tra diversi stakeholder che possono avere diversi background culturali e organizzativi, diversi livelli di conoscenza e diversi punti di vista e interessi che influenzano o possono avere un impatto sull'esecuzione o sui risultati del progetto.

I fattori che possono influenzare la scelta della tecnologia di comunicazione includono:

· L'urgenza di ottenere informazioni. Occorre tenere conto dell'urgenza, della frequenza e del formato delle informazioni da comunicare, che possono variare da progetto a progetto e anche in fasi diverse dello stesso progetto.

· Disponibilità della tecnologia. È necessario garantire che la tecnologia richiesta per consentire la comunicazione sia compatibile e disponibile per tutte le parti interessate per tutta la durata del progetto.

· Facilità d'uso.È necessario garantire che le tecnologie di comunicazione scelte siano adatte ai partecipanti al progetto e che siano pianificate adeguate attività di formazione, se necessario.

· Ambiente di progetto. È necessario determinare se la squadra si incontrerà e agirà di persona o virtualmente; se i membri del team si troveranno in uno o più fusi orari; se utilizzeranno più lingue per la comunicazione; e, in definitiva, se ci sono altri fattori nell'ambiente del progetto, come la cultura, che possono influenzare le comunicazioni.

· Segretezza e riservatezza delle informazioni.È necessario determinare se le informazioni trasferite sono classificate o riservate e se sono necessarie misure aggiuntive per proteggerle. Occorre inoltre prendere in considerazione i mezzi più appropriati per trasmettere tali informazioni.

Il modello di comunicazione di base prevede la seguente sequenza di passaggi:

· Codifica. Trasformazione (codifica) di pensieri o idee in un linguaggio in codice da parte del mittente.

· Invio di un messaggio. Invio di informazioni da parte del mittente tramite il canale delle informazioni (mezzo di trasmissione delle informazioni). Vari fattori (come distanza, tecnologia sconosciuta, infrastrutture insufficienti, differenze culturali e mancanza di informazioni aggiuntive) possono impedire la trasmissione di questo messaggio. Questi fattori sono indicati collettivamente come rumore.

· Decodifica. Il messaggio viene ricondotto in pensieri e idee significativi dal destinatario.

· Conferma. Dopo aver ricevuto il messaggio, il destinatario può inviare un segnale (riconoscimento) che il messaggio è stato ricevuto, ma ciò non significa necessariamente che il messaggio sia stato accettato o compreso.

· Feedback/Risposta. Quando il messaggio ricevuto viene decodificato e compreso, il destinatario converte (codifica) i pensieri e le idee in un messaggio e trasmette il messaggio al mittente originale.

Diversi metodi di comunicazione vengono utilizzati per diffondere le informazioni tra le parti interessate del progetto.

Questi metodi possono essere suddivisi nei seguenti grandi gruppi:

· Comunicazioni interattive. Tra due o più parti impegnate in uno scambio multilaterale di informazioni. Questo metodo è più efficace per garantire una comprensione comune di determinati problemi da parte di tutti i partecipanti; include riunioni, chiamate, messaggistica istantanea, videoconferenze, ecc.

· Comunicazione informando senza richiesta. Le informazioni vengono inviate a destinatari specifici che hanno bisogno di riceverle. Questo metodo garantisce la diffusione delle informazioni, ma non garantisce che saranno effettivamente ricevute o comprese dal pubblico previsto. Le comunicazioni non richieste includono lettere, note, rapporti, e-mail, fax, messaggi di posta vocale, blog, comunicati stampa, ecc.

· Comunicazione su richiesta. Utilizzato per volumi di informazioni molto grandi o per un pubblico molto ampio e richiede ai destinatari di accedere al contenuto trasmesso a proprio piacimento. Tali metodi includono siti intranet, e-learning, database di lezioni apprese, repository di conoscenze, ecc.

I metodi e gli aspetti di una gestione efficace delle comunicazioni includono, ma non sono limitati a:

Il modello mittente-destinatario. Implementare circuiti di feedback per fornire opportunità favorevoli di coinvolgimento/partecipazione e rimuovere le barriere comunicative.

· Scelta del mezzo di comunicazione. Scelte situazionali su quando comunicare verbalmente e quando per iscritto, quando preparare note informali e quando fare un rapporto formale e quando parlare di persona rispetto alla posta elettronica.

· Stile di scrittura. L'uso della voce attiva o passiva, la struttura della frase, la scelta delle parole.

· Modalità di gestione delle riunioni. Preparare l'agenda e affrontare i conflitti.

Metodi di presentazione. Consapevolezza dell'impatto del linguaggio del corpo e sviluppo di ausili visivi.

· Modalità di organizzazione del lavoro di gruppo. Raggiungere il consenso e superare gli ostacoli.

· Metodi di ascolto. Ascolto attivo (conferma, chiarimento e verifica della comprensione) e rimozione delle barriere che possono distorcere la comprensione.

11. GESTIONE DEL RISCHIO DEL PROGETTO

La gestione del rischio di progetto include i processi associati alla pianificazione della gestione del rischio, all'identificazione, all'analisi, alla pianificazione della risposta e al controllo del rischio del progetto. Gli obiettivi della gestione del rischio di progetto sono aumentare la probabilità e l'impatto di eventi benefici e ridurre la probabilità e l'impatto di eventi avversi durante l'attuazione del progetto.

Rischio di progettoè un evento o una condizione incerta il cui verificarsi influisce negativamente o positivamente sugli obiettivi del progetto, come l'ambito, la pianificazione, i costi e la qualità. Un rischio può essere dovuto a una o più cause e, se si verifica, può interessare uno o più aspetti.

Piano di gestione del rischioè una componente del piano di gestione del progetto che descrive come saranno strutturate ed eseguite le attività di gestione del rischio. Il piano di gestione del rischio comprende i seguenti elementi:

· Metodologia. Determinazione di approcci, strumenti e fonti di dati che verranno utilizzati per gestire i rischi in questo progetto.

· Ruoli e responsabilità. Identificazione dei membri principali del team, dei membri del team di supporto e dei membri del team di gestione del rischio per ciascuna attività inclusa nel piano di gestione del rischio e chiarimento delle loro responsabilità.

· Sviluppo del bilancio. Stima delle disponibilità finanziarie necessarie, tenuto conto delle risorse stanziate, da inserire nel piano di base al costo e sviluppo delle procedure per l'utilizzo del fondo eventuali perdite e del fondo di gestione.

· Definizione dei termini. Determinazione dei tempi e della frequenza dei processi di gestione del rischio durante tutto il ciclo di vita del progetto, sviluppo di procedure per l'utilizzo delle riserve programmate per possibili perdite, nonché determinazione delle attività di gestione del rischio che saranno incluse nel programma di progetto.

· Categorie di rischi. Fornisce un mezzo per classificare le potenziali fonti di rischio. È possibile utilizzare diversi approcci, ad esempio una struttura basata sugli obiettivi del progetto per categoria. La struttura della gerarchia dei rischi (RBS) aiuta il team di progetto a considerare le numerose fonti da cui possono derivare i rischi di progetto durante il processo di identificazione dei rischi. Diversi tipi di progetti corrispondono a diverse strutture RBS. L'organizzazione può utilizzare uno schema di categorizzazione del rischio pre-progettato, che può assumere la forma di un semplice elenco di categorie o sotto forma di un RBS. RBS è una rappresentazione gerarchica dei rischi in base alle categorie di rischio.

· Determinazione della probabilità e dell'impatto dei rischi. Una buona e credibile analisi del rischio implica l'identificazione di diversi livelli di probabilità e impatto dei rischi nel contesto di un progetto. Le definizioni generiche dei livelli di probabilità e di impatto vengono adattate a un progetto specifico durante il processo di pianificazione della gestione del rischio e quindi utilizzate nei processi successivi. La tabella seguente fornisce un esempio delle definizioni di impatti negativi che possono essere utilizzate per valutare l'impatto dei rischi associati ai quattro obiettivi del progetto (si possono creare tabelle simili per gli impatti positivi). La tabella seguente mostra gli approcci relativi e numerici (in questo caso, non lineari).

· Matrice di probabilità e impatto. La matrice di probabilità e impatto è una tabella che mostra la probabilità che si verifichi ogni rischio e il suo impatto sugli obiettivi del progetto se si verifica. I rischi sono classificati in base alle loro probabili conseguenze, che possono influenzare gli obiettivi del progetto. Un modo tipico per stabilire le priorità consiste nell'utilizzare una tabella di ricerca o una matrice di probabilità e impatto. Tipicamente, l'organizzazione stessa determina le combinazioni di probabilità e impatto, in base alle quali il livello di rischio è determinato come “alto”, “medio” o “basso”.

· Raffinata tolleranza degli stakeholder. Durante il processo di pianificazione della gestione del rischio, la tolleranza degli stakeholder può essere adattata per adattarsi a un progetto specifico.

· Formati di segnalazione. I formati di rendicontazione determinano come i risultati del processo di gestione del rischio saranno documentati, analizzati e condivisi. I formati di rendicontazione descrivono il contenuto e il formato del registro dei rischi, nonché qualsiasi altra rendicontazione sui rischi richiesta.

· Tracciamento. Il monitoraggio documenta come tutte le attività relative al rischio vengono registrate ai fini di un determinato progetto e quando e come verranno controllati i processi di gestione del rischio.

Metodi grafici

I metodi del diagramma di rischio includono:

· Diagrammi delle relazioni di causa ed effetto. Questi diagrammi, noti anche come diagrammi di Ishikawa o diagrammi a lisca di pesce, vengono utilizzati per identificare le cause dei rischi.

· Diagrammi di flusso di un processo o sistema. Questo tipo di visualizzazione grafica mostra l'ordine di interazione tra i vari elementi del sistema e le loro relazioni di causa ed effetto.

· Diagrammi di influenza. Rappresentazione grafica di situazioni che mostrano relazioni di causa ed effetto, sequenze di eventi nel tempo e altre relazioni tra variabili e risultati.

Analisi SWOT

Questo metodo consente di analizzare il progetto dal punto di vista di ciascuno degli aspetti: punti di forza, di debolezza, opportunità e minacce (SWOT), che rende più completa l'identificazione dei rischi, tenendo conto dei rischi all'interno del progetto. Quando si utilizza questo metodo, si inizia identificando i punti di forza e di debolezza dell'organizzazione, concentrandosi sul progetto, sull'organizzazione o sull'area di business nel suo insieme. L'analisi SWOT identifica quindi tutte le opportunità di progetto che derivano dai punti di forza dell'organizzazione, nonché qualsiasi minaccia derivante dai suoi punti deboli. Questa analisi esamina anche come i punti di forza dell'organizzazione compensano le minacce e identifica le opportunità che possono essere utilizzate per superare i punti deboli.

Registro dei rischi

L'output principale del processo di identificazione dei rischi è l'iscrizione iniziale nel registro dei rischi. Il registro dei rischi è un documento contenente i risultati dell'analisi dei rischi e della pianificazione della risposta ai rischi. Il registro dei rischi raccoglie i risultati di altri processi di gestione dei rischi man mano che vengono implementati, determinando un aumento nel tempo del livello e della varietà delle tipologie di informazioni contenute nel registro dei rischi. La predisposizione del registro dei rischi inizia durante il processo di identificazione dei rischi, durante il quale il registro viene popolato con le seguenti informazioni. Queste informazioni vengono quindi messe a disposizione di altri processi relativi alla gestione dei progetti e alla gestione del rischio.

· Elenco dei rischi identificati. I rischi individuati sono descritti in modo sufficientemente dettagliato. Questo elenco può utilizzare una struttura specifica per descrivere i rischi, ad esempio: può verificarsi un EVENTO che avrà un IMPATTO oppure, se esiste una CAUSA, può verificarsi un EVENTO che avrà una CONSEGUENZA. Inoltre, costruendo un elenco di rischi identificati, le cause profonde di tali rischi possono diventare più evidenti. Si tratta di condizioni o eventi fondamentali in grado di innescare uno o più dei rischi individuati. Dovrebbero essere registrati e utilizzati per supportare l'identificazione dei rischi futuri in questo e altri progetti.

· Elenco delle possibili risposte. A volte il processo di identificazione dei rischi può identificare possibili risposte ad essi. Tali misure di risposta, se identificate durante questo processo, dovrebbero fungere da input per il processo di pianificazione della risposta al rischio.

Analisi qualitativa del rischio— il processo di definizione delle priorità dei rischi per ulteriori analisi o azioni valutando e confrontando il loro impatto e la probabilità che si verifichino. Un vantaggio chiave di questo processo è che consente ai project manager di ridurre l'incertezza e concentrarsi sui rischi ad alta priorità.

Analisi quantitativa del rischio- il processo di analisi numerica dell'impatto dei rischi individuati sugli obiettivi del progetto nel suo complesso. Un vantaggio chiave di questo processo è che fornisce informazioni quantitative sul rischio per supportare il processo decisionale al fine di ridurre l'incertezza del progetto.

Modalità di raccolta e presentazione delle informazioni

· Conduzione di un'intervista. Le tecniche di intervista forniscono esperienza e dati storici per quantificare la probabilità e l'impatto dei rischi sugli obiettivi del progetto. Le informazioni richieste dipendono dal tipo di distribuzione di probabilità utilizzata. Ad esempio, per alcuni dei modelli di distribuzione più utilizzati, è necessario raccogliere informazioni sullo scenario ottimistico (bassa probabilità), pessimistico (alta probabilità) e più probabile. Documentare le giustificazioni per gli intervalli di rischio e le ipotesi associate è un elemento importante dell'intervista sul rischio poiché questi documenti consentono di trarre conclusioni sull'affidabilità e la validità dell'analisi.

· Distribuzione di probabilità. Le distribuzioni di probabilità continue, ampiamente utilizzate nella modellazione e nella simulazione, rappresentano incertezze in valori come la durata delle attività di schedulazione e il costo delle componenti del progetto. Le distribuzioni discrete possono essere utilizzate per rappresentare eventi incerti, come i risultati dei test o possibili scenari dell'albero decisionale. Sulla fig. Di seguito sono riportati due esempi di distribuzioni continue comunemente utilizzate. Tali distribuzioni descrivono modelli coerenti con i dati tipicamente ottenuti dall'analisi quantitativa del rischio. Le distribuzioni uniformi possono essere utilizzate nei casi in cui non esiste un valore evidente più probabile di altri tra i limiti superiore e inferiore specificati, ad esempio in una fase di progettazione iniziale.

Metodi per l'analisi quantitativa e la modellazione del rischio

I metodi ampiamente utilizzati utilizzano approcci all'analisi basati sia sugli eventi che sui progetti, tra cui:

· Analisi di sensibilità. L'analisi di sensibilità aiuta a identificare i rischi con il maggiore impatto possibile sul progetto. Aiuta a capire come le variazioni negli obiettivi del progetto sono correlate alle variazioni nelle varie incertezze. D'altra parte, stabilisce la misura in cui l'incertezza di ciascun elemento del progetto influisce sull'obiettivo in studio, mentre tutti gli altri elementi incerti sono nei loro valori di base. Un modo tipico per visualizzare l'analisi della sensibilità è il grafico tornado (figura sotto), utile per confrontare l'importanza relativa e l'impatto di variabili che presentano un alto grado di incertezza con altre variabili più stabili. Il grafico tornado è utile anche nell'analisi degli scenari di assunzione di rischi applicati ad alcuni rischi, la cui analisi quantitativa indica che i possibili benefici sono maggiori dei corrispondenti impatti negativi individuati. Un grafico tornado è un tipo speciale di grafico a barre utilizzato nell'analisi di sensibilità per confrontare l'importanza relativa delle variabili. In un grafico tornado, l'asse y è ogni tipo di incertezza nei valori di base e l'asse x è la diffusione o la correlazione dell'incertezza sull'output in studio. In questa figura, ogni incertezza contiene una barra orizzontale (linea) e la verticale mostra le incertezze con spread decrescente rispetto ai valori di base.

· Analisi del valore monetario atteso. L'analisi del valore monetario atteso (EMV) è una tecnica statistica che calcola il risultato medio quando ci sono scenari futuri che potrebbero verificarsi o meno (ad esempio, analisi in condizioni di incertezza). L'EMV delle opportunità favorevoli è solitamente espresso in termini positivi e delle minacce - in termini negativi. L'EMV richiede un'assunzione neutrale al rischio, né soggetta a rischi eccessivi, né, al contrario, rifiutarla completamente. Per calcolare l'EMV per un progetto, è necessario moltiplicare il valore di ogni possibile risultato per la probabilità che si verifichi, quindi sommare i valori risultanti. Tipicamente, questo tipo di analisi viene utilizzato sotto forma di analisi dell'albero decisionale.

· Modellazione e imitazione. La simulazione del progetto utilizza un modello per determinare i possibili impatti di incertezze dettagliate sugli obiettivi del progetto. Le simulazioni vengono generalmente eseguite utilizzando il metodo Monte Carlo. Nella simulazione, il modello di progetto viene calcolato più volte (in modo iterativo) e per ogni iterazione, i valori di input (ad esempio stime di costo o durata delle operazioni) vengono scelti in modo casuale dalle distribuzioni di probabilità di queste variabili. Durante le iterazioni, viene calcolato un istogramma (ad esempio, il costo totale o la data di completamento). L'analisi del rischio di costo utilizza stime dei costi. L'analisi del rischio di pianificazione utilizza un diagramma di rete di pianificazione e stime della durata. L'output della simulazione del rischio di costo utilizzando un modello a tre elementi e intervalli di rischio è mostrato nella Figura 1. qui di seguito. La figura mostra la corrispondente probabilità di raggiungere determinati obiettivi di valore. Curve simili possono essere sviluppate per altri scopi di progetto.

Strategie per rispondere ai rischi negativi (minacce)

· Evasione. L'elusione del rischio è una strategia di risposta al rischio in cui il team di progetto agisce per eliminare la minaccia o proteggere il progetto dal suo impatto. Di norma, si tratta di modificare il piano di gestione del progetto in modo tale da eliminare completamente la minaccia. Il project manager può anche isolare gli obiettivi del progetto dall'esposizione al rischio o modificare l'obiettivo a rischio (ad esempio, espandere l'ambito del programma, modificare la strategia o ridurre l'ambito). La strategia di evitamento più radicale è terminare completamente il progetto. Alcuni rischi che si presentano all'inizio di un progetto possono essere evitati chiarendo i requisiti, ottenendo informazioni, migliorando le comunicazioni o acquisendo competenze.

· Trasmissione. Trasferimento del rischio - Una strategia di risposta al rischio in base alla quale il team di progetto trasferisce le conseguenze del verificarsi di una minaccia, insieme alla responsabilità di rispondere, a una terza parte. Quando un rischio viene trasferito, la responsabilità di gestirlo è trasferita a un altro soggetto; il rischio non è eliminato. Il trasferimento del rischio non significa rinuncia alla responsabilità dello stesso trasferendolo a un progetto futuro oa un'altra persona, senza avvisare quest'ultimo o concludere un accordo con lui. Il trasferimento del rischio comporta quasi sempre il pagamento di un premio di rischio alla parte che assume il rischio. Il trasferimento della responsabilità del rischio è più efficace in relazione ai rischi finanziari. Gli strumenti di trasferimento possono essere molto diversi e includono, ma non sono limitati a: l'uso di assicurazioni, performance bond, garanzie, ecc. Contratti o accordi possono essere utilizzati per trasferire la responsabilità di determinati rischi a un'altra parte. Ad esempio, quando l'acquirente ha opzioni che il venditore non ha, può essere ragionevole trasferire parte del lavoro e dei rischi associati all'acquirente tramite un contratto. In molti casi, il rischio di costo può essere trasferito all'acquirente in un contratto a costo rimborsabile, mentre il rischio può essere trasferito al venditore in un contratto a prezzo fisso.

· declino. La mitigazione del rischio è una strategia di risposta al rischio in cui il team di progetto agisce per ridurre la probabilità o l'impatto di un rischio. Implica la riduzione della probabilità e/o dell'impatto di un rischio avverso a livelli di soglia accettabili. L'azione precoce intrapresa per ridurre la probabilità che si verifichi un rischio e/o il suo impatto nel corso di un progetto è spesso più efficace dell'azione correttiva intrapresa dopo che il rischio si è verificato. Esempi di azioni di mitigazione del rischio includono l'implementazione di processi meno complessi, l'esecuzione di più test o la scelta di un fornitore più affidabile. Inoltre, la riduzione potrebbe richiedere lo sviluppo di un prototipo per ridurre il rischio di ridimensionamento del processo o del prodotto rispetto a un modello da banco. Se non è possibile ridurre la probabilità, le azioni di mitigazione dovrebbero concentrarsi sull'impatto del rischio, vale a dire quei collegamenti che determinano la gravità dell'impatto. Ad esempio, la progettazione della ridondanza del sistema può ridurre la gravità del guasto dell'elemento originale.

· Adozione. L'accettazione del rischio è una strategia di risposta al rischio in cui il team di progetto decide di riconoscere il rischio e di non intraprendere alcuna azione fino a quando il rischio non si verifica. Questa strategia viene utilizzata se qualsiasi altro modo per rispondere a un rischio particolare non è possibile o non è conveniente. Indica che il team di progetto ha deciso di non modificare il piano di gestione del progetto per affrontare il rischio o non è in grado di determinare un'altra strategia di risposta adeguata. Questa strategia può essere passiva o attiva. L'accettazione passiva non richiede alcuna azione se non la documentazione della strategia: il team di progetto dovrà affrontare i rischi man mano che si verificano e rivedere periodicamente la minaccia per assicurarsi che non sia cambiata in modo significativo. La strategia di accettazione attiva più comune consiste nel riservare eventuali perdite, comprese determinate quantità di tempo, denaro o risorse necessarie per gestire i rischi.

Strategie per rispondere ai rischi positivi (opportunità)

· Utilizzo. Una strategia di sfruttamento può essere scelta per rispondere ai rischi con un impatto positivo se è necessario dal punto di vista dell'organizzazione che l'opportunità sia garantita per essere realizzata. Questa strategia è progettata per eliminare l'incertezza associata a un particolare rischio positivo attraverso misure che garantiscano che l'opportunità venga realizzata. Le risposte dirette all'uso includono portare i migliori talenti dell'organizzazione al progetto per ridurre il tempo necessario per completare il progetto, o utilizzare tecnologie nuove o migliorate per ridurre i costi e il tempo necessari per raggiungere gli obiettivi del progetto.

· Aumento. Una strategia di aumento viene utilizzata per aumentare la probabilità e/o l'impatto positivo di un'opportunità. Identificare e massimizzare i fattori chiave alla base di questi rischi di impatto positivo può aumentare la probabilità che si verifichino. Esempi di opportunità crescenti includono l'allocazione di risorse aggiuntive a un'operazione per completarla in anticipo.

· Separazione. La condivisione positiva del rischio implica il trasferimento parziale o totale della responsabilità di un'opportunità a una terza parte che si trova in una posizione migliore per sfruttare l'opportunità a beneficio del progetto. Le attività di condivisione comprendono: la formazione di partnership di condivisione del rischio, team, società spin-off o joint venture, che possono essere costituite con il preciso scopo di raccogliere i frutti di un'opportunità per tutte le parti.

· Adozione. L'accettazione dell'opportunità è il desiderio di sfruttare un'opportunità se si presenta, senza perseguirla attivamente.

12. GESTIONE ACQUISTI DEL PROGETTO

Project Procurement Management include i processi di acquisto o acquisizione di prodotti, servizi o risultati necessari per realizzare un progetto al di fuori del team di progetto. Un'organizzazione può agire sia come acquirente che come venditore di prodotti, servizi o risultati di progetti.

Project Procurement Management include i processi di gestione dei contratti e i processi di controllo delle modifiche necessari per creare e amministrare i contratti o gli ordini di acquisto preparati dai membri autorizzati del team di progetto.

Tipi di contratto

· Contratti a prezzo fisso. Questo tipo di contratto prevede il costo fisso totale del prodotto, servizio o risultato consegnato. I contratti a prezzo fisso possono anche fornire incentivi finanziari per il raggiungimento o il miglioramento di determinati obiettivi del progetto, come date di consegna pianificate, prestazioni tecniche e di costo o altri indicatori quantificabili e misurabili. In base ai contratti a prezzo fisso, i venditori sono legalmente tenuti a onorare tali contratti o incorrere in possibili perdite finanziarie se non lo sono. Gli acquirenti, in conformità con le disposizioni di tali contratti, sono tenuti a identificare con precisione il prodotto o servizio oggetto di acquisto. Possono verificarsi modifiche al contenuto, ma di norma ciò comporta un aumento del prezzo del contratto.

o Contratti fissi a prezzo fisso (FFP). Il tipo di contratto più utilizzato è il FFP. La maggior parte delle organizzazioni acquirenti preferisce questo tipo di contratto, poiché il prezzo delle merci è fissato all'inizio e non è soggetto a modifiche se il contenuto dell'opera non cambia. L'eventuale aumento di valore causato da una performance negativa è a carico del venditore, che è obbligato a portare a termine l'opera. In base alla FFP, l'acquirente è tenuto a identificare accuratamente il prodotto o servizio acquistato e qualsiasi modifica alle specifiche di acquisto può aumentare i costi dell'acquirente.

o Contratti con tariffa incentivante a prezzo fisso (FPIF). Questo accordo a prezzo fisso offre all'acquirente e al venditore una certa flessibilità, in quanto consente una deviazione dalla prestazione e fornisce incentivi finanziari per soddisfare le metriche concordate. Di norma, tali incentivi finanziari sono associati a costi, tempi o prestazioni tecniche da parte del venditore. I valori target degli indicatori di prestazione sono fissati all'inizio e il prezzo finale del contratto è determinato dopo il completamento di tutti i lavori, a seconda della loro prestazione da parte del venditore. Sotto FPIF, c'è un tetto di prezzo e tutti i costi al di sopra del tetto di prezzo sono a carico del venditore, che è obbligato a completare il lavoro.

o Prezzo fisso con Contratti di adeguamento dei prezzi economici (FP-EPA). Questo tipo di contratto viene utilizzato se l'esecuzione del contratto da parte del venditore si estende per un periodo di tempo significativo, che di solito è ricercato nei rapporti a lungo termine. Un contratto con un prezzo fisso, ma con una disposizione speciale che consente adeguamenti finali predeterminati al valore del contratto a causa del cambiamento delle condizioni, come l'inflazione o l'aumento (diminuzione) dei prezzi di determinati beni. La clausola di adeguamento del prezzo deve essere collegata ad un indice finanziario affidabile utilizzato per adeguare con precisione il prezzo finale. FP-EPA è progettato per proteggere sia l'acquirente che il venditore da condizioni esterne che non possono controllare.

· Contratti di rimborso spese. Questo tipo di contratto prevede il pagamento (rimborso) al venditore di tutti i costi effettivi legittimi sostenuti in conseguenza dell'esecuzione dell'opera, oltre alla remunerazione che costituisce il suo profitto. I contratti a costo rimborsabile spesso includono clausole che forniscono incentivi per il superamento o il miglioramento degli obiettivi del progetto (ad esempio, costi, tempi o prestazioni). I tre tipi più comuni di contratto di rimborso dei costi sono: contratto a tariffa fissa Cost Plus (CPFF), contratto a tariffa incentivante Cost Plus (CPIF), contratto a tariffa fissa Cost Plus, remunerazione CPIF (contratto Cost Plus Award Fee, CPAF). Un contratto a costo rimborsabile offre flessibilità al progetto consentendo modifiche alle istruzioni per il venditore nel caso in cui l'ambito del lavoro non possa essere descritto accuratamente all'inizio e debba essere regolato, o vi siano rischi elevati durante l'esecuzione del lavoro.

o Contratti di rimborso spese più canone fisso (CPFF). Il venditore viene rimborsato per tutti i costi concordati per l'esecuzione del lavoro previsto dal contratto e riceve anche un compenso fisso, che è una certa percentuale del costo stimato originale del progetto. La retribuzione viene pagata solo per il lavoro completato e non cambia a seconda della prestazione del venditore. Gli importi della remunerazione non cambiano se il contenuto del progetto non cambia.

o Contratti Cost Reimbursement Plus Incentive (CPIF). Il venditore riceve il rimborso di tutti i costi pattuiti per l'esecuzione dei lavori previsti dal contratto, nonché un compenso di incentivazione predeterminato per il raggiungimento di specifici indicatori di prestazione previsti nel contratto. I contratti CPIF prevedono che se il costo finale è maggiore o minore del costo originario stimato, i risparmi/eccessivi spese sono distribuiti tra il venditore e l'acquirente in un rapporto predeterminato, ad esempio, nel rapporto di 80/20 della differenza tra i costi pianificati e la prestazione effettiva del venditore.

o Contratti Cost-Reimbursement-Plus-Award (CPAF). Il venditore viene rimborsato di tutti i costi ragionevoli, ma la maggior parte del corrispettivo viene pagata solo sulla base del rispetto di una serie di criteri di prestazione soggettivi ampiamente interpretati definiti nel contratto. La determinazione del compenso si basa esclusivamente sulla valutazione soggettiva dell'acquirente sull'esecuzione del contratto da parte del venditore e generalmente non è impugnabile.

· Contratti "tempo e materiali"(Contratti di tempo e materiali, T&M). I contratti di tempo e materiali sono un tipo misto di accordo contrattuale, contenente disposizioni sia per il rimborso dei costi che per i contratti a prezzo fisso. Sono spesso utilizzati per l'aumento del personale, l'inserimento di esperti e per l'eventuale supporto di terze parti nei casi in cui non è possibile creare rapidamente una descrizione del lavoro accurata. Questi tipi di contratti sono simili ai contratti di rimborso dei costi in quanto consentono modifiche e aumenti di valore per l'acquirente. Al momento della conclusione del contratto, l'acquirente potrebbe non indicare il valore totale del contratto e il numero esatto degli articoli da consegnare. Pertanto, il costo dei contratti T&M può aumentare, come nei contratti rimborsabili. Per prevenire una crescita illimitata del valore, molte organizzazioni richiedono che i limiti di prezzo e di tempo siano inclusi in tutti i contratti T&M. D'altra parte, i contratti T&M possono anche assomigliare ad accordi a prezzo fisso in cui determinati parametri sono specificati nel contratto. Le tariffe orarie del lavoro o i costi dei materiali, compreso il profitto del venditore, possono essere predeterminati dall'acquirente e dal venditore se entrambe le parti concordano sul costo di determinate categorie di risorse, come una certa tariffa oraria per i capo ingegneri o un determinato prezzo per unità di materiale .

13. GESTIONE DEGLI STAKEHOLDER

La gestione degli stakeholder del progetto include i processi necessari per identificare le persone, i gruppi e le organizzazioni che possono o possono essere interessati dal progetto, per analizzare le aspettative degli stakeholder e il loro impatto sul progetto e per sviluppare strategie di gestione appropriate per un coinvolgimento efficace. ed esecuzione del progetto. La gestione delle parti interessate si concentra anche sulla comunicazione continua con le parti interessate per comprendere le loro esigenze e aspettative, rispondere ai problemi quando si presentano, gestire interessi in conflitto e facilitare un coinvolgimento appropriato delle parti interessate nel processo decisionale e nelle operazioni di progetto. La soddisfazione degli stakeholder dovrebbe essere gestita come uno degli obiettivi chiave del progetto.

Nell'analisi degli stakeholder vengono utilizzati vari modelli di classificazione, come ad esempio:

· matrice potere/interesse, raggruppare le parti interessate in base al loro livello di autorità ("autorità") e livello di interesse ("interesse") in relazione ai risultati del progetto;

· matrice potere/influenza raggruppare le parti interessate in base al loro livello di autorità ("potere") e coinvolgimento attivo ("influenza") nel progetto;

· matrice di influenza/impatto, raggruppare le parti interessate in base al loro coinvolgimento attivo ("influenza") nel progetto e alla loro capacità di portare a cambiamenti nella pianificazione o nell'esecuzione del progetto ("impatto");

· modello di caratteristiche, che descrive le classi di stakeholder in funzione del loro livello di potere (la capacità di imporre la propria volontà), dell'urgenza (la necessità di un'azione immediata) e della legittimità (il loro coinvolgimento è appropriato).

I livelli di coinvolgimento degli stakeholder possono essere classificati come segue:

· Disinformato. Lo stakeholder non è a conoscenza del progetto e dei potenziali impatti.

· resistere. Lo stakeholder è consapevole del progetto e dei potenziali impatti e resiste al cambiamento.

· Neutro. Lo stakeholder è a conoscenza del progetto, ma non sostiene né resiste al cambiamento.

· supporto. Lo stakeholder è consapevole del progetto, dei potenziali impatti ed è favorevole ai cambiamenti.

· Primo. Lo stakeholder è a conoscenza del progetto, dei potenziali impatti ed è attivamente coinvolto nel garantire il successo del progetto.

L'output principale del processo di identificazione degli stakeholder è il registro degli stakeholder. Contiene tutti i dettagli relativi agli stakeholder che sono stati identificati, inclusi ma non limitati a:

· Informazioni di identificazione: nome completo, posizione nell'organizzazione, ubicazione, ruolo nel progetto, informazioni di contatto.

· Informazioni sulla valutazione: requisiti e aspettative di base, potenziale impatto sul progetto, la fase più interessante del ciclo di vita del progetto.

Classificazione degli stakeholder: interni/esterni, solidali/neutrali/resisteri, ecc.

Oltre ai dati del registro degli stakeholder, un piano di gestione degli stakeholder spesso contiene anche:

· il livello di coinvolgimento desiderato e attuale delle principali parti interessate;

la portata e l'impatto del cambiamento sugli stakeholder;

· Relazioni identificate e potenziale intersezione degli stakeholder;

· requisiti delle parti interessate alle comunicazioni nella fase attuale del progetto;

informazioni sulle informazioni diffuse alle parti interessate, inclusi lingua, formato, contenuto e livello di dettaglio;

· il motivo della diffusione di tali informazioni e l'impatto previsto sul livello di coinvolgimento degli stakeholder;

tempi e frequenza di diffusione delle informazioni richieste agli interessati;

· un metodo per aggiornare e perfezionare il piano di gestione degli stakeholder man mano che il progetto avanza e si evolve.

Guida al Project Management Body of Knowledge (Guida PMBOK)

Record bibliografico della Biblioteca del Congresso degli Stati Uniti


Titoli: Project Management Institute (PMI), editore.

Titolo: Una guida al corpus di conoscenze sulla gestione dei progetti (guida PMBOK) / Project Management Institute.

Altri titoli: Guida PMBOK

Descrizione: Sesta edizione | Newtown Square, Pennsylvania: Project Management Institute, 2017. | Serie: Guida PMBOK |

Identificatori: LCCN 2017032505 (stampa) | LCCN 2017035597 (ebook) | ISBN 9781628253900 (ePUP) |

ISBN 9781628253917 (accendere) | ISBN 9781628253924 (PDF Web) | ISBN 9781628251845 (brossura)

Oggetto: LCSH: Gestione del progetto. | BISAC: BUSINESS AND ECONOMICS / Project Management (BUSINESS & ECONOMICS / Project Management).

Classificazione: LCC HD69.P75 (ebook) | LCC HD69.P75 G845 2017 (stampa) | DDC 658.4/04-dc23

Record LC disponibile su https://lccn.loc.gov/2017032505


Project Management Institute, Inc.

Viale Campus 14

Newtown Square, Pennsylvania 19073-3299 USA

Telefono: +1 610-356-4600

Fax: +1 610-356-4647

E-mail posta: [email protetta]

Sito web: https://www.PMI.org


Atti del Project Management Institute, Inc. sono protetti da copyright ai sensi della legge statunitense sulla proprietà intellettuale, riconosciuta nella maggior parte dei paesi. È necessario ottenere la nostra autorizzazione per ripubblicare o riprodurre i materiali PMI. Per ulteriori informazioni, visitare http://www.pmi.org/permissions_for_details.


Per effettuare un ordine commerciale o per informazioni sui prezzi, contattare l'Independent Publishers Group:

Gruppo editori indipendenti

Reparto ordini

814 North Franklin Street

Chicago, IL 60610 USA

Telefono: +1 800-888-4741

Fax: +1 312-337-5985

E-mail posta: [email protetta](solo per ordini)


Per tutte le altre domande, contattare il PMI Book Service Center.

PMI Book Service Center

PO Box 932683, Atlanta, GA 31193-2683 USA

Telefono: 1-866-276-4764 (USA o Canada) o +1-770-280-4129 (in tutto il mondo)

Fax: +1-770-280-4113

E-mail posta: [email protetta]


Stampato negli Stati Uniti d'America Nessuna parte di questa pubblicazione può essere riprodotta o trasmessa in qualsiasi forma o con qualsiasi mezzo, elettronico, manuale, fotocopie, registrazione o per mezzo di qualsiasi sistema di archiviazione e recupero delle informazioni, senza la preventiva autorizzazione del editore.


PMI, logo PMI, PMBOK, OPM3, PMP, CAPM, PgMP, PfMP, PMI-RMP, PMI-SP, PMI-ACP, PMI-PBA, PROJECT MANAGEMENT JOURNAL, PM NETWORK, PMI TODAY, PULSE OF THE PROFESSIONE e motto MAKING PROJECT MANAGEMENT INDISPENSABILE PER I RISULTATI AZIENDALI.

sono marchi di Project Management Institute, Inc. Per un elenco completo dei marchi PMI, contattare l'Ufficio legale di PMI. Tutti gli altri marchi, marchi di servizio, nomi commerciali, vestiti commerciali, nomi di prodotti e loghi che appaiono in questo documento sono di proprietà dei rispettivi proprietari. Tutti i diritti non espressamente concessi in questo documento sono riservati al titolare del copyright.

Tutti i diritti riservati. È vietata la riproduzione del libro in tutto o in parte in qualsiasi forma senza il permesso scritto dell'editore.


© Copyright 2017 Project Management Institute, Inc. Tutti i diritti riservati.

© Traduzione in russo, edizione, casa editrice di design "Olimp - Business", 2018

Notifica

Pubblicato dal Project Management Institute, Inc., PMI in breve, gli standard e le linee guida, a cui appartiene questo documento, sono stati sviluppati attraverso un processo di sviluppo di standard volontario e basato sul consenso. Questo processo riunisce i volontari e/o riunisce i commenti e le opinioni di persone interessate all'argomento trattato in questa pubblicazione. Sebbene PMI gestisca questo processo e stabilisca regole per garantire che il consenso sia raggiunto senza pregiudizi, PMI non scrive il documento né testa, valuta o verifica in modo indipendente l'accuratezza o la completezza del materiale contenuto negli standard e nelle linee guida pubblicate da PMI. Allo stesso modo, PMI non esamina la validità delle opinioni espresse in questi documenti.

PMI non sarà responsabile per eventuali lesioni, danni alla proprietà o qualsiasi altra perdita, speciale, consequenziale o esemplare, derivante direttamente o indirettamente dalla pubblicazione, dall'uso o dall'uso di questo documento. PMI non rilascia dichiarazioni o garanzie, esplicite o implicite, in merito all'accuratezza o alla completezza di qualsiasi materiale contenuto in questo documento e non rilascia dichiarazioni o garanzie che le informazioni contenute in questo documento soddisferanno i tuoi scopi o esigenze. . PMI non garantisce la qualità dei prodotti o servizi dei singoli produttori o fornitori derivanti dall'uso di questo standard o guida.

Nella pubblicazione e distribuzione di questo documento, PMI non fornisce servizi professionali o di altro tipo a o per conto di persone o entità; né PMI adempie agli obblighi di qualsiasi persona o entità nei confronti di terzi. Nell'utilizzare questo documento, l'utente di questo documento dovrebbe determinare da solo quale azione è necessaria nelle circostanze, basandosi esclusivamente sul proprio giudizio o, se necessario, sul consiglio di un professionista competente. Le informazioni sull'argomento trattato dal presente documento o dalle relative norme possono essere ottenute da altre fonti, a cui l'utente può fare riferimento, se necessario, per ulteriori informazioni non contenute nel presente documento.

PMI non ha autorità e non si assume alcun obbligo di monitorare la conformità delle pratiche esistenti al contenuto del presente documento o di allineare tali pratiche al presente documento. PMI non certifica, testa o ispeziona prodotti, progetti o progetti per il funzionamento sicuro o la sicurezza per la salute dei consumatori. Qualsiasi certificazione o altra affermazione di conformità a una qualsiasi delle informazioni sulla sicurezza o sulla salute contenute nel presente documento non può essere attribuita a PMI; in tal caso, la responsabilità è interamente a carico di chi ha rilasciato il certificato o ha fatto tale affermazione.

Parte 1. Guida al Project Management Body of Knowledge (Guida PMBOK®)

1. Introduzione
1.1 Panoramica e scopo di questo manuale

La gestione dei progetti non è una novità. Le persone lo usano da secoli. Esempi di progetti completati includono:

Piramidi a Giza

Olimpiadi,

Grande Muraglia cinese

Taj Mahal,

Pubblicazione di un libro per bambini

Canale di Panama,

Creazione di aerei a reazione commerciali,

vaccino polio,

Far sbarcare un uomo sulla luna

Programmi applicativi per computer commerciali,

Dispositivi portatili per l'utilizzo del sistema di posizionamento globale (GPS),

Il lancio della Stazione Spaziale Internazionale nell'orbita terrestre.


I risultati pratici di questi progetti sono stati il ​​risultato dell'applicazione da parte di leader e manager nel loro lavoro di pratiche, principi, processi, strumenti e metodi di gestione dei progetti. I project manager hanno utilizzato una serie di competenze chiave e applicato le conoscenze necessarie per soddisfare i propri clienti e le altre persone coinvolte o interessate dal progetto. Entro la metà del 20° secolo, i project manager hanno iniziato a lavorare per il riconoscimento del project management come professione. Un aspetto di questo lavoro è stato il raggiungimento di un accordo sul contenuto del corpus di conoscenze (BOK) chiamato project management. Il WOK diventa noto come Project Management Body of Knowledge (PMBOK). Il Project Management Institute (PMI) ha creato gli schemi di base e i glossari per PMBOK. I project manager si sono presto resi conto che PMBOK non poteva essere contenuto completamente in un libro. Pertanto, PMI ha sviluppato e pubblicato "Guida al Project Management Body of Knowledge" (Guida PMBOK®).

Secondo la definizione PMI, Project Management Body of Knowledge (PMBOK) è un termine che descrive la conoscenza all'interno della professione di project management. Il corpus di conoscenze sulla gestione del progetto comprende pratiche tradizionali comprovate e ampiamente utilizzate, nonché pratiche innovative emergenti.

Il Body of Knowledge (BQK) include materiale pubblicato e non pubblicato. Questo corpo di conoscenze è in continua evoluzione. Il presente Guida PMBOK® evidenzia quella parte del Project Management Body of Knowledge che è generalmente accettata come buona pratica.


? generalmente riconosciuto significa che le conoscenze e le pratiche descritte sono applicabili alla maggior parte dei progetti nella maggior parte dei casi e c'è consenso sul loro valore e utilità.

? Buona pratica significa che vi è generalmente accordo sul fatto che la corretta applicazione di queste conoscenze, abilità, strumenti e metodi ai processi di gestione dei progetti può aumentare le probabilità di successo in un'ampia gamma di progetti diversi per raggiungere i valori e i risultati aziendali attesi.


Il project manager lavora con il team di progetto e altre parti interessate per identificare e utilizzare le buone pratiche accettate per ogni progetto. La determinazione della combinazione appropriata di processi, input, strumenti, metodi, output e fasi del ciclo di vita per la gestione del progetto viene definita "personalizzazione" delle conoscenze descritte in questa Guida.

Il presente Guida PMBOK® non è una metodologia La metodologia è un sistema di pratiche, metodi, procedure e regole utilizzate in un particolare campo di attività. Il presente Guida PMBOK®è la base su cui un'organizzazione può sviluppare le proprie metodologie, politiche, procedure, regole, strumenti e metodi, nonché le fasi del ciclo di vita richieste nella pratica di project management.

1.1.1 Standard di gestione del progetto

Questa guida si basa su Standard di gestione del progetto. Uno standard è un documento stabilito da un organismo autorizzato, consuetudine o di comune accordo come modello o campione. Standard di gestione del progettoè stato sviluppato come standard ANSI (American National Standards Institute) utilizzando un processo basato su consenso, apertura, giusto processo ed equilibrio. Standard di gestione del progettoè il riferimento fondamentale per i programmi di sviluppo professionale e le pratiche di gestione dei progetti di PMI. Poiché è necessario adattare la gestione del progetto per soddisfare le esigenze di un particolare progetto, su cui si basano sia lo Standard che la Guida descrittivo, ma no direttiva pratiche. In quanto tale, questo Standard definisce i processi che sono buone pratiche per la maggior parte dei progetti nella maggior parte dei casi. La presente norma definisce anche gli input e gli output che sono tipicamente associati a questi processi. La norma non contiene requisiti per l'attuazione obbligatoria di determinati processi o pratiche specifiche. Standard di gestione del progetto incluso nella parte II Linee guida per il Project Management Body of Knowledge (Guida PMBOK®).

V Guida PMBOK® maggiori dettagli su concetti chiave, tendenze emergenti, considerazioni sulla personalizzazione dei processi di gestione dei progetti e informazioni su come applicare strumenti e tecniche ai progetti. I project manager possono utilizzare una o più delle metodologie nell'attuazione dei processi di project management descritti nella presente norma.

? Standard di gestione del portafoglio, e

? Standard di gestione del programma .

1.1.2 Vocabolario generale

Un vocabolario comune è un elemento essenziale di qualsiasi disciplina professionale. Lessico PMI dei termini di Project Management fornisce un vocabolario di base della terminologia professionale che organizzazioni, project, program e portfolio manager e altre parti interessate del progetto possono utilizzare in modo coerente. Lessico si svilupperà nel tempo. Il Glossario di questa Guida include un glossario di Lessico termini, nonché ulteriori definizioni. I progetti possono utilizzare altri termini specifici del settore, come definito nella letteratura del settore.

1.1.3 Codice Etico e di Condotta Professionale

Pubblica PMI creare fiducia nella professione di project manager e aiutare l'individuo a prendere decisioni corrette, specialmente in situazioni difficili in cui potrebbe essere chiesto di agire in modo disonesto o compromettere i suoi valori. I valori che la comunità globale del project management ha identificato come i più importanti sono la responsabilità, il rispetto, l'equità e l'onestà. Questi quattro valori sono alla base del Codice Etico e di Condotta Professionale.

Codice deontologico e di condotta professionale comprende sia standard di incentivazione che obbligatori. Gli standard di incentivazione descrivono il comportamento a cui dovrebbero aspirare i professionisti che sono anche membri del PMI, titolari di certificati o volontari in virtù delle loro convinzioni interiori. Sebbene non sia facile valutare il rispetto degli standard di incentivazione, da parte di quei professionisti che si considerano professionisti è previsto un comportamento conforme agli stessi, ovvero tali standard non possono essere considerati facoltativi. Gli standard obbligatori sono requisiti obbligatori e, in alcuni casi, limitano o vietano determinati comportamenti dei professionisti. I professionisti che sono contemporaneamente membri PMI, titolari di certificati o volontari che violano questi standard nelle loro attività sono soggetti alle procedure disciplinari del Comitato Etico PMI.

1.2 Elementi costitutivi

Questa sezione descrive gli elementi fondamentali necessari per lavorare sul campo e comprendere la disciplina del project management.

1.2.1 Progetti

Un progetto è uno sforzo temporaneo per creare un prodotto, un servizio o un risultato unico.


? Prodotto, servizio o risultato unico. I progetti vengono implementati per raggiungere gli obiettivi creando risultati. L'obiettivo è il risultato finale a cui il lavoro dovrebbe essere indirizzato; la posizione strategica da assumere; problema da risolvere; il risultato da ottenere; il prodotto da produrre; o servizio da fornire. Un deliverable è qualsiasi prodotto, risultato o capacità unica e verificabile di fornire un servizio necessario per completare un processo, una fase o un progetto. I risultati possono essere materiali o immateriali.


Il raggiungimento degli obiettivi del progetto può produrre uno o più dei seguenti risultati:

Un prodotto unico, che può essere un componente di un altro prodotto, un miglioramento o una correzione di un prodotto o un nuovo prodotto finale in sé (ad esempio, correzione di un difetto nel prodotto finale);

Servizio unico o capacità di fornire un servizio (ad esempio, un'unità aziendale che supporta la produzione o la distribuzione);

Un risultato unico, come un risultato finale o un documento (ad esempio, un progetto di ricerca porta nuove conoscenze che possono essere utilizzate per determinare se c'è una tendenza o un vantaggio per la società in qualche nuovo processo);

Una combinazione univoca di uno o più prodotti, servizi o risultati (ad esempio, un'applicazione software, documentazione associata e servizi di help desk).


Alcuni elementi possono essere ripetuti in alcuni risultati finali e attività di progetto. Questa ripetizione non cambia le caratteristiche fondamentali e uniche del project work. Ad esempio, gli edifici per uffici possono essere costruiti con gli stessi materiali o dallo stesso team di costruzione. Tuttavia, ogni progetto di costruzione rimane unico nelle sue caratteristiche principali (es. posizione, design, ambiente, ambientazione, persone coinvolte).

I progetti sono intrapresi a tutti i livelli dell'organizzazione. Una o più persone possono partecipare a un progetto. Il progetto può coinvolgere un'unità strutturale dell'organizzazione o più unità strutturali di diverse organizzazioni.

Esempi di progetti includono, tra gli altri:

Sviluppo di nuovi farmaci per il mercato;

Ampliamento dei servizi turistici escursionistici;

Fusione di due organizzazioni;

Migliorare il processo di business nell'organizzazione;

Approvvigionamento e installazione di nuovo hardware per computer da utilizzare nell'organizzazione;

Esplorazione di giacimenti petroliferi nella regione;

Modifica di un programma per computer utilizzato in un'organizzazione;

Condurre ricerche per sviluppare un nuovo processo produttivo;

Costruzione di edifici.

? Impresa temporanea. La natura temporanea dei progetti indica la presenza di un inizio e di una fine definiti. La definizione di "temporaneo" non significa necessariamente che il progetto sia concepito per un breve periodo. La fine del progetto si verifica quando una o più delle seguenti affermazioni sono vere:

Obiettivi del progetto raggiunti;

Gli obiettivi non saranno o non potranno essere raggiunti;

I finanziamenti per il progetto sono esauriti o non possono più essere stanziati;

La necessità del progetto è scomparsa (ad esempio, il cliente non vuole più che il progetto sia completato, un cambiamento nella strategia o nelle priorità richiede la conclusione del progetto, la direzione dell'organizzazione ordina la conclusione del progetto);

Risorse umane o materiali esaurite;

Il progetto è terminato per motivi legali o di convenienza.

I progetti sono temporanei, ma i risultati finali possono esistere dopo la fine del progetto. I progetti possono fornire risultati sociali, economici, materiali o ambientali. Ad esempio, un progetto di monumento nazionale produce un risultato che dovrebbe durare per secoli.

? I progetti guidano il cambiamento. I progetti sono la forza trainante del cambiamento nelle organizzazioni. Dal punto di vista aziendale, l'obiettivo di un progetto è spostare un'organizzazione da uno stato all'altro per raggiungere un obiettivo specifico (vedere la Figura 1-1). Si presume generalmente che prima dell'inizio del progetto, l'organizzazione sia nel suo stato iniziale. E il risultato desiderato di un cambiamento nel corso di un progetto è descritto come uno stato futuro.


Alcuni progetti possono comportare la creazione di uno stato di transizione, in cui diversi passaggi si susseguono l'uno dall'altro per raggiungere uno stato futuro. Il risultato del completamento con successo del progetto è il passaggio dell'organizzazione allo stato futuro e il raggiungimento di un obiettivo specifico. Per ulteriori informazioni sulla gestione dei progetti e delle modifiche, consultare il documento "Gestione del cambiamento nelle organizzazioni: una guida pratica" (Governo di portafogli, programmi e progetti: una guida pratica).


Riso. 1–1. Transizione dell'organizzazione in un nuovo stato con l'aiuto del progetto


? I progetti creano valore aziendale. Il PMI definisce il valore aziendale come il beneficio netto e quantificabile derivato da un'impresa. I vantaggi possono essere tangibili, immateriali o entrambi. Nell'analisi aziendale, il valore aziendale è considerato il vantaggio ricevuto in forme quali tempo, denaro, beni o attività immateriali in cambio di un qualche tipo di investimento. Centimetro. Analisi aziendale per i professionisti: una guida pratica, p. 185.


Il valore aziendale dei progetti è inteso come il vantaggio che gli stakeholder ricevono come risultato dell'attuazione di un particolare progetto. I vantaggi di un progetto possono essere tangibili, immateriali o entrambi.

Esempi di elementi materiali includono:

Contanti,

capitale sociale,

Ingegneria delle reti,

immobilizzazioni,

PMBOK-5 ® Guide rappresenta una buona pratica generalmente riconosciuta nella professione di project management.

Come scaricare PMBOK?

La nuova Guida PMBOK 5a edizione è stata pubblicata il 31 dicembre 2008. È ora disponibile per tutti i membri PMI alla pagina seguente:

Troverai un link con il titolo A Guide to the Project Management Body of Knowledge (PMBOK. Guide), quinta edizione che verrà utilizzato per acquistare questa versione di PMBOK. Quindi fai clic su questo link che ti darà la possibilità di aggiungere una copia dello standard nel tuo carrello. Al momento il suo prezzo è di $ 65,95 per i non membri e $ 49,50 per i membri di PMI. Infine fai un checkout e scarica la sua versione PDF. La procedura seguente deve essere adottata durante il download della copia di PMBOK 5.

Utenti Windows:

Quando si fa clic sulla versione russa per scaricare PMBOK ® Guide 5a edizione, viene visualizzato un messaggio simile a "Il sistema FileOpen associa i permessi dei membri alla pubblicazione" e viene richiesto di scaricare e installare il plug-in FileOpen Adobe Reader.

Questo passaggio è necessario solo per il primo utilizzo. Fare clic su Sì per avviare l'installazione del plug-in Adobe Reader." Quindi, dopo aver installato con successo il plug-in Fileopen, chiudere la finestra e tornare indietro e scaricare, ma per accedere è necessario essere un membro PMI.

Utenti Mac:

Mac utilizza Safari, che apre i PDF nel browser. Non può funzionare se la sicurezza e altre funzioni avanzate sono integrate nel PDF. Ciò richiede l'installazione di una versione completa di PDF Reader o Adobe Acrobat.

Ecco il commento del supporto APPLE sulla lettura di PDF con Safari. Adobe PDFViewer per Mac OS X non funzionerà correttamente su un sistema che non soddisfa i seguenti requisiti.