Sei sulla pagina 1di 56

PROJECT MANAGEMENT

Seminario introduttivo

Project Group Srl

MODULO 1 Pagina 1 di 56
Project Management – Seminario Introduttivo pag 2 di 56
Sommario

COSA SI INTENDE PER PROJECT MANAGEMENT .............................. 5

I MODELLI ORGANIZZATIVI .................................................................... 7


LA STRUTTURA FUNZIONALE ............................................................................... 7
LA STRUTTURA A MATRICE .................................................................................. 8
LA STRUTTURA A TASK FORCE ............................................................................ 9
IL PROJECT OFFICE.............................................................................. 10

LE FASI DEL PROJECT MANAGEMENT .............................................. 11

LA WORK BREAKDOWN STRUCTURE (W.B.S.) ................................. 13


CHE COSA È LA W.B.S.? ...................................................................................... 13
QUALI OBIETTIVI SI PONE LA W.B.S.? ................................................................ 14
COME SI REALIZZA UNA W.B.S.? ........................................................................ 14
TECNICHE DI PIANIFICAZIONE ............................................................ 15
TECNICHE DI PIANIFICAZIONE E CONTROLLO ................................................. 15
Il diagramma di Gantt ........................................................................................ 15
Introduzione alle tecniche reticolari .................................................................... 16
Modalità di rappresentazione ............................................................................. 18
Program Evaluation and Review Technique (P.E.R.T) ...................................... 20
Programmazione P.E.R.T. - un esempio applicativo .......................................... 20
ALCUNE CONSIDERAZIONI ................................................................................. 26
Il metodo C.P.M. ................................................................................................ 26
Complessità dei reticoli logici ............................................................................. 26
Strumenti di supporto ........................................................................................ 27
La sequenza temporale delle attività.................................................................. 27
LE RISORSE ........................................................................................... 28
CHE COSA SONO LE RISORSE? ......................................................................... 28
QUALI SONO LE RISORSE? ................................................................................. 28
TECNICHE DI CONTROLLO DEI PROGETTI ........................................ 29

Project Management – Seminario Introduttivo pag 3 di 56


IL CONTROLLO DI AVANZAMENTO ..................................................................... 29
Che cosa è il controllo di avanzamento dei progetti? ......................................... 29
Perché controllare? ........................................................................................... 29
Quali criteri di analisi si adottano? ..................................................................... 29
NOTE INTRODUTTIVE ........................................................................... 30

IL PROBLEMA DEL PROJECT MANAGER ........................................... 30

LA VARIABILITÀ ..................................................................................... 32
LA VARIABILITÀ NATURALE ................................................................................ 32
LA VARIABILITÀ DI COMPORTAMENTO .............................................................. 34
PROTEGGERSI DALLA VARIABILITÀ .................................................................. 35
Ma come si fa a proteggersi dalla variabilità? .................................................... 36
LA FOCALIZZAZIONE ........................................................................................... 39
I PASSI PER GESTIRE BENE ................................................................ 42
IDENTIFICARE IL VINCOLO DEL SISTEMA .......................................................... 42
SFRUTTARE IL VINCOLO E SUBORDINARE AD ESSO TUTTE LE
ATTIVITÀ ............................................................................................................... 44
PROTEGGERE IL VINCOLO ................................................................................. 45
GLI STRUMENTI PER GESTIRE IL VINCOLO ...................................... 46
La protezione del progetto ................................................................................. 46
Alimentare il percorso critico .............................................................................. 49
Allertare la risorsa.............................................................................................. 50
LA “CATENA CRITICA” .......................................................................................... 51
GESTIRE PIÙ PROGETTI ..................................................................................... 54
CONCLUSIONI ........................................................................................ 55

Project Management – Seminario Introduttivo pag 4 di 56


COSA SI INTENDE PER PROJECT MANAGEMENT
Parlando di Project Management, è opportuno come prima cosa fare
chiarezza su cosa significhi per noi ‘progetto’ (project).
A questo termine non daremo il significato che solitamente assume, ovvero
la fase di design, di sviluppo dei disegni costruttivi; ma faremo nostra
l’accezione del termine anglosassone ‘Project’, che equivale a qualcosa di
completo, un’opera da portare a termine.
Pertanto, d’ora in avanti con il termine ‘progetto’ non si intenderà solo
l’attività di progettazione di un’opera, ma in essa si ingloberanno tutte
quelle attività che, nel loro insieme, costituiscono l’intera realizzazione
dell’opera; attività che vanno dalla sua concezione originaria allo studio di
fattibilità, alla progettazione fino alla realizzazione vera e propria e, talvolta
fino alla messa in funzione ed alla gestione dell’opera compiuta.
A questo punto, dopo aver visto questa definizione, vediamo alcune
caratteristiche comuni alla maggior parte dei progetti:
 i progetti sono degli sforzi complessi che hanno inizio e fine, e non
sono ripetitivi. I progetti devono dar luogo a risultati specifici in un
momento dato, rispettando i limiti di budget: si tratta di iniziative originali
e non di mere ripetizioni di iniziative precedenti.
 un progetto è il processo di creazione di determinati risultati. Un
progetto, pertanto, può essere considerato come l’intero processo
necessario per realizzare un nuovo prodotto, un nuovo stabilimento, un
nuovo sistema o comunque per ottenere altri risultati ben determinati.
Spesso il prodotto che deve essere creato riceve più attenzione del
processo che lo crea, ma tanto il prodotto quanto il processo - che
insieme costituiscono il progetto - richiedono una gestione efficace. Il
risultato finale è altra cosa dal progetto che lo ha fatto conseguire.
 il progetto ha una vita finita. La vita del progetto ha un inizio ed una
fine, e passa attraverso alcune fasi caratteristiche (ad esempio
concezione, definizione delle specifiche, impostazione, costruzione,
installazione) solo di rado separate nettamente le une dalle altre.
 il carattere del progetto cambia ad ogni fase. Per fare un esempio, il
tasso di utilizzo delle risorse cambia, tipicamente aumenta con il
succedersi delle fasi del progetto, per poi decrescere rapidamente
quando il progetto volge al termine. Più in generale, le risorse umane, le
capacità tecniche, le organizzazioni e le altre risorse impiegate nel
progetto variano di fase in fase, e tutto questo chiaramente comporta la
complicazione della pianificazione e del coordinamento, e rende ancora
più cruciale la figura del project manager.
 ogni fase porta a risultati ben determinati i quali a loro volta
concorrono all’input della fase successiva. Al termine di ogni fase
esistono momenti cruciali di valutazione e di decisione. Si giunge così
ad autorizzare il passaggio alla fase successiva, ma si può anche
disporre, all’occorrenza, la ripetizione di una fase già superata.
 l’incertezza per i tempi e i costi complessivi diminuisce man mano
che il progetto procede: l’incertezza connessa al progetto si riduce

Project Management – Seminario Introduttivo pag 5 di 56


ogni volta che viene completata una fase del ciclo di vita del progetto.
Per questo, si avverte la necessità di sistemi e metodi di
programmazione e controllo del progetto che consentano di prevedere
al più presto ed il più accuratamente possibile il punto finale in termini di
tempi e costi.
 il costo connesso all’accelerazione dello svolgimento di un
progetto aumenta man mano che il progetto stesso si avvicina al
completamento. Ovvero, il recupero di tempo perduto di norma diventa
più costoso in ogni successiva fase del progetto, e questo sottolinea
l’esigenza di un controllo integrato durante tutte le fasi del progetto, con
particolare attenzione a quelle iniziali, per evitare ritardi.
Alla luce di queste considerazioni possiamo definire il Project Management
in questo modo:

la gestione sistemica di un’impresa complessa,


univoca e di durata delimitata nel tempo, rivolta al
raggiungimento di un obiettivo predefinito mediante
un processo continuo di pianificazione e controllo di
risorse differenziate e limitate, con vincoli
interdipendenti di tempo, costo, qualità.

Schematizzando, il Project Management è:


 una combinazione di uomini, risorse e fattori organizzativi riuniti
temporaneamente per raggiungere un obiettivo definito, avendo vincoli
in termini di tempo, costo e qualità
 un sistema di gestione che mira agli obiettivi, e che prevede specifiche
forme di organizzazione, di pianificazione e controllo delle attività, di
gestione delle risorse, e di attribuzione di responsabilità
 un processo continuo e dinamico basato sul concetto che non si può
controllare quello che non si può misurare
Possiamo individuare quattro fasi principali attraverso le quali si articola
l’attività di project management:
 definizione degli obiettivi, in termini di tempo, costo e qualità
 pianificazione del lavoro (definizione di piani e programmi; budget)
 organizzazione del lavoro (identificazione dell’area di attività e
responsabilità di ogni figura coinvolta)
 elaborazione di eventuali azioni correttive

Project Management – Seminario Introduttivo pag 6 di 56


I MODELLI ORGANIZZATIVI
Come visto, per gestire un progetto adottando le metodologie proprie del
Project Management (d’ora in avanti, per semplicità, PM) occorre innanzi
tutto definire una struttura organizzativa addetta alla gestione del progetto
stesso.

LA STRUTTURA FUNZIONALE
E’ abbastanza tipica nelle realtà aziendali incontrare una struttura
organizzativa definita funzionale (figura 1).

D.C.

ENTI DI STAFF

F.M. F.M. F.M.

PRODUCT MANUFACTU-
MARKETING
DEVELOPMENT RING

Figura 1 - La struttura funzionale

Tra i vantaggi di un’organizzazione così strutturata possiamo citare:


 un alto grado di valorizzazione degli specialisti
 una facile ottimizzazione dell’utilizzo delle risorse
 una chiara definizione delle procedure operative, delle responsabilità e
dei flussi di informazione
Per contro, si possono osservare i seguenti svantaggi:
 difficoltà di coordinamento tra le diverse funzioni
 mancanza di un responsabile unico di progetto
 difficoltà di individuazione di una unica interfaccia con il cliente
 scarsa visione del processo nella sua interezza
Questo tipo di struttura, nel momento in cui ci si dedica a progetti di una
certa complessità, e per i quali è di fondamentale importanza rispettare
tanto gli obiettivi di performance quanto i vincoli di tempo e di costo, si può
rilevare inadeguata.

Project Management – Seminario Introduttivo pag 7 di 56


LA STRUTTURA A MATRICE
Una organizzazione di questo tipo (figura 2) è strutturata in modo da
valorizzare il più possibile i vantaggi tanto dell’organizzazione per funzione
quanto dell’organizzazione per progetti; in pratica, si tratta di un ibrido tra
questi due tipi di struttura.

D.C.

ENTI DI STAFF

F.M. F.M. F.M. F.M.

P.M.1

P.M.2
PRODUCT MANUFACTU-
MARKETING
DEVELOPMENT RING
P.M.3

P.M.4

Membri del Core Team

Figura 2 - La struttura a matrice

Vantaggi:
 responsabilità univocamente individuata relativamente a tempi, costi e
qualità
 interlocutore unico per il cliente
 personale assegnato al progetto, ma non staccato dalla funzione di
origine (la valorizzazione degli specialisti viene abbinata all’efficienza)
 affiatamento del team
Svantaggi:
 possibilità di conflitti tra Project Manager e responsabili di funzione
 doppia dipendenza delle risorse coinvolte nel progetto

Project Management – Seminario Introduttivo pag 8 di 56


LA STRUTTURA A TASK FORCE
Talvolta risulta utile unire in un solo luogo il team dedicato al progetto
(questo per migliorare la comunicazione, il controllo ed il lavoro di
squadra). Questa forma (figura 3) può far pensare ad una organizzazione
strutturata decisamente ‘per progetto’, ma in realtà si tratta ancora
fondamentalmente di una struttura a matrice, in quanto i singoli
partecipanti non vengono posti alle dirette dipendenze dell’unità
responsabile del progetto (che identifichiamo con il Project Manager), ma
restano alle dipendenze della funzione di provenienza.

D.C.

ENTI DI STAFF

P.M.1 P.M.n

AREE
FUNZIONALI F.M. F.M. F.M.

PRODUCT MANUFACTU-
MARKETING
DEVELOPMENT RING

Figura 3 - La struttura a task force

Vantaggi:
 responsabilità unica per progetto e utilizzo risorse
 interlocutore unico per il cliente
 affiatamento ed efficacia sul progetto
 comunicazioni dirette e ben definite
Svantaggi:
 costo di struttura elevato
 personale trattenuto sul progetto più a lungo del necessario
(inefficienza)
 mancanza di continuità ed opportunità di crescita specialistica
 difficoltà di travaso delle esperienze tra task e funzioni.

Project Management – Seminario Introduttivo pag 9 di 56


