Project management
Da Wikipedia, l'enciclopedia libera.
« Se qualcosa può andare storto, lo farà. »
(Legge di Murphy)
Con l'espressione inglese project management, detto anche gestione di progetto o gestione di
progetti[1] si intende l'insieme di attività volte alla realizzazione degli scopi/obiettivi di un progetto.
Un progetto è uno sforzo delimitato nel tempo (con una data di partenza e una di completamento) diretto a
creare dei prodotti e/o servizi e/o risultati specifici che comportano dei benefici o del valore aggiunto al
committente/cliente.
Secondo il PMBOK[2] (pubblicato dal PMI) il project management è l'applicazione di conoscenze, attitudini,
tecniche e strumenti alle attività di un progetto al fine di conseguirne gli obiettivi.
La collocazione in un arco temporale finito distinguono il progetto dai processi operativi di un'azienda (le
cosiddette attività di routine) che sono invece permanenti o semi-permanenti e sono diretti a produrre in
modo ripetitivo lo stesso prodotto o servizio. Proprio la diversa natura di queste attività richiede lo sviluppo
di filosofie, attitudini e approcci diversi per la loro gestione.
La sfida principale del project management è quella di raggiungere gli obiettivi del progetto restando
all'interno del perimetro costituito dai classici vincoli determinati dal contesto del committente, solitamente
il costo, il tempo e lo scopo (nel senso anche della qualità). La sfida secondaria - ma non meno ambiziosa è quella di ottimizzare l'allocazione delle risorse e integrare gli input necessari a raggiungere gli obiettivi
definiti. Queste sfide infine devono essere portate avanti risolvendo i problemi e mitigando i rischi che
ciascun progetto, in misura diversa, troverà comunque lungo la sua strada (con un po' di ironia si potrebbe
considerare il project managementcome la risposta scientifica alla Legge di Murphy).
Il project management moderno è una cultura che viene soprattutto dall'esperienza derivante dalla gestione
di progetti complessi. Tra i primi a sottolineare questo approccio sia come Project Manager che come
consulente delle maggiori Società, Imprese e Committenti è stato Russel D. Archibald.
L'ingegneria gestionale si evolse e, grazie al lavoro pionieristico di Hans Lang e altri, vennero sviluppate
tecnologie per la stima dei costi di progetto e per la gestione dei costi. Nel 1956 venne fondata la
"American Association of Cost Engineers" (ora AACE International - "Association for the Advancement of
Cost Engineering") da parte dei primi cultori del project management e delle prassi correlate
(pianificazione, stima dei costi, controllo di progetto costi/pianificazione). La AACE ha continuato la sua
attività di sviluppo degli standard tecnologici e nel 2006 ha rilasciato il "Total Cost Management
Framework" (versione PDF del libro) sviluppato da John Hollman[5].
Nel 1969 venne fondato il Project Management Institute (PMI) con l'obiettivo di diffondere e rafforzare le
prassi di project managementattraverso l'affermazione di uno standard, sulla base della convinzione che i
diversi campi di applicazione del project management, dall'Edilizia alla Ingegneria del software avessero
una larga base comune nelle tecnologie e nelle metodologie di gestione dei progetti. Nel 1981 il Comitato
Direttivo del PMI autorizzò lo sviluppo della Guida al "Project Management Body of Knowledge" (altrimenti
noto come PMBOK), contenente una guida completa e sintetica degli standard e delle linee guida
indispensabili per le prassi di project management. L'International Project Management
Association (IPMA), fondata in Europa nel 1967, ha intrapreso una direzione simile istituendo l'IPMA
Competence Baseline (ICB). Entrambe le organizzazioni stanno partecipando ora allo sviluppo di uno
standard ISOper il project management.
Il ruolo del Project Manager [modifica]
Per approfondire, vedi la voce project manager.
La gestione di un progetto è solitamente demandata a un project manager, che a volte partecipa
direttamente alle attività che lo compongono, ma principalmente si focalizza nel coordinamento e nel
controllo delle varie componenti e dei diversi attori coinvolti con l'obiettivo di minimizzare la probabilità di
insuccesso.
Al completamento del progetto di solito il prodotto o servizio realizzato vengono presi in carico da una
figura operativa diversa, tipicamente il Product Manager o il Service Manager.
In progetti di grande respiro, l'attività di project management può essere delegata a più persone: si realizza
quindi un gruppo di project management. Comunemente nel gruppo esiste un leader che viene comunque
chiamato project manager, a questo si affiancano altre persone che si occupano delle attività di
management di parti del progetto secondo una vista per componenti del sistema o per aree specifiche.
Questi vengono detti talvolta task manager.
Concetti e tecniche fondamentali [modifica]
Premesso che sia a livello internazionale che in Italia circola una quantità notevole di metodologie e di
tecniche correlate alla teoria e alla prassi del project management, esistono dei concetti e delle tecniche
fondamentali ricorrenti nella maggior parte degli approcci esistenti.
Stima di un progetto [modifica]
La stima dimensionale di un progetto è una delle prime attività cruciali da cui dipende il successo del
progetto e la sorte del project manager. Esistono molteplici tecniche per quantificare i tempi e i costi
necessari a realizzare un progetto o, se si vuole, la sua durata. Nei progetti complessi, al fine di rendere il
più possibile oggettiva e affidabile la stima, è fortemente raccomandabile produrre almeno due stime
indipendenti possibilmente prodotte con tecniche diverse, provvedendo poi a effettuare una riconciliazione
che produca una convergenza. La durata del progetto naturalmente dipende dalla struttura della
pianificazione adottata, in particolare dal grado di parallelismo tra le attività che compongono il progetto,
parallelismo a sua volta dipendente dal numero di risorse impiegate. I passi comuni alla maggior parte
delle tecniche di pianificazione prevedono di:
identificare le attività elementari (task) necessarie a produrre i deliverable associati a ciascun
elemento della Work Breakdown Structure (WBS) e le loro dipendenze;
rappresentare la scomposizione dei task in un diagramma di Gantt, mettendo in evidenza le
interrelazioni tra i diversi elementi del progetto (macro-attività o work packages, task e output) in una
scala temporale;
valorizzare la quantità di lavoro necessaria (il cosiddetto effort) a completare ciascun task,
determinando la tipologia di risorse (umane e non) necessarie alla loro realizzazione;
calcolare i tempi di realizzazione di ciascun task in base al numero di risorse a loro assegnate;
determinare i costi del personale per la realizzazione di ciascun task moltiplicando la quantità di
lavoro (effort) stimato per i costi medi della tipologie di risorse individuate; aggiungere i costi degli altri
materiali e/o servizi necessari;
determinare il percorso critico in base alle dipendenze esistenti dentro la WBS;
calcolare il tempo totale (il cosiddetto elapsed) sommando i tempi di tutti i task che si trovano
all'interno del percorso critico;
determinare il costo totale sommando i costi (personale + materiali + servizi) di tutti i task.
Questo procedimento è reso molto più semplice dagli strumenti di controllo della pianificazione disponibili,
che consentono di rappresentare la struttura dei task associati alla WBS, visualizzare il diagramma di
Gantt e cercare il miglior assetto del piano che ottimizzi l'utilizzo delle risorse e minimizzi i rischi presenti
nella pianificazione, con il vincolo di restare all'interno del tempo di realizzazione richiesto dal committente.
Triangolo dei vincoli di progetto
Il Triangolo dei vincoli di progetto [modifica]
Al pari di ogni altro sforzo umano, anche i progetti vengono realizzati e rilasciati in un contesto sottoposto a
determinati vincoli. Tradizionalmente questi vincoli vengono elencati
come scopo/qualità, tempo e costo/risorse. Spesso viene usata l'immagine del triangolo del project
management (dove ogni lato rappresenta un vincolo), per rappresentare la loro correlazione: ciascun
vincolo non può essere cambiato senza impattare sugli altri due ovvero ciascun parametro è funzione degli
altri due. Un ulteriore variante di questo sistema dei vincoli separa la 'qualità' (o le 'prestazioni') dallo
'scopo', trasformandolo in un tetraedro con quattro vincoli correlati tra loro.
Il vincolo tempo indica la quantità di tempo disponibile per completare il progetto. Il
vincolo costo/risorse rappresenta il budget disponibile per il progetto e al tempo stesso l'insieme delle
risorse a disposizione del progetto (è evidente la correlazione diretta tra costo e risorse assegnate). Il
vincolo scopo/qualità rappresenta quanto deve essere fatto per conseguire i risultati attesi dal progetto sia
in termini di requisiti che di criteri di qualità/performance. Questi tre vincoli sono strettamente correlati:
incrementare lo scopo tipicamente significa aumentare i tempi e i costi/risorse del progetto; ridurre i tempi
spesso richiede costi più alti (risorse più grandi) e/o uno scopo più ristretto; un budget risicato (meno
risorse) può implicare tempi più lunghi e/o una riduzione dello scopo.
È proprio la teoria del project management che fornisce gli strumenti e le tecniche che consentono al team
di progetto di organizzare il proprio lavoro all'interno di questo sistema di vincoli ottimizzando il tutto.
Una rappresentazione alternativa dei vincoli consiste nello scegliere come variabili il costo, il tempo e
le risorse umane. Se occorre finire un progetto in un tempo minore si possono aumentare le persone
assegnate, il che aumenterà anche i costi??? [per il probabile aumento di inefficienza nella allocazione
delle risorse.] ???
Tempo [modifica]
Le dipendenze tra i task interni e quelle dagli eventi esterni (es: la fornitura di prodotti o materiali che
servono da input a determinatitask) possono impattare sulla durata del progetto, introducendo spesso nei
progetti reali la necessità di rivedere la pianificazione precedente. Un altro classico fattore che impatta sui
tempi riguarda la disponibilità delle risorse, piuttosto che l'assunzione (in fase di stima) di
produttività/performance significativamente diverse da quella effettiva del team reale. Nella maggior parte
dei progetti medio-grandi la misurazione dell'avanzamento, il controllo e l'adattamento del piano fanno
parte delle attività periodiche di routine del project manager. Il Tempo non è considerato un costo né una
risorsa, dato che il project manager non può controllare la velocità con cui trascorre; questo ne fa la
differenza fondamentale con gli altri vincoli.
Costo/Risorse [modifica]
I costi necessari a sviluppare un progetto dipendono principalmente da diverse variabili: quantità e qualità
delle risorse assegnate, costi del lavoro, costi dei materiali e/o dei servizi acquistati esternamente, gestione
dei rischi (es: quanto viene speso/accantonato per mitigare i principali rischi), costi di controllo e
amministrazione del progetto, impianti e strumenti a disposizione, rivalutazione dei costi (in caso di progetti
pluriennali), costi indiretti.
Scopo/Qualità [modifica]
Lo scopo del progetto, ossia i risultati che devono essere prodotti, è fortemente correlato alla qualità e/o
alle performance di quanto deve essere rilasciato. La qualità prodotta rappresenta l'accuratezza con cui i
risultati conseguiti sono aderenti ai requisiti concordati, nel senso che soddisfano completamente i requisiti
richiesti ed eventualmente aggiungono ulteriore valore per il committente. Per garantire un'aderenza
soddisfacente (zero sorprese) è necessario investire uno sforzo maggiore nella fase di ingaggio del
progetto, arrivando a definire con la maggior precisione possibile i requisiti e i criteri di accettazione che
dovranno essere utilizzati per valutare i risultati prodotti (caratteristiche e performance).
Articolazione delle attività di project management [modifica]
Il project management si articola in diversi tipi di attività:
1. Analisi e definizione degli obiettivi e degli eventi che li pilotano (i cosiddetti compelling events)
2. Pianificazione del lavoro in funzione degli obiettivi
3. Individuazione e controllo dei Rischi (Risk Management)
4. Valutazione e pianificazione delle risorse necessarie
5. Allocazione/disallocazione delle risorse
6. Organizzazione del lavoro e dei processi
7. Acquisizione delle risorse umane e dei materiali necessari
8. Assegnazione dei task
9. Direzione e coordinamento delle attività
10. Misurazione dell'avanzamento del progetto (Metriche di progetto)
11. Analisi dei risultati ottenuti sulla base dei fatti e delle informazioni raccolte
12. Definizione e controllo delle azioni correttive necessarie con rimessa del progetto in assetto con gli
obiettivi
13. (Ri) previsioni tempi, costi e altri indicatori del progetto
14. Gestione della qualità
15. Gestione e soluzione dei problemi
16. Assicurazione della qualità (riduzione al minimo delle non conformità)
17. Identificazione, gestione e controllo delle variazioni di scopo (change request o change control)
18. Chiusura del progetto e disallocazione delle risorse
19. Gestione dell'accettazione dei risultati prodotti
20. Comunicazione di progetto (che in realtà inizia dal punto 2) oppure dissemination
21. Notifica dei risultati ottenuti ai committenti
A queste si affiancano le attività trasversali che sottendono all'applicazione delle cosiddette "Soft skill",
meno tecniche e più orientate alla motivazione dei gruppi di lavoro e al rapporto interpersonale.
Obiettivi del Progetto [modifica]
Gli obiettivi del progetto definiscono i risultati da raggiungere alla fine del progetto, risultati necessari per il
conseguimento dei benefici attesi dai committenti. Gli obiettivi possono essere formulati nel modo migliore
verificandone l'aderenza ai requisiti indicati dall'acrosticoSMART (traducibile dall'inglese come
"intelligente", "furbo"):
Specifico/Semplice (ossia ben definito e chiaramente comprensibile)
Misurabile (o per lo meno valutabile) nella sua raggiungibilità
Accettabile (nel senso di "considerato raggiungibile" dalle persone coinvolte nel progetto)
Rilevante (ossia importante per il committente, al punto di affidare un mandato chiaro e forte a
coloro che hanno responsabilità nel progetto)
Tempificato/Tracciabile (nel senso che deve essere conseguito entro una data certa e poter
essere tracciato nel suo avanzamento)
La misurazione (o valutazione) del raggiungimento di un obiettivo può/deve essere accertata alla fine del
progetto. Tuttavia una continua vigilanza attiva sul progresso verso ciascun obiettivo dovrebbe essere
monitorata e valutata periodicamente nel corso del progetto.
La comunicazione di progetto, da non confondere con la comunicazione al committente dei risultati del
progetto, è un processo diretto a fare comprendere gli obiettivi e valorizzare contenuti del progetto presso
una quantità di pubblici diversi e differenziati. Ad es. promuovere il progetto, le sue finalità e
l'organizzazione che lo realizza, presso i Media (ufficio stampa), presso target interni (top management,
financing, comunicazione corporate ecc.) o utilizzarne i valori per il marketing aziendale [6].
Deliverable dell'attività di project management [modifica]
Per approfondire, vedi la voce Deliverable (project management).
I deliverable nell'ambito del project management sono identificabili in un insieme di documenti, a cui ci si
riferisce come Project Management Plan. Tali documenti hanno inoltre lo scopo di allineare le aspettative
degli sponsor, dei clienti e del team di progetto.
Variabili di controllo del progetto [modifica]
La disciplina del project management ha tra i propri principali obiettivi quello di tenere sotto controllo le
variabili del progetto, costituite dalle variabili già descritte nella sezione triangolo dei vincoli di progetto a cui
si aggiungono i rischi.
Il rischio può essere definito come una potenziale causa di fallimento del progetto o, in altre parole, un
evento potenzialmente in grado di mettere a repentaglio il raggiungimento degli obiettivi del progetto. La
maggior parte dei rischi con impatti negativi può essere risolta (o per lo meno mitigata) intervenendo nella
pianificazione del progetto e disponendo di maggior tempo e/o maggiori risorse. Secondo alcune definizioni
(inclusa la terza edizione del PMBOK) un rischio può essere classificato anche come positivo nel senso
che ad esso può essere associato una potenziale opportunità (ad es: completare il progetto prima del
previsto, per via di una immissione di risorse aggiuntive o di una sua semplificazione). I committenti di un
progetto a volte posso imporre in corsa un peggioramento sulle tre variabili
del triangolo: tempi, costi/risorse, scopo/qualità. Le restanti variabili, i rischi appunto, devono essere gestite
dal team di progetto ed in primis dal project manager, mediante una stima iniziale solida e accurata e
l'utilizzo di tecniche di pianificazione efficienti e reattive. Sia la determinazione di queste variabili
(tempi, costi/risorse, scopo/qualità) sia l'approccio da utilizzare verso i rischi di progetto, di solito vengono
fissati attraverso un processo di negoziazione tra le parti che si riflette nel contratto iniziale (formale o
informale che sia).
Un buon project manager, oltre alla profonda conoscenza di queste variabili, di solito ha una buona
esperienza anche nei processi di integrazione, comunicazione, gestione delle risorse umane,
assicurazione della qualità (Quality Assurance), pianificazione e gestione degli acquisti (Procurement).
Approcci metodologici [modifica]
Per approfondire, vedi la voce Approcci di project management.
Gli approcci utilizzati nell'ambito del project management consistono in diversi approcci metodologici
adottabili per la gestione delle attività di un progetto, che includono gli approcci agili, interattivi, incrementali
e basati sulla successione di fasi predefinite.
Molti di essi fanno riferimento al PMBOK sviluppato dal Project Management Institute. Tra i più importanti
(vedere ad esempiorecensione di Max Wideman) possono essere
considerati RUP, PRINCE2[7], TenStep, SDLC.
fasi di sviluppo di un progetto
Indipendentemente dall'approccio utilizzato, una particolare attenzione va dedicata alla definizione chiara
degli scopi/obiettivi del progetto e delle loro implicazioni; anche la definizione chiara dei ruoli e delle
responsabilità di tutti gli attori coinvolti, inclusi i committenti, riveste una importanza decisiva per il successo
del progetto.
Nel caso di progetti molto complessi (ad esempio nel caso di un insieme di progetti correlati) e comunque
in caso di impatti rilevanti dei progetti sulle organizzazioni coinvolte e sui loro processi, il progetto deve
essere considerato all'interno di un approccio più globale, agendo sul piano del Change management che
si occupa principalmente di gestire l'impatto umano e organizzativo di una trasformazione all'interno di un
contesto aziendale e/o sociale.
Tra i principali approcci esistenti vi sono:
L'approccio classico che è di fatto rappresentato dalla ortodossia del PMBOK sviluppato
dal Project Management Institute e a cui si ricollegano altri framework (es: Method 123, TenStep);
Il Rational Unified Process (RUP) costituito da un framework per lo sviluppo iterativo di prodotti
software creato da Rational Software Corporation;
L'approccio del Critical chain (catena/percorso critico) che si focalizza sulla disponibilità delle
risorse oltre che sulle dipendenze logiche tra attività di progetto;
Gli approcci di project management basati sui processi (Process-based management) che
derivano da una generalizzazione del concetto di controllo di progetto.
Sistemi di project management [modifica]
Per approfondire, vedi la voce Sistemi di project management.
Ciclo di monitoraggio e controllo
I sistemi utilizzati per la gestione di un progetto, pur essendo funzionali agli approcci di project
management utilizzati, hanno (almeno parzialmente) caratteristiche in comune che possono essere
utilizzati da approcci diversi. Seguendo l'approccio tradizionale lo sviluppo di un progetto include cinque
componenti: le quattro fasi di sviluppo più il controllo.
La fase di controllo di un progetto viene realizzata attraverso l'implementazione di un sistema di
controllo diretto a governare un insieme di aspetti che include (non necessariamente tutte le variabili
elencate) i costi, i rischi, la qualità, le comunicazioni, i tempi, le risorse umane, le variazioni di scopo, la
gestione degli acquisti. Un sistema di controllo accurato richiede la definizione e gestisce la misurazione un
opportuno insieme di indicatori (ad es: Earned Value) rivolto a tenere sotto controllo e prevedere
l'andamento delle principali variabili sopra indicate; questi indicatori, in parte standard e in parte definibili in
base alla specifica natura del progetto, fanno parte delle Metriche di progetto.
A prescindere dalla maggior parte delle metodologie usate, lo sviluppo di un progetto può essere articolato
in diverse fasi[8]:
allestimento e avviamento (o start-up), diretta determinare la natura e lo scopo del progetto;
pianificazione e progettazione, diretta a organizzare i tempi e i rilasci dei deliverable e identificare i
requisiti del progetto;
esecuzione (o produzione dei risultati), che consiste nella realizzazione dei processi necessari a
soddisfare i requisiti del progetto;
monitoraggio e controllo del progetto, diretta a osservare e misurare l'esecuzione del progetto
(tramite gli indicatori definiti nelleMetriche di progetto) in modo da identificarne per tempo i rischi e i
potenziali problemi e intraprendere, quando necessarie, le azioni correttive volte a rimettere il progetto
in linea con i propri obiettivi;
completamento e rilascio dei risultati, diretta a formalizzare l'accettazione dei deliverable rilasciati
e l'esecuzione di tutte le attività “amministrative” indirizzate a chiudere tutte le pendenze.
Strumenti per il project management [modifica]
Per approfondire, vedi la voce Strumenti di project management.
Gli strumenti di project management possono essere intesi sia come le tecniche utilizzate per supportare la
realizzazione delle attività di project management, sia come i prodotti software che implementano tali
strumenti e li forniscono contestualmente ad un insieme integrato di servizi e/o funzionalità. Per un elenco
degli strumenti più diffusi, fare riferimento alla voce Strumenti di project management.
Gli strumenti di project management possono essere intesi sia come le tecniche utilizzate per
supportare la realizzazione delleattività di project management sia come i prodotti software che
implementano tali strumenti e li forniscono contestualmente a un insieme integrato di servizi e/o
funzionalità.
Tecniche di supporto alle attività di Project management [modifica]
Tra le principali tecniche di supporto alle realizzazione delle attività di project management vi
sono:
Mappe mentali per supportare la fase di ideazione iniziale, il team building e la
rielaborazione finale delle esperienze
Diagrammi di causa ed effetto/Ishikawa, per analizzare e valutare la catena causale delle
problematiche che si presentano nel corso delle attività
Diagrammi Pert, per descrivere in chiave reticolare le attività e la loro connessione,
individuando i percorsi critici
WBS, per descrivere l'articolazione delle attività in termini di fasi, sottofasi... fino alle
attività elementari, in chiave gerarchico-associativa
Diagrammi di Gantt, per descrivere i legami logico/temporali delle fasi e delle singole
attività
Diagrammi Event Chain (Event Chain Diagrams)
Diagrammi per la rilevazione di indicatori (Run chart)
Project Cycle Optimisation (PCO - Ottimizzazione del ciclo di vita del progetto)
Participatory Impact Pathways Analysis, per sviluppare una visione comune tra i
protagonisti di un progetto
Mappe concettuali per sintetizzare e rappresentare le informazioni e la conoscenza di
progetto
Prodotti di supporto alle attività di Project management [modifica]
Esiste una notevole quantità di prodotti (o pacchetti applicativi) che implementano le tecniche di
cui sopra e le integrano in un insieme di funzionalità che agevolano la conduzione delle attività
per il controllo delle attività di project management.
Tra questi (in ordine alfabetico) vi sono alcuni prodotti con una significativa diffusione a livello
locale:
Prodotti in Italia:
Progeta (software Project Management web based)
Cardinis (suite di Portfolio Project Management)
Teamwork (Project Management, Issues, Documenti, Agenda)
Internazionali:
Artemis (suite di Portfolio Project Management)
Bugzilla (specifico per il tracking dei progetti di sviluppo software, Open Source software)
CA Clarity (suite di IT Project and Portfolio Management)
GanttProject (per le fasi di pianificazione e controllo, Open Source software)
Microsoft Project (per le fasi di pianificazione e controllo)
Microsoft Office Project Server (suite di Portfolio Project Management)
OpenERP (un sistema ERP/CRM completo di strumenti per il Project Management)
OpenProj (per la fase di pianificazione, Open Source software)
Open Workbench (per la fase di pianificazione e controllo, Open Source software)
Primavera Project Planner (suite di Portfolio Project Management)
Project.net (suite di Portfolio Project Management, Open Source software)
Planner (per le fasi di pianificazione e controllo, Open Source software) incluso
in GNOME Office
Voci correlate [modifica]
Diagramma di Gantt
PERT/CPM
Progetto
Project management
Work Breakdown Structure
Mappe mentali
Mappe concettuali
Il diagramma di Gantt, usato principalmente nelle attività di project management, è costruito
partendo da un asse orizzontale - a rappresentazione dell'arco temporale totale del progetto,
suddiviso in fasi incrementali (ad esempio, giorni, settimane, mesi) - e da un asse verticale - a
rappresentazione delle mansioni o attività che costituiscono il progetto.
Barre orizzontali di lunghezza variabile rappresentano le sequenze, la durata e l'arco temporale
di ogni singola attività del progetto (l'insieme di tutte le attività del progetto ne costituisce la Work
Breakdown Structure). Queste barre possono sovrapporsi durante il medesimo arco temporale
ad indicare la possibilità dello svolgimento in parallelo di alcune delle attività. Man mano che il
progetto progredisce, delle barre secondarie, delle frecce o delle barre colorate possono essere
aggiunte al diagramma, per indicare le attività sottostanti completate o una porzione completata
di queste. Una linea verticale è utilizzata per indicare la data di riferimento.
Un diagramma di Gantt permette dunque la rappresentazione grafica di un calendario di attività,
utile al fine di pianificare, coordinare e tracciare specifiche attività in un progetto dando una
chiara illustrazione dello stato d'avanzamento del progetto rappresentato; di contro, uno degli
aspetti non tenuti in considerazione in questo tipo di diagrammazione è l'interdipendenza delle
attività, caratteristica invece della programmazione reticolare, cioè del diagramma PERT[1]. Ad
ogni attività possono essere in generale associati una serie di attributi: durata (o data di inizio e
fine), predecessori, risorsa, costo.
Ad ogni attività possono essere associate una o più risorse. Alcuni software disponibili sul
mercato permettono di visualizzare il carico di lavoro di ogni risorsa e la sua saturazione,
impostando una certa disponibilità per ogni risorsa. Contestualmente, può essere definito il
calendario dei giorni lavorativi e festivi, e il numero di ore di lavoro giornaliere.
Ad ogni attività può poi essere associato un costo. Il costo può essere attribuito a una singola
attività oppure si può assegnare un costo orario alle risorse, determinando il costo dell'attività in
base al relativo impegno orario. Nel corso del progetto, ad ogni attività o alla risorsa può essere
attribuito un costo effettivo. Dai due dati di costo, preventivato al momento della stesura del
Gantt, ed effettivi, si ricavano tre curve e due indicatori di avanzamento dell'intero progetto. Le
tre curve riportano la cumulata del costo preventivato e/o effettivo in funzione del tempo, ossia i
costi totali effettivi e/o preventivati dall'inizio:
BCWS: Budget Cost of Work Scheduled: riporta i costi preventivati da 0 a vita intera
(da 0 a
);
ACWP: Actual Cost of Work Performed: riporta i costi sostenuti da 0 a tempo attuale
(da 0 a
);
BCWP. Budget Cost of Work Performed: riporta i costi preventivati da 0 a tempo attuale
(da 0 a
).
The Program (or Project) Evaluation and Review Technique, commonly abbreviated PERT, is
a statistical tool, used in project management, that is designed to analyze and represent the
tasks involved in completing a givenproject. First developed by the United States Navy in the
1950s, it is commonly used in conjunction with the critical path method or CPM.
Contents
[hide]
1 History
2 Overview
3 Conventions
4 Terminology
5 Implementation
6 Advantages
7 Disadvantages
8 Uncertainty in project
scheduling
9 See also
10 References
11 Further reading
12 External links
[edit]History
Program Evaluation and Review Technique
The Navy's Special Projects Office, charged with developing the Polaris-Submarine weapon system and
the Fleet Ballistic Missile capability, has developed a statistical technique for measuring and forecasting
progress in research and development programs. This Program Evaluation and Review Technique (codenamed PERT) is applied as a decision-making tool designed to save time in achieving end-objectives, and
is of particular interest to those engaged in research and development programs for which time is a critical
factor.
The new technique takes recognition of three factors that influence successful achievement of research
and development program objectives: time, resources, and technical performance specifications. PERT
employs time as the variable that reflects planned resource-applications and performance specifications.
With units of time as a common denominator, PERT quantifies knowledge about the uncertainties involved
in developmental programs requiring effort at the edge of, or beyond, current knowledge of the subject effort for which little or no previous experience exists.
Through an electronic computer, the PERT technique processes data representing the major, finite
accomplishments (events) essential to achieve end-objectives; the inter-dependence of those events; and
estimates of time and range of time necessary to complete each activity between two successive events.
Such time expectations include estimates of "most likely time", "optimistic time", and "pessimistic time" for
each activity. The technique is a management control tool that sizes up the outlook for meeting objectives
on time; highlights danger signals requiring management decisions; reveals and defines both criticalness
and slack in the flow plan or the network of sequential activities that must be performed to meet objectives;
compares current expectations with scheduled completion dates and computes the probability for meeting
scheduled dates; and simulates the effects of options for decision - before decision.
The concept of PERT was developed by an operations research team staffed with representatives from
the Operations Research Department of Booz, Allen and Hamilton; the Evaluation Office of the Lockheed
Missile Systems Division; and the Program Evaluation Branch, Special Projects Office, of the Department
of the Navy.
— Willard Fazar (Head, Program Evaluation Branch, Special Projects Office, U. S. Navy), The American
Statistician, April 1959.[1]
[edit]Overview
PERT is a method to analyze the involved tasks in completing a given project, especially the time
needed to complete each task, and to identify the minimum time needed to complete the total
project.
PERT was developed primarily to simplify the planning and scheduling of large and complex
projects. It was developed for the U.S. Navy Special Projects Office in 1957 to support the U.S.
Navy's Polaris nuclear submarine project.[2] It was able to incorporate uncertainty by making it
possible to schedule a project while not knowing precisely the details and durations of all the
activities. It is more of an event-oriented technique rather than start- and completion-oriented,
and is used more in projects where time, rather than cost, is the major factor. It is applied to very
large-scale, one-time, complex, non-routine infrastructure and Research and Development
projects. An example of this was for the 1968 Winter Olympics in Grenoble which applied PERT
from 1965 until the opening of the 1968 Games.[3]
This project model was the first of its kind, a revival for scientific management, founded by
Frederick Taylor (Taylorism) and later refined by Henry Ford (Fordism). DuPont's critical path
method was invented at roughly the same time as PERT.
[edit]Conventions
A PERT chart is a tool that facilitates decision making. The first draft of a PERT chart will
number its events sequentially in 10s (10, 20, 30, etc.) to allow the later insertion of
additional events.
Two consecutive events in a PERT chart are linked by activities, which are conventionally
represented as arrows (see the diagram above).
The events are presented in a logical sequence and no activity can commence until its
immediately preceding event is completed.
The planner decides which milestones should be PERT events and also decides their
“proper” sequence.
A PERT chart may have multiple pages with many sub-tasks.
PERT is valuable to manage where multiple tasks are occurring simultaneously to reduce
redundancy
[edit]Terminology
PERT event: a point that marks the start or completion of one or more activities. It
consumes no time and uses no resources. When it marks the completion of one or more
tasks, it is not “reached” (does not occur) until all of the activities leading to that event have
been completed.
predecessor event: an event that immediately precedes some other event without any
other events intervening. An event can have multiple predecessor events and can be the
predecessor of multiple events.
successor event: an event that immediately follows some other event without any other
intervening events. An event can have multiple successor events and can be the successor
of multiple events.
PERT activity: the actual performance of a task which consumes time and requires
resources (such as labor, materials, space, machinery). It can be understood as representing
the time, effort, and resources required to move from one event to another. A PERT activity
cannot be performed until the predecessor event has occurred.
optimistic time (O): the minimum possible time required to accomplish a task, assuming
everything proceeds better than is normally expected
pessimistic time (P): the maximum possible time required to accomplish a task, assuming
everything goes wrong (but excluding major catastrophes).
most likely time (M): the best estimate of the time required to accomplish a task,
assuming everything proceeds as normal.
expected time (TE): the best estimate of the time required to accomplish a task,
accounting for the fact that things don't always proceed as normal (the implication being that
the expected time is the average time the task would require if the task were repeated on a
number of occasions over an extended period of time).
TE = (O + 4M + P) ÷ 6
float or slack is a measure of the excess time and resources available to complete a task.
It is the amount of time that a project task can be delayed without causing a delay in any
subsequent tasks (free float) or the whole project (total float). Positive slack would
indicate ahead of schedule; negative slack would indicate behind schedule; and zero
slack would indicate on schedule.
critical path: the longest possible continuous pathway taken from the initial event to the
terminal event. It determines the total calendar time required for the project; and,
therefore, any time delays along the critical path will delay the reaching of the terminal
event by at least the same amount.
critical activity: An activity that has total float equal to zero. An activity with zero float is
not necessarily on the critical path since its path may not be the longest.
Lead time: the time by which a predecessor event must be completed in order to allow
sufficient time for the activities that must elapse before a specific PERT event reaches
completion.
lag time: the earliest time by which a successor event can follow a specific PERT event.
fast tracking: performing more critical activities in parallel
crashing critical path: Shortening duration of critical activities
[edit]Implementation
The first step to scheduling the project is to determine the tasks that the project requires and
the order in which they must be completed. The order may be easy to record for some tasks
(e.g. When building a house, the land must be graded before the foundation can be laid)
while difficult for others (There are two areas that need to be graded, but there are only
enough bulldozers to do one). Additionally, the time estimates usually reflect the normal,
non-rushed time. Many times, the time required to execute the task can be reduced for an
additional cost or a reduction in the quality.
In the following example there are seven tasks, labeled A through G. Some tasks can be
done concurrently (A and B) while others cannot be done until their predecessor task is
complete (C cannot begin until A is complete). Additionally, each task has three time
estimates: the optimistic time estimate (O), the most likely or normal time estimate (M), and
the pessimistic time estimate (P). The expected time (TE) is computed using the formula (O +
4M + P) ÷ 6.
Time estimates
Activity Predecessor
Expected time
Opt. (O) Normal (M) Pess. (P)
A
—
2
4
6
4.00
B
—
3
5
9
5.33
C
A
4
5
7
5.17
D
A
4
6
10
6.33
E
B, C
4
5
7
5.17
F
D
3
4
8
4.50
G
E
3
5
8
5.17
Once this step is complete, one can draw a Gantt chart or a network diagram.
A Gantt chart created using Microsoft Project (MSP). Note (1) the critical path is in red, (2) the slack is
the black lines connected to non-critical activities, (3) since Saturday and Sunday are not work days and
are thus excluded from the schedule, some bars on the Gantt chart are longer if they cut through a
weekend.
A Gantt chart created using OmniPlan. Note (1) the critical path is highlighted, (2) the slack is not
specifically indicated on task 5 (d), though it can be observed on tasks 3 and 7 (b and f), (3) since
weekends are indicated by a thin vertical line, and take up no additional space on the work calendar,
bars on the Gantt chart are not longer or shorter when they do or don't carry over a weekend.
A network diagram can be created by hand or by using diagram software. There are
two types of network diagrams, activity on arrow (AOA) and activity on node (AON).
Activity on node diagrams are generally easier to create and interpret. To create an
AON diagram, it is recommended (but not required) to start with a node named start.
This "activity" has a duration of zero (0). Then you draw each activity that does not
have a predecessor activity (a and b in this example) and connect them with an
arrow from start to each node. Next, since both c and d list a as a predecessor
activity, their nodes are drawn with arrows coming from a. Activity e is listed
with b andc as predecessor activities, so node e is drawn with arrows coming from
both b and c, signifying that e cannot begin until both b and chave been completed.
Activity f has d as a predecessor activity, so an arrow is drawn connecting the
activities. Likewise, an arrow is drawn from e to g. Since there are no activities that
come after f or g, it is recommended (but again not required) to connect them to a
node labeled finish.
A network diagram created using Microsoft Project (MSP). Note the critical path is in red.
A node like this one (from Microsoft Visio) can be used to display the activity name, duration, ES,
EF, LS, LF, and slack.
By itself, the network diagram pictured above does not give much more
information than a Gantt chart; however, it can be expanded to display more
information. The most common information shown is:
1. The activity name
2. The normal duration time
3. The early start time (ES)
4. The early finish time (EF)
5. The late start time (LS)
6. The late finish time (LF)
7. The slack
In order to determine this information it is assumed that the activities and
normal duration times are given. The first step is to determine the ES and
EF. The ES is defined as the maximum EF of all predecessor activities,
unless the activity in question is the first activity, for which the ES is zero (0).
The EF is the ES plus the task duration (EF = ES + duration).
The ES for start is zero since it is the first activity. Since the duration is
zero, the EF is also zero. This EF is used as the ES for aand b.
The ES for a is zero. The duration (4 work days) is added to the ES to get
an EF of four. This EF is used as the ES for c and d.
The ES for b is zero. The duration (5.33 work days) is added to the ES to
get an EF of 5.33.
The ES for c is four. The duration (5.17 work days) is added to the ES to
get an EF of 9.17.
The ES for d is four. The duration (6.33 work days) is added to the ES to
get an EF of 10.33. This EF is used as the ES for f.
The ES for e is the greatest EF of its predecessor activities (b and c).
Since b has an EF of 5.33 and c has an EF of 9.17, the ES ofe is 9.17.
The duration (5.17 work days) is added to the ES to get an EF of 14.34.
This EF is used as the ES for g.
The ES for f is 10.33. The duration (4.5 work days) is added to the ES to
get an EF of 14.83.
The ES for g is 14.34. The duration (5.17 work days) is added to the ES to
get an EF of 19.51.
The ES for finish is the greatest EF of its predecessor activities (f and g).
Since f has an EF of 14.83 and g has an EF of 19.51, the ES of finish is
19.51. Finish is a milestone (and therefore has a duration of zero), so
the EF is also 19.51.
Barring any unforeseen events, the project should take 19.51 work days to
complete. The next step is to determine the late start (LS) and late finish
(LF) of each activity. This will eventually show if there are activities that
have slack. The LF is defined as the minimum LS of all successor activities,
unless the activity is the last activity, for which the LF equals the EF. The LS
is the LF minus the task duration (LS = LF - duration).
The LF for finish is equal to the EF (19.51 work days) since it is the last
activity in the project. Since the duration is zero, the LS is also 19.51
work days. This will be used as the LF for f and g.
The LF for g is 19.51 work days. The duration (5.17 work days) is
subtracted from the LF to get an LS of 14.34 work days. This will be
used as the LF for e.
The LF for f is 19.51 work days. The duration (4.5 work days) is
subtracted from the LF to get an LS of 15.01 work days. This will be
used as the LF for d.
The LF for e is 14.34 work days. The duration (5.17 work days) is
subtracted from the LF to get an LS of 9.17 work days. This will be used
as the LF for b and c.
The LF for d is 15.01 work days. The duration (6.33 work days) is
subtracted from the LF to get an LS of 8.68 work days.
The LF for c is 9.17 work days. The duration (5.17 work days) is
subtracted from the LF to get an LS of 4 work days.
The LF for b is 9.17 work days. The duration (5.33 work days) is
subtracted from the LF to get an LS of 3.84 work days.
The LF for a is the minimum LS of its successor activities. Since c has an
LS of 4 work days and d has an LS of 8.68 work days, the LF for a is 4
work days. The duration (4 work days) is subtracted from the LF to get
an LS of 0 work days.
The LF for start is the minimum LS of its successor activities. Since a has
an LS of 0 work days and b has an LS of 3.84 work days, the LS is 0
work days.
The next step is to determine the critical path and if any activities
have slack. The critical path is the path that takes the longest to complete.
To determine the path times, add the task durations for all available paths.
Activities that have slack can be delayed without changing the overall time
of the project. Slack is computed in one of two ways, slack = LF EF or slack = LS - ES. Activities that are on the critical path have a slack of
zero (0).
The duration of path adf is 14.83 work days.
The duration of path aceg is 19.51 work days.
The duration of path beg is 15.67 work days.
The critical path is aceg and the critical time is 19.51 work days. It is
important to note that there can be more than one critical path (in a project
more complex than this example) or that the critical path can change. For
example, let's say that activities d and f take their pessimistic (b) times to
complete instead of their expected (TE) times. The critical path is
now adf and the critical time is 22 work days. On the other hand, if
activity c can be reduced to one work day, the path time for aceg is reduced
to 15.34 work days, which is slightly less than the time of the new critical
path, beg (15.67 work days).
Assuming these scenarios do not happen, the slack for each activity can
now be determined.
Start and finish are milestones and by definition have no duration,
therefore they can have no slack (0 work days).
The activities on the critical path by definition have a slack of zero;
however, it is always a good idea to check the math anyway when
drawing by hand.
LFa - EFa = 4 - 4 = 0
LFc - EFc = 9.17 - 9.17 = 0
LFe - EFe = 14.34 - 14.34 = 0
LFg - EFg = 19.51 - 19.51 = 0
Activity b has an LF of 9.17 and an EF of 5.33, so the slack is 3.84 work
days.
Activity d has an LF of 15.01 and an EF of 10.33, so the slack is 4.68 work
days.
Activity f has an LF of 19.51 and an EF of 14.83, so the slack is 4.68 work
days.
Therefore, activity b can be delayed almost 4 work days without delaying the
project. Likewise, activity d or activity f can be delayed 4.68 work days
without delaying the project (alternatively, d and f can be delayed 2.34 work
days each).
A completed network diagram created using Microsoft Visio. Note the critical path is in red.
[edit]Advantages
PERT chart explicitly defines and makes visible dependencies
(precedence relationships) between the WBS elements
PERT facilitates identification of the critical path and makes this
visible
PERT facilitates identification of early start, late start, and slack for
each activity,
PERT provides for potentially reduced project duration due to better
understanding of dependencies leading to improved overlapping of
activities and tasks where feasible.
The large amount of project data can be organized & presented in
diagram for use in decision making.
[edit]Disadvantages
There can be potentially hundreds or thousands of activities and
individual dependency relationships
PERT is not easily scalable for smaller projects
The network charts tend to be large and unwieldy requiring several
pages to print and requiring special size paper
The lack of a timeframe on most PERT/CPM charts makes it harder
to show status although colours can help (e.g., specific colour for
completed nodes)
When the PERT/CPM charts become unwieldy, they are no longer
used to manage the project.
[edit]Uncertainty
in project scheduling
During project execution, however, a real-life project will never execute
exactly as it was planned due to uncertainty. It can be ambiguity
resulting from subjective estimates that are prone to human errors or it
can be variability arising from unexpected events or risks. The main
reason that the Program Evaluation and Review Technique (PERT) may
provide inaccurate information about the project completion time is due
to this schedule uncertainty. This inaccuracy is large enough to render
such estimates as not helpful.
One possibility to maximize solution robustness is to include safety in
the baseline schedule in order to absorb the anticipated disruptions.
This is called proactive scheduling. A pure proactive scheduling is a
utopia, incorporating safety in a baseline schedule that allows to cope
with every possible disruption would lead to a baseline schedule with a
very large make-span. A second approach, reactive scheduling,
consists of defining a procedure to react to disruptions that cannot be
absorbed by the baseline schedule.