IL PROJECT OFFICE
Quando, per la gestione di un progetto, si adottano le metodologie proprie
del Project Management, oltre all’individuazione del Project Manager
stesso viene creato un apposito project office, inteso come luogo di
integrazione degli sforzi di tutti i partecipanti alla gestione del progetto:
ricordiamo infatti che i progetti comprendono molti compiti di varia natura, e
come tali richiedono l’apporto di risorse e competenze specialistiche
diversificate. Queste competenze possono essere assegnate tanto a
persone appartenenti alla struttura che ha in gestione il progetto, quanto a
persone esterne. In figura 4 è rappresentato un esempio di organigramma
di progetto.

Project Manager

Consulente tecnico

Progetto e sviluppo di Gestione prodotto Servizi ausiliari di


Installazione prodotto
prodotto coordinatore di project management
Manager installazione
Project engineer produzione Controller di progetto

Controllo Gruppo Reparti di Reparti di


prodotto sistemi produzione installazione

Progettazione

Software Hardware

Membri del project office


Rapporto tecnico
Partecipanti che non dipendono direttamente dal project manager
Il project manager, naturalmente, fruirà degli abituali supporti di staff
Officina prototipi

Servizi tecnici

Figura 4 - Esempio di organigramma di progetto

In generale, la dimensione del project office è funzione dell’entità e


dell’importanza del progetto; si può andare da una sola persona, il project
manager, fino a raggiungere le 10-15 persone o più, per progetti di grande
portata. E’ comunque buona norma limitare al massimo il numero di
persone assegnate al project office; questo per aumentare il
coinvolgimento (e, quindi, ottimizzare l’efficienza) delle varie funzioni
coinvolte (ricordiamo che il grado di coinvolgimento delle diverse funzioni
nel progetto varia nelle diverse fasi del progetto stesso), e, in secondo
luogo, per sgravare il project manager dai compiti di supervisione del
personale.
Diciamo che dovrebbero essere assegnate al project office le persone che:
 si occupano degli aspetti gestionali del progetto
 sono necessarie a tempo pieno per almeno sei mesi
 debbono avere contatti frequenti e stretti con il project manager o con
altri membri del project office per poter espletare i loro compiti
 non possono essere controllate efficacemente altrimenti, per ragioni
organizzative e geografiche

Project Management – Seminario Introduttivo pag 10 di 56


LE FASI DEL PROJECT MANAGEMENT
Per assicurare il raggiungimento degli obiettivi, occorre definire e
preventivare il processo teso al loro raggiungimento prima di partire, per
poter poi gestire il processo stesso in fase di avanzamento.
Ovvero, in corrispondenza di momenti di riesame prefissati si tratta di
verificare se quanto è stato fino a quel momento realizzato corrisponde a
quanto era stato preventivato in sede di pianificazione; in caso di ritardi o
imprevisti, si ha la possibilità di intervenire per tempo, apportando le
necessarie modifiche (ad esempio, in termini di risorse aggiuntive dedicate
alle attività ‘in ritardo’) al piano originario per poter recuperare in corsa gli
eventuali ritardi.
Alla luce di quanto visto, le fasi attraverso cui si articolano le attività del
project management sono riassunte in figura 5:

PIANIFICAZIONE D’OFFERTA

ACQUISIZIONE COMMESSA/PROGETTO

PROJECT START - UP

PROJECT CONTROL   PROJECT REVIEW

PROJECT CLOSE - DOWN
Figura 5 - Le fasi del project management

Scopo del project management, in ogni fase, è quello di PIANIFICARE,


CONTROLLARE E PREVEDERE PER POTER DECIDERE.
Noi concentreremo la nostra attenzione sulle fasi di start-up, control, review
e close-down del progetto; nella tabella seguente sono indicate le attività
principali di queste fasi:

Project Management – Seminario Introduttivo pag 11 di 56


START-UP - PIANIFICAZIONE articolazione lavoro/responsabilità
piano tempi (programma di sintesi)
piano risorse (carico di lavoro)
piano costi (preventivo parametrico)
piano finanziario (fonti/destinazioni)
- PROGRAMMAZIONE stima quantità/durate)
programma reticolare
allocazione risorse
- PREVENTIVAZIONE preventivo operativo
baseline tempi/costi
programma incassi/esborsi
- BANCA DATI DEL PROGETTO impostazione del progetto

CONTROL - RILEVAZIONE E MISURA avanzamento fisico, temporale,


AVANZAMENTO economico
rilevazione consuntivo / impegnato
- ANALISI E STIME A FINIRE indici e tendenze
stime a finire (quantità e costi)
riallocazione risorse
status reporting
- EVIDENZIAZIONE PROBLEMI simulazione impatti
simulazione soluzioni alternative
- ARCHIVIAZIONE alimentazione banca dati e
manuale di progetto

REVIEW - RIPIANIFICAZIONE simulazioni e decisioni


revisione articolazione/responsabilità
revisione programma tempi e risorse
revisione programma incassi/esborsi
- GESTIONE VARIANTI qualificazione e presentazione
negoziazione e approvazione
revisione preventivo e baseline
controllo
- GESTIONE RISERVE riallocazione riserve
controllo
- CONFIGURATION MANAGER aggiornamento tecnico del prodotto
revisione documentazione

CLOSE DOWN - RIESAME CRITICO strategie e politiche


redditività economica e finanziaria
cause di successo/insuccesso
- BANCA DATI AZIENDALE logiche di attuazione
durate consuntive

Project Management – Seminario Introduttivo pag 12 di 56


LA WORK BREAKDOWN STRUCTURE (W.B.S.)

CHE COSA È LA W.B.S.?


La necessità di gestire le molteplici variabili (risorse umane e finanziarie,
tempi, etc,) legate alla realizzazione di un macro-progetto, ha indotto gli
specialisti di “gestione-progetti” a creare un metodo che consentisse loro la
frammentazione dello stesso in tanti sotto-progetti più piccoli e meglio
gestibili.
Tale metodo quindi, è nato dalla necessità di gestire in maniera più
dettagliata e quindi meglio pianificabile e controllabile, le attività da
svolgere, per la realizzazione di un determinato progetto.
Ciò consente di assegnare le attività da svolgere a responsabilità precise,
di pianificare sia le sequenze logiche di attuazione del lavoro che le
quantità da produrre e le risorse necessarie, di programmare i tempi, di
preventivare le risorse ed i costi, di determinare l’avanzamento fisico e di
consuntivare le risorse ed i costi utilizzati al fine di stimare quantità, costi e
tempi a completamento; tutto questo in modo integrato e strutturato.
Per gestire tutto ciò è necessario adottare una struttura ad albero del
lavoro da fare, cioè creare una WORK BREAKDOWN STRUCTURE:
ovvero un’articolazione logica e gerarchica del lavoro da svolgere diretto
a produrre il risultato del progetto.
Logica, in quanto la logica di costruzione ed articolazione della W.B.S. non
è altro che la logica di gestione del progetto, e gerarchica perché ad ogni
livello della W.B.S. si ritrova tutto il lavoro da svolgere la cui
segmentazione è coerente con i livelli di pianificazione.
La W.B.S. comprende sia tutti i risultati del progetto:
 prodotti;
 servizi;
 funzioni
 mezzi di sviluppo;
 mezzi di prova;
 attrezzature specifiche;
che tutte le azioni che concorrono a determinare tali risultati:
 gestione;
 impostazione;
 progettazione;
 realizzazione;
 prove;
 avviamento;
 integrazione;
 qualità.

Project Management – Seminario Introduttivo pag 13 di 56


QUALI OBIETTIVI SI PONE LA W.B.S.?
Gli obiettivi principali che con l’utilizzo di una W.B.S. si intendono
conseguire sono:
1. assicurare che tutti gli obiettivi del progetto siano raggiunti attraverso
obiettivi di livello inferiore più controllabili (i cd. miles stones);
2. garantire che la struttura del progetto sia integrata e che ogni sua parte
sia consistente e legata al tutto;
3. assegnare i compiti e le responsabilità esecutive;
4. facilitare l’identificazione delle attività, ai vari livelli, da inserire nel
reticolo logico (trattato più avanti) di progetto;
5. permettere il controllo dei costi di ogni livello e aggregato;
6. permettere l’identificazione delle attività che causano scostamenti
(T,$,Q);
7. agevolare la ripianificazione del progetto o di sue parti;
8. agevolare lo sviluppo di decisioni di make or buy (ossia di fabbricare o
acquistare);
9. facilitare la comunicazione tra le varie funzioni coinvolte.

COME SI REALIZZA UNA W.B.S.?


Per rappresentare graficamente una W.B.S. di progetto è necessario
seguire una certa logica di costruzione, riepilogabile in queste fasi:
a) individuazione degli obiettivi/prodotti finiti (hardware, servizi,
attrezzature, etc.) del progetto tenendo conto delle logiche di gestione;
b) suddividere questi nelle parti componenti (strutture del progetto), nelle
fasi di evoluzione o nel mix dei precedenti (componenti + fasi);
c) suddividere ulteriormente i componenti e/o fasi fino a livello di attività e
compiti individuali da attribuire a singole unità organizzative o a singole
persone;
d) esplodere in attività elementari;
e) attribuire i codici di riferimento per i vari livelli della W.B.S., necessari
per una gestione informatica dei dati di progetto;
f) individuare le corrispondenze tra attività e responsabilità.

Project Management – Seminario Introduttivo pag 14 di 56


TECNICHE DI PIANIFICAZIONE

TECNICHE DI PIANIFICAZIONE E CONTROLLO


Abbiamo visto che, dovendo gestire una attività (progetto) di una certa
complessità, conviene scindere il progetto intero nelle sue fasi
(componenti), in modo che l’insieme delle componenti rappresenti il
progetto nella sua globalità. Andando ad esplodere successivamente in
modo ricorsivo le varie componenti, fino a quando non si raggiunge il livello
di dettaglio che si ritiene opportuno, si viene ad ottenere un grande numero
di attività elementari che, considerate tutte insieme, rappresentano l’intero
progetto.
Considerandole una per una, invece, le singole attività (‘pacchetti di
lavoro’) sono facilmente gestibili e controllabili (nel senso che possiamo
attribuire ogni singolo pacchetto di lavoro ad una specifica risorsa e,
potendo facilmente valutare quali attività sono state portate a compimento,
possiamo facilmente renderci conto dello stato di avanzamento
complessivo raggiunto dal progetto).
Quindi, siamo riusciti a creare un sistema che ci consente di scindere,
seguendo un processo rigorosamente logico, un’opera complessa nei vari
elementi che la compongono; è ora necessario riuscire ad organizzare tra
di loro queste attività elementari, e per fare questo bisogna definire per
ogni pacchetto di lavoro:
 le attività che lo devono precedere (senza le quali, cioè, l’attività in
questione non può aver luogo)
 le attività che sono da esso condizionate (ovvero le attività che possono
aver luogo solo se l’attività in questione si è conclusa)
 la durata dell’attività
Avendo a disposizione questi dati, possiamo pensare di definire quale
tragitto seguire (ovvero, QUANDO svolgere QUALE attività).

Il diagramma di Gantt
Il diagramma di Gantt costituisce una semplice tecnica usata per
rappresentare graficamente la tempificazione prevista per lo svolgimento di
una serie di attività (vedi figura 1).
ciascuna riga del diagramma può rappresentare:
 il tempo in cui è prevista l’esecuzione di una certa operazione (è il caso
rappresentato in figura)
 il periodo in cui è previsto l’impegno di una risorsa (una persona, una
macchina, un impianto...)

Project Management – Seminario Introduttivo pag 15 di 56


Tempi GIORNO
Operazione 4 8 12 16 20 24 28
A

Figura 1: Il diagramma di Gantt

Si tratta di una rappresentazione grafica molto semplice, immediata e


leggibile di quella che è la logica secondo la quale devono svolgersi tutte le
diverse attività che costituiscono un progetto, e su questo diagramma
possiamo rappresentare in modo semplice gli eventuali scostamenti dal
piano originario che le diverse attività hanno subito. Per contro, il
diagramma di Gantt è per sua natura statico, di mera visualizzazione, e
non uno strumento di programmazione vero e proprio.

Introduzione alle tecniche reticolari


Le tecniche reticolari sono la base su cui si effettua la programmazione
delle attività.
Noi definiamo il reticolo come un modello che rappresenta le modalità
effettive secondo le quali si prevede di realizzare il progetto, costituito da
attività logicamente collegate tra di loro. Queste tecniche sono basate sulla
teoria dei grafi (un grafo è un insieme di nodi connessi tra di loro da archi,
la cui successione determina il cammino). Lo sviluppo del reticolo delle
attività costituisce la base sulla quale l’organizzazione può valutare in
modo razionale le opzioni che si presentano in sede di pianificazione delle
attività.
Osserviamo che le attività che vanno a costituire il reticolo logico altro non
sono che i singoli pacchetti di lavoro (WBE) che avevamo individuato
quando siamo andati a definire la WBS del progetto (vedi, come esempio,
la figura 2).

Project Management – Seminario Introduttivo pag 16 di 56


WBS DI PROGETTO

Progetto

WBE 1
Descrizione

RETICOLO DI PROGETTO

attività 1
DESCRIZIONE, DURATA,
RESPONSABILITA'

Figura 2: dalla WBS di progetto al reticolo delle attività

Nel reticolo logico, possiamo individuare tre tipi di elementi fondamentali:


 evento è uno stato rappresentativo dell’evolversi del progetto
rappresenta l’inizio o la fine di una attività
non presuppone l’impiego di tempo
 attività è lo svolgersi di una azione
e l’elemento di lavoro all’interno del progetto
è un obiettivo di lavoro che deve essere raggiunto
ha inizio con un evento e termina con un altro
richiede l’impiego di tempo e/o mezzi
 durata è il tempo di completamento dell’attività, comprensivo tanto
del tempo tecnico quanto del tempo passivo
Il tempo tecnico è il tempo fisicamente necessario per lo svolgimento di
una operazione, mentre il tempo passivo è il tempo connesso all’attività,
ma non al suo svolgimento fisico. Ad esempio, per tornire 100 pezzi sono
necessarie 8 ore di lavoro (tempo tecnico); i pezzi, però, devono essere
trasportati al tornio, devono attendere che il tornio sia disponibile, e quindi,
una volta torniti, devono essere controllati: il tempo necessario per lo
svolgimento di queste ultime operazioni costituisce il tempo passivo, che
non è relativo allo svolgimento fisico dell’attività ma è comunque
necessario.

Project Management – Seminario Introduttivo pag 17 di 56


Modalità di rappresentazione
Noi vedremo due differenti modalità di rappresentazione di un reticolo:
 ARROW DIAGRAM METHOD (ADM), che di norma si utilizza
congiuntamente alla programmazione P.E.R.T.
 PRECEDENCE DIAGRAM METHOD (PDM), associato in genere alla
programmazione secondo il metodo del Critical Path Method
Una schematizzazione delle tecniche di pianificazione e delle modalità di
rappresentazione cui vengono normalmente associate è riportata in figura 3.

PROGRAMMAZIONE
RETICOLARE

P.E.R.T. C.P.M.
Program Evaluation METODI DI Critical Path
and review technique CALCOLO Method
Durate Durate
Probabilistiche Deterministiche

A.D.M. P.D.M.
Arrow Diagram METODI DI Precedence
Method RAPPRESENTAZIONE Diagram Method

Figura 3: Tecniche e rappresentazioni per la programmazione reticolare

Per quanto riguarda l’Arrow Diagram Method:

8 3

 gli eventi sono indicati con un circolo


 le attività con un segmento orientato
 una attività collega sempre due eventi
 la successione degli eventi è indicata dal verso della freccia
 la numerazione degli eventi non è legata alla successione logica degli
stessi
 ogni reticolo ha un evento iniziale ed uno finale

Project Management – Seminario Introduttivo pag 18 di 56


La rappresentazione secondo il Precedence Diagram Method:
 le attività sono rappresentate con un rettangolo
 i legami sono rappresentati con delle linee che uniscono due attività.
Possono essere di 4 tipi, a seconda di quella che è la logica secondo cui
possono succedersi le diverse attività:

1. Legami FINISH TO START

F.S. 0
A B

"B" PUO' INIZIARE SOLO DOPO LA FINE DI "A"

2. Legami START TO START

S.S. 0
A B

"B" PUO' INIZIARE SOLO SE E' INIZIATA "A"

3. Legami START TO FINISH

S.F. 0
A B

"B" PUO' FINIRE SOLO SE E' INIZIATA "A"

4. Legami FINISH TO FINISH

F.F. 0
A B

"B" PUO' FINIRE SOLO SE E' FINITA "A"

Inoltre, tali legami possono essere anche differiti nel tempo; ad esempio,
per il legame di tipo 1 (finish to start):

Project Management – Seminario Introduttivo pag 19 di 56


10 F.S. +10
A B

"B" PUO' INIZIARE 10 GIORNI DOPO LA FINE DI "A"

(questo differimento è sottolineato dalla scritta a destra della figura).

Program Evaluation and Review Technique (P.E.R.T)


 nasce negli Stati Uniti alla fine degli anni ‘50 su incarico della marina
militare, per seguire il progetto del sommergibile POLARIS
 trova applicazione quando le attività hanno durata incerta (ovvero,
stimiamo la durata media delle attività e la varianza delle stesse; quindi,
stante la forte incertezza relativa ai tempi di svolgimento, preferiamo
fare i nostri programmi e relativi calcoli mantenendo un margine di
indeterminazione quantificato sulle durate piuttosto che gestire per ogni
attività una durata fissa; soluzione più semplice ma spesso meno
realistica)
 sulla base di quanto appena detto, trova applicazione in attività quali
progetti di fattibilità, di ricerca o comunque innovativi, ovvero progetti per
i quali una stima deterministica delle durate delle attività può risultare
particolarmente difficoltosa
 di solito, per la programmazione P.E.R.T. si usa la rappresentazione
ADM.
 conoscendo media e varianza delle durate delle singole attività, siamo in
grado di dare delle risposte (sempre in termini di probabilità)
relativamente alla durata dell’intero progetto od alla probabilità di
completamento in un determinato lasso di tempo (P.E.R.T. statistico)

Programmazione P.E.R.T. - un esempio applicativo


Per spiegare come procedere nella realizzazione della programmazione
P.E.R.T., rifacciamoci ad un esempio molto semplice, ovvero una possibile
organizzazione delle attività per la realizzazione di una gru. Supponiamo di
aver già definito la WBS (ovvero, le singole attività che costituiscono il
progetto); supponiamo inoltre di aver già individuato i vincoli logici di
svolgimento delle attività (cosa deve essere stato svolto per poter
effettuare una determinata operazione), la durata attesa e la deviazione
standard associata ad ogni durata. A questo proposito, definiamo:
 a = durata ottimistica di una attività (durata che una scarsa probabilità,
ad esempio, lo 0,5 %, di non essere superata)
 m = durata più probabile (per intenderci, se abbiamo la distribuzione che
rappresenta le durate di attività analoghe a questa, m rappresenta il
valore modale di tale distribuzione (quello che capita più spesso)

Project Management – Seminario Introduttivo pag 20 di 56


 b = durata pessimistica (durata che ha una scarsa probabilità, ad
esempio lo 0,5 %, di essere superata)
 De = durata attesa dell’evento
  = deviazione standard della distribuzione che rappresenta la durata
dell’attività
Assumiamo:
a + 4m + b
De =
6
b-a
=
6
Nella tabella seguente sono riassunti questi dati:
Attività Vincoli  De
a progetto / 1,67 20
b disegni a 1,17 10
c ordine struttura b 1,67 10
d ordine motori b 0,5 5
e ordine allacciamenti b 0,83 8
f costruzione e trasporto struttura c 5 42
g montaggio struttura f 0,83 10
h costruzione e trasporto motori d 2,5 31
i costruzione allacciamenti e 2,5 31
l montaggio motori g, h, i 0,83 5
m collaudo l 0,5 3

A questo punto, passiamo a costruire il reticolo delle attività, tenendo


presente per il momento solo i vincoli di precedenza tra le attività stesse, e
non le durate con le relative varianze.
(consiglio pratico: come prima cosa, stendiamo “in brutta” la bozza del
reticolo partendo dall’ultima delle attività, la ‘m’ nell’esempio; quindi
procediamo all’indietro segnando le attività che sono i vincoli per
l’operazione in oggetto, ovvero la ‘l’, e andiamo avanti così, a ritroso, fino
ad aver introdotto tutte le attività del progetto. A questo punto, partendo
dallo schema ottenuto, andiamo a ridefinire in modo leggibile ed ordinato il
reticolo delle attività, a questo punto partendo dall’inizio).
In figura 4, è rappresentato il reticolo delle attività relativo al progetto in
questione.

Project Management – Seminario Introduttivo pag 21 di 56


Figura 4: Reticolo delle attività dell’esempio

Abbiamo detto che la programmazione P.E.R.T. trova applicazione quando


le attività hanno una durata incerta (infatti, per i nostri calcoli utilizziamo la
durata attesa De e la deviazione  dei tempi di completamento delle
operazioni); a questo punto, però, facciamo l’ipotesi che le attività durino
effettivamente il tempo De.
Facciamo inoltre l’ipotesi che ogni attività inizi nell’istante stesso in cui si
concludono tutte le attività che costituiscono i suoi vincoli di precedenza
(nell’esempio, ipotizziamo che l’attività ‘l’ abbia inizio non appena si sono
concluse le attività ‘g’, ‘h’, ‘i’); in queste ipotesi, la data di inizio delle attività
prende il nome di Data Minima (Tmin): rappresenta, in pratica, la data
prima della quale un evento non può verificarsi).
Per il loro calcolo, si parte dall’evento di inizio e si prosegue in avanti.

T m in,x
= max
h {T m in,h
+ De,h }
ove gli eventi h sono tutti gli eventi di inizio delle attività confluenti nel nodo x.
Nell’esempio, calcoliamo Tmin relativamente all’evento 7; abbiamo
calcolato la data minima relativamente agli eventi 4, 5 e 6 che vale
rispettivamente 82, 35 e 68. Per calcolare Tmin,7 dovremo sommare per
ogni evento la sua data minima con la durata dell’attività che parte da
quell’evento (rispettivamente 10, 31 e 31) e scegliere il risultato maggiore
tra quelli ottenuti:
Tmin,7 = max 82 +10 (92); 35 + 31 (66); 38 + 31 (69) =92
evento 4; att. g evento 5; att. h evento 6; att. i

Ora, definiamo la Data Massima (Tmax) come quella data oltre la quale
una attività non deve verificarsi, altrimenti va in ritardo l’intero progetto.

Project Management – Seminario Introduttivo pag 22 di 56


Si calcola partendo dall’evento di fine del progetto e si procede a ritroso;
occorre aver già calcolato le date minime degli eventi.

T m a x,x
= m in
h {T m a x,h
- De,h }
ove gli eventi h sono tutti gli eventi di fine delle attività che partono dal nodo x.

Nell’esempio, calcoliamo Tmax relativamente all’evento 2; abbiamo


calcolato la data massima relativamente agli eventi 3, 5 e 6 che vale
rispettivamente 40, 61 e 61. Per calcolare Tmax,2 dovremo sottrarre per
ogni evento alla sua data massima la durata dell’attività che giunge in
quell’evento (rispettivamente 10, 5 e 8) e scegliere il risultato minore tra
quelli ottenuti:

Tmax,2 = min 40 - 10 (30); 61 - 5 (56); 61 - 8 (53) = 30


evento 3; att. c evento 5; att. d evento 6; att. e

Dopo aver calcolato data minima e data massima, passiamo a definire:


evento critico è un evento per il quale coincidono la data minima e la data
massima;
cammino critico è il percorso che unisce l’evento di inizio a quello di fine
tramite esclusivamente eventi critici (se ne individua almeno uno in ogni
reticolo, e molto spesso è unico).
Qualunque ritardo in una attività appartenente al cammino critico non può
essere assorbito, e provoca un identico ritardo sulla durata complessiva del
progetto; pertanto dovremo tenere sott’occhio con particolare attenzione le
attività critiche, nel corso dell’evolversi del progetto.
NB: quanto appena detto, è esatto nell’ipotesi che le tutte le attività durino
effettivamente De. Considerando che i tempi di completamento delle
attività sono statistici, potrebbe succedere che le varie attività non
durino effettivamente De ma di meno (e questo ci tornerebbe a
vantaggio) o di più. In questo caso, può succedere che un percorso
originariamente non critico, a causa dell’allungamento dello
svolgimento delle attività rispetto a quanto previsto, lo diventi durante
l’avanzamento del progetto.
Anche per rispondere a quest’ultima osservazione, definiamo un altro paio
di grandezze:
slittamento totale St (che può verificarsi in un ramo parallelo a quello
critico): è quello slittamento che, usufruito totalmente da un’unica attività
del ramo, rende critiche nel ramo stesso tutte le attività, a valle ed a monte.
In formula:

St = Tmax,i - Tmin,i-1 - De

Project Management – Seminario Introduttivo pag 23 di 56


Tornando al nostro esempio, calcoliamo lo slittamento totale relativamente
alle attività ‘d’ ed ‘i’:
St,d = 61 - 30 - 5 = 26
Tmax,5 Tmin,2 De attività d

St,i = 92 - 38 - 31 = 23
Tmax,7 Tmin,6 De attività i

slittamento libero Sl: è quello slittamento che, pur usufruito per intero da
una attività del ramo, non rende critiche tutte le attività a valle (ovvero, non
ha influenza sulla loro data minima di inizio). In formula:

Sl = Tmin,i - Tmin,i-1 - De

Nell’esempio, calcoliamo lo slittamento libero relativamente alle stesse


attività, ‘d’ ed ‘i’:

Sl,d = 35 - 30 - 5 =0
Tmin,5 Tmin,2 De attività d

Sl,i = 92 - 38 - 31 = 23
Tmin,7 Tmin,6 De attività i

Nella tabella seguente, è riportato il riepilogo dei valori ottenuti


relativamente alle attività del nostro esempio, mentre la figura 5 è la
rappresentazione del reticolo completa di tutti i valori ricavati.

Attività Vincoli  De St Sl
a progetto / 1,67 20 0 0
b disegni a 1,17 10 0 0
c ordine struttura b 1,67 10 0 0
d ordine motori b 0,5 5 26 0
e ordine allacciamenti b 0,83 8 23 0
f costruzione e trasporto struttura c 5 42 0 0
g montaggio struttura f 0,83 10 0 0
h costruzione e trasporto motori d 2,5 31 26 26
i costruzione allacciamenti e 2,5 31 23 23
l montaggio motori g, h, i 0,83 5 0 0
m collaudo l 0,5 3 0 0

Project Management – Seminario Introduttivo pag 24 di 56


Figura 5: Reticolo completo delle attività dell’esempio

La durata totale del progetto, logicamente, sarà pari alla somma della
durata di tutte le attività che costituiscono il cammino critico; inoltre, dato lo
scarto medio  della durata di ogni attività, possiamo calcolare il valore di 
relativamente ad ogni percorso utilizzando la seguente formula:

(T ) =   ) n 2
 i

ove i i sono gli scarti del valore della durata delle attività appartenenti al
percorso in questione. Ovviamente, il percorso più interessante da studiare
è il percorso critico, e nel nostro esempio risulta che sul cammino critico
(T) = 5,8116.

Tramite questo studio del reticolo (che talvolta passa sotto il nome di
P.E.R.T. statistico), siamo in grado di rispondere ad una serie di domande
di questo tipo:
qual è il percorso critico del progetto?
[il percorso critico risulta costituito dalle attività a, b, c, f, g, l, m ovvero dagli
eventi 1, 2, 3, 4, 7, 8, 9]
qual è la durata attesa dell’intero progetto?
[la durata attesa si ottiene sommando le durate delle attività critiche;
risulterà pari a 100 giorni]
che probabilità ho di terminare il progetto in un determinato periodo di
tempo, ad esempio 120 giorni?
[alla durata attesa corrisponde al 50% di probabilità di completamento del
progetto; per calcolare la probabilità di completamento in 120 giorni si

Project Management – Seminario Introduttivo pag 25 di 56


applica la formula di standardizzazione di una variabile casuale; in questo
caso, per 120 giorni, risulta una probabilità del 93,7 %]
in quanto tempo terminerò l’attività con una probabilità definita? (ad
esempio quanto tempo dovremo preventivare per lo svolgimento del
progetto per essere sicuri al 90 % del suo completamento)
[sempre passando attraverso la standardizzazione della variabile casuale,
utilizzando la trasformazione inversa, otteniamo un tempo pari a 107 giorni]

ALCUNE CONSIDERAZIONI
Il metodo C.P.M.
Appare opportuno, visto che non se ne è parlato, definire in cosa differisce
il metodo C.P.M. dalla programmazione P.E.R.T. La differenza
fondamentale sta nel fatto che, mentre la programmazione P.E.R.T. si
basa su attività dalla durata incerta (di cui però si conosce la distribuzione
di probabilità), il metodo C.P.M. considera attività caratterizzate da un’unica
durata, che è una quantità deterministica. Questo ci permette di pianificare
i lavori in un modo diverso; infatti possiamo individuare in modo immediato
ed univoco le attività critiche senza dover tenere conto delle variazioni
statistiche della durata delle attività alla base del P.E.R.T. (ricordiamo che
nel P.E.R.T un percorso originariamente non critico può diventare critico se
le attività che lo compongono hanno una durata effettiva maggiore di De, e
questa è una eventualità prevista dal metodo). Però, per poter utilizzare
per le varie attività delle durate deterministiche (quindi immediatamente
individuate, senza possibile varianza) occorre sapere quanto
effettivamente dura la singola attività, e ciò è possibile per classi di progetti
diverse rispetto alle attività studiate con la programmazione P.E.R.T., o
comunque se si ha a disposizione un archivio di progetti precedentemente
studiati tale da consentire la definizione precisa della durata della singola
attività.

Complessità dei reticoli logici


Abbiamo visto lo studio del reticolo logico relativo ad un semplice ipotetico
progetto, costituito da solo 11 attività. Ci siamo resi conto che la definizione
del reticolo e quindi il calcolo dei vari fattori che compaiono nel reticolo non
è la cosa più semplice di questa terra pur dovendo gestire pochissime
attività. A questo punto, osserviamo che queste tecniche di pianificazione e
controllo sono di norma applicate a progetti di elevata complessità in cui si
parla normalmente di centinaia di attività relative allo svolgimento di un
progetto. Il calcolo manuale del reticolo diventa a questo punto di fatto
impossibile, così come impossibile diventa leggere il grafico che
rappresenta il reticolo.
Un possibile metodo per semplificare le cose senza rinunciare ad una
visione dettagliata del progetto, è quello denominato ’Rolling wave’ (cresta

Project Management – Seminario Introduttivo pag 26 di 56


dell’onda): tale metodo consiste nello svolgere la pianificazione di dettaglio
relativamente alle attività che dovranno aver luogo nell’immediato futuro (si
parla di finestre temporali di qualche mese), lasciando il resto del progetto
sviluppato solo a grandi linee (in pratica, si tratta di definire la WBS di
dettaglio relativamente solo alle attività destinate al futuro immediato,
lasciando nel generale, magari rappresentandole esplose solo al primo
livello di WBS, le altre attività).

Strumenti di supporto
Il metodo ‘Rolling wave’, anche se può essere di aiuto, non costituisce di
fatto la soluzione al problema; infatti, se da un lato diminuisce la
confusione a livello di rappresentazione, comunque non diminuisce di una
virgola la mole di calcoli da svolgere per la corretta effettuazione delle
attività di pianificazione e, successivamente, di controllo dello stato di
avanzamento delle attività.
Esiste in commercio una grande varietà di prodotti software orientati alla
gestione di progetti; si parte da prodotti di grande mercato, ovvero
applicativi semplici dal costo relativamente contenuto, sino ad arrivare a
pacchetti di estrema completezza (ovviamente, in questi casi il costo sale).
Se si deve acquistare un prodotto di questo tipo, bisogna valutare che sia
in grado di supportare tutte le attività cui si ha intenzione di far riferimento:
la programmazione P.E.R.T. piuttosto che il metodo C.P.M., la gestione dei
costi e delle responsabilità, l’utilizzo delle risorse e così via. In sintesi,
esistono molti (e molto diversi tra di loro) prodotti disegnati per supportare
le tecniche di Project Management; prima di acquistarne uno, bisogna
essere certi di scegliere un prodotto in grado di supportare tutte le attività
che dobbiamo svolgere.

La sequenza temporale delle attività


Abbiamo parlato di definizione della WBS e del reticolo logico; ora
vogliamo sottolineare l’ordine logico con cui si svolgono queste attività:
1. Definizione della WBS di progetto giungendo all’opportuno livello di
dettaglio
2. Definizione del reticolo logico delle attività, e quindi del percorso critico e
delle risorse da allocare al progetto
3. Programmazione vera e propria (scheduling): solo a questo punto si può
programmare lo svolgimento delle attività. I passi da seguire sono i
seguenti:
a) Proiezione
a) del reticolo logico definito sul calendario
b) Definire
b) una prima programmazione dei lavori
c) Verificare
c) il livello di utilizzo delle risorse (verificare, ad
esempio, di non impiegare in un periodo più risorse di quelle
che effettivamente abbiamo a disposizione)

Project Management – Seminario Introduttivo pag 27 di 56


LE RISORSE

CHE COSA SONO LE RISORSE?


Le Risorse sono quei fattori critici attraverso il cui impiego/utilizzo viene
realizzato l’obiettivo di ciascuna attività.

QUALI SONO LE RISORSE?


All’interno di un progetto, le Risorse necessarie alla sua realizzazione
possono essere molteplici; di seguito andremo ad enunciarne le principali:
 MATERIALI;
 LAVORO (impiegati, operai, interni, esterni);
 ATTREZZATURE - IMPIANTI;
 SUBFORNITORI;
 ALTRI COSTI DIRETTI (capacità elaborativa, etc.).

Project Management – Seminario Introduttivo pag 28 di 56


TECNICHE DI CONTROLLO DEI PROGETTI

IL CONTROLLO DI AVANZAMENTO

Che cosa è il controllo di avanzamento dei progetti?


Una volta che il progetto è stato avviato, il PERCORSO CRITICO e il
PROGRAMMA PREDEFINITO dovrebbero rappresentare il supporto
operativo per lo svolgimento corretto e per il controllo sulle diverse attività.
Tuttavia, è nella natura stessa del progetto la possibilità che possano
verificarsi scostamenti rispetto al previsto.
Diventa perciò essenziale procedere a verifiche periodiche e ad
aggiornamenti del programma in relazione alle varianze intervenute.
In corrispondenza di precise scadenze temporali (“data date”) si
procederà quindi alla estrazione di informazioni di avanzamento, alla
consuntivazione di quanto avvenuto e alla presa di decisioni su eventuali
azioni correttive per il programma futuro.

Perché controllare?
Le necessità di controllo nascono da varie necessità:
 per avere una fotografia del progetto e valutare la situazione rispetto
alle attese;
 per decidere gli eventuali interventi correttivi;
 per elaborare stime a finire e indici di performance;
 per elaborare simulazioni di alternative.

Quali criteri di analisi si adottano?


Sulla misurazione dei dati di avanzamento temporale e fisici si basano sia i
criteri di analisi che consentono di valutare l’andamento del progetto fino
alla “data date” e a misurare eventuali scostamenti rispetto al previsto
(controllo), ma soprattutto utilizzare i dati calcolati per elaborare le stime a
finire (previsione/simulazione).

Project Management – Seminario Introduttivo pag 29 di 56


NOTE INTRODUTTIVE
L’attività della maggior parte delle imprese è organizzata per progetti.
Abbastanza intuitivamente, si può affermare che un progetto è “l’insieme di
azioni, o passi, da svolgersi contemporaneamente o in sequenza,
strettamente necessarie al raggiungimento di un obiettivo finale: la
realizzazione di un prodotto nel rispetto di risorse assegnate.”
Ognuno di questi passi richiede un tempo di esecuzione e comporta costi
che i progettisti stimano in sede di pianificazione del progetto, al fine di
poter preventivare una data di completamento del lavoro e i relativi
investimenti.
Nello sviluppo di un progetto costi e tempi sono strettamente legati, uno
dipendente dall’altro. Lo sviluppo delle fasi progettuali è gestito da risorse
umane il cui costo dipende dal tempo impiegato; sulle fasi di realizzazione
dell’opera gravano spesso penali legate alle date di completamento delle
attività; ricordiamo anche il tempo di ritorno sull’investimento che, per
alcuni progetti, non è certo trascurabile!
Quindi, quando parleremo di “previsioni”, “specifiche” o “condizioni” di
progetto ci riferiremo indifferentemente ai costi e ai tempi.
Nonostante l’attenzione posta nella fase di previsione, non è sempre facile
portare a termine le attività nel rispetto della pianificazione effettuata, a
meno di non giungere a seri compromessi che incidono o sulle specifiche
di prodotto o sul ricavo del lavoro.
L’incertezza, l’imprevisto che caratterizzano la vita quotidiana, infatti,
colpiscono anche il mondo dei progetti, rischiando di compromettere il
risultato finale.
Come fare dunque a controllare lo sviluppo del progetto in modo da
raggiungere gli obiettivi prefissati?
Non considerare a fondo gli elementi che vincolano in qualsiasi modo lo
sviluppo delle attività vanifica gli sforzi e porta a sforare le previsioni
temporali, con una conseguente lievitazione dei costi.

IL PROBLEMA DEL PROJECT MANAGER


Per quanto si facciano previsioni dettagliate sui tempi di realizzazione delle
singole fasi e ipotesi di costo dettagliate, capita molto spesso di incorrere
in due fenomeni alquanto spiacevoli:
 il superamento del tempo massimo previsto,
 il superamento del budget di spesa.
Entrambi questi problemi rappresentano due facce della stessa medaglia:
l’incertezza.

Project Management – Seminario Introduttivo pag 30 di 56


I progetti, infatti, come qualunque altro aspetto della vita quotidiana, non
sono esenti dai colpi inferti dalla cosiddetta “legge di Murphy”; l’imprevisto
è sempre dietro l’angolo, pronto a colpire quando meno ce lo aspettiamo e
a rovinare tutta la nostra pianificazione.
Un’assenza improvvisa, un guasto ad un macchinario, una fornitura errata
sono tutti elementi che rischiano di minare nel profondo il regolare fluire di
un processo con conseguenze anche serie per il lavoro, ma anche per il
futuro dell’azienda.
In effetti, terminare un progetto oltre il tempo massimo previsto può far
perdere all’organizzazione credibilità, quote di mercato e guadagni
considerevoli a causa delle mancate vendite.
Anche il superamento dei costi può arrecare danni; l’organizzazione può
essere costretta a sobbarcarsi spese che fatica a sopportare e queste, se
accompagnate da un ritardo nel completamento del progetto e da una
conseguente procrastinazione negli incassi, può condurre un’azienda al
tracollo finanziario.
Quando il responsabile del progetto si rende conto che il completamento
del progetto entro i termini previsti è in pericolo, scattano le difese: Esse
possono essere, ad esempio:
 ricorrere allo straordinario, lavorando anche fuori dall’orario
quotidiano o in giorni non lavorativi;
 coinvolgere altre risorse, interne o esterne all’organizzazione;
 giungere, laddove sia possibile, ad un compromesso sulle
specifiche di progetto.
Come si può notare le azioni che si mettono in atto sono riparatrici e hanno
come obiettivo quello di diminuire l’entità del danno… che comunque ci
sarà!
Il responsabile di progetto si troverà a dover scegliere che cosa
proteggere: il tempo o i costi?
Potrà capitare infatti che si riesca a rispettare i tempi di consegna previsti,
a scapito dei costi, oppure che si mantengano i costi previsti, a scapito del
tempo o della qualità del prodotto finale. Entrambe queste situazioni non
sono positive per l’organizzazione che si troverà ad avere ricavi inferiori a
quelli previsti o una perdita di competitività e di quote di mercato.
Un buon manager di progetto si trova dunque a voler proteggere le sue
previsioni per non dover adattarsi al compromesso offerto dalle azioni
correttive sopra descritte. Ma gli avvenimenti che possono interferire sul
risultato delle attività sono molti e imprevedibili. Nessuna azione infatti è
immune dall’incertezza e dalla variabilità delle condizioni con cui
continuamente siamo costretti a fare i conti.

Project Management – Seminario Introduttivo pag 31 di 56


LA VARIABILITÀ
La variabilità è una caratteristica intrinseca a tutti i processi ed è la causa
principale della maggior parte dei problemi. Sarà impossibile infatti
prevedere tutto ciò che può capitare durante un percorso articolato,
formato da più fasi e svolto da più persone.

LA VARIABILITÀ NATURALE
Esiste una variabilità naturale con cui ci scontriamo quotidianamente. Un
esempio chiarirà meglio la situazione:
siamo a capo di un gruppo di amici che devono partire per trascorrere una
vacanza insieme. Dopo avere effettuato le prenotazioni ci troviamo a dover
organizzare quanto meno la partenza.
L’aeroporto dista 90 Km dalla città di partenza e la strada da percorrere è
un‘autostrada piuttosto trafficata. I biglietti riportano come ora di
presentazione al check-in le 10,30 della mattina. Decidete di organizzare
due auto piccole che porteranno il gruppo a destinazione, in modo da
evitare il più possibile problemi di parcheggio.
Dovete stimare il tempo di viaggio fino all’aeroporto.
Percorrete spesso quel tratto di autostrada e sapete bene che per coprire i
90 Km ci impiegherete all’incirca 45 min. … all’incirca… cosa significa?!
Disegniamo la distribuzione della probabilità che abbiamo di arrivare in 45
min all’aeroporto:

p
r
o
b
a
b
i
l
i
t
à

Fig. 1 T
e
La vostra esperienza vi insegna che il tempo di percorrenza del tratto di
m
strada varia generalmente in questo modo:
p
 45 min., in una giornata normale; o
 più di un’ora, in una giornata piovosa;
d
 anche un’ora e mezza in caso di traffico intenso causato da piccoli
i
incidenti (piuttosto frequenti).
p
e
r
c
o
Project Management – Seminario Introduttivo pag 32 di 56
r
Considerate anche che un componente del gruppo potrebbe arrivare in
ritardo all’appuntamento per la partenza e che potreste avere problemi con
la macchina durante il viaggio. Dunque, a che ora partire?
La probabilità di impiegarci meno di 45 minuti esiste, ma è veramente
limitata; la probabilità di impiegarci 45 minuti è molto alta, ma persino la
probabilità di impiegarci 3 ore non è del tutto nulla. Maggiore è l’incertezza
e maggiore è la coda di distribuzione.
Decidete di considerare l’ipotesi peggiore per la percorrenza
dell’autostrada, aggiungendoci un tempo di sicurezza per eventuali
problemi con le auto (30 min).

p
r
L
o L i
b i n
a n e
b e a
i a
l
d
i m i
t e
à d s
i i T
Fig. 2
P a 3
c e
r n 0
u m
o %
A questo punto risulta che l’appuntamentoa per la partenza dovrà r pessere
b
fissato almeno due ore prima del ritrovo all’aeroporto, cioè alle 8,30.
e o
a
z
Conoscete bene i componenti b del gruppo e le caratteristiche personali di
z d
ognuno, quindi decidetei di differenziare l’ora dell’appuntamento per
a i
ognuno in base alla sua propensione
l al ritardo.
i
Ce la farete così ad arrivare in tempo…?! p
t
Come si può notare dall’esempio,
à il tempo di percorrenza è
e stato
maggiorato ben più del 30%, r
= margine di sicurezza aggiunto per proteggersi
dagli imprevisti, ma addirittura
5 c
risulta aumentato del 150% (2 ore contro i
45 min della prima stima).0 o
r
% cosa voglia dire per un manager “proteggere
Possiamo ora immaginarci le
r
previsioni” dalla variabilità che si incontra abitualmente.
e
Come nell’esempio, così anche per la stima dei tempi progettuali naccade
che ci sarà circa il 50% di probabilità di terminare prima del tempo previsto
z
o esattamente in quel tempo; di conseguenza non è questa la previsione a
che sarà considerata ma essa sarà maggiorata di un tempo di “protezione”
e si sposterà a destra della mediana, di solito verso l’80 o il 90%. Ciò
significa che ogni passo di sviluppo è imbottito di un margine di sicurezza
che fa lievitare enormemente i tempi di dell’intera attività.

Project Management – Seminario Introduttivo pag 33 di 56


LA VARIABILITÀ DI COMPORTAMENTO
Oltre alla variabilità naturale esiste anche la variabilità del comportamento
delle risorse che sono coinvolte nello sviluppo delle attività.
Studi condotti da scienziati e business leader, quali E.M.Goldratt, ma
anche l’ esperienza diretta che ognuno di noi matura, ci permettono di
affermare che esistono tre modi di “perdere tempo”, cioè di sprecare il
nostro amato margine di sicurezza:
 la sindrome dello studente;
 l’adozione del multitasking;
 la dipendenza tra fasi del progetto.
La sindrome dello studente è intuitivamente riconducibile al
comportamento tipico degli studenti. Quando ad un allievo viene chiesto di
svolgere un compito entro una certa data sufficientemente distante, egli,
forte del tempo che ha a disposizione, rinvia l’impegno fino all’ultimo
momento disponibile. Quando poi (finalmente!) si siede per affrontarlo, si
trova inevitabilmente a dover fronteggiare una seria di imprevisti (perché
“Murphy esiste!), che richiedono più del tempo che è ancora a sua
disposizione. Lo studente quindi consegna il compito in ritardo o lo svolge
approssimativamente, giungendo a compromessi sul contenuto dello
stesso.
Lo stesso processo si ritrova nei progetti. Chiediamo ad una risorsa di
svolgere un determinato compito entro una data assegnata e la risorsa non
si impegna subito su quell’attività….. tanto c’è tempo! Purtroppo, proprio
come nel caso degli studenti, quando si stabilisce che è giunto il momento
di dedicarsi a quella attività, non è rimasto abbastanza tempo per
fronteggiare gli imprevisti e il progetto subisce un ritardo.
Capita inoltre che una risorsa pressata da più fronti, cioè alla quale è
richiesto di lavorare su più progetti, nel tentativo di non deludere nessuno
cada nella trappola del multitasking. La risorsa anziché lavorare
sequenzialmente sui progetti a lei assegnati, salta da un progetto all’altro
dedicando ad ognuno una frazione del proprio tempo. Apparentemente
questo sembra un comportamento molto fruttuoso: si portano avanti più
lavori allo stesso tempo, ma a conti fatti, si dimostra essere assai deleterio.
Vediamo un semplice esempio per chiarire meglio il concetto e mostrare la
validità di quanto affermato.
Supponiamo che una persona debba svolgere tre fasi A,B,C ognuna delle
quali richiede 10 giorni di lavoro. Se queste vengono eseguite
sequenzialmente, il tempo di sviluppo di ogni passo è pari a 10 giorni.
(figura 3)

A B C

T T T
Figura 3 e e e
m m m
p p p
o o o

p p p
e e e
r r r

A B C
Project Management – Seminario Introduttivo = = = pag 34 di 56
Se invece la risorsa decide di lavorare solo cinque giorni su ogni progetto e
poi di passare al successivo, il tempo di sviluppo di ogni passo diventa di
20 giorni (figura 4).

A B C A B C
T
e
m T
p e
o m
T
p
e
p o
Figura 4 e
m
p
r p
o
e
A r
L’ultimo nemico è rappresentato dalla dipendenza
= tra fasi delpe progetto. In
B
effetti, se una fase accumula ritardo a causa
2 di una
=
serie di rimprevisti, è
inevitabile che questo si ripercuota anche
0 sulla fase successiva;
C se poi
2
anche questa è in ritardo, la fase successiva subirà0 un ritardo
= pari alla
somma dei ritardi delle fasi precedenti. In pratica, i ritardi si 2accumulano
rischiando di provocare uno slittamento della data di conclusione. 0

Purtroppo, questo stesso fenomeno non si registra, generalmente, in


presenza di fine anticipata di una fase. Se cioè una postazione termina il
proprio lavoro prima del previsto, la postazione successiva spesso non può
sfruttare questo vantaggio ed iniziare prima perché è impegnata altrove; in
questo modo il vantaggio acquisito viene perso.

PROTEGGERSI DALLA VARIABILITÀ


La vita di un progetto si caratterizza nel fatto che ha un inizio ed una fine, e
passa attraverso alcune fasi caratteristiche (ad esempio ideazione,
definizione delle caratteristiche e delle specifiche, impostazione,
costruzione e/o installazione) solo di rado separate nettamente le une dalle
altre. Il compito del manager di progetto è quello di definire il contenuto di
tali fasi e di fare in modo, per ogni fase, di poter pianificare, controllare e
prevedere per poter decidere.
Il carattere del progetto cambia ad ogni fase: per esempio, il tasso di
utilizzo delle risorse e il conseguente impegno di costi, ecc. Più in
generale, le risorse impiegate nel progetto variano di fase in fase, e tutto
questo chiaramente comporta la necessità di pianificazione e di
coordinamento.
La pianificazione nasce dalla necessità di gestire le attività, da svolgere per
la realizzazione di un determinato progetto, in maniera più dettagliata e
quindi meglio prevedibile e controllabile.

Project Management – Seminario Introduttivo pag 35 di 56


Nella maggioranza dei casi la metodologia di pianificazione si sviluppa
utilizzando strumenti conosciuti dai manager di progetto, come il PERT e il
GANTT.
Essi sono strumenti che permettono di dividere il progetto in fasi di attività,
rendendolo così più “visibile” e controllabile. Ciò consente di assegnare le
attività da svolgere a responsabilità precise, di pianificare sia le sequenze
logiche di attuazione del lavoro che le quantità da produrre e le risorse
necessarie, di programmare i tempi, di preventivare le risorse ed i costi, di
determinare l’avanzamento fisico e di consuntivare le risorse ed i costi
utilizzati al fine di stimare quantità, costi e tempi a completamento; tutto
questo in modo integrato e strutturato.

Abbiamo visto che la variabilità, con cui siamo costretti a fare i conti
costantemente, è un’acerrima nemica della pianificazione. I manager di
progetto devono assolutamente proteggersi da essa, se vogliono portare a
termine le attività nel rispetto degli obiettivi dati.
Ricordiamo ancora che le variabili tempi e costi sono strettamente legate e
dipendenti, quindi ci riferiremo ad una o all’altra indifferentemente.
Rispettare gli obiettivi dati significa perciò rispettare le previsioni di tempo e
di costo.
Ma come si fa a proteggersi dalla variabilità?
La prima tentazione, come abbiamo visto negli esempi sulla variabilità, è
quella di aggiungere protezione alle previsioni per evitare di accettare
azioni correttive di compromesso quando veniamo sorpresi dall’imprevisto.

Project Management – Seminario Introduttivo pag 36 di 56


Il meccanismo mediante il quale viene inserito il margine di sicurezza
l’abbiamo visto con il grafico di distribuzione della probabilità. Questo
margine viene inserito a quasi tutti i livelli di un progetto, infatti:
 chiunque sia chiamato a fare una stima del tempo necessario a
completare un passo, dichiarerà un tempo effettivo, maggiorato di
una quantità tale che lo assicuri di portare a termine il proprio
compito entro la data prevista (responsabile di una fase di
progetto);
 ogni livello di gestione cerca di tutelarsi aggiungendo altro margine
di sicurezza (responsabile di una sezione di progetto, per esempio
l’ideazione o la realizzazione);
 chi fa le stime, aumenta le previsioni per prevenire gli effetti di
eventuali tagli richiesti dall’amministrazione (il manager di progetto).
Tali meccanismi si innescano quindi per la tutela dall’incertezza ma anche
perchè vogliamo soddisfare le aspettative del cliente quali il rispetto dei
termini di consegna.

Sul grafico di distribuzione della probabilità (Fig. 2) abbiamo visto che


spostare le previsioni verso la destra della mediana significa impattare
notevolmente sui termini di consegna. In questo modo, la previsione nel
suo complesso richiede tempi di realizzazione lunghissimi, decisamente
superiori a quelli effettivamente necessari.

Essere un buon manager significa soddisfare le aspettative di chi si affida


a noi per la gestione efficiente dei progetti.
I nostri “committenti” sono sia interni all’organizzazione (la proprietà) che
esterni (il cliente che beneficia del risultato).
Da una parte i clienti richiedono tempi di realizzazione brevi e costi
contenuti; dall’altra se si considera il tempo che intercorre tra l’investimento
effettuato dall’organizzazione e il momento in cui ci si aspetta che i frutti di
tale investimento coprano l’investimento stesso, possiamo pensare che

Project Management – Seminario Introduttivo pag 37 di 56


anche l’organizzazione investitrice abbia un forte interesse a tempi di
sviluppo brevi e costi contenuti.

Per soddisfare queste necessità, il manager di progetto sarà portato a non


spostarsi di tanto da una stima ragionevole, non aggiungendo protezione
alle fasi di progetto…

…che, come abbiamo visto, allungano notevolmente i tempi di sviluppo


deludendo il cliente e gli investitori.

Project Management – Seminario Introduttivo pag 38 di 56


Il responsabile di progetto si trova in un vero e proprio conflitto
rappresentato dalle posizioni di decisione:

Come si può scegliere tra le due posizioni assicurandosi che la soluzione


porterà ad una gestione efficiente, oltre che efficace, del progetto?

LA FOCALIZZAZIONE
Elemento fondamentale per una buona gestione è la capacità di focalizzare
i problemi che impattano di più sul risultato finale.
Un manager che non sappia focalizzare non riesce a controllare né costi
né tempi né il risultato. Il problema, però, è che in un progetto intervengono
molti fattori e il manager potrebbe trovarsi in difficoltà nel decidere su quale
concentrare la propria attenzione; oppure potrebbe cercare di tenere tutto
costantemente sotto controllo, ottenendo purtroppo l’effetto contrario a
causa dell’umana incapacità di focalizzare non più di pochi elementi
contemporaneamente.
Cosa deve fare quindi il manager? Come scegliere i pochi elementi
importanti su cui concentrare l’attenzione e il controllo?
La chiave sta nel riconoscere il ruolo dei vincoli del sistema. Il vincolo di un
sistema non è niente di diverso da ciò che chiunque riconosce in queste
parole: tutto ciò che limita un sistema dal raggiungere performance più
elevate verso il raggiungimento del proprio obiettivo.
Possiamo immaginare il sistema di attività come una catena. Che cosa
determina la forza dell’intera catena?
Un esempio chiarirà meglio il concetto.

Project Management – Seminario Introduttivo pag 39 di 56


Una fila di soldati cammina per tracciare un sentiero che sarà utilizzato poi
da altri soldati per raggiungere e installare il nuovo campo.

Il sentiero sarà pronto solo quando tutti i soldati della fila saranno passati
dallo stesso punto, quindi il tempo necessario alla preparazione di ogni
tratto sarà quello che intercorre tra il passaggio del primo soldato in quel
tratto e il passaggio dell’ultimo soldato nello stesso punto (tempo di
sviluppo).
Quando i soldati iniziano a camminare sono in fila indiana ben compatti,
ma dopo un po’ si ritrovano sparpagliati. La distanza tra il primo e l’ultimo è
notevolmente aumentata. Se l’ufficiale ferma la truppa, la ricompatta e la fa
ripartire, parte del “tempo di risultato” è andato perso.
Se vogliamo diminuire il tempo di sviluppo, diremmo che i soldati
dovrebbero andare più veloci. Ma ci concentriamo sull’efficienza di ogni
soldato o vogliamo che la truppa nel suo insieme si muova più
velocemente?
La velocità a cui si muove la truppa nel suo insieme non è data dalla
velocità di ogni soldato ma è dettata dalla velocità del più lento (vincolo o
collo di bottiglia). Come facciamo a far si che la truppa non si disperda
(tenendo limitato il tempo di sviluppo)?

Leghiamo il primo soldato al soldato più lento, il collo di bottiglia. In questo


modo tutta la truppa proseguirà al ritmo dettato dal vincolo e non ci sarà
dispersione, se non nei pressi del vincolo stesso. È li che focalizzeremo la
nostra attenzione!
La forza della catena è data infatti dall’anello più debole. Se questo si
spezza, per quanto gli altri anelli siano robusti, forti, la forza complessiva
della catena crolla a zero. Appare quindi evidente che, per evitare che la
catena si spezzi, è necessario identificare e gestire al meglio questi
elementi.

Project Management – Seminario Introduttivo pag 40 di 56


Lo stesso percorso deve essere seguito nei progetti. In quest’ambito, il
problema risiede proprio nel capire quale fattore, tra i vari che influenzano il
risultato del nostro progetto, sia effettivamente responsabile delle
prestazioni dell’intero sistema; si tratta cioè di individuare l’elemento
vincolante, dal quale dipende la buona riuscita o il fallimento del progetto.

Torniamo per un attimo al conflitto che è stato individuato in precedenza.


Esso è sostenuto dalla convinzione che tutte le fasi di progetto abbiano
bisogno di protezione.

Abbiamo appena dimostrato però che la performance del sistema non è


data dalla prestazione di ogni singolo passo, o fase, ma dalla performance
del vincolo.

Focalizziamo dunque l’attenzione su questo elemento che determina la


prestazione di tutto il progetto. La protezione sarà aggiunta solo alle attività
che fanno parte del collo di bottiglia.
In questo modo l’assunto sollevato per cui si ritiene necessario che tutte le
fasi di progetto abbiano bisogno di protezione, viene invalidato e il conflitto
si risolve.

Project Management – Seminario Introduttivo pag 41 di 56


I PASSI PER GESTIRE BENE
Individuata la necessità di focalizzare l’attenzione sul vincolo, riducendo
così le fasi su cui porre l’attenzione, vediamo ora in dettaglio i passi che il
project manager deve seguire al fine di gestire bene i progetti.

IDENTIFICARE IL VINCOLO DEL SISTEMA


Il primo passo consiste nell’identificare il vincolo del sistema.
All’interno di un progetto, costituito come detto da una sequenza di azioni
tra loro interconnesse in modo diverso, tale vincolo è identificabile nelle
modalità di utilizzo delle risorse sul “percorso critico”.
Ma cos’è il “percorso critico”? Esso è quella successione di azioni tra loro
direttamente collegate dalla quale dipende la durata minima del progetto o,
in altre parole, la più lunga, in termini di tempo, concatenazione di passi
dipendenti. Generalmente, viene identificato utilizzando le carte PERT.
Facciamo un esempio.
Supponiamo di dover tracciare la carta PERT di un progetto relativo alla
costruzione e alla messa in opera di un impianto. Per non complicarci la
vita, prendiamo in considerazione solo poche “macrofasi”: costruzione
dell’edificio, stipula dei contratti con i fornitori, costruzione dei macchinari,
installazione dei macchinari, messa in opera. , ,Tracciamo ora il grafo
(Figura 1).

Project Management – Seminario Introduttivo pag 42 di 56


Figura 2: Carta Gantt

In base alla definizione che abbiamo dato di percorso critico, possiamo


affermare che, nel nostro esempio, esso è costituito dal cammino
attraverso le fasi della costruzione dell’edificio, della sua messa “in opera”
e dell’installazione delle macchine al suo interno (per un totale di
centocinquanta giorni); le restanti fasi (stipulare contratti con i fornitori e
costruzione macchinari) non fanno parte del percorso critico. Evidenziamo
il percorso critico sulla carta Gantt con un tratto più marcato.

Ma perché diciamo che il cammino critico costituisce il vincolo del sistema?


Perché esso detta la data di completamento e il ritmo di avanzamento
dell’intero progetto.
Guardando l’esempio, infatti, appare evidente che qualsiasi ritardo sul
percorso critico si traduce in un ritardo del progetto, con la conseguente
crescita di tempi e costi di progetto. Al contrario, un eventuale ritardo in
una delle fasi esterne al percorso critico può non incidere sul risultato
finale.
Sulla scorta di questa considerazione, appare evidente la necessità di
gestire opportunamente le risorse che operano sul percorso critico, da cui
l’esigenza di focalizzare l’attenzione su questo cammino.

Project Management – Seminario Introduttivo pag 43 di 56


SFRUTTARE IL VINCOLO E SUBORDINARE AD ESSO TUTTE LE
ATTIVITÀ
Il secondo passo da compiere consiste nello sfruttare il vincolo: poiché
esso ha capacità limitata, è strettamente necessario che sia impegnato,
“strizzandone” la massima prestazione possibile. Come detto, infatti, il
tempo perso in inattività, dovute ad esempio ad inefficienze delle fasi o allo
start-up di fase, non può più essere recuperato e si traduce in un ritardo
nel completamento del progetto.

A questo punto è necessario subordinare tutte le attività al vincolo e alla


sua capacità. Se possiamo ottenere dal collo di bottiglia una prestazione
limitata, inferiore a quella che potremmo ottenere dalle risorse non-collo di
bottiglia, non c’è ragione di obbligare i non-colli di bottiglia a sfruttare a
pieno la propria capacità. Come abbiamo visto, la performance del sistema
non è data dalle prestazioni di ogni singolo passo, o fase, ma dalla
performance del vincolo; di conseguenza, l’adozione di una politica
difforme da quella proposta porterebbe solo ad ammassare scorte di lavoro
davanti al collo di bottiglia, senza accelerare l’avanzamento del progetto.
Facciamo di nuovo un esempio per chiarire meglio questi concetti.
Questa volta ci trasferiamo nella sede di una banca. Nell’ambito di una
campagna pubblicitaria, si è deciso di spedire a tutti i clienti (qualche
migliaio) una brochure che illustra i nuovi prodotti bancari: assicurazione
sulla vita, fondi di investimento, mutui, ecc..
Il Direttore chiede alla segretaria di imbustare e spedire il materiale e, vista
la mole di lavoro, le consiglia di farsi aiutare anche dalle assistenti dei due
vicedirettori. Prima di congedare la ragazza e di partire per una convention,
le raccomanda di non perdere tempo in chiacchiere con le colleghe perché
il lavoro da svolgere è tanto e, poiché il materiale deve essere spedito
entro una settimana, a conti fatti devono essere preparate almeno 800
buste al giorno.
Quando si riuniscono, le ragazze scoprono che il lavoro è anche più
pesante del previsto perché la tipografia non ha piegato le brochure, quindi
sono tutte da piegare a mano, e, come se questo non bastasse, sono finite
le etichette per gli indirizzi e il fornitore è chiuso per ferie per almeno
quindici giorni….
Le ragazze si guardano affrante, poi decidono di spartirsi i compiti: una
piega e imbusta le brochure; l’altra, l’unica con una bella grafia, scrive gli
indirizzi sulle buste e la terza controlla gli indirizzi, li spunta da un elenco e
mette il francobollo.
Dopo tre giorni, il Direttore torna in ufficio e passa a controllare lo stato di
avanzamento dei lavori, sicuro di trovare le ragazze “a metà dell’opera”.
Controlla le spunte sull’elenco dei clienti e scopre che la brochure è stata
spedita solo a un migliaio di clienti.

Project Management – Seminario Introduttivo pag 44 di 56


Il Direttore raggiunge le ragazze per chiedere ragione del ritardo e giunto
dalla segretaria addetta al controllo degli indirizzi e all’affrancatura scopre
che sulla sua scrivania ci sono solo un paio di dozzine di buste. Il Direttore
le chiede ragione della lentezza del flusso in uscita e le ricorda che tutti
devono dare il massimo..... e, a quanto vede, lei non si sta comportando in
tal senso!
La ragazza si scusa affermando che non è colpa sua, ella sarebbe più
veloce, ma il materiale le arriva ad un ritmo inferiore al suo ritmo di lavoro e
lei si adegua!
Il Direttore, scettico e ancora convinto che la segretaria abbia mentito,
raggiunge la postazione delle altre due ragazze e si trova di fronte a
questa situazione: la ragazza che imbusta è immersa nel lavoro e il
materiale viene preparato a velocità molto elevata, tanto che sul tavolo è
già pronta una montagna di buste; la “scribacchina” è sommersa dalle
buste ancora da compilare. Il Direttore sgrida quest’ultima convinto che
una lavata di capo la sproni ad essere più efficiente. Ad un controllo
successivo, però, si accorge che la situazione non è cambiata e capisce
che sta già “strizzando” la massima capacità della sua segretaria e che è
inutile obbligare le colleghe a lavorare al massimo della propria efficienza
perché questo non porta un miglioramento delle prestazioni del processo. Il
direttore accetta quindi che il ritmo di lavoro sia pari a quello del vincolo e
decide di ridurre il numero di risorse impegnate, ridistribuendo i carichi di
lavoro come segue: la ragazza che controlla gli indirizzi e affranca le buste
viene sollevata dall’incarico e ricollocata al proprio posto di segretaria a
tempo pieno e i suoi compiti vengono riversati sulla collega che piega e
imbusta le brochure. Così facendo, il ritmo di lavoro delle segretarie è
pressoché uguale e il lavoro procede in modo costante, senza
sovraccarichi per le risorse e/o tempi morti.

PROTEGGERE IL VINCOLO
L’ultimo passo consiste nel proteggere il vincolo.
Poiché il vincolo è l’elemento debole della catena, quello sul quale cioè non
possiamo permetterci di perdere tempo, appare chiaro che è necessario
adottare degli strumenti che ci permettano di proteggere il vincolo stesso,
cioè di gestire opportunamente le risorse che operano sul percorso critico.

L’evidenza quotidiana ci mostra che spesso la nostra soluzione di


aggiungere margine di sicurezza si rivela inefficace. Accade infatti che,
nonostante questo accorgimento, si sforino le previsioni di tempo e quindi il
budget di progetto.
Le cause di tale fenomeno sono da ricercarsi, come già stabilito, nella
variabilità naturale, cioè l’imprevedibilità degli eventi, e nella variabilità di
comportamento delle persone che, più o meno consapevolmente,
adottano atteggiamenti che portano a sprecare il margine di sicurezza

Project Management – Seminario Introduttivo pag 45 di 56


inserito nelle previsioni; è questo il caso della sindrome dello studente, del
multitasking e della dipendenza tra fasi del progetto.

Affrontiamo quindi individualmente i diversi fattori che causano ritardi nei


progetti e cerchiamo per ognuno di essi una soluzione, uno strumento di
protezione che ci permetta di contrastarne gli effetti.

GLI STRUMENTI PER GESTIRE IL VINCOLO


La protezione del progetto
Come abbiamo già avuto modo di constatare, la sindrome dello studente
consiste nel procrastinare l’inizio di un compito fino all’ultimo momento
possibile.
Facciamo un esempio. Supponiamo di chiedere ad una risorsa di stimare il
tempo necessario a svolgere un lavoro; la previsione fornita dalla risorsa,
ovviamente, sarà elaborata tenendo conto del tempo effettivamente
necessario, aumentato di una quota tale da avere la certezza quasi
assoluta di terminare il lavoro entro la data prevista.
Assegnamo ora lo stesso compito alla risorsa e chiediamole di terminarlo
entro il tempo indicato dalla risorsa stessa.
Scatta la sindrome dello studente.
Il nostro collaboratore, infatti, tanto più se esperto, non si impegnerà
immediatamente nello svolgimento del compito, ma ne rimanderà l’inizio
poiché consapevole del fatto che “tanto c’è tempo”: ha inserito un margine
di sicurezza tale da essere praticamente certo di farcela….
Come abbiamo già visto, però, noi sappiamo con altrettanta sicurezza,
poiché l’evidenza quotidiana ce lo mostra, che non ce la farà e consegnerà
in ritardo il lavoro.

Tale processo, ripetuto per tutte le fasi di un progetto, determina


l’inevitabile sforamento delle previsioni di tempo e di budget.

La scelta di aggiungere margine di sicurezza ad ogni singola fase di un


progetto si dimostra quindi controproducente; concedere alle persone un
tempo superiore al necessario per l’esecuzione di un compito fa scattare
atteggiamenti, più o meno consapevoli, che, come detto, si ripercuotono
negativamente sull’avanzamento del progetto.
Per contrastare questo fenomeno, immaginiamo di eliminare il margine di
sicurezza insito in ogni fase del progetto, inducendo così le risorse a
svolgere il lavoro nel tempo strettamente necessario. Se, infatti, ogni
risorsa è “posta sotto pressione”, è chiamata cioè a svolgere il proprio
lavoro in un tempo molto limitato, non potrà procrastinare l’inizio

Project Management – Seminario Introduttivo pag 46 di 56


dell’attività, evitando così di ridursi all’ultimo minuto e di rischiare di
ritardare l’inizio della fase successiva.

Un altro comportamento tipico delle risorse, e altrettanto deleterio, consiste


nell’adozione del multitasking: la persona lavora su più fasi o progetti
contemporaneamente, saltando da uno all’altro, convinta così di rendere di
più. In effetti, in questo modo si ha la possibilità di far avanzare più progetti
pressoché simultaneamente, ma i tempi di esecuzione di ognuno si
allungano notevolmente a seguito della moltiplicazione dei tempi di start-
up.

L’eliminazione del margine di sicurezza contrasta anche il fenomeno del


multitasking. Se la risorsa ha a disposizione solo il tempo strettamente
necessario per l’esecuzione del compito, non può distogliere la propria
attenzione da esso e dedicare tempo ad altre attività.

Riassumendo, possiamo affermare che l’adozione di questa soluzione


permette di ridurre drasticamente il tempo di realizzazione dell’intero
progetto, limitandolo a quanto strettamente necessario, e,
contemporaneamente, di stimolare le persone ad operare al massimo della
propria efficienza.

Ovviamente, non si può trascurare l’esistenza dell’incertezza imputabile a


fenomeni indipendenti dalle risorse, quali ritardi di approvvigionamenti o
imprevisti in fase di realizzazione. Non possiamo cioè permetterci di
dimenticare che “Murphy esiste” e che può colpire in qualsiasi momento e
ripetutamente.
Come possiamo tutelarci contro gli imprevisti se abbiamo eliminato tutto il
margine di sicurezza?
Come possiamo proteggere la data di completamento del progetto?
Per risolvere questo problema, utilizziamo uno strumento che ci permetta
di proteggere la data di completamento del progetto.
Questo strumento di protezione consiste in una quantità di tempo collocata
al termine del percorso critico e costruita partendo dalla durata del
percorso critico stesso.
In sostanza, prevediamo che ogni fase del progetto sia elaborata
esattamente nel tempo strettamente necessario (pari al tempo mediamente
impiegato per quel tipo di lavorazione) e raccogliamo il margine di
sicurezza “tolto” da ogni passo in coda al percorso critico ( Figure 1 e 2).

Project Management – Seminario Introduttivo pag 47 di 56


Tale protezione permette di assorbire eventuali ritardi occorsi in una o più
fasi del progetto, proteggendone così la data prevista di completamento.
Per dimensionare questo buffer si possono utilizzare complicate formule
matematiche oppure una “regola comune” molto semplice: aggiungere in
coda al progetto un tempo pari alla metà della durata del percorso critico.

Facciamo un esempio.

Supponiamo di dover gestire un progetto, il cui percorso critico sia


costituito da 4 fasi: A,B,C,D.
Il nostro comportamento abituale è così descrivibile. Per poter pianificare lo
svolgimento del lavoro e prevedere una data di consegna al cliente,
chiediamo agli esecutori di ogni fase di fare una stima del tempo
necessario e otteniamo, ad esempio, questo risultato:

Nel complesso, sono necessari 21 gg (9gg + 5 gg + 3gg + 4gg). Poiché


però siamo persone avverse al rischio e non vogliamo fare brutte figure
con i clienti consegnando il lavoro in ritardo, aggiungiamo il nostro margine
di sicurezza, ottenendo una previsione che ci sembra plausibile e che ci dà
l’illusione di avere la certezza di completare il progetto in tempo.
Comunichiamo così al cliente di aver bisogno di 28 gg.
Supponiamo ora di adottare lo strumento di protezione descritto.
Noi sappiamo che i responsabili di ogni fase dichiarano, generalmente, un
tempo superiore a quello effettivamente necessario, al fine di tutelarsi
contro eventuali imprevisti; chiediamo ora loro di fornirci l’impegno medio,
privo di margine di sicurezza. Questo, per ipotesi, è il risultato ottenuto:

Project Management – Seminario Introduttivo pag 48 di 56


Il percorso critico nel complesso richiede quindi 12 giorni.
Non possiamo però promettere al cliente che consegneremo il progetto in
12 giorni, dobbiamo fornire una data attendibile di fine lavoro che ci
permetta di tutelarci contro l’incertezza; dobbiamo cioè inserire una
protezione la cui entità, in base alla regola comune citata sopra, è pari alla
metà del tempo richiesto dal percorso critico.
La protezione è pari quindi a 6 giorni e noi possiamo dire al cliente che
saremo in grado di consegnare il lavoro in soli 18 giorni contro i 28 del
caso precedente con un risparmio netto di 10 giorni.
Alimentare il percorso critico
Finora abbiamo visto soluzioni che ci permettono di evitare ritardi imputabili
a problemi occorsi nelle fasi appartenenti al percorso critico; abbiamo in
sostanza trascurato tutti quei passi che, pur facendo parte del progetto e
pur essendo funzionali al raggiungimento dell’obiettivo finale, non ne
costituiscono un aspetto critico.
Cosa succederebbe però se si verificassero dei problemi su uno, o più, dei
percorsi “non critici” che alimentano il cammino critico? Inevitabilmente, il
ritardo su un percorso non critico si ripercuoterebbe sul vincolo che
vogliamo proteggere (cioè sul percorso critico), causando degli scompensi
che potrebbero tradursi in un superamento della data di completamento
prevista.
Per evitare di incorrere in questo problema, il project manager può
collocare, in corrispondenza delle fasi in cui i percorsi non critici si
innestano sul percorso critico, un buffer di tempo creato secondo lo stesso
criterio del buffer di progetto. (Figura 3)

Il tempo destinato a questo strumento di protezione viene quindi ricavato


eliminando i margini di scurezza dalle fasi dei percorsi non critici e
collocando un “pacchetto” di tempo pari alla metà del percorso non critico
in coda al percorso stesso, a monte dell’innesto.

Project Management – Seminario Introduttivo pag 49 di 56


Allertare la risorsa
Consideriamo ora l’ultimo dei tre fattori che avevamo identificato come
responsabili del ritardo dei progetti: la dipendenza tra fasi.
La dipendenza tra fasi fa sì che il ritardo accumulato da una fase a causa
di una serie di imprevisti, si ripercuota inevitabilmente anche sulla fase
successiva, propagandosi così fino alla fine dell’intero progetto.
Purtroppo, questo stesso principio non vale in caso di fine anticipata.
Supponiamo infatti che una risorsa termini il proprio lavoro prima del
previsto, facendo acquisire al progetto del vantaggio temporale; a causa
della schedulazione del lavoro, spesso la risorsa successiva non può
iniziare ad operare sul progetto perché è impegnata in un’altra attività e il
progetto è costretto ad arrestare il proprio avanzamento, perdendo il
vantaggio acquisito e, quel che è peggio, impedendo il recupero di un
eventuale ritardo accumulato in altre fasi.

Per contrastare questo fenomeno di accumulo dei ritardi, possiamo


eliminare dalla pianificazione le date di inizio di ogni singola fase della
catena critica e gestire il tempo di elaborazione di ogni passo tramite un
sistema di avvisi volti ad allertare le risorse dell’imminente arrivo del
materiale/documento/informazione da processare.

Anche in questo caso, facciamo un esempio per chiarire meglio il concetto.


Ipotizziamo che il progetto giunga alla risorsa A e che questa cominci a
processarlo. La risorsa successiva B, che a causa dell’eliminazione della
schedulazione temporale non sa ancora esattamente quando il lavoro
giungerà alla sua postazione, viene allertata e avvisata che entro un
determinato lasso di tempo dovrà essere pronta ad operare sulla fase.
A mano a mano che si avvicina il momento in cui B dovrà iniziare a
lavorare al progetto, la risorsa riceve ulteriori avvisi che confermano o
smentiscono l’arrivo del materiale.
Questo procedimento fa in modo che, avvisata per tempo, B sia pronta a
processare il materiale esattamente nell’istante in cui questo la raggiunge,
evitando così che l’intero progetto sia bloccato a causa di un’eventuale
indisponibilità della risorsa.
L’anticipo con il quale viene allertata la risorsa può essere un tempo fisso
(ad esempio 2 settimane) oppure può essere pari al tempo impiegato dalla
risorsa precedente a quella allertata per portare a termine il proprio lavoro
(quando A inizia a svolgere il proprio compito, B viene allertata).

Project Management – Seminario Introduttivo pag 50 di 56


LA “CATENA CRITICA”
Gli strumenti di protezione sin qui illustrati permettono al project manager
di tutelarsi contro la variabilità naturale e di comportamento.
Esiste tuttavia un ulteriore fattore che può causare ritardo nel
completamento di un progetto: il conflitto di risorse, situazione che si
manifesta soprattutto in caso di elaborazione simultanea di più progetti, ma
che non è estranea alle realtà che sviluppano progetti in successione.
La difficoltà nasce quando la disponibilità di risorse per l’esecuzione di un
determinato passo è limitata e la fase in questione è presente in più
percorsi contemporaneamente.
Per chiarire meglio il concetto ci avvaliamo di un semplice esempio.
Ipotizziamo di dover gestire un progetto che si sviluppa su un percorso
ciritico e due percorsi non critici. Su tutti e tre i cammini individuati deve
operare la risorsa “X”, che ha capacità limitata e alla quale viene chiesto di
lavorare contemporaneamente sui percorsi non critici 1 e 2 (Figura 4).

X F
B
1 B
X u
f
f
e
X F r
B d
2 i
Percorso critico p
r
FB1 FB del percorso non critico 1 o
g
FB2 FB del percorso non critico 2 e
t
t
Figura 4 – Progetto con conflitto di risorsa o

Come risulta dal grafico di figura 4, per un certo periodo la risorsa “X” è
sovraccarica.
A causa della capacità limitata, “X” non può soddisfare le esigenze di tutti
e, poiché non riesce ad evadere la mole il lavoro assegnata, accumula un
ritardo che, se non assorbito dai feeding buffer FB1 e FB2, si ripercuote
sull’intero progetto.
Come possiamo gestire questa situazione?
Ripercorriamo il cammino tracciato precedentemente ed iniziamo
identificando il vincolo.

Project Management – Seminario Introduttivo pag 51 di 56


Potrebbe venire la tentazione di individuare nuovamente il vincolo nel
percorso critico, ma la necessità emersa di gestire un conflitto di risorse
annulla questa possibilità. Il percorso critico, infatti, identifica “la più lunga
catena di passi dipendenti”, più lunga in termini di tempo, trascurando le
dipendenze dalle risorse; dipendenze che, invece, in questo caso
costituiscono evidentemente il punto cruciale.
Se il project manager continuasse a focalizzare la propria attenzione sul
solo percorso critico, si troverebbe a dover affrontare una situazione molto
difficile in quanto rapidamente mutevole: ogni qualvolta entrasse in gioco
la risorsa “X” il cammino critico verrebbe modificato per adeguarlo alle
nuove tempistiche. Cercare di proteggere il percorso critico, quindi, si
tradurrebbe in uno sforzo enorme ed inutile perché in un panorama tanto
mutevole il project leader non riuscirebbe a focalizzare.
Il project manager deve invece focalizzare l’ attenzione su un percorso che
tenga conto sia delle dipendenze tra fasi che delle dipendenze dalle
risorse; tale percorso è identificato con l’espressione Catena Critica .
In base alla definizione, ci aspettiamo che la catena critica sia il percorso
che passa attraverso le diverse fasi che “X” deve svolgere; che sia, cioè,
quel cammino che tiene conto anche della scarsità della risorsa “X” e del
conflitto in cui essa si trova.
Se questo è vero, però, ci poniamo subito una domanda: come fa il project
manager a sapere se “X” deve svolgere prima la fase sul percorso 1 o
prima quella sul percorso 2?
Il primo passo per rispondere a questa domanda consiste nel valutare
molto lucidamente se uno dei passi che richiede il coinvolgimento della
risorsa “X” non possa essere rimandato ad un altro momento. Accade
spesso, infatti, che una risorsa, convinta di risparmiare tempo, esegua dei
lavori che, seppur attinenti a quelli richiesti dal percorso/catena critica, non
sono rilevanti per il completamento del progetto e possono essere quindi
rimandati a periodi in cui la risorsa scarsa non è sotto pressione.
Una volta rinviati i lavori non immediatamente necessari si può procedere
nella definizione della successione in base alla quale la risorsa “X” deve
essere impiegata. (Figura 5)
In linea di massima, a meno di determinate specifiche o esigenze di
lavorazione particolari, la sequenza non è rilevante. In effetti, fintantoché
l’esecuzione di una fase in seguito ad un’altra comporta un allungamento
dei tempi complessivi di esecuzione del progetto che può essere assorbito
dal buffer di progetto,la data di completamento del lavoro è protetta.
Qualora esigenze particolari richiedessero invece una schedulazione tale
da produrre ritardi che “mangiano” tutta la protezione posta in coda al
progetto, si dovranno adottare strategie opportune: accettare di impiegare
più tempo del previsto oppure, ove possibile, anticipare l’inizio dell’intero
progetto.

Project Management – Seminario Introduttivo pag 52 di 56


L’aver identificato il vincolo nella catena critica anziché nel percorso critico,
infatti, non inficia la validità degli strumenti di protezione già illustrati che
restano pertanto elementi indispensabili nella lotta ai fattori che
determinano ritardo nel completamento dei progetti.
Questo significa che il project manager può e deve avvalersi dello
strumento di allerta delle risorse per evitare l’accumulo di ritardi di fase in
fase e per poter sfruttare al meglio eventuali anticipi sul completamento di
un passo.
Grande importanza riveste inoltre la collocazione dei buffer in coda ai
percorsi non critici.
Abbiamo detto che questi ultimi devono essere posti in corrispondenza dei
punti in cui i percorsi non critici si innestano sul percorso critico.
Poiché il percorso critico è stato “sostituito” dalla catena critica, appare
evidente che queste protezioni andranno collocate in modo da proteggere
la catena critica.

Per chiarire meglio, riprendiamo l’esempio grafico di figura 5 e evidenziamo


su di esso la nuova posizione dei feeding buffer (Figura 6).

Project Management – Seminario Introduttivo pag 53 di 56


Come risulta dal grafico, i feeding buffer sono stati ricollocati, spostandoli
da valle a monte della risorsa “X” , proteggendo così la catena critica.

GESTIRE PIÙ PROGETTI


Se, come spesso accade, lavoriamo su più progetti contemporaneamente,
il problema del conflitto di risorsa diventa quasi inevitabile. Progetti diversi
spesso contemplano fasi uguali e ci si trova ad avere risorse talmente
sovraccariche di lavoro, da non riuscire a smaltirne la mole nei tempi
richiesti. In sostanza, ci si trova a dover gestire un collo di bottiglia che
blocca il regolare flusso di sviluppo dei progetti.
Forti dell’esperienza sin qui maturata, la reazione spontanea porta ad
applicare il concetto di catena critica. Purtroppo l’evidenza empirica mostra
che questo approccio, molto valido nella risoluzione di conflitti di risorsa
all’interno di un singolo progetto, non sortisce gli effetti sperati quando
entrano in gioco più realtà progettuali. Questo limite è facilmente
comprensibile: la soluzione adottata ai fini della gestione dei conflitti nei
singoli progetti consiste, generalmente, nel posporre le fasi non
immediatamente necessarie alla realizzazione dell’intero lavoro. Quando
però si lavora in ambito multi-progettuale, l’applicazione di questa
soluzione cozza contro le aspettative dei molteplici project leader il cui
percorso critico coinvolge il collo di bottiglia: nessuno accetterà mai che la
lavorazione posposta sia quella relativa al suo cammino.
D’altra parte, non è possibile ignorare l’esistenza del collo di bottiglia; se
così avvenisse, infatti, si incorrerebbe in grossi problemi di
sincronizzazione dei progetti e si finirebbe con il perdere tempo proprio sul
vincolo, con una conseguente riduzione del throughput ovvero del numero
di progetti completati.

Project Management – Seminario Introduttivo pag 54 di 56


La strada da percorrere deve quindi essere un’altra.
Se riflettiamo sul concetto di “collo di bottiglia”, ci accorgiamo che esso non
è altro che un vincolo e quindi possiamo applicare la tecnica che ormai
conosciamo; dobbiamo cioè identificare e sfruttare il vincolo e subordinare
ad esso tutte le altre risorse.
Identificare il collo di bottiglia non è difficile. Come abbiamo detto, infatti,
esso è costituito dalla fase comune a più progetti, per l’elaborazione della
quale l’organizzazione dispone di risorse scarse.
Sappiamo anche che sfruttare il vincolo significa ottenere il massimo della
sua prestazione.
Poiché il collo di bottiglia è costituito da una fase progettuale, tale obiettivo
potrà essere raggiunto solo schedulando il lavoro della risorsa in funzione
delle date previste di completamento dei progetti.
Una volta definita questa schedulazione, possiamo gestire i diversi progetti
come fossero entità a sé stanti: eliminiamo i conflitti più grossi, adeguando
lo svolgimento dei progetti alle esigenze del vincolo e subordinandolo alla
capacità del vincolo stesso.
Siamo sicuri, adottando questa strategia, di non trascurare nulla e di non
trovarci in un secondo momento a dover gestire conflitti esplosivi?
Possiamo stare tranquilli perché l’impatto sul progetto derivante dallo
sviluppo simultaneo degli altri progetti viene “automaticamente” tenuto
sotto controllo tramite la schedulazione del lavoro del collo di bottiglia.
Tutto è sotto controllo.
Non resta che proteggere il vincolo, azione che, ora, si rivela relativamente
semplice: utilizziamo un buffer di tempo. Stabilita l’entità del buffer, basta
schedulare tutti i progetti che devono transitare attraverso il collo di bottiglia
perché partano con un anticipo, rispetto alla data prevista, pari al buffer.

CONCLUSIONI
Prima di chiudere questa breve presentazione sulle possibili soluzioni al
problema che affligge i project manager, lo sforamento delle previsioni di
tempi e costi di progetto, facciamo un piccolo riassunto di quanto abbiamo
visto.
Dopo aver identificato il problema e le relative cause e aver constatato che
la soluzione adottata generalmente dai manager di progetto, aggiungere
margine di sicurezza, non fornisce i risultati sperati (i progetti terminano
comunque in ritardo o con un notevole aumento dei costi), abbiamo
cercato di identificare degli strumenti di protezione alternativi al margine di
sicurezza.
Abbiamo adottato un nuovo approccio ai progetti e acquisito la
consapevolezza che è necessario focalizzare l’attenzione solo sul vincolo

Project Management – Seminario Introduttivo pag 55 di 56


del progetto e abbiamo appreso una serie di passi che permettono di
gestire bene:
 Identificare il vincolo del progetto
 Sfruttare il vincolo
 Subordinare tutto al vincolo
 Proteggere il vincolo

Siamo giunti alla conclusione che il vincolo di un progetto è rappresentato


dal percorso critico e che per proteggerlo dobbiamo adottare tre strumenti
opportuni:
 La protezione del progetto: che protegge la data di completamento
del progetto;
 L’allerta della risorsa: permette di evitare il fenomeno della sindrome
dello studente e l’accumulo di ritardi;
 L’alimentazione del percorso critico: evita che il percorso critico
risenta di eventuali problemi occorsi sui percorsi non critici che lo
alimentano

Se, però, ci troviamo di fronte ad un conflitto di risorsa, cioè pochi compiti


sono in lotta per esser processati dalla stessa risorsa, il percorso critico
non è più rappresentativo del vincolo perché esso considera solo i legami
di dipendenza tra le fasi, trascurando quelli di dipendenza dalle risorse.
Di conseguenza, dobbiamo identificare un cammino opportuno, detto
catena critica, che può essere molto diverso dal percorso critico, ma che, in
quanto vincolo, deve essere ugualmente identificato, sfruttato e protetto e
tutto deve essergli subordinato.
Qualora poi dovessimo gestire lo sviluppo di più progetti
contemporaneamente, sarebbe ancora più facile incorrere nel conflitto di
risorsa.
In queste situazioni anche la catena critica non è più sufficiente in quanto
non gestisce gli inevitabili conflitti tra project leader.
La soluzione nasce dal riconoscere nella risorsa critica un collo di bottiglia,
quindi un vincolo, da sfruttare attraverso una opportuna schedulazione del
lavoro; da proteggere tramite un buffer del collo di bottiglia e al quale
subordinare lo sviluppo di tutti i progetti che necessitano di essere
processati dalla risorsa collo di bottiglia.

Project Management – Seminario Introduttivo pag 56 di 56